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.
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.
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.
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?
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]
@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.
