AVR mit Lazarus OHNE Embedded

[Mathias]

Da der DIAMEX-AVR von avrdude unterstütz wird, müsste es mit Lazarus gehen.

https://www.diamex.de/dxshop/DIAMEX-USB ... k-fuer-AVR

[Maik81SE]

Da der DIAMEX-AVR von avrdude unterstütz wird, müsste es mit Lazarus gehen.

https://www.diamex.de/dxshop/DIAMEX-USB ... k-fuer-AVR

will ich wohl meinen, das ich damit unter Lazarus keine Probleme bekommen werde.
Vorerst werde ich die noch via Console Brennen und im späteren Verlauf mal schauen, das ich diesen Direkt einbaue.

bin auch gerade dabei, meine erste IO zu schreiben inkl, aller Constanten, Variablen, welche ich brauche, und komme nach und nach auf einige Fehlermelduungen, welche wohl NICHT erfasst wurden.

Nachdem ich das Thema mit den Units und Includes soweit vom Zettel bekomme, lande ich gerade hier bei dieser Meldung.

Code: Alles auswählen

Projekt kompilieren, Modus: avr-embedded, OS: embedded, CPU: avr, Ziel: SerCom: Exit code 1, Fehler: 1, Hinweise: 4
Hint: Start of reading config file /home/pi/fpcupdeluxe/fpc/bin/i386-linux/fpc.cfg
Hint: End of reading config file /home/pi/fpcupdeluxe/fpc/bin/i386-linux/fpc.cfg
Verbose: Free Pascal Compiler version 3.2.0-r45643 [2020/12/22] for avr
Verbose: Copyright (c) 1993-2020 by Florian Klaempfl and others
Verbose: Target OS: Embedded
Verbose: Compiling SerCom.lpr
Verbose: Compiling /home/pi/fpcupdeluxe/fpcsrc/rtl/inc/lnfodwrf.pp
Verbose: Compiling /home/pi/fpcupdeluxe/fpcsrc/rtl/inc/exeinfo.pp
Verbose: Compiling /home/pi/fpcupdeluxe/fpcsrc/rtl/inc/strings.pp
strings.pp(129,37) Hint: Function result variable does not seem to be initialized
Verbose: Assembling strings
exeinfo.pp(62,27) Hint: Parameter "addr" not used
exeinfo.pp(178,7) Fatal: Unknown compilerproc "fpc_ansistr_assign". Check if you use the correct run time library.
Verbose: Compilation aborted
Verbose: /home/pi/fpcupdeluxe/fpc/bin/i386-linux/ppcrossavr returned an error exitcode

Der Fehleraufruf findet genau in dieser Zeile statt.

Code: Alles auswählen

{$else FPC_HAS_FEATURE_COMMANDARGS}
      filename:='';                  

Magst du mal bitte nachfolgenden Screanshot in deinem AVR Embedded Tutorial nachtragen, damit wir alle die gleichen und Korrekten Einstellungen verwenden?

2020-12-22-210547_1366x768_scrot.png (124.58 KiB) 10276 mal betrachtet

ich hab unter Garantie eine vergessen oder ein paar falsche drinnen.

[PascalDragon]

Schalte das die Option Zeilennummern in Laufzeitfehler-Backtraces anzeigen (-gl) (unter Compilereinstellungen -> Debuggen aus). Die entsprechenden Units, die dadurch eingebunden werden (eben nämlich lnfodwrf, exeinfo und strings) sind einfach zu mächtig für den AVR (genauso wie AnsiString, deswegen ist dieses Feature per Default deaktiviert).

[Maik81SE]

Schalte das die Option Zeilennummern in Laufzeitfehler-Backtraces anzeigen (-gl) (unter Compilereinstellungen -> Debuggen aus). Die entsprechenden Units, die dadurch eingebunden werden (eben nämlich lnfodwrf, exeinfo und strings) sind einfach zu mächtig für den AVR (genauso wie AnsiString, deswegen ist dieses Feature per Default deaktiviert).

ist der durch das ausschalten von Generate info for the Debugger (slower / increases exe-size) nicht auch schon Deaktiviert?
Wenn nein, dann ist der Hinweis gold wert.

Habe meine Benutzerdefinierten Einstellungen mal mit diesen Parametern gefüttert und läuft soweit auch ohne Weitere Fehler.

• -al
• -O-
• -OpAVR5
• -WpATMEGA16

Auch das direkte Brennen aus Lazarus hab ich für meine Zwecke eingebunden.

Code: Alles auswählen

/usr/bin/avrdude -c stk500v2 -p m16 -P/dev/ttyACM0 -b57600 -U flash:w:Projekt1.hex

einzig, was mich da zugegen stört, das man die Hex-File bei jedem Projekt Manuell ändern muß, oder ist da jemandem ein Allgemeiner Syntax als Parameter ("Projektname".hex) bekannt?

[Timm Thaler]

Du kannst so anfangen, aber Optimierungen sollten später auf -O3, sonst erzeugt der Compiler eine Menge unnötigen Code. Zum Beispiel 16-Bit For-Schleifen, obwohl nur 8-Bit definiert.

[Maik81SE]

Du kannst so anfangen, aber Optimierungen sollten später auf -O3, sonst erzeugt der Compiler eine Menge unnötigen Code. Zum Beispiel 16-Bit For-Schleifen, obwohl nur 8-Bit definiert.

das sowieso

Aber wie ich leider mitbekomme, schein es dennoch ein Problem der UART unter FPC zu bekommen, den ich auf mikrocontroller.net liegen habe.

[af0815]

Dort liegt der UART falsch. SCNR

Was ist genau dein Problem ? Scheint - ist keine Aussage.

[Maik81SE]

Dort liegt der UART falsch. SCNR

Was ist genau dein Problem ? Scheint - ist keine Aussage.

OutPut unter PicoCom mit dem C-Code = Hallo Welt
OutPut unter PicoCom mit dem Lazarus erstelltenn Code = ''

Würde ich aber gerne anderen Forum lassen, da es mit dem Eigentliche nichte mehr zu tun hat.

Edit

Code: Alles auswählen

 procedure UARTSendChar(value: char);
 begin
   while UCSRA and (1 shl UDRE) = 0 do begin
   end;
   UDR         := byte(c);			<--- c <> value
 end;

Der Fehler lag im Detail...
Man sollte auch mal seine Variablen so verwenden, wie man diese in der Deklaration hat.

Copy|Past - Fehler

[Timm Thaler]

Aber wie ich leider mitbekomme, schein es dennoch ein Problem der UART unter FPC zu bekommen, den ich auf mikrocontroller.net liegen habe.

Mach mal einen eigenen Thread dazu auf, und stell den Code rein. mikrocontroller.net ist nicht sehr hilfreich bei Pascal, das sind größtenteils eingefleischte C-Jünger.

Meine Uarts laufen.

[Maik81SE]

Aber wie ich leider mitbekomme, schein es dennoch ein Problem der UART unter FPC zu bekommen, den ich auf mikrocontroller.net liegen habe.

Mach mal einen eigenen Thread dazu auf, und stell den Code rein. mikrocontroller.net ist nicht sehr hilfreich bei Pascal, das sind größtenteils eingefleischte C-Jünger.

Meine Uarts laufen.

Wie gesagt...
Meine läuft jetzt auch
Da kann ich mich nach den Feiertagen um die TWI mit meinen beiden 8bit IO-Expandern kümmern und dann geht der Spaß richtig los.
Aber ja...
Bei Mikrocontroller.net habe ich auch eben wieder mitbekommen, das viele lieber aus die Hardware achten

Aber meine Verwendeten Units werde ich im neuen Jahr auch noch einmal anfassen und zur Verfühgung stellen.

[PascalDragon]

Schalte das die Option Zeilennummern in Laufzeitfehler-Backtraces anzeigen (-gl) (unter Compilereinstellungen -> Debuggen aus). Die entsprechenden Units, die dadurch eingebunden werden (eben nämlich lnfodwrf, exeinfo und strings) sind einfach zu mächtig für den AVR (genauso wie AnsiString, deswegen ist dieses Feature per Default deaktiviert).

ist der durch das ausschalten von Generate info for the Debugger (slower / increases exe-size) nicht auch schon Deaktiviert?
Wenn nein, dann ist der Hinweis gold wert.

Wenn aus irgendeinem Grund die IDE -gl dennoch an den Compiler weiterreichen sollte, dann macht der Compiler das ganz brav.

Habe meine Benutzerdefinierten Einstellungen mal mit diesen Parametern gefüttert und läuft soweit auch ohne Weitere Fehler.

• -al
• -O-
• -OpAVR5
• -WpATMEGA16

Die unteren drei solltest du auch über die Compilereinstellungen einstellen können.

Auch das direkte Brennen aus Lazarus hab ich für meine Zwecke eingebunden.

Code: Alles auswählen

/usr/bin/avrdude -c stk500v2 -p m16 -P/dev/ttyACM0 -b57600 -U flash:w:Projekt1.hex

einzig, was mich da zugegen stört, das man die Hex-File bei jedem Projekt Manuell ändern muß, oder ist da jemandem ein Allgemeiner Syntax als Parameter ("Projektname".hex) bekannt?

Wie hast du es denn eingebunden? In Compiler Kommandos -> Nachher ausführen? Dort könntest du einfach $(OutputFile) statt Projekt1.hex nutzen (oder so ähnlich).

[Maik81SE]

Auch das direkte Brennen aus Lazarus hab ich für meine Zwecke eingebunden.

Code: Alles auswählen

/usr/bin/avrdude -c stk500v2 -p m16 -P/dev/ttyACM0 -b57600 -U flash:w:Projekt1.hex

einzig, was mich da zugegen stört, das man die Hex-File bei jedem Projekt Manuell ändern muß, oder ist da jemandem ein Allgemeiner Syntax als Parameter ("Projektname".hex) bekannt?

Wie hast du es denn eingebunden? In Compiler Kommandos -> Nachher ausführen? Dort könntest du einfach $(OutputFile) statt Projekt1.hex nutzen (oder so ähnlich).

Das habe ich wie folgt eingebunden...

2020-12-24-221716_1366x768_scrot.png (135.75 KiB) 10166 mal betrachtet

Die Option $(OutputFile) hatte leider nicht den Effekt, aber da ich an diesem Projekt jetzt auch eine Weile schreiben werde, Stört mich der Aspekt nur sekundär.
Ist ja nicht so, das ich aller 5 Minuten ein anderes Projekt für meine µC schreibe.

[PascalDragon]

Die Option $(OutputFile) hatte leider nicht den Effekt, aber da ich an diesem Projekt jetzt auch eine Weile schreiben werde, Stört mich der Aspekt nur sekundär.
Ist ja nicht so, das ich aller 5 Minuten ein anderes Projekt für meine µC schreibe.

Hab's mir jetzt gerade nochmal selbst angeschaut. Lazarus nimmt per Default .elf als Extension an, also musst du das folgende nehmen:

Code: Alles auswählen

$Path($(OutputFile))$NameOnly($(OutputFile)).hex

2.0.10 scheint allerdings ein Problem mit $(OutputFile) zu haben, weswegen du dort $(TargetFile) nehmen solltest (der Unterschied ist, dass TargetFile das Startkommando bezeichnet, falls eins gesetzt ist, während OutputFile auch immer die Ausgabedatei ist).

[Maik81SE]

Hab's mir jetzt gerade nochmal selbst angeschaut. Lazarus nimmt per Default .elf als Extension an, also musst du das folgende nehmen:

Code: Alles auswählen

$Path($(OutputFile))$NameOnly($(OutputFile)).hex

2.0.10 scheint allerdings ein Problem mit $(OutputFile) zu haben, weswegen du dort $(TargetFile) nehmen solltest (der Unterschied ist, dass TargetFile das Startkommando bezeichnet, falls eins gesetzt ist, während OutputFile auch immer die Ausgabedatei ist).

Jopp, genau das ist es, sommit schaut die entsprechende Zeile nun wie folgt aus.

Code: Alles auswählen

/usr/bin/avrdude -c stk500v2 -p m16 -P/dev/ttyACM0 -b57600 -U flash:w:$Path($(OutputFile))$NameOnly($(TargetFile)).hex

[PascalDragon]

Du solltest auch TargetFile für den Aufruf in Path nutzen, damit es wirklich korrekt ist. Es macht bei dir keinen Unterschied, weil deine hex Datei im gleichen Verzeichnis wie dein Projekt liegt.