Hallo! Worum geht es hier: Ich will etwas bauen, das viele Daten von einem Sensor über I2C ausliest, diese minimal verarbeitet, in einen Puffer einliest und diesen dann periodisch als plain-text auf eine SD-Karte mit FAT16/FAT32 schreibt. Es ist erforderlich, dass der I2C mit 400 kHz läuft, da sonst schon das Auslesen zu lange benötigt. Es entstehen etwa 100 kbyte plain-text pro Sekunde, zwei Puffer für je eine Sekunde passen in etwa 32 kbyte Arbeitsspeicher. Das Auslesen soll von einem Timer-Interrupt gesteuert werden, damit die Daten regelmäßig gelesen werden. Die SD-Karte wird beschrieben, wenn der jeweilige Puffer voll ist und soll das Auslesen nicht stören. Das soll natürlich abgeschlossen sein, bevor der andere Puffer gefüllt ist, damit man dann kontinuierlich die SD-Karte mit Sensordaten füllen kann. Nun zu meiner Frage: Ich benötige eine Prototyping-Plattform, die es mir ermöglicht, das innerhalb weniger Tage (eigentlich innerhalb eines Tages) zu implementieren. Ich hätte also gerne eine Lösung, bei der ich mir nicht erst dutzende gcc-Compiler zusammensuchen und installieren darf, Datenblätter zu Taktsystemkonfigurationen durchsuchen muss, etc., sondern einfach etwas, das funktioniert. Ich will damit nicht in eine Großserie gehen, sondern einfach ein Problem lösen. Codeeffizienz und -eleganz sind also zweitrangig. Ich habe leider keinen Überblick über die Lösungen auf dem Markt, vielleicht könnt ihr mir da helfen. Schön wäre sowas wie der Arduino mit vernünftiger IDE, aber ich befürchte, dass der AtMega zu langsam ist und zu wenig Arbeitsspeicher hat, um diese Aufgabe zu bewältigen. Meine Vermutung wäre also, dass eine ARM-Lösung geeignet wäre, aber ich habe da keine Ahnung, welche Boards welcher Hersteller meine Anforderungen erfüllen könnten. Wichtig ist, dass es Codebeispiele und Libraries gibt, mit denen ich meine Anforderungen umsetzen kann. Ich habe für dieses Projekt leider keine Zeit, mich intensiv einzuarbeiten.
Nimm Geld in die Hand, und lasse es jemanden machen, der es kann.
Dann nehme doch das was Du schon kennst, dann entfällt schon mal die
Einarbeitungszeit in Plattform und Toolchain.
Was verwendest Du denn bis jetzt ?
Ich kann mir zwar das Schmunzeln kaum verkneifen wenn ich daran denke
wie Du Dich in einem Tag in Plattform, Toolchain, LIBs und Code
einarbeitest, aber was sollst.
Wie kommst Du von 400Khz I²C auf 100kb text ?
Max H. schrieb im Beitrag #3980527:
> könnte er das mit einem RasPi
Der der schon mit einem Raspi per Du ist könnte das vieleicht, wenn das
undeterministische Zeitverhalten von Linux nicht stört.
Der würde aber andere Fragen stellen.
Michael Knoelke schrieb: > Wie kommst Du von 400Khz I²C auf 100kb text ? Wenn man z.B. signed 8bit dezimal ausgibt kommt man schon auf 4 ASCII Zeichen (32bit), dazu vllt. noch ein bisschen Formatierung (Leerzeichen + Zeilenumbrüche) und Beschriftungen. > Der der schon mit einem Raspi per Du ist könnte das vieleicht Deswegen auch das "Je nachdem wie viel Ahnung..."
Ok, das klingt logisch. Er sagte ja plain Text ... Was ist wenn ich die Dezimalzahlen in JPG Bilder umrechne. Wieviel MB/s muss ich dann wegschaufeln ? someone schrieb: > Es entstehen etwa 100 kbyte plain-text pro Sekunde, zwei Puffer für je > eine Sekunde passen in etwa 32 kbyte Arbeitsspeicher. Also passen in 16KB Arbeitsspeicher 100Kbyte Daten ? Nee, raff ich nicht. Also wenn ich mir so einen Kopf um Performance mache dann speicher ich das RAW weg und bearbeite das später. Bei dem geschätzten 1/4tel overhead also 300kbit/s = 40Byte/sec. Ähm, waren das eben noch 100Kbyte/s ? 40byte /s vom I²C in die SD Karte zu bekommen sollte so gaaanz knapp sogar mit einem Arduino hinhauen. holger schrieb im Beitrag #3980533: > Jemand der auch nur ein bisschen Ahnung hat Und jemand der nur ein wenig Stil hat hält sich mit unangemessenen persönlichen Beleidigungen etwas zurück oder hat zumindest genug Schneid das nicht anonym zu tun.
Auf Getrolle gehe ich nicht ein. Vielen Dank für die anderen hilfreichen Antworten bisher. Es ist ja nicht so, dass ich weder Ahnung noch Code hätte. Das Projekt ist allerdings eine Sache, die ich nebenher machen soll und daher habe ich keine Lust, mich INTENSIV in eine Plattform einzuarbeiten. Hauptsächlich programmiere ich Anwendungen für PCs. Die Hardwaresachen mache ich hobbymäßig, da dann üblicherweise "gemütliche" Anwendungen ohne SD-Karte auf 8- und 16-bit-Microcontrollern. Die Komponenten des Systems sind getestet, der Code ist geschrieben. Die Teile zum Auslesen des Sensors, zum Befüllen der Puffer, zum Aufbau der Datenstruktur und zum Erzeugen der auf die SD-Karte zu schreibenden Daten sind stinknormales C, sollten sich also ohne Anpassungen auf verschiedenen Plattformen ausführen lassen. Unterschiede wird es beim I2C-Handling geben (ich erwarte da aber eine Hardwareabstraktion, der ich sage, was an welche Adresse geschrieben werden soll bzw. von welcher Adresse gelesen werden soll. Totales Standardzeug eben.) und bei der SD-Karte. Ich gehe aber davon aus, dass sich das in kurzer Zeit anhand von vorhandenen Codebeispielen für meine Zielplattform anpassen lässt. Von unqualifizierten Kommentaren bitte ich daher abzusehen. Aktuell hat man mir eine Plattform gestellt, die leider noch etwas verbugt ist und, wie sich vorher herausgestellt hat, kein 400kHz-I2C unterstützt (Galileo). Der Code läuft prinzipiell, ist aber zu langsam. Und ja, es liegt an der Bus-Geschwindigkeit (habe ich nachgemessen). Davon abgesehen, dass die dafür einzusetzende Arduino-IDE grauenhaft ist, lässt sich damit das Problem in kurzer Zeit angehen (lösen ja leider nicht.) Ich habe leider kein SD-Breakout-Board, sonst hätte ich schon geschaut, ob sich die Sache nicht doch mit den üblichen 8-Bittern irgendwie lösen lässt. Aber wenn ich sowieso schon Hardware besorgen muss, dann kann es auch gleich eine Plattform sein, die meinen Ansprüchen gerecht wird. Ich habe aber eben keine Lust, versehentlich irgendein exotisches Board zu besorgen, das ohne vernünftigen Beispielcode kommt und bei dem ich erstmal eine Woche damit verbringe, ein Hello-World-Programm zum Laufen zu bringen. Die Mühe würde ich mir für ein persönliches Hobby-Projekt durchaus machen, aber darum geht es hier ja nicht. Die Sache mit dem Raspberry Pi hört sich allerdings sehr interessant an, daran hatte ich noch nicht gedacht. Der hat auch so viel Arbeitsspeicher, dass man darüber nachdenken könnte, einfach alles dort zu belassen. Mich würde nun nur interessieren, wie ich sicherstellen kann, dass die I2C-Lesekommandos in einigermaßen regelmäßigen Abständen (mit ca. 1 ms) kommen. Vielleicht kann mir hier ja jemand geeignete Dokumentation empfehlen.
Michael Knoelke schrieb: > someone schrieb: >> Es entstehen etwa 100 kbyte plain-text pro Sekunde, zwei Puffer für je >> eine Sekunde passen in etwa 32 kbyte Arbeitsspeicher. > Also passen in 16KB Arbeitsspeicher 100Kbyte Daten ? > Nee, raff ich nicht. Ich erhalte vom Sensor ca. 17000 Byte Daten pro Sekunde. Da ich mir dachte, dass es vielleicht problematisch werden könnte, wenn jede Millisekunde auf die SD-Karte geschrieben wird (ich baue die Dateisystemtreiber und Hardwareabstraktionen nicht, mich würde es aber nicht wundern, wenn dort ein gewisser Overhead vorhanden wäre), führe ich zwei Puffer ein. Eine Sekunde lang wird in den Puffer1 geschrieben, wenn dieser voll ist, wird in den Puffer2 geschrieben und andersrum. Sobald der Puffer voll ist, wird ein Flag gesetzt, das das Programm dazu veranlasst, den gefüllten Puffer in einem Rutsch auf die SD-Karte zu schreiben. Die Daten auf der SD-Karte sollen sich aber mit bereits vorhandenen Programmen auswerten lassen, müssen also als plain-text vorliegen. Für einen int16-Wert benötige ich auf dem Microcontroller 2 Byte, als Text benötige ich aber 6 Byte (der längste String ist "-32768", also 6 Zeichen). Daher der Unterschied zwischen den Größe der internen Daten und der Größe der auf die SD-Karte zu schreibenden Daten. Der zu schreibende String wird unmittelbar vor dem Schreiben erzeugt, das geht (zumindest aktuell) ausreichend schnell. > Also wenn ich mir so einen Kopf um Performance mache dann speicher ich > das RAW weg und bearbeite das später. Bei dem geschätzten 1/4tel > overhead also 300kbit/s = 40Byte/sec. > Ähm, waren das eben noch 100Kbyte/s ? > > 40byte /s vom I²C in die SD Karte zu bekommen sollte so gaaanz knapp > sogar mit einem Arduino hinhauen. Ich kann es natürlich ausprobieren, befürchte aber, dass der Datenpuffer dann ziemlich klein werden muss. Der Arduino hat soweit ich weiß 2k Speicher, ich muss mich also viel stärker darauf verlassen, dass die Schreiboperation auf die SD-Karte sehr schnell ist. Da habe ich Zweifel, wobei ich es Mangels SD-Breakout-Board natürlich nicht ausprobiert habe.
Du hättest uns gerne früher detailierter informieren dürfen. Bei fast jedem OS brauchst Du Hardwarepuffer bei 1ms Echtzeitanforderung. Wenn Du den Raspi davon überzegen kannst den zu verwenden sollten die 512byte Puffer in diesem kleinen Kerl die Probleme lösen: FT201X – Full Speed USB to I2C Bridge http://www.ftdichip.com/Products/ICs/FT201X.html All FTDI devices now supported in Ubuntu 11.10, kernel 3.0.0-19 Refer to TN-101 if you need a custom VCP VID/PID in Linux
So, nachdem ihr nun meine Lebensgeschichte kennt (wen's interessiert ... ich glaube, im ersten Beitrag wurde schon alles Wichtige erwähnt), wäre es nett, mal noch einige Vorschläge zu erhalten. Heute gibt es ja von jedem Hersteller irgendwelche Evaluation Boards, die sich auch alle mit einfacher Benutzbarkeit brüsten. Ich gehe davon aus, dass es hier einige Entwickler gibt, die sich damit auskennen und einschätzen können, ob man mit den jeweiligen Plattformen zügig zu Ergebnissen kommt. Meine Ansprüche an Programmkomplexität sind jetzt ja auch nicht allzu hoch, wenn man davon ausgeht, dass es eine Library für den SD-Karten-Dateizugriff geben sollte.
Eine hardwaremäßig einfache und günstige Lösung wäre der Olimexino-STM32: https://www.olimex.com/Products/Duino/STM32/OLIMEXINO-STM32/open-source-hardware Der hat einen mikroSD-Slot und einen STM32 mit 20 kB SRAM und 400kHz I²C für 20€. Dies lässt sich über eine verkorkste Arduino-Version programmieren, aber unter Verwendung eines normalen JTAG-Adapters (zB J-Link) und eines entsprechenden Kabels auch problemlos über die üblichen verdächtigen für Cortex-M (Keil µVision, TrueStudio, eclipse+gcc etc.). Die ElmChan FatFS Library hat auch ein Beispiel für STM32-Controller. Aber ob sich das ohne jede Cortex-M Erfahrung an einem Tag umsetzen lässt, halte ich auch für fraglich...
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.