Hallo Ich hab mir jetzt kleines Protokoll ausgedacht, mit dme ich den MC vom Computer aus fernsteuern kann.Nun wüder ich gerne eure meinung dazu hören, ob das guter C Stil ist oder ob meine lösung zu rechneintensiv (zeitkritisch/interrupt) ist. Hab zur einfachen verständlichkeit alles unwichtige weggelassen. Ich hoffe ihr könt mir ein paar tips geben. mfg Max
Was ist wenn ich 0x30 in das EEPROM an Adresse 0x39 schreiben möchte? - sende CMD_STARTCODE - sende EEPROM_WRITE - sende Adresse 0x39 - sende Daten 0x30 - sende CMD_STOPCODE Ist das so richtig? Kommen die Daten auch ins EEPROM? Bleiben die Daten nicht im Interrupthandler stecken, weil die Adresse und die Daten die ich sende mit den Befehlen übereinstimmen? Gruß Feadi
Das geht schon so. Du musst Dir nur gedanken machen, was passiert, wenn Du eine Adresse oder Daten sendest, die zufällig mit der Zahl, die CMD_STARTCODE, oder schlimmer, CMD_STOPPCODE symbolisiert, übereinstimmen. Dafür hast Du mehrere Möglichkeiten: a) Du weißt, wieviele Daten Du dahin schreibst. Soll heißen: Du sendest CMD_STARTCODE, dann die Anzahl der Datenbytes. Oder diese sind konstant, dann brauchst Du sie natürlich nicht übertragen. Somit "weiß" der uC, ab wann er wieder auf Kommandos hören soll. Dann könntest Du auch ganz auf CMD_STOPPCODE verzichten. b) Du denkst Dir ein etwas komplizierteres Protokoll aus, z.B ähnlich der ESC-Sequenzen bei c: "/n" ist Kommando für NewLine, "//" ist ein "echtes" Daten-"/". Gruß, Sebastian
Hallo Da hab ihr recht, da hab ich noch garnicht darann gedacht, das selbe würde ja auch beim display passieren. Danke @Sebastian Beide ideen haben ihre vor und nachteile, bei a wirsd schwirig wenn mal ein neuer befehl hinzu kommt, und beim 2ten wird warscheinlich der interrupt zu lange und es geht was verloren. Was mir auch noch aufgefallen ist, das ich vieleicht noch ein das Parity bit übertragen solte um zu prüfen ob das auch so richtig ist, oder ob es zu fehlern gekommen ist. Auf jedne fall danke für die tips mfg Max
Kleiner Tip: Wenn es nicht zeitkritisch ist, dann verwende doch für Befehle, Adressen und Daten die ASCII-Darstellung ihrer Hex-Werte. Das hat den Vorteil, dass Du zu sendende Daten mit einem normalen Editor erzeugen kannst (und wenn es nur für den Anfang zum testen ist). nimm zum Beispiel folgende Buchstaben (beliebig): "S": sende CMD_STARTCODE "W": sende EEPROM_WRITE "39": sende Adresse 0x39 "30": sende Daten 0x30 "X": sende CMD_STOPCODE Zum Schreiben des EEPROM schickst Du einfach folgenden String: SW3930X Wenn Du ausserdem "definierst", dass ein Blank und CR ignoriert werden, dann werden die Kommandos richtig lesbar: S W39 30 X (schreibe 30hex in Adresse 39) S W3A 20 21 22 23 X (schreibe 4 Bytes 20-23 ab Adresse 3Ahex) Viel Spass, Stefan
und wenn du auch noch viel zu viel speicher am controller hast dann mach gleich noch schöne befehlsnamen.. statt - sende CMD_STARTCODE - sende EEPROM_WRITE - sende Adresse 0x39 - sende Daten 0x30 - sende CMD_STOPCODE einfach EEPROM_WRITE 39,30 cmd_stopcode ist demnach ein \r bzw ein \n startcode brauchen wir nicht.. der rest sollte auch leicht parsbar sein... einfach nach einem leerzeichen suchen... das davor ist der command .. danach sind parameter ;) dann trennt man die noch bei jedem command gleich und alle sind glücklich ;) btw ich würde den parser aber schon so intelligent machen, dass man auch texte übergeben kann... also z.b LCD_WRITE 0,1,"Test \" \\ blah ,,,,," sprich \" wird ein " am lcd \\ ein \ und die ,,,,, werden ignoriert weil sie innerhalb der "...." sind ;) 73
Hallo
@Stefan:
Das ist eien gute idee, das solte sich eigentlich machen lassen. Ist
auch wesentlich einfacher mit einem Terminalprogramm zu erzeugen.
@Hans
Währe natürlich auch eien möglichket.Währe auf jeden fall eine
Herausvorderung. Hab es jetzt aber schon einfachner gelöst. Es wird nur
getestet ob das letzte zeichne ein / war, und ob das gerade empfangene
ein n ist. wenn ja, wird einfach des Status auf NEWLINE gesetzt und
gut.
if (command_count > 30){
command_count = 0;
command_ctrl = NULL;
}
if ((command[command_count - 1] == '/')&&(data=='n')){
command_ctrl=NEWLINE;
command[command_count] = data;
command_count++;;
}else{
command[command_count] = data;
command_count++;
}
Was dabei noch Probleme machne könnte ist die abfrage
command[command_count - 1]. Was kann pasieren wenn command_count 0 ist
und trotzdem eins abgezogen wird? der compiler läst es zwar gelten,
aber das muss ja nichts heisen.
@max.p: Das ist eine gute Frage. Wenn du den Wert größer machst als dein Array, dann wird einfach der nächste Wert im Speicher gelesen. Also wenn dein Array command[10] bei Adresse 0x100 beginnt und demnach bei 0x109 endet, dann kannst du mit command[10] auf die Speicherstelle 0x110 zugreifen. Das solltest du aber vermeiden, denn auf der Speicherstelle könnte ja schon wieder das nächste Array oder die nächste Variable liegen. Was der Prozessor jetzt aber mit command[-1] macht weiß ich nicht. Denn beim AVR gibt es einen (ASM) Befehl, mit dem ich relativ zu einer Startadresse ein Byte vom Speicher lesen kann (über Offset). Ich glaube die Compiler nutzten diesen sehr gerne für Arrays (bin mir aber nicht sicher!!!). Wird der Befehl verwendet, so kann es schon sein, dass von einer total anderen Adresse gelesen wird. Schreib einfach mal ein kleines Programm und schaue dir im AVR-Studio Debugger an was der Compiler daraus macht. Gruß, Florian
Hallo Florian bin jetzt aus dme simulieren im Studio nicht schlau geworden. Auch in mehreren C-Tutorials im Internet bin ich nicht fündiggeworden, anscheine nd hast du recht. mit -1 würde einfach auf eine niedrigere Speicheraddresse zugegriffen. Was in meinem Augen gefährlich ist, da ich nie sagen kann was sich dort befindet. Ich werde das ganze einfach lösen indem ich stat Index 0 mit 1 beginne und das dafür freigewordene bit 0 für command_ctrl verwenden und es über ein macro einblenden. mfg Max
Ja, natürlich kann man in C auch mit negativen Indizes aus einem Array lesen. Das kann zuweilen auch Sinn haben. Aber wie immer: in C ist jeder selbst dafür verantwortlich, nur auf Array-Elemente zuzugreifen, von denen er weiß, dass dort gültige Daten zugreifbar sind. (Dafür gibt's dann halt kein Laufzeitsystem.)
Hallo, ich habe das ganze nun mal ausprobiert: Stehen die Indizierungnen für das Array zu Kompilerzeit bereits fest, also wird z.B. temp=array[5]; geschrieben, dann rechnet der Compiler die Adresse gleich aus. Ein temp=array[-1]; funktioniert ebenso, der Compiler nimmt dann halt eine Adresse unterhalb von array[0]. (Der Compiler nimmt den Befehl LDS, bei welchem gleich die Absolute Adresse mit übergeben wird. Wir jedoch eine Dynamische Adressierung verwendet, dann benutzt der Compiler die Indirekte Adressierung. Der Compiler lädt die Grundadresse in ein Registerpaar. Schreibt man dann temp=array[t-3]; so zieht der Compiler von dem Registerpaar 3 ab und greift dann auf die Adresse zu. Ist t nun null, so wird hier auch auf die 3. Adresse unterhalb von array[0] zugegriffen. Wie Jörg schon gesagt hat bist du selber dafür verantwortlich dass so etwas nicht passiert. Denn gerade wenn du mehrere Variablen verwendest, kann es schon passieren dass du ungewollt eine andere Variable veränderst. Das kann dann zu sehr unberechenbarem verhalten führen. Gruß, Florian
Hallo Auf jeden fall gut, das ich gleich gefragt hab und nicht erst wenn der fehler vor der tür steht, danke an euch beide. Wede wohll noch eine If abfrage auf 0 einbauen, zur sicherheit. mfg Max
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.