Dick Swan, this has become a very interesting conversation, thank you for taking part in it.
I understand the concept you encourage with multi-tasking on RobotC, which is to have separate threads work (at least nearly) independent virtually creating two separate 'processes.' Though sub- dividing a vex robot in to 4 or 5 different processes is something I have a hard time digesting.
Why would one need two threads to monitor the input of two joysticks? (Yes, I understand both would work on their corresponding module of robot) Though one is perfectly fine. I appreciate the modular design of sub-dividing the two drivers in to separate program, but I simply don't think it is necessary. Also, I was unaware of the synchronization objects present in RobotC, I don't see them used very much where they really should be (maybe the learning curve is too steep for some users). With that said: I don't have a problem with spawning two threads for purposes like this - but 20 threads, for gods knows what, is ridiculous.
I didn't mean to suggest that implementing a multi-threading systems was easy - only that it does not need to be as nearly comprehensive as those found on a RTOS that have hundreds of threads running along-side one another with large gaps of priorities between one another at varying degrees of access-levels. On the cortex you might have a couple running in the firmware ( am not sure how many you have running under the hood of robotC) and you shouldn't _need_ neither use that many in user code.
With this you make a good point; and I have no problem with using threads to detour routines that block for an extended period of time.
What I mean to say with the visual studio example is that software based testing is much more convenient, practical, and sufficient in most
cases at this level and thus you shouldn't force the firmware-level debugger on to the user. I do, however, support your implementation of an emulator.