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

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

Reply to
vivek
Loading thread data ...

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 to
Sean

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

formatting link

Reply to
Vladimir Vassilevsky

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
 Click to see the full signature
Reply to
Tim Wescott

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 to
Mark Borgerson

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 to
Arlet Ottens

What's a "task loop"?

--
Grant Edwards                   grante             Yow! My mind is making
                                  at               ashtrays in Dayton ...
 Click to see the full signature
Reply to
Grant Edwards

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 to
andrew queisser

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.

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 to
Mark Borgerson

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
 Click to see the full signature
Reply to
Tim Wescott

It'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
 Click to see the full signature
Reply to
Tim Wescott

... snip ...

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]: 
 Click to see the full signature
Reply to
CBFalconer

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
 Click to see the full signature
Reply to
Tim Wescott

y

total

ry

asses 2

te 1.

'

on

4
1

Striking 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

Reply to
Ed Prochak

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.