>> My question is, why people are telling me that i need >> a RTOS ( Real Time Operating System ) to develop an ... There are two general ways to structure an embedded program (I would call any uC based system an embedded system) - 1) poll loop 2) task switching. The poll loop way is what you are familiar with. You have a main loop in your program that checks and controls the various things that your system does. If one of these checks/action takes a lot of time, the other checks/actions have to wait their turn in the loop before they get a chance to do anything. If you have a check/action that has to be done without delay, you can put it in an ISR (interrupt service routine) so that it interrupts what ever the poll loop is doing. The ISR puts the poll loop on hold while it runs then returns control to the poll loop. The poll loop is one thread of execution and the ISR is another. All PIC programming is done this way because the PICs do not support the other way (task switching) else for technical reasons. For many systems, the poll loop way is the best way. At some point, however, as the complexity raises (more checks/actions and strict time constraints on what order things have to be done in), it become difficult or impossible to make the poll loop satisfy all the requirements. The task switching way does not have a main poll loop. Instead of having one loop that checks/does A,B,and C, it lets you have one loop to check/do A, one loop to check/do B, and one loop to check/do C. Each check/action can be written in a separate function (referred to as the 'task' or 'thread') that typically has its own infinite loop. You can think of each task as its own, somewhat independent program (thread of execution) running on the uC. Only one thread of execution is actively running on the uC at a time. Whenever an interrupt occurs, the currently running thread of execution is put on hold while the interrupt runs. This is just like what happens when an interrupt occurs in the poll loop example above. The difference is that when the ISR is done, it does not necessarily return control of the uC back to the same thread! The original thread is just kept on hold while a different thread gets to run. Eventually, based on rules that are called 'scheduling', the original thread will be the one that 'wakes up' from some interrupt and it will continue on its way. To make sure that an opportunity to switch tasks happens frequently, you could have a timer creating an interrupt say.. 30 times a second. A surprisingly small (but complicated) amount of code is needed to proved this 'task (thread) switching' behavior as long as the uC provides a way for each thread to have its own stack space in memory and a way to save its context (put the thread on hold). (The PIC does not) If you wrote this task switching yourself for one project then for a second project, instead of rewriting the entire task switching code again from scratch, you might pull it out from your first project and reuse it. You would find that you could put it in a library that provided functions for any program you write in the future that enables it to task switch without worrying about the code in your library that makes it happen. That library you would call an operating system (OS). If the rules that you made up for scheduling when threads get to run provide a predictable worst-case time between when events happen and when threads get to run (and a few more details), you would call it a real-time operating system (RTOS) and you could sell it to other programmers for use in their projects. Next you would find that some programmers wanted to use your RTOS code on other uC's. So you port your code to other processors. To keep the code manageable, you separate the parts that are the same for any processor from the parts that need to be changed for each new processor you port to. The parts that change you would call the driver. You would have one copy of the base code that does not need to change (like the definitions of the functions prototypes in your library or 'API') and you would have one driver (the part of the code that changed) for each uC you supported. Next you would find that you could also provide functions in your library (RTOS) to make it easy for programmers to use, say.. an SPI interface. Because the specifics on how to implement the SPI interface varies from uC to uC, you would separate it into the parts that are common to any SPI use and the part that had to change to match the details of how a uC talks SPI (bit bashing on some uC, MSSP on others). You would call the non-changing part the 'SPI API' in your RTOS and the changing parts the SPI driver for this uC and the SPI driver for that uC. You would then repeat this same API / driver pattern that you used for the 'Task Switching' API and 'SPI API' over and over again for memory management, communications protocols, etc... Drivers don't have to be used only for code that changes from one uC to another. You can use the driver pattern any time you can factor out the code that changes for any parameter; uC, hardware, UI style. For example you could have a driver for each type of video hardware that plugs into your embedded system's bus. So that's what an RTOS and drivers are. --BobG -----Original Message----- From: pic microcontroller discussion list [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of pic list Sent: Thursday, August 09, 2001 2:40 AM To: PICLIST@MITVMA.MIT.EDU Subject: [EE]:Embedded system ,RTOS Hi, Good afternoon. i have several issues that i am in doubt. 1. what is embedded system? what is the difference between a normal electronic system with a uC, with an embedded system? 2. i am used to programming pic16F84 and 68hc11. the procedure is like this. key in the assembly in an editor, them assemble them to hex file, then download them to the uC. that's it. the uC can be brought everywhere and still function the same. My question is, why people are telling me that i need a RTOS ( Real Time Operating System ) to develop an embedded system? They are telling me that drivers need to be written, so on and so forth. Why? What role does the RTOS play? i don't get it, cause i am still looking things at the binary level. 3. Another issue is the driver issue. When someone told me that driver need to be written for certain embedded component, i start to go blank. how should i start? Another senior engineer told me that i have actually been writing drivers without knowing it. really? Can anyone please enlighten me? thanks a lot __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu