Out of memory?

jeremy__ · Thu Mar 29, 2012 6:53 pm

Dick Swan, this has become a very interesting conversation, thank you for taking part in it.


	Dick Swan wrote: Responding to some of the points in the last post. Almost all VEX and FIRST "tele operation" / "user control" solutions are multi-tasked! Theve have two tasks which are represented by the two human drivers. Notice I used the word "solution" and not "program" to start this paragraph. ROBOTC VM does support synchronization primitives. They were added sometime in the last year.

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.


	Quote: I don't think it is easy to add "proper" multi-tasking to a system that has not been designed from the beginning for multi-tasking. My definition of "proper" multi-tasking includes independent tasks with a scheduler that shares CPU cycles among different runnable tasks; ROBOTC has a round robin scheduler for runnable tasks at same priority level and the highest runnable priority task(s) are always executed. I've analyzed the alternative environments for the platforms supported by ROBOTC and none of them had this functionality. Some of the weaknesses included only single task priority, non-runnable tasks burned CPU cycles, timeslices way too long, or simply didn't support multi-tasking.

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.


	Quote: Regarding "print to PC terminal" screwing up user program. Many users simply implement "print to terminal" commands in every cycle through their main loop which can seriously slow down the main loop. At least one of the alternatives would stall user program execution until "print to PC terminal" passed. The stalling occurred because on interrupt based systems buffer was full and on the non-interrupt solution polling was done on "terminal UART". So writing 100 characcters to "PC terminal" at 100Kbps would take 10 msec. For many programs (e.g. a simple line follower with a 1" wide line and robot moving at 1 meter per second) 10 msec is enough time to break the line following program; when the "print to PC terminal" is enabled you also may need to slow the line following speed to 1/2 or 1/4 of normal. Recall that "print to terminal" will not be the only multi-msec delay.

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.


	Quote: The typical ROBOTC end user is not familiar with Visual Studio and wouldn't want to go through the learning curve to debug their program on the PC. Which is one of the reasons that ROBOTC introduced a "emulator" mode about a year ago for testing on PC without requiring a real robot.

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.

Out of memory?

Who is online