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.