Hallo zusammen, im moment habe ich irgendwie einen dicken Knoten in meinem Kopf. Schreibe am besten erstmal hin, was ich erreichen möchte. Ich möchte einen Atmega8 über USB mit Settings Werten füttern, die dann im EEPROM agelegt werden sollen. Genauso sollen die Settings über UART auslesbar sein und auch ein paar Daten µC -> PC transferiert werden können. Das ganze schreibe ich in C, welches ich auch noch nebenher am lernen bin (Soll nun aber nicht das Thema hier sein. Denn ich weiß selbst, das ich noch lücken in C habe). Das mit dem UART habe ich soweit drauf, lediglich einen Ringpuffer muss ich noch realisieren, aber allgemein kann ich UART selbst lösen. Mir geht es eher um das Thema Protokoll und EEPROM nutzung im Bezug auf UART. Wobei das wohl teilweise auch nur Wissenslücken sein dürften und eventuell ein bisschen unordnung in meinem Kopf. Also suche ich hier Hilfe um mein Oberstübchen zu richten :-) So nun zu dem dicken Knoten. EEPROM: Ich möchte die Daten im EEPROM über eine direkte Speicheradresse speichern und lesen können. So bräuchte ich am Anfang ja nur mittels #define mir die Adressen auf sprechende Namen mappen und bin dann flexibel. Der Atmega8 hat laut Datenblatt 512Byte EEPROM Speicher, aber ich kann im Datenblatt nirgends finden, an welchen Speicherstellen die abgelegt sind. Das müssten dann ja irgendwelche Werte zwischen 0x0000 und 0xXXX (X ist das was ich suche) gespeichert werden, also Word Werte. Ich habe da nun schon viel im Forum gelesen zu dem Thema. Unter anderem wird da auch gesagt, man solle Structs nehmen. Wobei sich dann die frage wieder aufwerfen würde, wie ich bei einem Struct die Speicherstelle im Protokoll ansprechen kann. Daher die Frage. Was ist da die beste Methode, wenn ich wie oben schon geschrieben über UART Settings ablegen und lesen möchte. Dann kann mir sicher auch jemand mit den Speicherstellen weiter helfen. Muss gestehen, das ich mit dem Bytes schaukeln noch meine probleme habe. PROTOKOLL: Dann hab ich noch ein paar fragen zu der eigentlichen Kommunikation über UART. UART kann ja immer nur 8Bit in einem rutsch übertragen. Somit muss ich mir ja ein Protokoll ausdenken, das dann regelt was für eine Funktion ich haben möchte. Beispiele: Funktion 1: Schreibe Setting in EEPROM. Funktion 2: Lese Setting in EEPROM. Funktion 3: Lese Variablen Wert aus RAM. usw... Dazu habe ich mir überlegt das Protokoll in etwas so aufzubauen: ([xxx] sollen immer 8 Bit Pakete sein) [Startcondition] [Funktion] [Speicherstelle] [1..n Datenpakete] [Stopcondition] So ein Datenbündel soll dann erst in ein Buffer geschrieben werden und bei erreichen der Stopcondition ein Flag gesetzt werden, das dem Hauptprogramm dann signalisiert, hier sind neue Daten zum bearbeiten. Das ganze RX UART will ich dann im Interrupt machen. Soweit denke ich mal, dürften meine Gedanken auf wenig Gegenwehr stoßen. Ansonsten bin ich immer offen für Kritik. So nun aber zu dem was mich bedrückt. Was nimmt man da als Start- und Stoppcondition für Zeichen? Jedes Zeichen kann, bzw Zeichenfolge kann ja durchaus auch in einem Datenpaket enthalten sein. Oder ist es besser die Startcondition gleich ganz weg zu lassen (Da im Interrupt verarbeitet und der sowieso erst nach empfang der Daten ausgelöst wird) und für die Stopcondition dann den Carrier \r (Wagenrücklauf) zu nehmen? Fragen über fragen. Deshalb bin ich froh, wenn jemand mir da jemand helfen kann, sauberes wissen zu erlangen. So ein richtiges Beispiel kann ich auch nicht finden, wo ich mir das ansehen kann, wie man das am besten macht. Andersrum möchte ich aber auch nicht einfach irgendwas kopieren, ein bisschen drin rum hacken und dann hoffen und freuen, wenn es funktioniert hat. Das wiederspricht sich mir, denn ich möchte schon gerne wissen, was die kleine µC da auf meinen Platinen macht. Danke schonmal an alle, fürs helfen. Grüße Stephan
Zum Protokoll, als Idee: http://www.ibrtses.com/embedded/shortmsgprotocol.html Zum EEPROM: Welchen Compiler verwendest du? Zum Lesen/Schreiben des EEPROMs gibt es meistens eine kleine Bibliothek oder Funktionen die das bewerkstelligen. Im Datenblatt sind auch Beispiele vorhanden.
Stephan W. schrieb: > Ich habe da nun schon viel im Forum gelesen zu dem Thema. Da hast do wohl irgendwie das falsche gelesen. Das EEPROM im Mega8 ist byteweise organisiert, beginnt bei Null, und wird mit speziellen Befehlen des AVR-Befehlssatzes angesprochen. Wie das in C geht, steht hier: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#EEPROM Oliver
Oliver schrieb: > Stephan W. schrieb: >> Ich habe da nun schon viel im Forum gelesen zu dem Thema. > > Da hast do wohl irgendwie das falsche gelesen. > Das EEPROM im Mega8 ist byteweise organisiert, beginnt bei Null, und > wird mit speziellen Befehlen des AVR-Befehlssatzes angesprochen. > > Wie das in C geht, steht hier: > > http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#EEPROM > > Oliver Nuja, das kommt eben auf den Compiler an...
Stephan W. schrieb: > Fragen über fragen. Die wichtigste Frage hast du dir nicht gestellt. Textuelle Übertragung oder Binäre Raw Daten Wie schnell muss die Übertragung gehen bzw. (was damit zusammenhängt) wie oft muss eine Übertragung gemacht werden. Wenn das selten passiert (und selten bedeutet in Zeitabständen größer 1 bis 2 Sekunden), dann würde ich immer einer textuelle Übertragung den Vorzug geben. Vorteil: * Start und Stopcondition sind kein Problem, weil eben nicht mehr jeder Bytewert in den Daten vorkommen kann * leicht zu beschreiben und leicht zu programmieren * Ich bin nicht darauf angewiesen, auf der Gegenstelle ein Programm zu haben, welches Daten zb vom Benutzer abfrägt und die binär auf die Reise bringt. Ein simples Terminalprogramm reicht im einfachsten Fall. * keine Probleme bei Erweiterungen, neue Kommandos sind ein Kinderspiel * keine Probleme bei Erweiterungen, andere Datentypen sind ein Kinderspiel * Im Falle eines Falles kann man mit Portsniffern leicht mitlesen und findet so raus, wo in den Übertragungen etwas schief geht, weil der Sender ein falsches Datenformat generiert. * Sender/Empfänger Synchronisierung ist leicht durchführbar Nachteil: * textuell ist etwas geschwätziger als rein binäre Übertragung * was damit einhergeht: es ist etwas langsamer * ein kleiner Codeaufwand um die auf der Leitung laufenden textuellen Repräsentierungen wieder in verwertbare Binärdaten zu formen.
Daniel V. schrieb: > Nuja, das kommt eben auf den Compiler an... Nun ja, es geht um einen ATMega, und das hier ist das Forum "gcc". Wie viele verschiedenen Compiler kommen da in Frage? Oliver P.S: Die EEPROM-lib steckt sowoieso nicht im Compiler, sondern in der clib. Auch da ist die Auswahl sehr übersichtlich...
Oliver schrieb: > Daniel V. schrieb: >> Nuja, das kommt eben auf den Compiler an... > > Nun ja, es geht um einen ATMega, und das hier ist das Forum "gcc". Wie > viele verschiedenen Compiler kommen da in Frage? > > Oliver > P.S: Die EEPROM-lib steckt sowoieso nicht im Compiler, sondern in der > clib. Auch da ist die Auswahl sehr übersichtlich... Hmmm.... http://de.wikipedia.org/wiki/Atmel_AVR#Software Ich habe bisher mit 3 verschiedenen Compilern gearbeitet. Jeder macht es zugegebenermaßen ähnlich, aber eben nicht gleich.
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.