On Thu, 17 Jan 2008 09:00:02 -0800, Mark Borgerson wrote:> In article <krudnQC6yLn0HRLanZ2dnUVZ_uTinZ2d@web-ster.com>, > tim@seemywebsite.com says... >> On Thu, 17 Jan 2008 09:21:25 -0600, Vladimir Vassilevsky wrote: >> >> > vivek wrote: >> > >> >> i have never used RTOS previously as i was working on 8 bit >> >> controllers.(c/assembly). >> >> >> >> now i have to work with C and RTOS on a 32 bit processor. >> >> >> >> what will be the difference between the two in terms of architecture >> >> and way of writing code. >> > >> > Think of each thread as if it is an interrupt subroutine servicing >> > some request. Assign the threads and the priorities accordingly. >> > >> And _don't_ put a task loop inside of a task! If you have a task >> that's doing two different things, split it up into two tasks. >> >> Putting task loops inside of tasks in an RTOS-based application is a >> good way to combine the deficiencies of both approaches. > > Would that include prohibiting code such as: > > // GPS characters are placed in queue by interrupt handler // GPS task > must pull characters from queue, run state // machine to extract data, > then set flag when new data // is available > > while(GPS_ChAvailable()){ > ch = GPS_GetChar(); > newdata = GPS_Parse_Input(ch); > } > if(newdata)......... > > Are you recommending processing only one character from the GPS each > time the GPS task is invoked? Or does the prohibition apply only task > loops that might have to wait on other tasks? > > > Mark BorgersonIt's putting a loop inside a task that's doing two different things, like parsing characters from the GPS at the same time that it's controlling the brew time on some tea. In a "real" task-loop (or state machine) architecture you may well have to parse input one character at a time to keep the machine ready for some more important thing, which you don't in a properly designed RTOS-based system. -- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
s/w architecture diff between RTOS and non-RTOS system
Started by ●January 17, 2008
Reply by ●January 17, 20082008-01-17
Reply by ●January 17, 20082008-01-17
Tim Wescott wrote:> Grant Edwards wrote: >> Tim Wescott <tim@seemywebsite.com> wrote: >>> Vladimir Vassilevsky wrote: >>>... snip ...>>> >>>> Think of each thread as if it is an interrupt subroutine >>>> servicing some request. Assign the threads and the priorities >>>> accordingly. >>>> >>> And _don't_ put a task loop inside of a task! >> >> What's a "task loop"? > > AKA "state machine". > > Where I learned it they called it a task loop, most people > seem to call it a state machine. > > Just in case I've left anyone confused, it's where you set > flags in ISRs that respond to events, then you have a loop > that responds to the flags by executing some code & (maybe) > changing state.Here is a contrary example. The system has to receive messages from something else. Those messages arrive via a serial line at some fairly slow rate. They consist of: 1. Sync character - unique. Say 0xff. 2. Length byte - total number of chars in message, max 64. 3. .. up to length - binary values, range 0..127. 4. Final char. Checksum for bytes classes 2 and 3. 5. Noise chars that don't fit. Ignore and go to state 1. I would implement this with a state machine, i.e. a switch, entered by the interrupt call. On any error it will revert to the 'awaiting sync' state 1. The code may be fairly long, but the 'per interrupt' execution time will be small. When the process gets a correct checksum in state 4 it sends the entire message off to some other process and returns to state 1. The sequence is (in states) 1 to 1 or 2 2 to 1 or 3 3 to 3 or 4 or 1 (4 when length counter zero.) 4 to to transfer and 1 or just to 1. The system can receive any ASCII message of up to 63 chars and EOL, or any binary message that can be expressed in the 7 bit ascii char set. The checksum has to avoid ever generating the sync char. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. -- Posted via a free Usenet account from http://www.teranews.com
Reply by ●January 18, 20082008-01-18
On Thu, 17 Jan 2008 20:57:35 -0500, CBFalconer wrote:> Tim Wescott wrote: >> Grant Edwards wrote: >>> Tim Wescott <tim@seemywebsite.com> wrote: >>>> Vladimir Vassilevsky wrote: >>>> > ... snip ... >>>> >>>>> Think of each thread as if it is an interrupt subroutine servicing >>>>> some request. Assign the threads and the priorities accordingly. >>>>> >>>> And _don't_ put a task loop inside of a task! >>> >>> What's a "task loop"? >> >> AKA "state machine". >> >> Where I learned it they called it a task loop, most people seem to call >> it a state machine. >> >> Just in case I've left anyone confused, it's where you set flags in >> ISRs that respond to events, then you have a loop that responds to the >> flags by executing some code & (maybe) changing state. > > Here is a contrary example. The system has to receive messages from > something else. Those messages arrive via a serial line at some fairly > slow rate. They consist of: > > 1. Sync character - unique. Say 0xff. 2. Length byte - total > number of chars in message, max 64. 3. .. up to length - binary > values, range 0..127. 4. Final char. Checksum for bytes classes 2 > and 3. 5. Noise chars that don't fit. Ignore and go to state 1. > > I would implement this with a state machine, i.e. a switch, entered by > the interrupt call. On any error it will revert to the 'awaiting sync' > state 1. The code may be fairly long, but the 'per interrupt' execution > time will be small. When the process gets a correct checksum in state 4 > it sends the entire message off to some other process and returns to > state 1. > > The sequence is (in states) > > 1 to 1 or 2 > 2 to 1 or 3 > 3 to 3 or 4 or 1 (4 when length counter zero.) 4 to to transfer and 1 > or just to 1. > > The system can receive any ASCII message of up to 63 chars and EOL, or > any binary message that can be expressed in the 7 bit ascii char set. > The checksum has to avoid ever generating the sync char. > > -- > [mail]: Chuck F (cbfalconer at maineline dot net) [page]: > <http://cbfalconer.home.att.net> > Try the download section.Parsing serial streams is, indeed, something that's often done in state machines. You can either do it in the ISR, or your ISR can just be responsible for stuffing the serial characters into a FIFO, and the task loop for executing the parsing code whenever there's something in the FIFO, with all more important code executing first. A counter-counter example would be a motion controller that always executes exactly the same code in lock-step with some time base. It may have 'states' in the sense of quasi-continuous variables in it's filters, but it doesn't have states in the sense of a state machine implemented as a big switch statement. -- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Reply by ●January 18, 20082008-01-18
On Jan 18, 12:32=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:> On Thu, 17 Jan 2008 20:57:35 -0500, CBFalconer wrote: > > Tim Wescott wrote: > >> Grant Edwards wrote: > >>> Tim Wescott <t...@seemywebsite.com> wrote: > >>>> Vladimir Vassilevsky wrote: > > > ... snip ... > > >>>>> Think of each thread as if it is an interrupt subroutine servicing > >>>>> some request. Assign the threads and the priorities accordingly. > > >>>> And _don't_ put a task loop inside of a task! > > >>> What's a "task loop"? > > >> AKA "state machine". > > >> Where I learned it they called it a task loop, most people seem to call=> >> it a state machine. > > >> Just in case I've left anyone confused, it's where you set flags in > >> ISRs that respond to events, then you have a loop that responds to the > >> flags by executing some code & (maybe) changing state. > > > Here is a contrary example. =A0The system has to receive messages from > > something else. =A0Those messages arrive via a serial line at some fairl=y> > slow rate. =A0They consist of: > > > =A0 =A0 1. =A0Sync character - unique. =A0Say 0xff. 2. =A0Length byte - =total> > =A0 =A0 number of chars in message, max 64. 3. =A0.. up to length - bina=ry> > =A0 =A0 values, range 0..127. 4. =A0Final char. =A0Checksum for bytes cl=asses 2> > =A0 =A0 and 3. 5. =A0Noise chars that don't fit. =A0Ignore and go to sta=te 1.> > > I would implement this with a state machine, i.e. a switch, entered by > > the interrupt call. =A0On any error it will revert to the 'awaiting sync='> > state 1. =A0The code may be fairly long, but the 'per interrupt' executi=on> > time will be small. =A0When the process gets a correct checksum in state=4> > it sends the entire message off to some other process and returns to > > state 1. > > > The sequence is (in states) > > > =A0 1 to 1 or 2 > > =A0 2 to 1 or 3 > > =A0 3 to 3 or 4 or 1 (4 when length counter zero.) 4 to to transfer and =1> > =A0 or just to 1. > > > The system can receive any ASCII message of up to 63 chars and EOL, or > > any binary message that can be expressed in the 7 bit ascii char set. > > The checksum has to avoid ever generating the sync char. > > > -- > > =A0[mail]: Chuck F (cbfalconer at maineline dot net) [page]: > > =A0<http://cbfalconer.home.att.net> > > =A0 =A0 =A0 =A0 =A0 =A0 Try the download section. > > Parsing serial streams is, indeed, something that's often done in state > machines. =A0You can either do it in the ISR, or your ISR can just be > responsible for stuffing the serial characters into a FIFO, and the task > loop for executing the parsing code whenever there's something in the > FIFO, with all more important code executing first. > > A counter-counter example would be a motion controller that always > executes exactly the same code in lock-step with some time base. =A0It may=> have 'states' in the sense of quasi-continuous variables in it's filters, > but it doesn't have states in the sense of a state machine implemented as > a big switch statement. > > -- > Tim Wescott > Control systems and communications consultinghttp://www.wescottdesign.com > > Need to learn how to apply control theory in your embedded system? > "Applied Control Theory for Embedded Systems" by Tim Wescott > Elsevier/Newnes,http://www.wescottdesign.com/actfes/actfes.htmlStriking to me is none of the followup comments have said anything about the RT of RTOS. I also noticed that nothing in the original post mentions real-time requirements either. You should use an Real Time Operating System when you need one. Some characteristics of your application that should lead you in that direction: *Specific time constrains. (this is the definition of real-time) Example: scanlines produced for a laser printer must be completed fast when they are needed. Late lines will cause bad printouts. to do a page per minute at 600DPI means one scanline every 10miliseconds (and 4800pixels per line) *logical model suggests using multiple tasks Example: a network device will need a protocol stack which is often easier to implement as multiple tasks, as long as the stack can meet the communications time constraints. Given the problem description, about any Kernel could have sufficed for vivek's application. Other than the general constrain of keeping up with the communications protocols, I see nothing real time about it. Maybe there was some other reason for your boss to force you to use the RTOS. (training you for the next project??) that's my thoughts on this topic. have a good day. Ed
