kennt von Euch jemand zuf=C3=A4lligerweise einen Mixed Signal ARM9, der 4 ADCs mit jeweils 14 Bit Aufl=C3=B6sung (idealerweise differentiell) die bis zu 10MS/s schaffen. Dazu noch ein paar GPIOs von denen man ein paar sowohl als Edge als auch Level IRQ verwenden kann (IRQs kommen h=C3=B6chstens im kHz-Takt).
Das w=C3=A4re so der Wunschbaustein f=C3=BCr eine Me=C3=9Fwerterfassung in = meiner Diplomarbeit.
Einen entsprechenden ARM7 Cortex M3 habe ich gefunden, da l=C3=A4uft aber leider kein "richtiges" Linux drauf (=C2=B5CLinux schon, aber ich h=C3=A4tte lieber was mit 2.6er, oder 3.xer Kernel) und es mangelt doch arg am Speicher.
In meine BA-Arbeit hab ich einen Cortex M3 benutzt, der neben der Softwarefunktion
- 3 Kanal ADC (Abtastfrequenz ~800kHz)
- Webserver
- Speicherkarte (FAT)
- (G)UI
- CAN
- Standard-IO gemacht hat. Mit (Keil) rtOS waren das insgesamt 12 Threads. Das geht aber auch mit freien rtOS. Die sind nur schlechter Dokumentiert... Und die 64k Ram waren mehr als genug. Auch dem Flash des stm32f107 habe ich nicht voll bekommen.
Ich w=C3=BCrde gerne die alle 300ms anfallenden Messdaten (jeweils 4MiB Samples) direkt auf ein entsprechend schnelles Netzwerklaufwerk (NFS, CIFS, etc.) wegschreiben. Ausserdem =C3=A4ndern sich je nach Me=C3=9Faufbau= die Anforderungen der Tiggersignalauswertung, daher w=C3=A4re es sch=C3=B6n, we= nn man das Triggerprogramm nachladen k=C3=B6nnte, oder sogar direkt auf dem Teil kompilieren. =20
Einen entsprechenden Cortex M3 habe ich auch schon gefunden, der geeignet w=C3=A4re. Nur fehlt da halt die M=C3=B6glichkeit die Daten gleich= auf ein Netzlaufwerk wegzuschreiben (ausser man baut da noch NFS oder CIFS mit ein). Was absolut nicht geht ist da noch einen normalen PC mit Steuersoftware dazwischenzuschalten, denn das haben wir im Moment und davon wollen wir (wir=3DArbeitsgruppe) aus praktischen Gr=C3=BCnden wegkommen (massive Probleme mit den Sondertreibern f=C3=BCr das spezielle Netzwerkprotokoll der verwendeten DAQ-Hardware).
Tats=C3=A4chlich sind die Echtzeitanforderungen gar nicht mal so krass. Alle
300ms kommt ein Triggersignal (eigentlich Burst), das u.U. nicht einfach nur eine Flanke enth=C3=A4lt sondern eine ganze Reihe von Zustandswechseln, die jeweils etwas zu bedeuten haben (nein, ich kann daran leider nichts =C3=A4ndern). Die Zustandswechsel finden in einem
1kHz-Raster in einem Rahmen von 10ms statt. So wie das aussieht k=C3=B6nnte das irgendein serieller Leitungscode sein, der da =C3=BCber die Leitung geht, aber wir bezeichnen das einfach nur als "Trigger". Nach dem Trigger habe ich dann ~100ms Zeit ein Photodiodenarray auszulesen, die Taktung kann man selber vorgeben. Der limitierende Faktor ist die Zeit bis zum n=C3=A4chsten Trigger.
Warum kombinierst du nicht einfach einen Cortex M3 mit einem ARM9 deiner Wahl?
Die zeitkritischen ADU Aufgaben verfrachtest du in den M3, speicherst das in einen Pufferspeicher und übergibst das auf Anforderung z.B. per SPI an den ARM9 mit Linux der das ganze dann ins Netz schreibt.
Ich würde gerne die alle 300ms anfallenden Messdaten (jeweils 4MiB Samples) direkt auf ein entsprechend schnelles Netzwerklaufwerk (NFS, CIFS, etc.) wegschreiben. Ausserdem ändern sich je nach Meßaufbau die Anforderungen der Tiggersignalauswertung, daher wäre es schön, wenn man das Triggerprogramm nachladen könnte, oder sogar direkt auf dem Teil kompilieren.
... nimm blos kein Netgear, da erlebst Du böse Überraschungen :-) ...
Ich sehe (für einen Informatiker) kein großes Problem den vorhandene TCP/IP-Stack vom rtOS entsprechend aufzubohren. Dürfte eher eine Fleissarbeit werden. Du brauchst dabei nichtmal auf Ressourcen zu achten. Bei meiner (nicht optimal programmierten) Software hat der Cortex sich größtenteils an den Füssen gespielt. Ich habe bei 72MHz alle
100ms einen Script abgearbeitet, inclusive Protokoll auf FAT-SD-Karte...
Nortfalls könnte man schnell und dreckig die Daten auf eine FAT-SD-Karte schreiben, und 1x Minute per FTP pollen. Falls es mal klemmt, auf 4GB geht ne Menge drauf...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.