Bislang habe ich mir meine Controller immer selber aufs Bord genagelt
und Peripherie dran gehängt. Für die jetzige Anwendung scheint aber
etwas fertiges wie ein Pi das Richtige zu sein (Da er alle Hardware
hat). Bislang habe ich aber noch nichts mit PIs zu tun gehabt:
Aufgabe
- 16 Bit-SAR-ADC mit 1 MSPS an CPU anschließen
- Timer auf 1 us
- binnen 1 us
- ADC auslesen
- Wert in RAM aufnehmen
- nach Messende Speicher auf SD schreiben
oder
- direkt auf Karte speichern.
- Start und Stopp der Aufzeichnung über Bluetooth-COM
Mit einer SD habe ich noch nicht gearbeitet, evt. macht ein OS Sinn.
Wenn ich 32 Bit mit 1 MSPS für 10 s speichern will, dann brauche ich 38
MByte RAM. Damit befinde ich mich definitiv außerhalb des Bereichs von
µCs.
Ich habe den Pi Zero im Auge. Ich denke mir reicht 1 Core. Am liebsten
würde ich Bare Metal ohne OS programmieren und für die SD-Karte eine Lib
verwenden.
Macht das generell Sinn oder gibt es geeignetere Bords?
Letztlich wird es nur ein Datenlogger, aber ein schneller.
Viele Grüße!
Marko
PS: Was für ein ADC ist für das Audio genutzt? Kann ich das zum Messen
nehmen?
:
Bearbeitet durch User
Was für ein Signal willst du denn mit dem ADC erfassen? Wenn du jede ADC Wandlung mit dem Raspberry anstößt, dann haben die Abtastwerte vermutlich keinen gleichen zeitlichen Anstand zueinander. Grob ja, aber ich vermute da ist dann sehr viel Jitter drauf weil das eben aus einer CPU kommt die noch andere Dinge nebenbei machen muss.
> Damit befinde ich mich definitiv außerhalb des Bereichs von µCs. Das ist schonmal Unfug. > Am liebsten würde ich Bare Metal Dann viel Spass mit der voellig lueckenhaften Dokumentation. Ich wuerde ein FGPA nebst NIOS2 ins Auge fassen. Da gibt es guenstige fertige Boards vom Chinesen die zumindest schon 32 MB (SD-)RAM mit an Bord haben. Aber ein Renesas SH-3/4 inkl. moderner Typen koennten das auch. Und ARMe mit Speicherinterface natuerlich auch.
Ich hoffe dass ich auch auf dem PI die Kontrolle über einen Timer habe und meine Messfunktion von diesem Timer-Interrupt anstoßen lassen kann. Auf den µC bin ich mein eigener Herr, da gehören alle Timer mir. Wie sieht das im Pi aus wenn da ein OS drauf läuft?
Ein PPGA-Projekt wollte ich eigentlich nicht anfangen. Ich hatte mal mit einem Zynq ein Kameramodul per DMA ausgelesen. Das hat ewig gedauert bis ich das am laufen hatte. Aber ein 1 MSPS-Signal abzutasten sollte mit reiner Programmierung funktionieren. Ich will halt jetzt keine Eigenentwicklung anfangen, nur um am Ende zu lernen dass es eine fertige geeignete Lösung gibt.
Larry schrieb: > Und ARMe mit Speicherinterface natuerlich auch. Jepp, das wäre auch mein Favorit, ein STM32F4 mit externem RAM. Von PI würde ich ebenso abraten, der TO wird wegen mangelnder Dokumentation an der Bare-Metal-Programmierung scheitern. Allenfalls käme noch ein BeagleBone Black in Frage: Beitrag "Re: MCU mit 64Mbyte RAM" Dr. Sommer schrieb dort: Das Beagle Bone Black hat 512 MB SDRAM. Der Prozessor ist weitgehend dokumentiert, kann bare-metal programmiert werden, ist dank PRU hart Echtzeit-fähig und kann praktisch alles was ein Mikrocontroller kann. Meistens wird man ihn aber mit Linux benutzen. Kostet ca 60€.
Wie wäre es mit einen Red Pitaya? Da ist alĺes schon an Board https://www.reichelt.at/usb-messlabor-stemlab-125-14-starter-kit-2-kanaele-50-mhz-usb-stemlab-14-sk-p187257.html?&nbc=1&trstct=lsbght_sldr::148362 https://de.m.wikipedia.org/wiki/Red_Pitaya Aber wahrscheinlich ist es zu teuer. Aber Zeit ist bekanntlich Geld. Für weitere eigene Boards kann man dann das FPGA (Field-Programmable Gate Array) (Xilinx Zynq 7010), maßgeschneidert ohne unnötiges Rundherum einsetzen. (falls es sich finanziell überhaupt lohnt)
Marko R. schrieb: > Wenn ich 32 Bit mit 1 MSPS für 10 s speichern will, dann brauche ich 38 > MByte RAM. Damit befinde ich mich definitiv außerhalb des Bereichs von > µCs. Doch, das geht. Da gibts doch was von Ratiopharm ... ähm ... Microchip: PIC32MZ1064DAR176 https://www.microchip.com/wwwproducts/en/PIC32MZ1064DAR176 Der hat 640k SRAM und 32MB DDR2 DRAM mit im Package mit drin. Du brauchst Dich nicht um DDR2-Layoutgeschichten etc zu kümmern, und TFQP im 0.5mm Raster ist auch von Hand noch lötbar. Das wäre Deine Lösung, bei der Du das gesamte Timing selber im Griff hast, ohne mit FPGA etc ein neues großes Fass aufmachen zu müssen. > PS: Was für ein ADC ist für das Audio genutzt? Kann ich das zum Messen > nehmen? Nein. Audio ist speziell. Audio ist zum Beispiel gleichspannungsfrei. Dein Signal wird es wahrscheinlich nicht sein. Das menschliche Ohr geht bis 20 kHz, Audio also bis 48 kSPS oder mit 4-facher Überabtastung bis 192 kSPS. Nix mit 1MSPS. Spezifiziere erstmal Deine Anforderungen: Was ist das für ein Signal, welche Eigenschaften hat es, wo kommt es hier, Abtastrate, Auflösung,... fchk
Ein Zero ist natürlich verlockend, schon allein wegen Takt und Speicher bei dem Preis. Wie hier aber bereits geschrieben wurde ist die Dokumentation lausig. Die Hardware ist proprietär und Infos gibt es nur in Bruchstückchen. Anyway, ein interessantes FrameWork für Bare Metal gab es mit Ultibo. Ich weiß allerdings nicht wie weit das noch gepflegt wird. Und, es ist in Pascal. Wenn es "nur" um das Sampling geht, dann kannst du auch versuchen mit der DMA aus dem Linux Userland heraus zu "spielen". Die kann man (etwas aufwendig) so einstellen, dass sie abwechselnd den ARM Timer und die Pins liest. -- Braucht also viel Speicher. -- Da mußt du danach dann rüber und dir die passenden Samples heraus suchen. Ich hatte keine Möglichkeit gefunden den DMA Takt einzustellen. Man kann aber mit den Timings herumspielen. -- Also alles Bastelei. ;-)
PS: Schau Dir mal den ADC an: https://www.analog.com/media/en/technical-documentation/data-sheets/231016f.pdf fchk
Der PIC32MZ1064DAR176 sieht gut aus. Dann kann ich auch eine 1Bit-SD-Anbindung machen. Ich will das Druckspektrum in einem Gefäß messen. Ich vermute Frequenzen bis 100 kHz und will daher mit 1 MSPS abtasten. Die Membran meinen Drucksensors hat bei 10 kHz eh ihre Resonanzfrequenz und macht mit typischem PT2-Verhalten danach dicht. Der Plan ist also einen AD7984 (getrieben von einem ADA4940) zwischen CPU und meinem analogen Frontend zu hängen. Parallel muss ich noch das Temperatur-Signal wandeln, das kann aber langsam passieren, da suche ich mir einen Delta-Sigma für aus. Das Red Pitaya sieht gut aus, ich denke aber mal die haben das die RX-ADCs verwendet. Die sind für die Sprektrummessung OK, für den Temperatursensor reicht aber deren DC-Verhalten nicht. Ich traue es mich ja fast nicht zu sagen, aber Geld spielt nicht ganz so die Rolle, etwas Hardware darf ich schon einkaufen. Entwicklungszeit zu sparen ist wichtiger, da die Messung nur 1x gemacht wird. Ich will halt nicht sofort zum Eagle greifen und meine Schaltung einhacken, nur damit dann jemand mit was fertigen um die Ecke kommt. Daher jetzt erstmal die Rundumsicht wie man es angeht: Voll selber entwickeln oder gibt es was fertiges. Und während ich schon Lust hätte das PIC-Monster zu nehmen, sind das Ziel halt nur die Messdaten. Ach ja: Der Behälter ist in Drehbewegung, was heißt: Batteriebtrieb und Funk.
Marko R. schrieb: > Der PIC32MZ1064DAR176 sieht gut aus. Dann kann ich auch eine > 1Bit-SD-Anbindung machen. Wieso 1 Bit? Das Teil hat einen kompletten 4 Bit SDHC Host an Bord. > Ich will das Druckspektrum in einem Gefäß messen. Ich vermute Frequenzen > bis 100 kHz und will daher mit 1 MSPS abtasten. Die Membran meinen > Drucksensors hat bei 10 kHz eh ihre Resonanzfrequenz und macht mit > typischem PT2-Verhalten danach dicht. Der Plan ist also einen AD7984 > (getrieben von einem ADA4940) zwischen CPU und meinem analogen Frontend > zu hängen. > Parallel muss ich noch das Temperatur-Signal wandeln, das kann aber > langsam passieren, da suche ich mir einen Delta-Sigma für aus. Der PIC32 hat 6 einzelne 12 Bit ADCs mit bis zu 3 MSPS dabei, da brauchst Du keine externen ADCs. Im Prinzip bräuchtest Du auch für Deine Druckmessung einen der internen ADCs verwenden, wenn Dir 12 Bit reichen. Die 4 extra Bits erfordern einen erheblichen zusätzlichen Aufwand, um nicht im Rauschen zu enden. > Ich traue es mich ja fast nicht zu sagen, aber Geld spielt nicht ganz so > die Rolle, etwas Hardware darf ich schon einkaufen. Entwicklungszeit zu > sparen ist wichtiger, da die Messung nur 1x gemacht wird. Wenn Platz kein Problem ist, dann schau hier: https://www.microchip.com/DevelopmentTools/ProductDetails/DM320008 http://ww1.microchip.com/downloads/en/DeviceDoc/70005311A.pdf Da ist eine BGA-Version drauf mit externem 128MByte DDR2-DRAM und ohne Crypto-Zeugs. Crypto solltest Du nicht brauchen. Das externe DDR2-DRAM ist genauso schnell wie das interne, aber eben extern und Faktor 4 mehr. Das sollte dann für Deine Geschichten allemal reichen. SD-Karten-Slot ist auch drauf, und Dein eigenes Zeugs schließt Du an die beiden Stecker auf der Unterseite an. Debugger ist auf den Board drauf, d.h. ein externes PICKIT entfällt auch. Damit hast Du dann relativ wenig Hardwareaufwand. fchk
:
Bearbeitet durch User
OK, das sieht echt verlockend aus. Platz ist ein Problem, weil das ganze mit bis zur 100 Umdrehungen pro Sekunde dreht. Da will ich so wenig Zeug wie möglich dran haben. Ich muss jetzt erstmal weg (Kind abholen). Ich melde mich morgen. Vielen Dank, in diese Richtung hatte ich noch gar nicht gedacht. PS: BGA ist kein Problem.
PS: Die Kumpels hier arbeiten alle auf SAM. Mein letztes Projekt lief auf einem ATTiny ;-)
Vom Pi Zero (und dann auch noch bare metal) würde ich eher die Finger lassen. Wenn schon Linux-Kiste, dann auf jeden Fall eher ein Beaglebone, den gibt es sogar als "Beaglebone on a Chip" als BGA, inkl. DDR-RAM, etc. im 1,27mm Pin-Pitch BGA (von Octavo Systems). Wenn du noch nicht so viel Erfahrung im Linux-Umfeld hast, dann ist das mitunter aber auch nicht ganz ohne. Der Bb ist zwar schon relativ lange am Markt und mitunter einer der am besten dokumentierten SBCs aber es geht trotzdem nicht alles voll automatisch. Falls dir etwa "device tree binaries" (dtb) nichts sagen, dann hast du mitunter schon Spaß, um nur einen dämlichen UART auf irgendwelche Pins zu konfigurieren (ging jedenfalls mir am Anfang so). Witzigerweise habe ich zu Unizeiten selber mal an einem Projekt mitgearbeitet, bei dem das DAQ-System mitrotiert ist (war auf ATMEGA-Basis) und ein wichtiger Punkt je nach Drehzahl (und die waren bei uns niedriger als 6k rpm) ist natürlich noch die Energieversorgung durch Batterien oder Akkus und da ist ein Beaglebone sicherlich um Größenordnungen hungriger als ein PIC32, STM32, SAM, etc. und dementsprechend größer musst du die Akkus dimensionieren.
OK, eine Nacht drüber geschlafen denke ich werde ich eine STM32 nehmen, der mir einen DMA vom internen ADC --> Quad-SPI SD-Karte ermöglicht. Wenn der Quad-SPI einen Puffer hat, dann sollte das funktionieren und ich kann auf den riesen RAM verzichten. Ich denke so brauche ich im Programm nur noch den DMA einrichten und starten. Den Rest macht dann die Hardware bis ich das wieder stoppe. Ich schau jetzt mal welches das kleinste Eva-Board ist das mir eine SD-Karte zur Verfügung stellt und ich denke damit starte ich dann. Viele Grüße! Marko
Marko R. schrieb: > OK, eine Nacht drüber geschlafen denke ich werde ich eine STM32 nehmen, > der mir einen DMA vom internen ADC --> Quad-SPI SD-Karte ermöglicht. > Wenn der Quad-SPI einen Puffer hat, dann sollte das funktionieren und > ich kann auf den riesen RAM verzichten. Denke daran: SD-Karten sind nicht deterministisch, die können durchaus mal eine halbe Sekunde pausieren, und sie tun das auch. Du hast keinen Einfluss darauf. Das einzig positive an SD-Karten ist, dass sie groß und billig sind. Beides brauchst Du hier nicht. Und SD-Karten nachen eben kein Quad-SPI, sondern nur 1-Bit SPI, und für die schnellen Übertragungsmodi musst Du eh das native 4 Bit MMC/SD Interface implementieren. Wenn, dann solltest Du NOR-Flash nehmen. Sowas z.B. https://www.digikey.de/product-detail/de/micron-technology-inc/MT25QL01GBBB8ESF-0SIT-TR/557-1981-1-ND/9673962 Das ist ziemlich deterministisch, weil es keinen Controller enthält. Und es ist schnell. Wenn Du es damit nicht hinbekommst, brauchst Du wirklich RAM. fchk
Frank K. schrieb: > Wenn, dann solltest Du NOR-Flash nehmen. Sowas z.B. > > https://www.digikey.de/product-detail/de/micron-technology-inc/MT25QL01GBBB8ESF-0SIT-TR/557-1981-1-ND/9673962 > > Das ist ziemlich deterministisch, weil es keinen Controller enthält. Und > es ist schnell. Wenn Du es damit nicht hinbekommst, brauchst Du wirklich > RAM. Etwas zwischenspeichern muss man mit NOR Flash sicher auch, die Page Program Time ist sicher > 1us. Also 2 DMA Kanäle, 1 DMA von ADC -> Interner SRAM. Wenn eine Page voll ist, dann beim 1. DMA den Buffer wechseln und mit 2. DMA die Daten zum Flash schieben.
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.