Daten vom PC mit AVR in I2C-EEPROM speichern

Hi zusammen,

ich bin derzeit dabei eine Steuerung für meine Selbstbau-CNC-Fräse zu entwickeln. Die Schrittmotorsteuerungen habe ich schon gebaut und diese funktionieren auch. Momentan steuere ich diese noch über den Parallelport des PCs mittels VB. Da aber Windows leider nicht echtzeitfähig ist ruckelt es leicht, wenn ich die Maus bewege. Wenn ich die Prozesspriorität auf das maximum stelle geht es zwar, aber eine schöne Lösung ist das ja auch nicht.

Daher würde ich die Motoren gerne mit einem AVR ansteuern. Etwas Erfahrung habe ich schon damit. Hab schon das eine oder andere Programm in Bascom geschrieben.

Die Daten würde ich dann gerne erst komplett übertragen und dann per AVR verarbeiten. Die Übertragung würde ich der einfachheit halber über RS232 machen. Zum speichern dachte ich an I2C-EEPROMs. Weil ich noch nicht absehen kann wie viele Daten es letztendlich wirklich sind dachte ich an 4x 24C512 um genug Reserven zu haben.

Jetzt die Überlegungen / Fragen:
Ich könnte in den AVR einen Modus integrieren, in dem er die über das UART empfangenen Daten einfach an die EEPROMs weitergibt.

Ist der I2C-Bus da schnell genug? Bis auf wieviel Baud könnte ich da bei dem RS232 gehen um sicher kein byte zu verlieren?

Insgesamt hab ich dann Platz für gut 252kByte. Wie lange würde eine Komplette übertragung dauern?

Oder wäre es vielleicht geschickter das ganz anders zu lösen? Evtl. über eine CF- oder SD-Karte? Kann man die über den PC so beschreiben, dass ein AVR sie auslesen kann? Dann müsste auch der PC nicht direkt bei der Fräse stehen.
Oder habe ihr noch eine ganz andere Idee?

Fragen über Fragen.....

Ich hoffe ihr könnt mir helfen!!

Gruß
Marius

Als etwas schnellere Alternative zu I2C gibt es noch die SPI Schnittstelle. da gibt es auch etwa größere Speicher (Dataflash bis etwa 1 MBytes) das ist dann etwas größer als die I2C EEPROMS aber kleiner, und einfacher anzusprechen als eine SD Karte.

Man könnte die Daten aber vermutlich auch einfach in Echtzeit vom PC zum AVR übertragen und per Handshakteleitung oder Rückkanal dafür sorgen, das die Daten nicht zu schnell kommen. Man kann dann einen Teil des RAMs als Puffer nutzen.

Also wenn Du mit -angenommen- 36 kBaud sendest und den I2C mit 100 kHz betreibst, dann kannst Du jedes Bit in der Zeit, in der es vom PC kommt, drei mal zum I2C-Empfänger senden.
Ich würde Dir aber lieber SD-Karten empfehlen. Die kannst Du notfalls auch am PC direkt beschreiben.

Eine oft genutzte Variante für SD-Karten am AVR ist folgende:
Da SD-Karten für die Kompatibilität zu Windows ja mit einem Dateisystem (i.d.R. FAT32) ausgestattet sein müssen, müsstest Du auf dem AVR entweder einen FAT-Treiber implementieren oder folgenden Trick machen:
Du legst in Windows eine Datei an, die 2 GB (also Maximalgröße) groß ist.
An den Anfang der Datei schreibst Du dann einfach eine Zeichenfolge, die eindeutig ist, z.B. "HIER BEGINNT MEINE ACH SO TOLLE DATEI:"
und im AVR liest Du dann einfach jedes Byte aus, und schaust, wann Du Deine Zeichenfolge findest. Ab dieser Stelle kannst Du dann einfach nonstopp schreiben. Und im Windows dann anschließend lesen. Oder umgekehrt.

Vielen Dank für eure Meinungen. I2C würde dann wohl reichen, aber eine SD-Karte zu verwenden würde mich schon sehr reizen ;-)

@thewulf00:
Hast du da ein Tutorial wo das Verfahren beschrieben wird? Ich hab schon gesucht und diese Seite gefunden: http://members.aon.at/voegel/index.html
Diese bräuchte ich soweit ich verstehe auf jeden fall. Zusätzlich hab ich noch dieses hier gefunden: http://staff.ltam.lu/feljc/electroni..._Low_Level.pdf
Dies hilft mir zwar schon etwas, aber so ganz verstanden hab ich es noch nicht. Da steht auch nichts vom anlegen einer Datei mit definiertem Anfang. Für die PC-Seite hab ich auch noch nichts gefunden, wie man (am besten aus VB) auf die Karte schreibt. Ist das überhaupt das was du meintest, oder reden wir aneinander vorbei?

jeder speicher, ist nichts weiter als eine anhäufung von bytes, die so zu organisieren, dass man da dateien und ordner anlegen kann benötigt ein dateisystem (auf den meisten flashkarten wird da FAT16/32 verwendet) ... einem AVR kann man das dateisystem beibringen(programmieren oder bibiothek) oder du umgehst das dateisystem, indem du ein paar mit dummybytes gefüllte dateien anlegst, mit einem eindeutigen startcode wie es wulf schon beschrieben hat anlegst und dann die bytes innerhalb der dateien manipulierst und später am computer über eigene software beschreibst und ausliest

falls du die speicherkarte NUR im gerät verwenden willst, kannst dir das dateisystem auch schenken, dann sprichst du die speicherkarte wie einen gewöhnlichen eeprom z.B. an (über SPI) einzige bedingung du must imer ganze blöcke von 512 byte übertragen!

also 1k speicher bereithalten, immer abwechselnd 1 speicher über uart-interrupt mit daten befüllen und den anderen in der hauptroutine in die karte schreiben, dann einfach speicher wechseln

Gibt es denn keinen I2C Baustein, der das FAT FileSystem implemetiert und die Filesystem-Befehle über den Bus zur Verfügung stellt?

Fundstück: http://www.dharmanitech.com/2009/01/...ga8-fat32.html

öhm ... hmmm .. gut frage ... ich denke eher nicht ... dafür gibts ja eigentlich µC ... wenn du einen findest sag bescheid ... wäre auch interessiert ... aber würde das sinn machen? eh du dem "treiber" alle befehle gegebn und die datei ausgelesen hast um sie zu verarbeiten könntest du doch lieber gleich über den viel stressfreieren SPI bus die datei direkt verarbeiten ... es gibt zig libs die fat16 systeme unterstützen, musst halt nur anwenden können und programmspeicher opfern

Sorry, habe nicht gesehen, das du SO schnell bist... (Siehe EDIT im oberen Beitrag...)
klar gibts dafür µC. Aber auf den meisten ist Prozessorzeit und Speicher nicht gerade dafür geplant so etwas lästiges und fehlerträchtiges wie Filesysteme zu verwalten. Zummal die Sache seit 1980 hinreichend gelöst ist - man also eigentlich nur noch Fehler in der eigenen Umsetzung machen kann ;-) Schön wäre es einfach eine Datei zu öffnen, random zu schreiben und lesen und recht sicher sein, das man nachher auf dem PC die Daten auch noch hat.

@thewulf: Fragmentiert darf dein Filesystem dabei aber nicht sein... Gibt es eigentlich die guten alten "Bad Sektoren" auf den SD Karten noch? Theoretisch können Speicherstellen ja immernoch ausfallen.

Ich habe die letzte halbe Stunde ein wenig die Suchmaschienen genervt:
1.) Projekt zum Selbermachen mit Sourcecode für FAT32 implementierung: http://www.dharmanitech.com/2009/01/...ga8-fat32.html
2.) Kompletter Baustein: http://www.e-lab.de/diverse/components.htmlScrollen zu "MMC-Disk Drive I2C" Wobei mir das nicht wie ein Industrieerprobter Baustein aussieht, der schon zigtausendfach im Einsatz ist.
3.) Noch eine Implementierung http://elm-chan.org/fsw/ff/00index_e.html (Zitat: "The FatFs is easy to port generic file system module for small embedded systems.")

Grüße
Lurchi

hey geil, nette links muss ich sagen , vor allem der letzte sieht sehr interessant aus!

ich geb zu ich hab nur 2min gegoogelt und aufgegeben, aber ich muss ja "nebenbei" noch arbeiten :p

ich bastle grad an den zukunftsaussichten meiner diplomarbeit, da ist so ne anbindung von flash karten zur datenpufferung bei verbindungsverlust schon eingeplant, die umsetzung ist noch ein wenig von datenlast und programmaufwand abhängig ... I2C .. hmmm ich glaub cih ha die Pins schon belegt ma schaun .. muss die patine eh neu designen .... hab ausversehen beim footprint des Max232 die pins nicht gegen den uhrzeigersinn herum angeordnet XD jetzt hab ich 8 platinen für die tonne, 2 hab ich zum ausprobieren "geflickt" XD

@Majuz:
Am PC bearbeitest Du die Datei einfach wie alle Dateien.
D.h. Du legst auf der leeren aber formatierten SD-Karte einfach ein Datei an, die den gesamten freien Speicher bekommt, und dann öffnest Du sie und schreibst an den Anfang einfach Deine Zeichenkette.
Das das Öffnen einer 2GB-Datei ein paar Probleme mit sich bringt, wärs gescheiter, einfach mit einem Programm (in Deinem Fall VB) diese Datei anzulegen, dann Deine Zeichenkette zu schreiben und dann einfach auf maximale Größe aufzufüllen.

@Lurchi:
FAT16 unterstützt keine Fragmentierung innerhalb einer Datei, sie muss immer zusammenhängend sein. Bei FAT32 weiß ichs nicht, aber eine große Datei, die den gesamten freien Speicher einnimmt, kann unmöglich noch fragmentiert sein.

Vielen Dank für eure Antworten!

@thewulf00
In meinem Fall muss ich ja die Daten nur ein eine Richtung übertragen: vom PC zum µC.
Daher verstehe ich das jetzt so (Bitte korrigieren falls falsch!!):
- SD-Karte am PC mit FAT16 formatieren
- mittels VB eine Textdatei erstellen, in der Folgender Text steht, wobei die Buchstaben die Daten sind:

Code:

---

<DATEIANFANG>
AHDFNFKSNRPFKCNFOIRNMGLKDNDNSIUHFPWIOQOIDNFUNOGMDON
<DATEIENDE>

---

- mittels µC mit Bascom und dem hier: http://members.aon.at/voegel/index.html Die Karte sektorenweise einlesen und die gelesenen Daten nach <DATEIANFANG> durchsuchen wenn nichts gefunden, den nächsten Sektor lesen
- wenn dies gefunden wurde ab dort lesen und die Daten verarbeiten bis <DATEIENDE> auftaucht.
- Da der µC nichts auf die Karte schreiben soll muss die Datei ja nicht größer sein, als notwendig.

Wie die Daten genau aussehen weiß ich noch nicht, wahrscheinlich aber berechne ich alles am PC vor und übertrage dann nur nach dem Schema: X+500Schritte, Y-200SChritte oder sogar die reinen Zahlen die dann paralel auf einen Port des µC gelegt werden. Also von 0 - 255 - dann wäre es genau ein byte pro schritt. Dann hat der µC am meisten Spielraum für andere Sachen (LCD usw.). Nachteilig wär halt die Dateigröße (bei 1Mio Schritten aber gerade mal 1MiB, was für heutige SD-Karten ja lachhaft ist). Da wäre es am besten, wenn ich dem µC mitteilen würde: "Linie von x,y nach a,b" oder "Kreis um x,y mit Radius r". Dann hat aber der µC wieder mehr zu rechnen und weniger Reserven.

Weiß jemand wie groß die SD-Karte bei verwendung von http://members.aon.at/voegel/index.html sein darf?

Vielen Dank

Gruß
Marius

@thewulf00: Wie gemein! Dann waren die Norton Utilities ein großer Schwindel!! Und ich habe (nicht wirklich) stundenlang zugeguckt wie Dateien neu arangiert wurden ;-)
Mal im Ernst. Wenn ich mich recht entsinne organsiert FAT die Teile einer Datei (sofern diese größer als ein Sektor - i.d.R. 512 Byte - ist) auf dem Speichermedium als verkettete Liste, die von Sektor zu Sektor verfolgt werden kann. In der eigentlich FAT war lediglich die erste Sektoradresse der Datei abgelegt. Diese Liste muss nicht sequenzieller Reichenfolge auf dem Speichermedium abgelegt sein. Das hat sich von FAT12 bsi VFAT nicht geändert...

@Lurchi du hast völlig recht, nun führe dir aber nochmal die funktionsweise einer festplatte vor augen! eine sich drehende platte, auf der IRGENDWO ein tastkopf schwebt ... fang ich an zu schreiben, platziert er n fetzen hier, n fetzen da usw. ein flash speicher, sofern darauf die dateien nicht allzu wüst zerstückelt werden, schreibt von haus aus immer sequentiell ein byte nach dem anderen .... wenn ich jetzt auf einer 5MB Karte(hypothetisch) 5 mal 1 byte dateien schreibe, die dann jede 2te datei lösche und dann eine 2mb datei schreibe, wird sie fragmentiert.
solange die karte immer schön gelöscht wird bevor drauf geschrieben wird, gibts da kein problem ... so hab ichs zumindest aus eigener erfahrung gelernt ... (vor längerer zeit)

ich würde trotzdem einfach die datei per kabel zur maschiene übertragen und die flashcard nur als speicher verwenden oder eben nen EEPROM chip nehmen, aber wo bleibt dann die herausforderung ^^

thewulf00 hat natürlich auch recht. Bei einem 2 GB Speichermedium eine 2 GB Speicherdatei zu erstellen zwingt das OS dazu selbst "nur" als gelöscht markierte Bereiche zu überschreiben. Und somit eine unfragmentierte Datei zu erstellen.
Was ich mich jetzt nur wundere: Wenn FAT Dateien als verkettete Liste von Sektordatenblöcken anlegt muss injedem Sektor die Informationen für den folgenden Sektor abgelegt sein , thewulf00 aber schreibt, das er Dateien in jeweils 512 Byte blöcken sequenziell aufeinanderfolgend auf das Medium schreibt - und er hat das so schon gemacht. Also MUSS die Verwaltung von Dateien auf SD Karten anders als auf konventionellen Datenträgern organisiert sein - oder der SD Controller macht diese Arbeit transparent im Hintergrund.
aber ich glaube das spielt für die eigentliche Frage in diesem Thread keine Rolle...

Also so langsam wirds mir zu hoch ;-)

Also muss ich nach <DATEIENDE> noch irgendwelche zufallszahlen schreiben, bis die Karte voll ist (bei weniger als 2Gb), damit die Datei nicht fragmentiert wird? Wenn ich die Karte aber jedes mal formatiere ist sie ja komplett leer. Warum sollte dann die Datei nicht an einem Stück sein? Ist in der SD-Karte ein Algorithmus eingebaut, damit alle Zellen der Karte möglichst gleichoft beschrieben werden und die Datei deshalb fragmentiert? Ansonsten bringt es ja nur Nachteile auf eine komplett leere Karte eine kleine Datei fragmentiert zu schreiben.

Sorry für die Verwirrung. Formatieren reicht natürlich.

@Lurchi - Soweit ich weiß, kann FAT16 keine fragmentierten Dateien. Das, was Dein Norten defragmentiert hat, waren mehrere Dateien und nicht Teile einer Datei, denke ich zumindest.
Aber wie gesagt, wenn man eine Datei mit Maximalgröße anlegt, ist das Thema eh passé.