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.
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...
