Compilieren mit WINAVR

[Mordhorst]

Moin zusammen,

ich hätte da gerne mal ein Problem: Ich bin seit sehr kurzem stolzer Besitzer eines Asuro-Roboters. Das werkseitig geflashte Testprogramm läuft einwandfrei. Wenn ich jedoch ein einfaches Programm flashe, tut sich nix. Flashe ich dann nochmal das Hexfile des Testprogramms von der CD geht´s wieder. Flashprobleme also keine! Kann also nur am Compiler, WINAVR 20100110, liegen. Hier das Programm:

#include "asuro.h"
int main(void)
{
Init();
StatusLED(RED);
while(1);
return 0;
}

Nix weltbewegendes. Meldung des Compilers:

Errors: none
-------- end --------

> Process Exit Code: 0
> Time Taken: 00:04

Ich habe vor dem maken gecleaned. Flashen geht nach Statusmeldungen des Flasprogramms auch einwandfrei.
Jemand ´ne Idee?

Danke
Andreas

[oberallgeier]

.. while(1); .. Flashprobleme also keine! Kann also nur am Compiler, WINAVR 20100110, liegen ..

Hallo Andreas,

a) Nach landläufiger Meinung sitzt der Fehler äusserst selten in einem Compiler, zumal wenn der weit verbreitet und gut beleumundet ist; der Fehler ist viel öfters (meiner Erfahrung nach fast immer) vor dem Bildschirm zu finden. Auch wenn der Fehler nur am Compiler liegen kann.
b) Nach meinem bescheidenen Wissen zu C endet die Ausführung von while(1); unmittelbar nach dem Semikolon, also unmittelbar nach einmaligem Durchlauf. Dagegen werkelt die ähnliche, übliche Syntax der Dauerschleife - also while (1) {}; - theoretisch ohne Ende, unendlich, dauernd . . .

Anmerkung: ein einmaliger Programmdurchlauf ist bei so nem kleinen Progrämmchen wie Deinem so schnell erledigt, dass das nur mit guter s..schneller Hilfe wie z.B. Oszilloskop mit Trigger etc mitkriegt. Probiers mal mit der Standardsyntax.

[radbruch]

Hallo

Das Programm scheint schon zu stimmen. Init(); setzt die Status-LED auf grün, StatusLED(RED); ändert das dann auf rot und bei while(1); wartet der asuro endlos.

Wenn die LED grün bleibt, könnte das daran liegen, dass die zweifarbige LED falsch herum eingebaut wurde und deshalb rot und grün vertauscht sind. Der Test dafür würde etwa so aussehen:

#include "asuro.h"
int main(void)
{
Init();
StatusLED(GREEN);
while(1);
return 0;
}

Wenn die Status-LED bei diesem Programm rot leuchtet ist sie vertauscht eingebaut.

Möglicherweise wird auch eine falsche Hex-Datei geflasht. Weitere Möglichkeiten die mir grad so einfallen:

- Bei Notepad2 war das Problem, dass man vor dem Kompilieren den Quellcode speichern muss.

- Sollte der Fehler darin liegen, dass das Programm nicht kompiliert wurde, dann sollte man prüfen, welches Datum die .hex-Datei hat, die man flasht. Oder man löscht die Hex-Datei bevor man kompiliert und prüft, ob eine neue Datei erzeugt wurde.

- Vor dem erneuten Kompilieren kann man noch prüfen, ob das Flashprogramm erkennt, dass die Datei gelöscht ist.

- Man könnte auch bewusst einen Syntaxfehler in den Quellcode einbauen um zu prüfen, ob dieser beim Kompilieren auch wirklich verwendet wird.

Gruß

mic

[Peter(TOO)]

Hallo Geier,

b) Nach meinem bescheidenen Wissen zu C endet die Ausführung von while(1); unmittelbar nach dem Semikolon, also unmittelbar nach einmaligem Durchlauf. Dagegen werkelt die ähnliche, übliche Syntax der Dauerschleife - also while (1) {}; - theoretisch ohne Ende, unendlich, dauernd . . .

Nicht so ganz ....
Die Syntax lautet
while (Bedingung) Befehl ;

Da jeder Befehl mit einem ";" enden muss, wäre es nicht möglich mehrer Befehle in der Schlaufe auszuführen.
Mit { .... } kann man beliebig viele Befehle zu einem Bloch zusammenfassen, welche dann syntaktisch als einzelner Befehl ausgewertet werden.
C erlaubt auch leere Befehle. Somit sind

while(1);
und
while(1) {};
gleichwertig.

Überall wo in C ein Befehl stehen darf kann man mit geschweiften Klammern auch einen ganzen Block einfügen.


MfG Peter(TOO)

[oberallgeier]

Hallo Geier,
Nicht so ganz ....
Die Syntax lautet
while (Bedingung) Befehl ; ...

Danke Peter, kein Zweifel Du hast Recht. Es ist dumm gelaufen mit meiner falschen Antwort: der Kernighan-Ritchie erwähnt nirgendwo die Form ohne geschweifte Klammern (diese Klammern sind dort sicher irgendwo als Befehlspaket-Schnürsenkel erläutert), ich selbst hatte diese Schreibweise nie verwendet (komisch wo ich doch extrem schreibfaul bin :-/ ), aber ne Internetrecherche hatte für mich mal diese Form (glaubwürdig) als Einmaldurchlauf beschrieben. Beim Schreiben klingelte meine Terminerinnerung und ich hatte daher meine Aussage nicht durch nen Test bestätigt. Nu hab ich den Test grad hinter mir - hab den Salat - und danke Dir wie immer für Deine Geduld mit meinen Un-Kenntnissen.

Test

// Testcode im main:
// - - - - - - - - - - - - - - - -
    uputs0 ("\r\twhile (1); im main wird gestartet");   //
    while (1);
    uputs0 ("\r\twhile (1); im main ist abgearbeitet");   //

// - - - - - - - - - - - - - - - -

Testergebnis - vollständiger Ausdruck; es fehlet die zweite Ausgabe "... ist abgearbeitet". Wen wunderts noch?

    C501 R5M10_70 m1284/20MHz 31. Okt. 2015 08:48
    UART0_128 - 115 kBd.    UART1_128 - 57 kBd.
    Reset (warm, PC2) durch RC5x3 987
    KEIN zyklischer, automatischer Reset
    I²C - twimaster 78 kHz, TWBR = 120
    RC-5 auf PC4, RC3BYT

    Init ADC : ADC6-Batt    Ub_ADC5 Min 500 , Mess 341

    main => i2clook    Suche I²C-Devices im Bereich 0x70/112dez - 0xFE/254dez
    ---------
        Slave addr    130 dez = 0x82    MoCo
        Slave addr    132 dez = 0x84    KoCo
        Slave addr    134 dez = 0x86    ARCo
        Slave addr    136 dez = 0x88    ALCo
    ----------------------------------------------------
    Jedes '-' bedeutet: Slave/s nicht vorhanden oder defekt.
    i2clook => main
    while (1); im main wird gestartet 

Geändert von oberallgeier (31.10.2015 um 09:28 Uhr) Grund: Test

Hier die Internetquelle mit der falschen Antwort.

[Mordhorst]

Moin zusammen,

es funktioniert. Es ist wohl so, dass man erst das Programm abspeichern muss vorm Kompilieren. Bin ich von DEV-C++ und MPLABX anderas gewohnt.

Herzlichen Dank für eure schnellen Antworten
Andreas