Isaac Marino Bavaresco wrote: > Awaking a thread that was already awoken or even running is innocuous > (at least in FreeRTOS). Perhaps, if you're already using something like that. As I remember, his pseudo code said something about "starting" a thread, not waking it. Waking it in this context makes some sense, but starting it doesn't. >> All the interrupt routine should do, if you use interrupts at all, >> is to get the data and leave it lying around someplace the receiving >> thread can find it, usually in a FIFO is the data is just a byte >> stream. The receiving thread runs all the time, but the call to get >> the next byte blocks until one is available. Now the receiving >> thread can do a computed GOTO on the opcode byte and run a separate >> routine per command. These command routines can get parameter bytes >> as appropriate and don't jump back to the start of the main command >> loop until their command has been processed. This is essentially >> using a state machine to processes a state-dependent input stream, >> with the PC being the state variable. I find that sort of >> architecture works well for handling asynchronous input streams. > > He is not using a state-machine, he is running a RTOS (probably > FreeRTOS, which he already used before). He didn't say that, but that has nothing to do with the concept of using a state machine and the PC being the state variable. Whether the thread spins waiting on the next input by calling TASK_YIELD or goes to sleep and then is awoken when there is more input is a minor low level detail invisible to the app thread at that level. > The thread can also "sleep" for some time (which is usually the > timeout) > then it won't waste not even one single CPU cycle, and the ISR may > awake > it when data is available. > It may awake either by timeout or because the ISR received some data, > and act accordingly. Yes that is another way to do it, although more complex. Whether that's approriate or not depends on the RTOS, the relative power of the CPU, etc. Most likely either method is OK given that you've bought into a RTOS that supports it and truly understand what is going on under the hood. > If the RTOS's tick is 1ms, the latency may be several ms depending on > the number of threads, unless the thread priority is raised above all > the others, then it runs at the beginning of each tick. You only get into this mess with a overly complicated (for most PIC projects) RTOS in the first place. The really simple cooperative multi-tasking system where each task calls TASK_YIELD periodically works remarkably well for small embedded projects. It's hardly a "RTOS", just a task switcher. It may not cover all needs for really complicated requirements, but is simple with low footprint. There are no "ticks", no thread priority, no sleeping and asynchronous awakening, no mutexes, and of course none of the infrastructure to support any of this. At first glance, it may seem wasteful to have a thread that has nothing to do spin in a loop calling TASK_YIELD. But think about it carefully and it's actually kind of elegant. The system is optimized for lightweight and fast task swapping with no baggage. The overhead to run a task and have it quickly call TASK_YIELD is very little time, much much less than a millisecond in the normal case. Also keep in mind that the number of tasks is small. 3 is a typical number for such small embedded systems with dedicated purposes. Most of the time nothing is going on and all the tasks are being cycled thru rapidly because they are all calling TASK_YIELD quickly. Then something unusual occurs like a input byte is available in the input command stream FIFO. The thread spinning in a loop waiting for just that event will discover that event quickly, handle it, and get back to calling TASK_YIELD. Most purely CPU bound operations that don't require any new input complete so quickly that a task can perform the whole operation before going back to calling TASK_YIELD without undue latency imposed on the other threads. And even if something came up for thread 2 to handle while thread 1 was doing some CPU bound processing, it will run quickly after thread 1 is done. In the end the CPU actually gets used quite efficiently. Again, such a simple system can't solve all problems, but it does seem to quite nicely solve the vast majority of real world jobs PICs are asked to perform. Keep it simple. Most of the uses I see of phancy RTOSs is just overkill because someone thought using a RTOS was cool or didn't think about it real hard. The underlying complexity doesn't come for free, and you get into issues of juggling time slices, priorities, mutexes, and the like that a simpler scheme avoids. So while a fancy RTOS may appear to simplify things at first glance, you actually have to know a lot more about what you're doing to not get into trouble. Ufortunately, fancy RTOSs tend to hype their benefits to exactly those people that shouldn't be there. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist