Forums

s/w architecture diff between RTOS and non-RTOS system

Started by vivek January 17, 2008
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.

i do have an idea that tasks have to be created, a scheduler has to
run etc.. but is there a place to know more...

Thanks & regards
VIVEK
vivek wrote:

> what will be the difference between the two in terms of architecture > and way of writing code. > > i do have an idea that tasks have to be created, a scheduler has to > run etc.. but is there a place to know more...
My 1st encounter with an RTOS was ThreadX on an ARM7. The app was an intelligent bridge between two proprietary RS485 poll-and-response networks. Up to then I had always used a simple round-robin task scheduler, but the boss wanted the RTOS. So I read the manual, scratched my head and tried to figure out why (and where) I would need the services provided. Finally I came up with two threads, one for the host (that polled me) and another for the local net I was polling. Right away I had a problem. If the host queried for a report, I would begin processing the cmd, but meanwhile the other thread carried on with the local network, buffering event data that it received. Because the two threads ran concurrently, it was hard to distinguish between events already reported to the host, events being formatted for the current report and new ones. Deadlines were looming and I didn't have time to sort this all out properly, so I created a mutex between the two threads. The local thread would complete its query and response for one node and then release the mutex so the host thread could check for a pending command. This worked, at the cost of some time efficiency (and probably defeated the whole purpose of the RTOS), but at least my firmware completed all its tasks on schedule. Another problem was that some host commands involved direct access to a local node; my program being merely the pipeline. But what if the local thread happened to be accessing a node just then? The mutex solved this problem, too, because the host thread would wait for it, use exclusive access to the local net and then release the mutex back to the local thread. At this point someone in Marketing decided that we needed an Ethernet version of the product. To simplify development we used a Lantronics XPort Ethernet-to-serial module. The polling host was gone, replaced by a higher level host on the user's LAN that would send config commands but no routine polling; I had to initiate event reports myself. Time was still pressing (when am I ever going to work on a project with reasonable, ie achievable, deadlines?) and I had to deliver something toot sweet. So I created a separate thread to simulate the former host polling, wrapped around the core logic I had already built. Also a new thread to handle network reports, taking the poll reports as input and reformatting them for transmission. Although I had to create two different firmware versions (with a #define EXPORT_VERSION statement), changes to the core logic were easily manageable. Finally the RTOS began to make some sense. YMMV. Sean_Q_

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. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
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. -- 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
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 Borgerson
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).........
When using real tasks, I would prefer to make a blocking call to a GetChar() routine from inside the parser. This usually leads to cleaner code than a state machine approach.
On 2008-01-17, Tim Wescott <tim@seemywebsite.com> wrote:
> 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!
What's a "task loop"? -- Grant Edwards grante Yow! My mind is making at ashtrays in Dayton ... visi.com
"Mark Borgerson" <mborgerson@comcast.net> wrote in message 
news:MPG.21f92970428996b7989763@newsgroups.comcast.net...
> > 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 Borgerson >
I've run into this exact problem more than once. I don't see anything fundamentally wrong with the above code but if the GPS spews characters fast enough to stay inside the polling loop then you would never exit that loop. You'd probably want to break out of the loop each time a record, packet or some predetermined number of characters has been read. The next question to ask is what kind of priority the task with the polling loop has. If it's very high priority you might be kept busy if there's a lot of activity coming from the GPS and you'd want to yield to the OS when possible. My experience with the transition from the "main loop plus interrupt handlers" approach to an RTOS is that you want to pay close attention to priorities before you break your application into tasks. Sometimes data flow considerations (as above) trump functional or logical groupings, e.g. you might end up with a "communications task" and a "protocol" task vs. a "GPS" or "LCD" task. Andrew
In article <fmokgq$hb3$1@usenet01.boi.hp.com>, andrew.queisser@hp.com 
says...
> > "Mark Borgerson" <mborgerson@comcast.net> wrote in message > news:MPG.21f92970428996b7989763@newsgroups.comcast.net... > > > > 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 Borgerson > > > > I've run into this exact problem more than once. I don't see anything > fundamentally wrong with the above code but if the GPS spews characters fast > enough to stay inside the polling loop then you would never exit that loop. > You'd probably want to break out of the loop each time a record, packet or > some predetermined number of characters has been read.
That's a good point. I've never used a GPS that was transmitting more than about 200 characters per second--less than 50% of the 4800Baud bandwidth. If the GPS were running at 57.6K, it might have continuous blocks of 40 to 60 characters and they might arrive fast enough that the system would stay in that loop through the whole packet. Your idea of exiting from the loop in some way at the end of each packet, if not sooner, sounds good.
> > The next question to ask is what kind of priority the task with the polling > loop has. If it's very high priority you might be kept busy if there's a lot > of activity coming from the GPS and you'd want to yield to the OS when > possible. > > My experience with the transition from the "main loop plus interrupt > handlers" approach to an RTOS is that you want to pay close attention to > priorities before you break your application into tasks. Sometimes data flow > considerations (as above) trump functional or logical groupings, e.g. you > might end up with a "communications task" and a "protocol" task vs. a "GPS" > or "LCD" task. >
Yes. A "Collect_GPS_Line task followed by a Parse_GPS_Line, with the latter waiting for a message or semaphore from the collection task seems like a good approach. Mark Borgerson
On Thu, 17 Jan 2008 21:26:39 +0000, Grant Edwards wrote:

> On 2008-01-17, Tim Wescott <tim@seemywebsite.com> wrote: >> 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! > > 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. -- 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