Multithreading

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it possible to have Multithreading in Embedded Programming??
I have had some experience with Embedded C programming, but C doesn't support multithreading..
Is it possible to write Java codes for Atmel MCUs??
Which compiler has to be used??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I may well be wrong but I thought that the way freeRTOS (and, by extension, other RTOS') handled stuff was called multithreading...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have written a tutorial on this.
C may not natively support multithreading, but it doesn't exclude it. Considering major operating systems are written in C that are multitasking and multithreading that would suggest that it is possible. Also ask what the java runtime byte code interpreter is written in.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And you don't even need an RTOS to really do it, to be honest. I don't know the exact CS definition of it, but I recently wrote a C program (but not for an AVR) that ran "bare metal", with four tasks, each getting its turn depending on what was happening. You could call them threads i suppose.

The "OS thread" listened for interrupts from an ethernet controller and set some flags depending on the interrupt.
The "Ethernet in thread" listened on incoming packets, responded if it should, and set flags and set up some data shuffling if the data should be further processed.
The "Ethernet out thread" listened to other flags and set up DMA transfers from memory if there was data to send.
And finally the "Data catcher thread" which requested data over a bus, shuffled it to memory, acted on control flags and set other flags.
Each thread would run after each other (simplest scheduler I could think of) if their controlling flags were set, or they could be skipped if they didn't need to do anything.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Check out protothreads

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is both possible and fairly common (depending in part on how you define multithreading). Many languages, including C, need library support for multithreading - that is, they call functions of the particular RTOS the program is running on top of. Some languages such as Ada have multithreading (concurrency) built into the language, which is much nicer IMO.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Adam Dunkels has a nice implementation of what he calls Protothreads:

http://www.sics.se/~adam/pt/

I've tried his software with several compilers and platforms, and it works very well.

I just noticed wizhippo's post.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A main loop and a bunch of interrupt handlers is exactly the same concept isn't it?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not really, Protothreads doesn't use interrupts.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think Bob meant "as Multithreading" (subject of this thread). In which case the answer is "yes". The main() code and each of the ISR()s are a thread of execution so anything that has main() and even one ISR() is "mutithreaded".

All that something like FreeRTOS does is to formalize this using one main() and one timer interrupt and in the timer interrupt is then switches between other "threads".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want to do threads without using a whole realtime operating system, I heartily recommend the avr-threads-1.3 library found here:

http://bourbonstreetsoftware.nfs...

I've used it on an atmega168 in C and in Ada. It has just enough to do what you want without bloating your program ROM too much. In addition to threads, it has mutexes and events.

Warren

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

without bloating your program ROM too much

With RTOS it's seldom the ROM that is the issue - it's the RAM consumed to hold TCBs and per-task stacks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IMO protothreads is just an ugly macro hack. All it does is hide a huge switch in some macros.

You might as well be using a main loop that calls functions that uses a state variable to track their progress.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is just macro magic, but IMO it is much more readable then a main loop and functions with state machines inside them.

Take a look at Adams example where he uses a state machine using the switch statement and a version using the protothreads macros.

I personally find the protothreads version easier to follow and understand.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
List of RTOS for AVR

+

How about ChibiOS from J. de Sirio ?

http://chibios.sourceforge.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

How about ChibiOS from J. de Sirio ?

Please add that post to the end of the linked thread and I'll update it next time I'm there.