Hallo, ich muss Daten von zwei Geräten über eine RS232 Schnittstelle und einer weiteren über SPI abholen und auf eine SD Karte schreiben (also eine Art Daten logger). Das "SPI-Gerät" liefert dabei ca. 800 mal pro Sekunde 20 Byte, ein "RS232-Gerät" vier mal pro Sekunde 300 Byte mit 9600 Baud, das andere sieben mal pro Sekunde 110 Byte mit 19200 Baud. Es sollen unbedingt alle Daten auf die SD Karte geschrieben werden, es darf also kein Datensatzt verloren gehen weil z.B. wegen des Empfangs auf einem Port der andere nicht gelesen werden kann. Ich hatte nun folgende Idee welche ich hier mal zur Diskusion stellen möchte: Ich nehme für die beiden "RS232-Geräte" je einen ATMega8, lese uber das UART die Daten ein und lege sie in einem Puffer ab. Über einen Ausgang signalisiere ich einem (dritten) ATMega?? dass neue Daten zur Abholung bereit stehen. Dieser "Master" Controller erhält 800 mal pro Sekunde vom "SPI-Geräte" einen Interrupt und holt in dessen Folge die 20 Byte von diesem ab. Danach fragt er die beiden ATMega8 an den "RS232-Geräten" über die o.g. Leitungen ab, ob dort seit der letzten Abfrage neue Daten vorliegen. Falls ja, holte er diese über SPI. Dann schreibt er die Daten des "SPI-Gerätes" und ggf. die der "RS232-Geräte" auf die SD Karte und wartet auf den nächsten Interrupt des "SPI-Gerätes". So könnten sich die Datenquellen nicht gegenseitig stören. Da der "Master" weit öfter abfragt als die "RS232-Geräte" neue Daten liefern, wären die Puffer immer geleert wenn neue Daten ankommen. Was haltet Ihr davon? Schiesse ich hier mit Dynamit auf Spatzen weil ich drei uC verbraten will? Gruß Ralf
Wie wäre es, wenn du den ATmega162 oder "was noch größeres" nehmen würdest? Der 162 hat schon 2 USART und SPI sollte er auch irgendwie unterstützen (weiß jetzt gerade nicht, ob er ein Hardware-SPI hat). Das sollte man also eigentlich alles mit einem Controller hinbekommen. Mehrere würde ich erste nehmen, wenn sie räumlich getrennt sein müssen.
Ich habe vor allem Bedenken, dass ich Probleme bekomme wenn z.B. gerade Datem vom "SPI-Gerät" geholt werden und dann womöglich zeitgleich beide RS232 ihre Daten senden. Irgendetwas müsste dann warten und es könnten vielleicht DAtenverlogen gehen.
Du solltest dir auch noch Gedanken darüber machen wo du deine Daten lässt wenn die SD Karte gerade mal wieder ein Schläfchen von z.B. 110ms wegen Wear Levelling macht. Eine meiner Karten macht da gelegentlich sogar 310ms! Die Dinger taugen nur als großer Datenspeicher wenn man ausreichend RAM zum puffern oder eine Menge Zeit hat.
Ooops! Das wußte ich noch gar nicht. Was könnte man den außer einer SD-Karte auf die Schnelle nehmen?
Das sollte alles kein Problem sein. Das Datenaufkommen ist extrem klein. 1600byte vom SPI, 1200byte vom einen seriellen, 770 vom anderen, zusammen etwa 3.5kByte pro Sekunde. Das ist ein Vielfache unter der Spezifikation einer SD Karte. Etwas kleineres wie einen Mega644 wuerd ich aber nicht nehmen.
> vier mal pro Sekunde 300 Byte mit 9600 Baud, das andere
Geht das ?
Sehr gute Frage, nein, das kann nicht gehen.
Nochmal Oops :-/ das war nur so dahin geschätzt, geht aber ja schon rein rechnerisch nicht. Es könnten auch ein paar Byte weniger sein oder man müßte die Bausrate erhöhen. Dabei ändert sich das Grundproblem aber eher wenig...
Sofern Du interruptgesteuertes Empfangen und Senden verwendest und ausreichende Sende- und Empfangspuffer verwendest, sollte es zu keinen Problemen kommen. Nimm halt 'nen Controller, der mehr als nur ein paar Bytes RAM für diese Puffer aufweist.
Angehängte Dateien:
-
Datenlogger.jpg
190 KB
Halo Ralf, Wenn Du noch keine Hardware hast, ich hätte ein Board mit vielen Schnittstellen drauf und einen ARM Prozessor und SD-Card Interface. Anbei ein Foto davon. Wäre interesse da? - LPC2368 - 2x CAN - 2x Seriell - 2x RS485, oder Digitale IOs - IIC - SPI - Ethernet - USB - SD/MMC Card (auch Micro-SD) - RTC, Goldcap oder Batterie - DC-Versorgung bis 30V - Passend für Bopla Gehäuse EG1530
Nun ja, wenn dann Daten an einem UART ankommen gibts eine Interrupt in dessen Folge diese Daten eingelesen werden. Wenn das aber genau dann passiert, wenn über SPI Daten von dem anderen Gerät gelesen werden oder gerade auf die SD Karte geschrieben wird, gibts da nicht Probleme?
@Markus: Was soll das Teil denn kosten? Kann sein, dass ich mich erst morgen wieder heir melde, muß gleich weg...
Wichtig ist, dass in jedem Fall ein Interrupt ausgelöst wird und dieser so schnell wie möglich mit wenig Code abgearbeitet wird. Einfach Daten auslesen und in einem Array puffern. Damit sollte es keine Probleme geben. Meine Software habe ich so programmiert, dass niemals im Code gewartet wird. Bei 57MHz schafft die CPU über 100000 Main-Zyklen. Ich lasse die jetzt mit 19MHz laufen, dann sind es immer noch 22000 Main-Zyklen. Damit kann noch allerhand angestellt werden. Die SD-Karte würde ich im Main-Loop beschreiben, dann können Interrupts jederzeit bei neuen Daten das Schreiben unterbrechen und es werden alle ankommenden Daten sicher abgeholt. Die CPU hat über 50KB RAM, da hat einiges Platz. Die Kosten sind stark abhängig von der gewünschten Bestückungsoption und von der Software, ja nach dem was Du haben willst. Benötigst Du das als Einzelstück? Privat oder gewerblich?
> Nun ja, wenn dann Daten an einem UART ankommen gibts eine Interrupt in > dessen Folge diese Daten eingelesen werden. Ja, für jedes einzelne Byte genau einmal. Nun überlege mal, wie lange potentiell so eine Interruptroutine damit beschäftigt ist, ein Byte aus dem UART-Empfangspuffer zu holen, in ein Array im RAM zu kopieren und den Arrayindex zu erhöhen. Nicht wirklich lange. > Wenn das aber genau dann passiert, wenn über SPI Daten von dem anderen > Gerät gelesen werden oder gerade auf die SD Karte geschrieben wird, > gibts da nicht Probleme? Ich gehe mal davon aus, daß Du Hardware-SPI verwendest - auch das kann wiederum interruptgesteuert arbeiten. Da die oben beschriebene Interruptroutine ganz erheblich weniger Zeit benötigt, als die Übertragung eines einzelnen Bytes über die UART, steht also zwischen den empfangenen Bytes sehr viel Zeit für das Verarbeiten und Wegschaffen der Daten zur Verfügung. Das einzige Problem besteht in der Doppelnutzung der SPI-Schnittstelle, über die sowohl zyklisch Daten empfangen und versendet werden sollen, versendet nämlich an die SD-Karte. Da wäre eine andere Ansteuerung der SD-Karte, entweder über eine zweite SPI-Schnittstelle oder eine in Hardware mit Schieberegistern aufgebaute SPI-Schnittstelle, die parallel angesteuert werden kann, angesagt. Letztere Lösung wäre vielleicht auch zum Empfang der SPI-Daten vom dritten Gerät geeignet, da dieses Deiner Beschreibung zufolge sogar mit einer Steuerleitung das Vorhandensein von Daten signalisieren kann. Wenn es das für jedes Byte einzeln tut, dann sollte die Angelegenheit so lösbar sein. Ein µC mit vier Schnittstellen (zwei UARTs und zwei SPI-Schnittstellen) wäre da sicherlich die eleganteste Lösung. Wenn ich die eingangs genannten Zahlen addiere, kommen da um die 4 kByte pro Sekunde zusammen - ein Pufferspeicher für eine Sekunde dürfte mehr als ausreichend sein, um jede auch noch so merkwürdige SD-Karte zu beschreiben. Solange Du ausreichend Speicher hast, um die schwankende Schreibrate der SD-Karte zu kompensieren, sehe ich kein Problem.
Der LPC2368 hat ein MMC-Interface mit drin, der kann sogar die SD-Card mit 4 Datenbit breitem Bus ansteuern. Dabei ist auch der MMC Teil über DMA nutzbar, somit sollte die Prozessorlast überschaubar klein sein. (Infos unter: http://www.standardics.nxp.com/products/lpc2000/lpc23xx/~LPC2368/)
Hi, Ich nutze einen AtMega162 @ 16 Mhz mit 2 UARTs bei 250.000 baud und habe damit keine Probleme. Wenn Du die SD-Karte per Software-SPI im Main-Loop ansteuerst, sollte das doch ein sehr überschaubares Programm werden. Das müsste sogar auf Lochraster passen… Konrad
> ... sollte das doch ein sehr überschaubares Programm werden. > Das müsste sogar auf Lochraster passen… ? Du meinst wohl, daß das Programm auf Lochkarte paßt :-)
[sarkasmus] Also ich würde da eine Z80 CPU verwenden, die gibts im DIL Format da ist eine Komplette CPU schon fix und fertig drin. Die B Ausführung läuft sogar mit 6MHZ. Nur noch ein paar wenige Bauteile drum herum (EEPROM, RAM, Z80PIO usw.) schon hat man ein tolles Board. Man muss nur noch per Software die serielle Schnittstelle und SPI emulieren, aber das macht ja sowiso jeder heutztage. Ich verwende diese CPU's schon seit 15 Jahren und verstehe überhaupt nicht warum neue erfunden wurden. Schlussendlich ist das ganze auch viel billiger weil alles bei E*B*A*Y für Keingeld zu haben ist. [/sarkasmus]
Dass du seit 15 Jahren mit dingern arbeitest, merkt man :-)
@Markus: Ich wäre auch sehr an Deinem Board interessiert. Kannst Du die möglichen "Optionen" und einen ca. Preis nennen? Ich würde gerne 4x RS232 bzw. 3xRS232/1xUSB bzw 2x RS232/1xUSB loggen wollen (höchste Loggingfrequenz 50 bzw. 100Hz). Anwendung privat, evtl auch nur das rohe Platine. Ciao, Bennie
Ich hab mal alle Funktionen/Optionen zusammengestellt, siehe PDF. Am günstigsten wird es sein, wenn ich die Platine zur Verfügung stelle und ev. noch ein paar Bauteile. Der Preis wird bei ca. 300 EUR liegen, darin enthalten die Platine, Bauteile, Schaltplan. Derzeit muss ich diese noch selbst von Hand löten. Daher ist alles sehr Zeitintensiv und aufwändig. Für Hobby Bereich ist da eher ein Development-Board sinnvoll, da günstiger. Meine Schaltung hat den Vorteil, dass sehr viele Schutzbeschaltungen (Supressordioden, Spulen, galvanische Trennung, usw.) enthalten sind, die auf den Demo-Boards meist fehlen. Es kommt hier auf das Einsatzgebiet an. Also im freien Feld würde ich nicht mit einem Demo-Board hantieren wollen. Und natürlich das Gehäuse...
@Markus: Danke für die exakte Aufstellung- wirklich sehr beeindruckend! Leider ist auch der Preis aber zu hoch um dieses Board nur fürs "Hobbybasteln" zu verwenden; Hatte ich schon fast vermutet, insbesondere mit dem Passgenauen Gehäuse wirklich eine sehr professionelle Lösung. Ciao, Bennie
@Bennie: Hast Du schon mal LPC2xxx programmiert und USB zum laufen bekommen? Ich habe gerdae das Problem, dass der PC die Bulk Telegramme nicht empfängt und ich könnte Unterstützung gebrauchen. Dann liese sich auch einiges am Preis machen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.