Hallo, habe wohl gerade einen Volltreffer gelandet... (ich Trottel) Habe einen EEPROM Spreicher per I2C an einen ATMega angeschlossen. Aus dem Speicher wollte ich dann später Daten auslesen um sie während der Laufzeit zur Verfügung zu haben. Die Lese- und Schreibroutine klappt auch soweit, bis auf dass im EEPROM momentan keine "realen" Daten drin sind ;=) Da das EEPROM größer ist als der Seicher des uC, frage ich mich, wie ich jetzt das EEPROM mit den richtigen Daten füllen kann... Meine Ideen: 1) Programm schreiben das von der seriellen Schnittstelle Daten entgegennimmt und diese dann Byte für Byte ins EEPROM schreibt. Anschließend das Programm löschen und das richtige aufspielen. Da ich da keine Ahnung habe wie ich die Daten seriell übertragen soll (kann ja in Hyperterminal auf der PC Seite schlecht eine Quelldatei angeben), stehe ich vor einem Problem. 2) Programm schreiben das nur I2C Routinen und eine Start-/Endadresse enthält, den Rest des uC Speichers mit einem Teil meiner Daten vollpacken und das Programm das EEPROM von der Start- bis zur Endadresse beschreiben lassen. Anschließend neues Programm mit anderen Start-/Endadressen und Daten erstellen (bzw. bestehendes anpassen) usw. Am Ende dann wieder das richtige aufspielen. Damit mir sowas nicht wieder passiert: wie macht ihr das, bzw. wie läuft es besser/richtig? Gibt es eine Möglichekit per PC auf ein eingelötetes (I2C-)EEPROM zuzugreifen? Schönes Wochenende, Peter
Einen DIL-Sockel verwenden und nicht mit Harz vergießen :-) Dein Punkt 1) ist doch in Ordnung. Schreibroutinen brauchst Du sowieso, und Byte für Byte von UDR zu schreiben, sollte doch kein Problem sein: bei Adresse 0 starten, am Ende einfach ausschalten.
Hi, bin eigentlich sehr froh, dass ich kein DIL verwendet habe und fast ausschließlich SMD (SO, TQFP, 0603 Rs und Cs...) eingesetzt habe. Lieber etwas länger beim Löten brauchen als ständig zu bohren. Was die Kommunikation per UART angeht: "menschlich" lesbare Zeichen klappen ohne Probleme (z.B. Debugmeldungen), nur wie sieht es mit "Sonderzeichen/Steuerzeichen" aus? Würde ja am liebsten einem Programm auf der PC Seite eine Datei vorwerfen, die der PC dann mit X Baud an den uC überträgt. Wenn es so etwas gibt, sind meine Probleme gelöst. Denn wie du schon sagtest: das passende uC Programm ist simpel: Byte entgegennehmen, ins I2C EEPROm schreiben, (Adress-)Zähler erhöhen und wieder ein Byte entgegennehmen... Könnte höchstens ein paar Geschwindigkeitsprobleme bekommen wenn der serielle Datenempfang schneller ist als das eingesetzte I2C EEPROM. Peter
Du kannst ja dein RS232->I2C Programm so schreiben, dass du Daten blockweise (EEPROM Page-Write Modus!) vom PC an den µC sendest. Wenn ein Block im EEPROM ist, Bestätigung an den PC. Dann nächsten Block übertragen. Zum Thema Hyperterminal: Denk mal darüber nach, evtl. ein anderes zu verwenden... ;-) MFG Kai
bei Binärübertragung gibt es immer wieder mal Probleme, hauptsächlich auf PC-Seite. Was nicht heisst, dass es nicht geht! Kommt aber auch aufs Terminalprogramm an. An deiner Stelle würde ich mir auf MC-Seite ein kleines Programm schreiben, welches Hex-Dateien dekodiert. Eine Hex-Datei ist reiner Ascii-Code, nebenbei Adressinformationen und Checksummen. Start der Übertragung mit einer Escape-Sequenz (oder auch per Hardware über einen freien Pin, bei Reset schaut der MC an diesem Pin, ob eine Datenübertragung stattfinden soll). Ein ganz anderer Ansatz: wenn du den MC im Reset hälst, kannst du den EEPROM auch über einen externen I2C-Prommer beschreiben.
Nachtrag zum Terminal. Gerade wieder entdeckt: http://www.mikrocontroller.net/forum/read-8-155472.html
Hallo, das geht ja verdammt schnell hier. Danke für eure Hilfe, komme ja kaum nach. @Kai: Ja, das geht sicher (wenn du das sagst). Mal sehen ob ich damit auch klar komme. Habe das bis jetzt immer nur Byteweise gemacht. Was gibt es denn für empfehlenswerte kostenlose (oder günstige) Alternativen? @crazy horse: Wenn Binärübertragung geht, bin ich glücklich.Wer kann das, bzw. gibt es da Anleitungen/Dokumentation? Kann ja in jedem Fall noch irgendwie eine Kontrolle einfügen (mit Parity Bits komme ich wohl noch klar, Hashfunktionen sind mir dann zu hoch, außer ich schreibe und lese aus und mache das am PC). Wenn ich alle Bytes umwandele, habe ich ja gleich die doppelte Datenmenge, wobei mein Codevorrat allerdings kleiner wird (nur noch 0...9, A...F). Einen I2C Programmer habe ich (noch) nicht. Scheint aber doch eine sinnvolle Anschaffung zu sein. Kommt auf die "To-Do-Liste". Danke bis hierhin schon mal, hat mir echt geholfen. Kann dann am Wochenende probieren den Bock wieder zu beheben. Peter
@Kai: DANKE! Damit sollten alle meine Probleme gelöst sein. Warum findet Google so was tolles nicht (grml). Dort bekomme ich fast nur Kommerzsoftware. Egal, danke. Schönes Wochenende, Peter
http://www.lancos.com/prog.html der funktioniert, bei mir zumindest :-) doppelte Datenmenge bei Hex-Datei: das ist doch kein Problem, der begrenzende Faktor wird sowieso die EEPROM-Schreibzeit bleiben, auch bei page-write. Und um sich handshake zu ersparen: einfach baudrate entsprechend niedrig wählen. Bsp: 8byte page-write, 10ms Schreibzeit, also sollte ein Byte nicht schneller als alle 1,25ms reintröpfeln, mit 4800 Baud bist du auf der sicheren Seite (rund 2ms/byte). Bei Hex-Übertragung kannst du locker auf 9600 gehen, ohne irgendwelche Timing-Probleme zu bekommen.
Ich versehe gar nicht wo das Problem ist ... man nehme ein Progrämmchen im µC, das bei bestimmter Zeichenfolge von UART z.B. AT&EE in einen "Dauer lese - verschiebe - Modus" wechselt, die danach eingehenden Daten ins EEPROM schreibt und nach Endphrase z.B. EXIT&EE wieder in den Normalmodus der µC-Tätigkeit wechselt. Dann baut man in VB n kleines Progrämmchen mit nem Eingabefenster und nem Submit-Button, das dann bei Betätigung die Daten AT&EE xxxxx Nutzdaten Eingabefenster EXIT&EE über COM 1/2/3/4 verschickt und fertig ist die Laube.
Ist sowieso sinnvoll so ne Routine einzuplanen, fals man im Nachhinein den EEPROM-Inhalt ändern muss. In System ist doch die Beste Methode, oder?
@Marco: Da hast du meiner Meinung nach recht. @Peter: Ich weiß zwar nicht, ob sich deine EEPROM Daten auch mal ändern können, aber wenn du neue Daten von extern aufspielen willst ist der Tipp von Marko (EEPROM Modus + passendes VB Programm) nur empfehlenswert. MFG Kai
Hallo, mittlerweile bin ich dank eurer Tipps weiter. Habe ein extra Programm für den uC geschrieben, das die Daten von COM1 des PC entgegennimmt und im EEPROM ablegt. @Marko: das Problem liegt darin, dass ich im Programmieren in C, Visual Basic o.ä. am PC eine "Niete" bin ;=) Ok, Grunderfahrungen sind da, aber auf die serielle Schnittstelle zuzugreifen: keine Ahnung wie das unter XP geht. Außerdem bräuchte ich dann noch einen VB Compiler (einen älteren C Compiler hätte ich noch hier). Deshalb wollte ich ein fertiges Programm verwenden. Aber, evtl. schreibe ich da wirklich was eigenens. Geht das denn unter XP auch so einfach (direkt auf die Hardware/COM-Port zuzugreifen) wie unter DOS? Kommt auch auf die TO-DO Liste, denn für die Zukunft schient das echt die eleganteste und universellste Lösung zu sein. @Kai: In der Testphase schon, anschließend nicht mehr. Es sei denn, ich funktioniere das ganze noch mal um. Gruß, Peter
Es gibt in Dos die (einfache) Möglichkeit direkt eine Datei nach Com1 zu kopieren: mode com1;9600,n,8,1,p copy /b eeprom.hex com1 Du musst glaub ich beim Beschalten der seriellen auf der PC Seite den DTR und CTS-Pin beschalten. Evtl einfach auf GND, dann hast du hast keine Flusssteuerung. Andere Möglichkeit wäre noch die Implementierung eines der X/Y/Z-Modem Protokolle. Gruß Roland
Ich hab noch ne alte VB6-Version hier ... auf XP und 2K-System ist echt keine große Sache, nur so ne windige DLL hab ich nachinstallieren müssen, dann ging der Umgang mit LPT und COM wie geschmiert.
Also ich arbeite mit Visual Studio 2005 (C++ und C#) und da kann ich eine "Serial Port" Komponente in mein Programm einfügen. Diese repräsentiert dann die serielle Schnittstelle mit der man dann beliebige Daten übertragen kann. MFG Kai
ist bei VB das Selbe, Oberfläche anlegen, MSCom Icon plazieren, Eigenschaften einstellen und schon kanns losgehen ... einfach die zu sendenden Daten ins Objekt schieben
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.