Hallo liebe µC- Gemeinde, ich bin Student und brauche die Empfehlung und Hilfe der Cracks hier im Forum. Es geht um Folgendes - ich habe eine Textdatei vorliegen welche bis zu 50MB groß werden kann, sie besteht nur aus Einsen und Nullen - also ein ewig langer Binärstring. Dieser String soll jetzt einen Digitalport ansteuern und jeweils nach einem Triggersignal einen Burst Pegeländerungen rauspusten. Die Problematik ist an sich ja recht simpel beschrieben - jedoch habe ich bisher noch nichts mit externen Speichern und dem AVR gemacht. Als erste Idee kam mir die SD Karte als externen Speicher zu nutzen - es gibt ja einige Projekte im Netz dazu. Jetzt wollte ich bevor ich mich hart in C einarbeite und da viel Zeit reinstecke, erstmal nach alternativen Fragen oder eventuell hat jemand ja eine ganz andere Idee wie man das Problem angehen kann. Da ich versuche diese Textdatei noch zu optimieren (ca. 5MB) würde ich auch gerne Tipps für diese Ausgangssituation haben. Da ich noch auf keinen AVR festgelegt bin, bin ich auch für eventuell schon fertige Komplettlösungen zu haben. Mit freundlichen Grüßen Ben
Die Einsen und Nullen in der Textdatei zu 8 Stück als Gruppe zusammenfassen und als Byte speichern. So hast Du nurnoch 1/8 Platzverschwendung. Du kannst dann das Byte aus der Datei auslesen und auch gleich an einen 8-Bit-Port des AVR ausgeben. Oder halt wieder in Bits zerlegen und seriell an einem Pin rausschieben. Ist relativ einfach. SD-Kartenauswertung mit Fat32 gibts genügend als C und sogar in Bascom.
soll die pegeländerung nach einem bestimmten muster gehen? pwm? periodisch? vollkommen random? wie generierst du das file? einfach die funktionen mit denen du die 0 und 1 am pc generierst am avr generieren lassen!
Du musst ja nicht die ganze Datei auf einmal lesen. Du liest immer nur die nächsten Zeichen die du setzen musst und dann wenn du die verarbeitet hast den nächsten Block.
Was stand denn hier so schlimmes, das Zensurursel gleich mehrmals drüberfegte? Also als (externen) Massenspeicher ist SD (bzw. MicroSD) wohl die beste Wahl. Die sind sehr groß und extrem preiswert erhaeltlich. (Manchmal bekommt man z.B. bei ebay sogar noch kleine 128 oder 256MB Karten für 1 Euro - für den AVR sind 128MB eh meist mehr als genug...) Die kannst du mit wenigen Pins ansteuern, in Blöcken von 512Byte mittels SPI (als Hardware auf dem AVR drauf) in den RAM lesen und dort weiterverarbeiten. Wie das geht gibt es hier (http://www.mikrocontroller.net/articles/AVR_FAT32) als fertige lib. Dateisystem brauchst du aber nicht, da du die SD auch blockweise lesen kannst, somit kannst du Programmspeicher sparen und sogar kleine AVRs wie den ATmega8 nutzen. Der Stromverbrauch von SD ist auch minimal und ein paar Widerstaende als Pegelteiler von 5V->3.3V wirst du dir selber bauen können. Als "Sockel" kannst du einen dieser nervigen micro SD -> SD Adapter nutzen und Pins direkt anloeten... Wenn ein "PC" neben den AVR stehen kann/soll kannst du V-USB (http://www.obdev.at/products/vusb/index-de.html) nutzen um vom PC die Daten an den AVR zu senden. MfG
Oder gleich AVRBridge bequem aus einer Programmiersprache deiner Wahl verwenden: http://ka010.wordpress.com/avrbridge/
Also diese Bursts sollen mit 40kHz rausgehen, deshalb fällt eine SD Karte via SPI wohl flach. Ich habe jetzt eine neue Idee, aber vielleicht habt ihr ja noch Hinweise für mich. Meine Idee wäre jetzt mit einem überdimensionierten ARM Teil ala Raspberry PI oder Beagle Board die Daten der SD Karte zu lesen, weil das kann dsa System ja schon von sich aus und diese über die GPIO auf SRAM zwischen speicher zu senden die mit dem AVR verbunden sind. Ich würde dann zwei dieser Speicherbausteine nutzen, immer wenn der eine gefüllt wird mit Daten, kann der andere abgelesen werden - somit müsste ich doch einen konstanten Datenstream erreichen, welcher nicht durch Interrupts oder andere Programmteile unterbrochen wird. Leider habe ich keine Erfahrung mit solchen Speicherbausteinen - habt ihr da Empfehlungen ? Würde sich da vielleicht sogar ekin Latch oder Schieberegister eignen. Ich meine die Größe dieses Puffers muss ja nur die Trägheit des wiederbefüllens auf Seite des ARMs wegmachen ( der ist ja so langsam durch das Betriebssystem mit Taktzeiten um 1ms ) Oder bin ich völlig auf dem Holzweg ? Also Daten auf SD Karte, als Dauerstring in einer txt (10001010101000) sollen mit 40kHz auf einem Digitalport ausgegeben werden. Datenmenge bis 50MB Gruß Ben
Und warum scheiden AVR*s dann aus? 40kHz, da lacht ein AVR mit 16MHz drüber. Du musst die Daten aus deinem Speicher im AVR SPeicher nur zwischenbuffern!
@ Ben (Gast) >Also diese Bursts sollen mit 40kHz rausgehen, deshalb fällt eine SD >Karte via SPI wohl flach. Wer sagt das? Ein AVR @ 16 MHz kann mit 8 Mbit/s die Daten aus der SD-Karte ziehen, macht 1MB/s. OK, der Overhead für FAT32 kommt hinzu, und der ist relevant. Aber 40kB/s schafft auch ein AVR. >Meine Idee wäre jetzt mit einem überdimensionierten ARM Teil ala >Raspberry PI oder Beagle Board die Daten der SD Karte zu lesen, weil das >kann dsa System ja schon von sich aus und diese über die GPIO auf SRAM >zwischen speicher zu senden die mit dem AVR verbunden sind. Ich würde >dann zwei dieser Speicherbausteine nutzen, immer wenn der eine gefüllt >wird mit Daten, kann der andere abgelesen werden - somit müsste ich doch >einen konstanten Datenstream erreichen, welcher nicht durch Interrupts >oder andere Programmteile unterbrochen wird. Alles viel zu kompliziert. >Oder bin ich völlig auf dem Holzweg ? Jo. >Also Daten auf SD Karte, als Dauerstring in einer txt (10001010101000) >sollen mit 40kHz auf einem Digitalport ausgegeben werden. Datenmenge bis >50MB "ich bin Student und brauche die Empfehlung und Hilfe der Cracks hier" Netiquette. Ein Bit speichert man nicht als ASCII Zeichen, das hat nämlich 8 Bit. Wenn man die Daten gleich sinnvoll, sprich binär speichert, passieren wundersame DInge. Speicherbedarfs sinkt auf 1/8, sprich 6,25MB Die Datenrate sinkt auf 1/8, sprich 5kB/s Da kann der AVR nebenbei Kaffee kochen und Pi nochmal nachrechnen ;-) AVP + FAT32 Lib + SD-karte packen das locker.
Danke Falk und icke für die schnelle Antwort. Ich erzeuge die Textdatei mit einem anderen Programm, habt ihr da einen Tip für mich wie ich die Textdatei in ein passendes Format für den Speicher bekomme ? Ich meine ich wollte ja eine Art Binärstring erzeugen und diese Einsen und Nullen dann im Speicher natürlich Bitweise ablegen. Also ist das Paket SD Karte mit den zugehörigen Libs via ISP schnell genug. Gut dann habe ich da in einer anderen Quelle wohl etwas falsch verstanden. Mir ist in der Nacht noch eine Idee gekommen, und zwar habe ich die Datei ja auf dem Hauptrechner (Entwicklungspc) liegen. Wäre es nicht auch möglich die Daten über die serielle Schnittstelle an den AVR zu senden 115kbit/s und dort dann im Speicher zu puffern ? Mit dem Puffer ist mir noch nicht so ganz klar wie Ihr das umsetzen würdet. Wenn ein Datenstrom am AVR ankommt wie speichere ich diesen am besten in einem "Puffer" ab. Sprich erzeuge ich einfach eine Variable und schiebe dort dann die an der Schnittstelle anliegenden Daten rein und beschreibe sie danach neu ? Bzw erzeuge vielleicht zwei Variablen um die eine immer zu befüllen während ich die andere abarbeite, damit keine Pausen während des Bitstreams entstehen. lg Ben P.S: Entschuldigung wegen der Missachtung der Netiquette
Hi Ben. Du brauchst kein Dateisystem. Du kannst die Daten direkt sektorweise nacheinander auf der SD-Karte ablegen. Zunaechst wandelst du deine Textdatei ins Binaere um - ein kleines, gefriemtes Tool in einer Programmiersprache deiner Wahl sollte das tun koennen. Danach z.B. in Linux mittels eines gewoehnlichen Card-Readers: dd if=<binaeredatendatei> bs=512 of=/dev/sd<buchstabe des SD devices> Im AVR brauchst du nun nur noch die MMC Bibliothek - ganz ohne FAT, und damit sehr klein und schnell. Die eigentlichen Daten kannst du dann direkt Byteweise aus der Karte lesen (Du musst nur alle 512Byte 2Byte fuer CRC ueberspringen - mittels eines globen Zaehlers aber auch kein Problem.) Wenn du Puffern musst kannst du das an der Stelle mittels einer 256byte Doppelpuffers tun - aber vermutlich ist das nicht noetig da die Daten sehr schnell von der SD-Karte kommen. (20KByte/sec sind es locker)
1 | if (mmc_startr(0x28000)==TRUE) { // skip 5*16 MByte (80MB) |
2 | uint32_t i; |
3 | for (i=0;i<0x2000000;i++) { //use 6th 16MByte |
4 | OCR1AL=mmc_getbyte(); |
5 | _delay_us(60); // for about 16kHz sampling rate |
6 | }
|
7 | mmc_stopr(); |
(mmc_getbyte() implementiert bereits das ueberspringen von 2 Bytes alle 512 Bytes) Auf Wunsch stelle ich gern ausfuerlicheren Beispielcode zur Verfuegung. MfG Stephan
So, ich nocheinmal. Naja, anbei mein original Code. Ich weis - boese gehackt. Achja, basiert auf: http://www.mikrocontroller.net/articles/AVR_FAT32 (Lediglich der Dateikram ist entfernt, und Sequenzlesen ist korrigiert/ergaenzt) MfG
@Ben (Gast) >Ich erzeuge die Textdatei mit einem anderen Programm, Kann man das nicht anpassen? > habt ihr da einen >Tip für mich wie ich die Textdatei in ein passendes Format für den >Speicher bekomme ? Im Zweifelsfall einen kleinen Konverter in C schreiben. Ist leicht gemacht, sogar mit Parametern. > Ich meine ich wollte ja eine Art Binärstring erzeugen >und diese Einsen und Nullen dann im Speicher natürlich Bitweise ablegen. Wer hindert dich daran? >Also ist das Paket SD Karte mit den zugehörigen Libs via ISP schnell >genug. SPI, ISP ist was anderes. >Mir ist in der Nacht noch eine Idee gekommen, und zwar habe ich die >Datei ja auf dem Hauptrechner (Entwicklungspc) liegen. Wäre es nicht >auch möglich die Daten über die serielle Schnittstelle an den AVR zu >senden 115kbit/s und dort dann im Speicher zu puffern ? 115k2 Baud sind ~11kB/s, du willst ~5kB/s. Sollte klappen. >Mit dem Puffer ist mir noch nicht so ganz klar wie Ihr das umsetzen >würdet. Wenn ein Datenstrom am AVR ankommt wie speichere ich diesen am >besten in einem "Puffer" ab. Du brauchst ein FIFO in Software. >und beschreibe sie danach neu ? Bzw erzeuge vielleicht zwei Variablen um >die eine immer zu befüllen während ich die andere abarbeite, damit keine >Pausen während des Bitstreams entstehen. Du brauchst mehr als 2 Variablen, siehe oben.
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.