Mike, I did some measurements using MPLAB SIM in my SimpleRTOS, and found the following values: PIC32MX @ 40MHz(40MIPS) with 1ms tick (XC32 optimization "-Os"): [1] Yield: 147 Tcy (3.674us =3D 0.3674% of tick time) [1] vSleep 198 ~ 202 Tcy (4.950 ~ 5.050us =3D 0.5% of tick time) [2] Timer interrupt 217 Tcy (5.425us =3D 0.5425% of tick time) PIC24FJ @ 32MHz(16MIPS) with 1ms tick (XC16 optimization "-Os"): [1] Yield: 111 Tcy (6.937us =3D 0.6937% of tick time) [1] vSleep 177 Tcy (11.062us =3D 1.1% of tick time) [2] Timer interrupt 138 Tcy (8.625us =3D 0.8625% of tick time) [1] Time elapsed from the moment one task calls the function until the moment the next task executes the first statement. [2] Time elapsed from the moment TMR1 overflows until the moment the next task executes the first statement. I have some questions about your bit-banged UART: Do you use interrupts on the RX pin? What is the baud-rate? What is the processor? If you use interrupts in the low level routines, you could raise the interrupt priority above the RTOS kernel priority and have a very fast response. Interrupt on the RX pin and a timer interrupt for TX is all you need to achieve very fast baud-rates with a software UART. Best regards, Isaac Em 20/02/2014 10:44, Mike snyder escreveu: > Hi Isaac, > > I have been following this thread with great interest. I usually use the > infinite loop construct for my applications however your post has prompte= d > me to take another look at the RTOS use case. > > One question: > > Have you done any timing analysis on how much time a context switch takes > in your OS? The reason I ask - I am thinking of porting an application th= at > does bit banged UART (due to it being a custom protocol and the standard > UART does not work too well for that...) In this situation after reading = a > byte I would like to do some processing before waiting for the next byte= .. > I am wondering how effective the task switching could be to allow maximum > time to be devoted to the serial task and then spend the time while waiti= ng > for the start bit to do some processing before resuming the serial rx > part... > > I could just try this out with your scheme but if you have some timing > analysis available it might come in handy... > > Thanks for sharing your rtos code I think I can learn a lot from this... > > Mike > > > On Thu, Feb 20, 2014 at 8:11 AM, Kerry Wentworth < > kwentworth@skunkworksnh.com> wrote: > >> So far, all I've done is save the files you posted and give them a quick >> once over. I can't just rewrite customers' code. and I have no new real >> time projects at the moment. I will look at it in my spare time, but it >> could take weeks. >> >> Kerry >> >> Isaac Marino Bavaresco wrote: >>> Kerry, >>> >>> >>> Did you try my co-routine code? I would like to know if it could work >>> for you, as I'm tempted to improve it so others can use it in real >>> applications. >>> >>> I converted the list manipulation functions back to pointers and found >>> that this way it uses less RAM and FLASH. It ought to be faster also. >>> >>> >>> Best regards, >>> >>> Isaac >>> >>> >>> >>> >>> Em 17/02/2014 11:42, Kerry Wentworth escreveu: >>> >>>> I can certainly see advantages to your method. Adding, deleting and >>>> re-arranging steps is MUCH more difficult with my method. I originall= y >>>> "invented" my method (20+ years ago) on a PC using QuickBasic. I have >>>> used it with QuickC, MSVC, and on Rabbit controllers, as well as PICs. >>>> >>>> I work with small (16F) PICs, and my compiler (CCS PCW) does not suppo= rt >>>> indirect function calls that your method uses (Yes, that can be gotten >>>> around) >>>> >>>> When all is said and done, all we can do is present methods and let ea= xh >>>> programmer take what they like. Your method is definitely going in MY >>>> toolbox. >>>> >>>> Kerry >>>> >>>> >>>> Isaac Marino Bavaresco wrote: >>>> >>>>> Em 17/02/2014 02:35, Kerry Wentworth escreveu: >>>>> >>>>> >>>>>> I suppose "straightforward and easy to write and understand" is in t= he >>>>>> eye of the beholder. >>>>>> >>>>>> >>>>> Correct, one becomes accustomed to using a certain programming style >> and >>>>> produces good results with it. >>>>> Not to say there are not other styles, some of them simpler and with >>>>> other benefits. >>>>> >>>>> >>>>> >>>>> >>>>>> I do find myself occasionally needing to jump forward to step 14, or >>>>>> backwards to step3, usually due to a detected mechanical >> malfunction. >>>>>> The equivalent of the dreaded goto, I guess. Convenient, if not >>>>>> actually necessary. >>>>>> >>>>>> >>>>> Indeed, sometimes a well placed 'goto' solves a lot of problems, >>>>> simplifies the code and makes it more efficient. >>>>> It is easy to put a goto in a co-routine, it is done exactly the same >> as >>>>> in a normal function. >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Isaac >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >> -- >> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist >> --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .