Embeded Tutorial?

I'm looking for a tutorial that I can forward to some folks. I know of three different ways of implementing software.

In the first, you have just one real and virtual thread of control, and the software goes something like:

main() { // setup ... while(1) { do_this(); delay(a_while); do_that(); delay(a_while_longer); do_the_other_thing(); delay(even_more); } }

In the second, you're too cheap to buy an RTOS, but you want to have multiple virtual threads of control, so you use what I was taught to call a task loop and what most folks seem to call a state machine:

bool this_flag, that_flag, the_other_flag;

interrupt this_isr() {this_flag = true; /* cleanup */} interrupt that_isr() {that_flag = true; /* cleanup */} interrupt the_other_isr() {the_other_flag = true; /* cleanup */}

main() { // setup ... while (1) { if (this_flag) { do_this(); // resets this_flag } if (that_flag) { do_that(); // resets that_flag } if (the_other_flag) { do_the_other_thing(): // resets the_other_flag } } }

In the third, you spring for an RTOS. Technically you still only have virtual threads of control (since your processor can't really run two pieces of code at once), but you use semiphores and what not to create the same effect.

My question is: Does anyone know a good tutorial that covers all of this, or at least techniques for implementing the task loop/state machine method?

Thanks.

--
Tim Wescott
Control systems and communications consulting
 Click to see the full signature
Reply to
Tim Wescott
Loading thread data ...

[...]

[...]

[...]

I don't know if there is a book with the necessary depth and breadth. May be you can write one? It will certainly be useful.

Jack Ganssle's "Art of designing embedded systems" has a chapter where he talks about interrupts and state machines.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

The rule of embedded software is that there is no real rule. I just finished an implementation with a mix of your case 1 and case 2:

While counting down / timing Data converter Update display Check for buttons Change state Finish tasks

When counter/timer expires, switch to:

Button Change Interrupt Service Routine

While no Button Change Shutdown data converter Shutdown display Power down / sleep < wake up from interrupt >

Update display Do data conversion Back to task loop

--------------------------------------------------

I can't say for sure if my software is a task loop or an interrupt loop. So, rules are made to be broken.

Reply to
linnix

Believe it or not, LaBrosse's book covers each topic you cited with example (pseudo) code and is quite tutorial in its approach in my opinion.

Michael

Reply to
msg

"Tim Wescott"

[..]

There is a book called "Patterns for time triggered embedded systems".

"... in the case of many embedded systems, the time triggered approach has many advantages. Indeed, within industrial sectors where safety is an obvious concern, such as the aerospace industry and increasingly the automotive industry, time triggered techniques are widely used because it is accepted both by the system developers and their certification authorities, that they help improve reliability and safety."

formatting link

Reply to
Lanarcam

"Lanarcam" a écrit dans le message news:

47b02654$0$27988$ snipped-for-privacy@news.free.fr...

And there is this free downloadable course

formatting link

Reply to
Lanarcam

The following article about hierarchical state machine design might interest you:

formatting link

You will also find a lot of articles about Real-time and embedded programming at:

formatting link

-- EventStudio 4.0 -

formatting link
Sequence diagram based embedded system design tool

Reply to
EventHelix.com

I don't have Labross's book, although I've skimmed it and watched someone use it to port mucus to a brand new chapter. I don't care how good the programmer* is -- any time someone can prop a book up by their monitor, just type in code, and have it all work, it's a good book.

So I'll take that quite seriously.

  • Well, he's a good programmer, too.
--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

Lanarcam schrieb:

That's very interesting! I'll keep this as a generic tutorial in case I meet someone who is interested in such a course. It supplemented my knowledge on Embedded stuffs as well :)

cheers, Matthias

--
Matthias Arndt 
PGP-Key: http://www.final-memory.org/files/marndt.asc   ICQ: 40358321
 Click to see the full signature
Reply to
Matthias Arndt

Matthias Arndt schrieb:

Hm... from page 29 of the pdf:

I don't have any experience with the 8051, but I would expect that any c-compiler that has been updated during the last 10 years would optimize this function away.

The only reliable way to create a delay using such a for-loop is to declare y as volatile.

Old and obsolete stuff is you ask me.. For beginners this may do more harm than good.

Nils

Reply to
Nils

Why would this be specific to 8051 ??

Any C compiler would compile this code.

Old and obsolete, I take that personally !!! ;-)

donald

Reply to
donald

donald schrieb:

Sure it will compile, but why write such a null-code at all?

This is what GCC 4.2.2 makes out of the code. Compiled with -O1 for x86, but I'm sure it'll look similar for other architectures and compilers:

Not much delay there if you ask me..

:-)

Nils

Reply to
Nils

Try making x and y static.

donald

Reply to
donald

donald schrieb:

Doesn't makes it better :-)

This code:

Compiles into:

Still not much of a delay (and not much of clever code either...)

If you want the compiler to not optimize the loop away y must be declared as volatile. No other way around it.

I see such delay-loop b*shit way to often. Last time it was in a DSP example code for some init-code to wait some moment after powering on a piece of hardware. Good idea in principle.

I don't know what the engineer was smoking while he wrote that code though. The code even had comments and gave hints how many iterations would give what kinds of delays. How stupid is that? All compilers removes redundant loops unless you compile without optimizations or force them via volatiles.

Reply to
Nils

Not true, for example certain versions of Hi-Tech C would compile that code into a delay loop correctly without any special command line switches. No need for 'volatile' declarations.

Michael

Reply to
msg

As you say "certain versions" of some compilers will do it one way and lots will optimise it out.

So as a delay it is non portable and the delay is completely variable depending on the system it is running on.

In which case do a hardware delay using HW timers. It to will not be portable BUT it will give a precise and reliable delay.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

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.