ORIGINAL: JohnMac
So far as the 14Mz using a windows interface, is this really so much of a problem? So far as I am aware the windows operating system does not interfer with the actual control operating system,
If that were true, then given that the programming changes are made at the windows GUI, none of the changes would ever take effect !
and therefore when you eventually get the blue screen of death, the radio keeps working. OK, when you land you may have to do a soft reset, but so long as the program is backed up nothing is lost, or am I not understanding this right?
Well, here's my take on it, based on many years of writing comm's code.
Regardless of whether they run Windows on one processor and some proprietary OS on the other, the two MUST interact in one way or another in order for your programming changes to take effect.
Let's say you program in a servo reverse command via the Windows GUI ... do you want the servo to actually reverse, or do you just want the GUI to mistakenly say that the reversal has been done ?
If the latter, then you just wasted your time and also your money buying a GUI that does nothing ; if the former, then
the GUI must communicate a change of configuration data to the processor which is responsible for generating the data frames that are to be transmitted. In other words, the data frames that are generated by the non-Windows component are based on data provided to it by the Windows component. Regardless of whether that data is provided by message passing, by shared memory zones with mutex's, or whatever, the fact that one process' output data forms the other's input data means that a malfuntion in one process can trigger unwanted effects in the second process.
Unless Futaba has implemented a moded approach in which you can totally divorce the two - e.g. having 2 modes such as (1) programming, but with no RF output and (2) RF output but no programming, that means that a malfunction in the Windows side while you are flying could translate into a fairly undesirable outcome. Now, the same ability for a UI interface malfunction to affect the RX output does of course exist in prior computer radios which utilize proprietary code for their UI without a moded approach - so the only difference really is whether one considers the proprietary OS to be more or less error prone than Windows, and the answer to that is a very subjective one.
See
http://www.rcuniverse.com/forum/fb.asp?m=2529697 for some of the prior discussions on this topic.
Gordon