Multi-Threading Assembler Cog --- Beta Tester Needed
pjv
Posts: 1,903
Hi All;
I've been making significant performance enhancements to my Real Time Scheduler that permits a single assembly cog to run multiple simultaneous user-written time dependent application threads such as serial comms, stepper motors, LCD display, I2C, SPI, keyboard, mouse, RTC, etc. The applications all interact with the Scheduler in a standard co-operative manner, and no application is permitted to wait-loop or wait of any sort. All thread timing must be performed ONLY by the Scheduler.
The Scheduler itself consumes 56 longs. The theoretical number of threads possible is 144 in one cog, at which point one runs out of cog memory, but that is for a trivial contrived condition. The maximum possible number of independently timed "LED Flasher Threads" is 110, each timed to a resolution of 1 uSec, and at a speed of 10kHz. A practical, non-contrived, real-world application number is in a more modest 8 to 16 thread range, depending on the complexity and speed requirements of the application.
So each live application thread will be timed and dispatched from the Scheduler at the earliest possible microsecond tick, and execute a dozen or so instructions, and return to the Scheduler with a pause time (in uSecs) and a contiuation address for its next pass. The Scheduler then waits until the next thread is ready to be run, and dispatches that thread, and so on for all threads.
In this manner all threads co-operate, and no thread may hog the processor by looping or waiting, as those are cycles that need to be made available to other threads.
The timing of a thread can be set with 1 uSec resolution, and the shortest thread possible is 2 uSec. The system overhead for each task switch is approximately 1 uSec for the scheduler main line, plus 1/2 uSec per thread. So consider a generous estimate of the scheduler overhead to be roughly 1 uSec per thread times the total number of thread switches in a period of time. Of course one also needs to consider the actual time spent in the application for a total system performance assessment.
Presently the Zero and Carry flags are not preserved between task switches.... that code still requires some compacting.
So I believe the code is in very solid shape, and am soliciting the forum for an accomplished Propeller assembly programmer to have a go at using it, including some of their own applications to confirm its readiness for the market.
Any takers please??? ..... please PM me.
Cheers,
Peter (pjv)
I've been making significant performance enhancements to my Real Time Scheduler that permits a single assembly cog to run multiple simultaneous user-written time dependent application threads such as serial comms, stepper motors, LCD display, I2C, SPI, keyboard, mouse, RTC, etc. The applications all interact with the Scheduler in a standard co-operative manner, and no application is permitted to wait-loop or wait of any sort. All thread timing must be performed ONLY by the Scheduler.
The Scheduler itself consumes 56 longs. The theoretical number of threads possible is 144 in one cog, at which point one runs out of cog memory, but that is for a trivial contrived condition. The maximum possible number of independently timed "LED Flasher Threads" is 110, each timed to a resolution of 1 uSec, and at a speed of 10kHz. A practical, non-contrived, real-world application number is in a more modest 8 to 16 thread range, depending on the complexity and speed requirements of the application.
So each live application thread will be timed and dispatched from the Scheduler at the earliest possible microsecond tick, and execute a dozen or so instructions, and return to the Scheduler with a pause time (in uSecs) and a contiuation address for its next pass. The Scheduler then waits until the next thread is ready to be run, and dispatches that thread, and so on for all threads.
In this manner all threads co-operate, and no thread may hog the processor by looping or waiting, as those are cycles that need to be made available to other threads.
The timing of a thread can be set with 1 uSec resolution, and the shortest thread possible is 2 uSec. The system overhead for each task switch is approximately 1 uSec for the scheduler main line, plus 1/2 uSec per thread. So consider a generous estimate of the scheduler overhead to be roughly 1 uSec per thread times the total number of thread switches in a period of time. Of course one also needs to consider the actual time spent in the application for a total system performance assessment.
Presently the Zero and Carry flags are not preserved between task switches.... that code still requires some compacting.
So I believe the code is in very solid shape, and am soliciting the forum for an accomplished Propeller assembly programmer to have a go at using it, including some of their own applications to confirm its readiness for the market.
Any takers please??? ..... please PM me.
Cheers,
Peter (pjv)
Comments
Massimo
Bill M.
Thanks,
C.W.
My request for Beta Testers yielded two volunteers. I have had some very insightful responeses that vetted the appropriateness of the code. I also created some flow charts and user documentation, but the latter may need to be embellished somewhat. Furthermore, I have been away from my activities here for several weeks, and then this Christmas thing directed my time to family needs, so I am not yet ready to say we are done.
I have continued to use the Scheduler in code destined for industrial applications, and have found it to be rock solid.
So now that the new year is upon us, I will get back to it to see how I might make this available to the Propeller community. Because of the huge effort it took for me to get there, I am considering a nominal license fee, like one dollar per instance for commercial users, and one free copy for non commercial hobbyists. Not sure how to implement that as I dont want to create an administrative nightmare..... any ideas??
Cheers,
Peter (pjv)
What is the status of handling the C and Z flags?
I don't really have any good ideas on licensing something like this other than a request for a per commercial use fee like you suggested, but it would be hard to enforce. Maybe some of the forum members with more experience in the commercial embedded space might have some ideas.
My primary need is to implement a UART along with some other functionality that needs to get as much CPU time as possible within a single COG. This is a place where having a timer interrupt available would be great. I'm planning to release under MIT or some form of Open Source license, so I'll roll my own in this case. I'm thinking along the lines of something that behaves a little like DoEvents() in VB.Net. Basically each call to DoEvents() would check to see if its time to handle the UART thread, or return to run more of the main thread. My main need is to spend as little time as possible in a Waitcnt state.
C.W.