Embedded Linux und Echtzeit

[Andreas T. (bugmonster)]

Ich suche ein System, dass ich als Linux-Maschine konfigurieren kann und 
welches mir gleichzeitig die Echtzeitfähigkeiten eines kleinen 
Mikrokontrollers bietet. Im Moment verwende ich den Raspberry Pi und 
will ein paar einfache Wandlungen machen. Das funktioniert zwar, aber 
eher schlecht bzw. unhandlich. Ich muss da für meine Zwecke jetzt wohl 
einen kleinen Mikrokontroller andocken, der dann eine schnelle 
verlässliche Signalverarbeitung ermöglicht. Gibt es da Empfehlungen für 
ein System, was das schon leistet? Eventuell Arduino Yin?

Andreas

[atmi (Gast)]

Äh, ist dir ueberhaupt klar was der Begriff "Echtzeit" eigentlich 
bedeutet?

Was benötigst du:
 - Harte Echtzeit
 - Weiche Echtzeit?
 - Was sind die kritische Latenzen?
 - Welcher Jitter ist erlaubt?

Käre die Anforderungen bevor du dir etwas suchst ...

[Andreas T. (bugmonster)]

Nun, das mit der Echtzeit ist vielleicht etwas naiv von mir ausgedrückt. 
Ich habe eine TSIC 306 Wärmesensor an ein GPIO-Pin des Raspberrys 
angeschlossen. Der überträgt seine Daten digital mit einer nominalen 
Baud-Rate von 8kHz. Ich polle das Pin und muss jetzt Zeiten messen (so 
ca.125 us vs. 30 us). Dieser naive Ansatz funktioniert. Allerdings macht 
Linux dauernd mal was anderes und ich kann die Zeiten nicht einhalten. 
Meine Lösung: Es war einfach diesen 'Jitter' softwareseitig zu erkennen 
und die Werte dann zu verwerfen (macht ein C-Programm). Damit lese ich 
die Werte mit sehr hoher Zuverlässigkeit jetzt aus. Lediglich: das Ganze 
erscheint mir ziemlich gebastelt. Jetzt habe ich einen MCP 3008 
Analog-Wandler angeschlossen. Hier würde ich gerne mit einer 
einigermaßen genauen Samplingfrequenz von ca. 1 kHz Werte einlesen. Im 
ersten Schritt habe ich ein kleines python Programm geschrieben, nur 
weil das leicht zugänglich und recht gut dokumentiert war. Natürlich 
weiß ich hier garnichts über die Samplingfrequenz. Ich lese so schnell 
es geht und erhalte schon mal halbwegs brauchbare Werte. Die Genauigkeit 
muss ich noch checken.

Ich habe jetzt überlegt, einen anderen Mikrokontroller via SPI 
anzudocken, dort dann ein Programm zu schreiben, welches nicht dauernd 
von irgendwelchen Interrupts für unbestimmte Zeit unterbrochen wird. Das 
ist natürlich auch ein ziemlicher Aufwand. Alternative Echtzeit Linux. 
Ist aber nach dem was ich so gelesen habe auch sehr Aufwendig und 
erscheint mir nicht richtig 'professionell'. Deswegen die die Idee: gibt 
es vielleicht ein Gerät, welches dieses Problem schon im Auge hat. Das 
Problem haben andere doch auch. Man möchte die Simplizität eines kleinen 
Mikrokontrollers gepaart mit dem Komfort eines Linux-Systems.

Also eventuell Arduino-Yin?

Andreas

[nixBus (Gast)]

Häng einen µC davor un dfrage den dann vom PI mit i2c/rs232/wasauchimmer 
ab.

[Strubi (Gast)]

Hi Andreas,

richtig gute Echtzeit (Bereich von wenigen us) kriegst du nur mit der 
Xenomai-Erweiterung und speziell darauf angepassten Kerneltreibern hin.
Ebenso musst Du deinen Userspace darauf anpassen, d.h. die Funktionen 
nutzen, die sofort auf das Eintreffen eines Ereignissen ("Transfer 
abgeschlossen" reagieren.
Wie gut die Echtzeit ist, hängt aber wieder vom Gesamtsystem, 
insbesondere der CPU und dem Clock, Interrupt-Handling oder DMA-Engine 
ab.
Bei richtig harten Anforderungen geht's wohl nicht ohne externen uC, 
bzw. macht dann eine Dual-Core-Geschichte ev. Sinn, wenn es Leistung 
braucht.

Grüsse,

- Strubi

[A. B. (funky)]

SPI kann auch der Raspberry.
Desweiteren kann der Rasperry auch GPIO Interrupts ( WiringPi kannste 
dir mal anschauen)

Aber irgendwleche Echtzeitanforderungen für eine Temperaturmessung zu 
definieren ist schon sehr mit Kanonen auf Spatzen geschossen.
Ich würde aber sagen, das ein I2C bzw SPI Temperatursensor die bessere 
Wahl für einen Raspberry darstellt, anstatt das man da die ganze Zeit 
ein 8kHz Signal abfragen muss(wobei man das mit IRQs ja auch nicht 
wirklich muss).
Du schickst eine Kommando und bekommst als Antwort die Temperatur. Und 
ob das nun 100mal die Sekunde oder nur einmal passiert ist bei 
Temperatur doch eher Wurscht, oder was hast du vor?

[Andreas T. (bugmonster)]

@Strubi:
Da bin ich beim Suchen auch schon drüber gestolpert. Ich habe es dann 
verworfen, weil ich mal annehme, dass man mindestens so zwei volle Tage 
braucht um das zu laufen zu kriegen. Also, ich war diesbezüglich 
abgeschreckt. Vielen Dank für den positiven Hinweis.

[Andreas T. (bugmonster)]

@funky:
Ich habe das auch per interrupt versucht - war nicht besser. Da hätte 
ich eventuell einen Kerneltreiber schreiben müssen. Ich habe angefangen 
mich da einzulesen.

Du hast recht. Das Problem entsteht überhaupt nur durch das sog. 
Zacwire-Protokoll des TSIC 306. Ein SPI-Sensor wäre wohl die einfachste 
Lösung. Wußte ich zu Anfang nicht. Ich hatte beim meiner Suche keinen 
Sensor gefunden, der die Genauigkeit des TSIC 306 (ca. 0,3K im 
Raumtemperaturbereich mit autom. Kalibrierung) hatte. Ich werde noch mal 
nach SPI Sensoren suchen.

Ja, ich nehme im Moment alle 30 Sekunden einen Wert im Wechsel zwischen 
zwei Sensoren. Dafür ist eigentlich keine Echtzeit nötig.

[Maxx (Gast)]

per I2C: SHT21

http://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/Humidity/Sensirion_Humidity_SHT21_Datasheet_V3.pdf

0.3° typical tolerance zwischen 5 und 60°C