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=
> > =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.html
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 by Tim Wescott●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 CBFalconer●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 Tim Wescott●January 17, 20082008-01-17
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 Borgerson
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
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 Tim Wescott●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
Reply by Mark Borgerson●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 andrew queisser●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 Grant Edwards●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 Arlet Ottens●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 Mark Borgerson●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