CreateThread(wThreadName......... this is an attempt to open for discussion the variety of styles that PIC software engineers have developed to implement operating systems. Assertion: Every PIC program that "works" has an operating system in the broadest sense. If this topic interests you, you might as well print this out and read it when you have spare time. It's rather lengthy. Toward the end I dwell on event-driven operating systems. If you read on you'll notice that I'm rather fond (obsessed) with event-driven programming languages and I've extended my interests into EDOS's (EventDrivenOperatingSystems). Saga I've been researching operating systems theory and implementation for about a month now. My starting point was the app note "A real-time operating system for the Pic.." in the MCHIP ECH. It contains an introduction to RTOS terminology and theory of multitasking, and two code examples (one for a 16C5x and one for 16C64). The code part was frustrating to try to relate to the theory (and difficult to follow even with comments). I read some of the "further reading" books the appnote author listed in the bibliography. I took a copious amount of notes. I drew diagrams and flow charts. I struggled with the logic of semaphores. I'm still trying to prove the appnote author's assertion that the binary semaphore can be implemented using interrupts. I printed several Windows System Journal articles which further also defined and elucidated the concepts of semaphore, mutex, critical section, thread, and process. Being somewhat versed in the Event-driven programming languages of AccessBASIC and VisualBASIC, I'm looking to build an event-driven front end for my PIC projects. If the event-driven paradigm can be applied to the PIC (and it seems likely) I won't have to throw away my VB training. The buzzword these days is "reuseable/recycleable software" and I have extended that to "reuseable self education". So whatever programming style you have been exposed to and latched onto, you will want to stick with for time-economy reasons. EDOS's After a maximum length conversation with Chris@Microchip (he cut it short but I could have talked for another 30 minutes) my eyes opened to the possibility of an EDOS. He pointed out several AppNotes in the ECH that relied upon the following simplistic model for an operating system. ORG 04h ;vectored interrupt GOTO Do_Events Call Init_System Call Init_Peripherals lzz GOTO lzz ;Wait for Events (Event Call Routines) (Lookup Tables) Do_Events SaveStatus SelectCase: Case0 CallEvent0 Case1 CallEvent1 ... CaseN-1 CallEventN-1 CaseElse ;an unknown interrupt occured CallErrorHandler ;do whatever you do with the glitch/bug EndSelect RestoreStatus RETFIE END ;end of program memory Chris at Microchip mentioned that Case0 should be either the most important interrupt to be serviced or the most frequently executed interrupt (like the system's clock tick). CaseElse is my own way of trapping the runtime error much like in VisualBasic's OnErrorGoto ErrorHandler In event driven programming error trapping is like batting practice to a ballplayer. You spend most of your time anticipating, trapping, and analyzing errors. Then you go back into your program and try to fix it so the errors are handled in a more graceful way. The least graceful method of dealing with system errors is "abnormal program termination" which for a PIC would be a software RESET and in Windows Programming it would be the "white window of death", with a user message like "fatal error executing KERNAL.EXE" On a really boring day at my terminal at work, even the "white window" event is welcome. I encourage everyone who finished this article to keep this thread going. I am willing to discuss the topic on a personal basis via my email address as well. Later.