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
s/w architecture diff between RTOS and non-RTOS system
Started by ●January 17, 2008
Reply by ●January 17, 20082008-01-17
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_
Reply by ●January 17, 20082008-01-17
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
Reply by ●January 17, 20082008-01-17
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
Reply by ●January 17, 20082008-01-17
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
Reply by ●January 17, 20082008-01-17
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.
Reply by ●January 17, 20082008-01-17
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
Reply by ●January 17, 20082008-01-17
"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
Reply by ●January 17, 20082008-01-17
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
Reply by ●January 17, 20082008-01-17
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
