Erfahrungen mit RTOS auf Atmega1280 oder Atmega2560

[Tobias G. (t-g-laeser)]

Hallo Forengemeinde,

Für ein Projekt habe ich mich entschlossen ein RTOS auf einem Atmega 
einzusetzen. Die Schaltung besteht soweit schon und es sollen sehr viele 
unterschiedliche Sachen erledigt werden.
Bisher habe ich keinerlei Erfahrung mit RTOS auf AVR hab mich aber die 
letzten Wochen durch diverse Foren und Code-Beispiele gelesen.

Benötigte Funktionen:
alle 16 AD-Ports auslesen und bearbeiten
5 Taster auslesen und bearbeiten
8 LEDs
8 Dip-Schalter
Display (4-Wire-Daten, 4x20 Zeichen)
I2C: Temperatur, Porterweiterung, Lichtsensor, RTC, ADC, EEPROM
Hupe (Einfaches I/O Signal)

Nun ist mir leider kein passendes RTOS über den Weg gelaufen, bzw ich 
habe keine richtige Ahnung was für mich am geeignetsten wäre.

gut 10 Tasks sollte es haben und wenig Speicher benötigen. Aber wie kann 
ich Displayfunktionen und die Werte der AD-Wandler in allen Tasks 
verwenden?

Ich wäre Euch für eine Starthilfe in dem Bereich RTOS speziell für den 
µC (Atmega1280 oder Atmega2560) sehr dankbar!

Mit freundlichen Grüßen
Tobias Gläser

[(prx) A. K. (prx)]

Worum geht es? Willst du ein bestimmtes Problem lösen, oder willst du 
dich unbedingt mit einem RTOS befassen?

Um rauszukriegen, wie man mit einem RTOS gemeinsame Resourcen korrekt 
verwendet, kann man auch mit dem PC anfangen. Multithreading geht 
nämlich ähnlich und die Prinzipien von Semaphoren, Queues, Timern und 
Critical Sections sind ziemlich universell. FreeRTOS kann man ebenfalls 
auf dem PC unter Windows nutzen, um damit Erfahrung zu gewinnen ohne 
sich mit den eingeschränkten Debugging eines Mikrocontrollers plagen zu 
müssen.

[Tobias G. (t-g-laeser)]

Hallo A. K.,

mit RTOS auf dem PC habe ich mich bereits im Studium befasst.
Die Platine mit den oben genannten Funktionen ist bereits fertig 
entwickelt.
Eine Lösung mit einem normalem Programm wäre sicherlich möglich, aber 
bestimmt nicht so schön wie mit einem RTOS und Multitasking.

Die Frage ist eigentlich, ob jemand schonmal ein umfangreicheres Projekt 
mit einem RTOS auf einem solchem AVR (Atmega1280 oder Atmega2560) 
gemacht hat und dieses zuverlässig und ohne Speicherprobleme läuft.
(am besten mit gcc, zur Not auch IAR)

Mit freundlichen Grüßen
Tobias Gläser

[Arne (Gast)]

Ich habe mal ein Projekt mit pC/OS (http://www.embedded-os.de) begonnen. 
Brauche es eigentlich nicht, war mehr Neugierde in Bezug auf RTOS. Habe 
es bis dato noch nicht beendet, da ich die HW nicht fertig habe, die die 
Sensoren auswertet.

[Peter D. (peda)]

Tobias Gläser schrieb:
> Eine Lösung mit einem normalem Programm wäre sicherlich möglich, aber
> bestimmt nicht so schön wie mit einem RTOS und Multitasking.

Kommt drauf an, welche Schönheit Du meinst.
Zumindest wäre es schneller bwz. bräuchte weniger Ressourcen.

Ein normales Programm (Main-Loop) heißt ja nicht, Spaghetticode 
schreiben zu müssen.
Man kann auch dann prima kleine Module schreiben und aufrufen.
Das ist auch sehr übersichtlich und erweiterbar.

Die ADCs und Tasten kann man prima im Timerinterrupt auslesen bzw. 
entprellen.
Ebenso kann man dem LCD einen Textspeicher spendieren, der dann alle 
200ms an das LCD geschickt wird oder im Timerinterrupt etwa ein Byte/ms.

Die Main-Routinen holen sich dann alles nur aus dem SRAM bzw. schreiben 
dahin. Haben also keinerlei unnötige Wartezeiten.


Peter

[Uwe (de0508)]

Hallo,

ich kann Peter nur zustimmen und verweise auf den von ihm geschriebenen 
Scheduler:

Beitrag "Wartezeiten effektiv (Scheduler)"

Ich hatte erst cocoOS http://www.cocoos.net/ verwendet, das mir aber für 
die einfachen Aufgaben schon zu viel Code verbraucht.

Bei Peters Ansatz läuft ein Timer mit 1ms Takt, das ist der Systemtakt.
In der ISR wird bei einem meiner Programme die Eingangspins entprellt 
und auch eine Drehgeber (2-fach) abgefragt.

Die Verschiedene "Tasks" rufen sich teilweise gegenseitig auf, oder 
kommunizieren über Semaphore (TRUE / FALSE) miteinander.
Der Datenaustausch zwischen den Tasks erfolgt über globale (statische) 
Speicherbereiche.

Z.B. habe ich die Kodierung von Morsezeichen für ein Bakenprojekt über 
die Verkettung von einigen Tasks realisiert.

/* TASK Prototypen */
static void task_key_press(void);
static void task_key_release(void);
static void task_trx_on_traeger(void);
static void task_trx_off_traeger(void);
static void task_trx_bake(void);
static void task_morse_ch(void);
static void task_morse_pause(void);

Ich muss z.B. die steigende und fallende Flanke einer "Taste" 
verarbeiten, deshalb rufen sich die Tasks

task_key_press()

 und

task_key_release()

 gegenseitig auf:

Hier ein Auszug wie schön leserlich ein Programm werden kann, die 
Funktion der Makros (alles in GROSSBuchstaben) kann man sich denken:

static void task_key_press(void)
{
  if ( get_key_press( _BV(KEYER_BIT) ) ) {

    PWM_ON();      // 660Hz on
    SET_OFF(TRX);    // on

    sem_trx_send = TRUE;
    REM_SCHEDULER_DEAD_TIME();    // und alle anderen Tasks !

    ADD_SCHEDULER_KEYRELEASE();
  } else {
    ADD_SCHEDULER_KEYPRESS();
  }
}

static void task_key_release(void)
{
  if ( get_key_release( _BV(KEYER_BIT) ) ) {

    PWM_OFF();      // 660Hz off
    SET_ON(TRX);    // off

    sem_trx_send = FALSE;
    ADD_SCHEDULER_DEAD_TIME();

    ADD_SCHEDULER_KEYPRESS();
  } else {
    ADD_SCHEDULER_KEYRELEASE();
  }
}

|ADD_SCHEDULER_DEAD_TIME| starte nach 30 Sekunden, wenn am Eingang |KEYER_BIT| 
kein Signal anliegt.

///////////////////////////////////////
// ADD_SCHEDULER_DEAD_TIME();
static void task_trx_on_traeger(void)
{
  if (!sem_trx_send) {
    PWM_ON();
    SET_OFF(TRX);
    timeradd( task_trx_off_traeger, SECONDS(1) );
  }
}

Nachtrag, das gesamte Bakenprojekt mit allen Daten etc. benötigt:

avr-size main.elf 
   text     data      bss      dec      hex  filename
   2172      142       50     2364      93c  main.elf

Es passt damit nicht mehr in ein attiny25 aber der attiny45v wurde dann 
für den Sender gewählt.

Mit diesem Taskmodel kann man auch einfach Flussdiagramme oder 
Petrienetze in Codeform bringen.

.

[Tobias G. (t-g-laeser)]

Vielen Dank für Eure schnellen Antworten!

Arne schrieb:
> Ich habe mal ein Projekt mit pC/OS (http://www.embedded-os.de) begonnen.
> Brauche es eigentlich nicht, war mehr Neugierde in Bezug auf RTOS. Habe
> es bis dato noch nicht beendet, da ich die HW nicht fertig habe, die die
> Sensoren auswertet.
Sieht sehr interessant aus, aber für mich als neuling im Bezug auf RTOS 
auf AVR etwas unverständlich und vermutlich schwer "anpassbar". USB, 
File-Systems, Netzwerk, ... kommt bei mir alles nicht zum Einsatz. Eher 
einfache digitale/analoge Signale.

Peter Dannegger schrieb:
> Kommt drauf an, welche Schönheit Du meinst.
> Zumindest wäre es schneller bwz. bräuchte weniger Ressourcen.
Das ist mir schon wichtig. Allgemein gefallen mir die Vorteile von RTOS 
sehr, deswegen möchte ich mich auch damit beschäftigen.

Peter Dannegger schrieb:
> Man kann auch dann prima kleine Module schreiben und aufrufen.
> Das ist auch sehr übersichtlich und erweiterbar.
Meine bisherigen Programmierprojekte bestanden immer aus Modulen, die 
durch Interrupts und Timer aufgerufen werden.
Aber wie kann ich diesen nun Prioritäten etc zuordnen, damit diese wie 
im RTOS ablaufen?

Uwe S. schrieb:
> ich kann Peter nur zustimmen und verweise auf den von ihm geschriebenen
> Scheduler:
>
> Beitrag "Wartezeiten effektiv (Scheduler)"
>
> Ich hatte erst cocoOS http://www.cocoos.net/ verwendet, das mir aber für
> die einfachen Aufgaben schon zu viel Code verbraucht.
Vielleicht ist diese Frage nun etwas blöd, aber was unterscheidet das 
nun von einem kompletten RTOS? Das ist doch komplett mit Tasks etc, oder 
täusch ich mich nun?
CocoOS sieht auch sehr interessant aus, aber eben wie bei allen anderen 
OS wie FreeRTOS etc., fehlt mir der "Arschtritt" und Anfang richtig 
damit umzugehen.

Uwe S. schrieb:
> Mit diesem Taskmodel kann man auch einfach Flussdiagramme oder
> Petrienetze in Codeform bringen.
Wie ist es mit mehreren zeitproblematischen Ereignissen hier?

Mit freundlichen Grüßen
Tobias Gläser

EDIT: Habe mich die letzten Wochen etwas mit 
http://www.femtoos.org/index.html beschäftigt...