AVRPascal – free code editor for FPC for AVR

[ackarwow]

@All

Does anyone have a working and tested code in FPC 3.3.1 for Arduino Leonardo? Preferably a simple Blink. I need .pas, .elf and .hex. Maybe @ccrause in his rich library of examples?

I am testing avrdude 8.0 and my blink for Leonardo causes a stop after about 10 seconds. When I upload .hex generated by Arduino IDE - everything works OK. I assume the error is in my code or my way of compiling RTL...

[Dzandaa]

Hi,

@ackarwow:

Sorry, I just have Uno and Nano (also ESP32 and ESP8266, but this is another story  )

B->

[ackarwow]

(...)
Sorry, I just have Uno and Nano (also ESP32 and ESP8266, but this is another story  )
(...)

Thanks, @Dzandaa. I do not personally use Arduino Leonardo but AVRPascal should support it. And Arduino Leonardo is very specific board, e.g. it needs to reset port before uploading...

[VisualLab]

I don't have an Arduino Leonardo either.

[CM630]

Thanks for the clarification, this does not seem to be the thing for me.
Btw, as Leonardo was mentioned, AFAIR its main advantage is that it can emulate a mouse/keyboard, but the same can be done with a Bluepill. Indeed, the Bluepill requires an UART or an STLINK for programming, both available for an euro or two.

[ccrause]

Does anyone have a working and tested code in FPC 3.3.1 for Arduino Leonardo? Preferably a simple Blink. I need .pas, .elf and .hex.

This blink example works on a Leonardo board, it has been running for probably 1/2 an hour without issues.  Attached find zipped elf and hex.  Flashed with avrdude 6.3-20171130 on Linux Mint:

Code: Text  [Select][+][-]

1. avrdude -P /dev/ttyACM0 -c avr109 -p m32u4 -U flash:w:blink.hex:i
2.  
3. Connecting to programmer: .
4. Found programmer: Id = "CATERIN"; type = S
5.     Software Version = 1.0; No Hardware Version given.
6. Programmer supports auto addr increment.
7. Programmer supports buffered memory access with buffersize=128 bytes.
8.  
9. Programmer supports the following devices:
10.     Device code: 0x44
11.  
12. avrdude: AVR device initialized and ready to accept instructions
13.  
14. Reading | ################################################## | 100% 0.00s
15.  
16. avrdude: Device signature = 0x1e9587 (probably m32u4)
17. avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
18.          To disable this feature, specify the -D option.
19. avrdude: erasing chip
20. avrdude: reading input file "blink.hex"
21. avrdude: writing flash (292 bytes):
22.  
23. Writing | ################################################## | 100% 0.03s
24.  
25. avrdude: 292 bytes of flash written
26. avrdude: verifying flash memory against blink.hex:
27. avrdude: load data flash data from input file blink.hex:
28. avrdude: input file blink.hex contains 292 bytes
29. avrdude: reading on-chip flash data:
30.  
31. Reading | ################################################## | 100% 0.01s
32.  
33. avrdude: verifying ...
34. avrdude: 292 bytes of flash verified
35.  
36. avrdude: safemode: Fuses OK (E:CB, H:D8, L:FF)
37.  
38. avrdude done.  Thank you.

[ackarwow]

(...)
This blink example works on a Leonardo board, it has been running for probably 1/2 an hour without issues.  Attached find zipped elf and hex.  Flashed with avrdude 6.3-20171130 on Linux Mint:
(...)

Many thanks! You are great!

[ackarwow]

This blink example works on a Leonardo board (...)

@ccrause,
Did you turn on goto support and inlining (-Sg -Si) during compilation?

[ccrause]

This blink example works on a Leonardo board (...)

@ccrause,
Did you turn on goto support and inlining (-Sg -Si) during compilation?

Goto is not used, so -Sg does not matter. -Si should be used to inline the blinkOn / blinkOff procedures, however the compiler seems to inline these calls regardless of the inline setting. Whether inlining is explicitly enabled or not the code should still work. -Sm should be specified because the F_CPU should be defined for the delay unit. Below a full compiler command for reference (note that -Sgi is set in fpc.cfg):

Code: Text  [Select][+][-]

1. ~/fpc/installs/lib/fpc/3.3.1/ppcrossavr -l -vhwi -mobjfpc -Fu../../library -Wpatmega32u4 -Sm -dF_CPU:=16000000 -O2 blink.pp
2. Hint: Start of reading config file /home/christo/.fpc.cfg
3. Hint: End of reading config file /home/christo/.fpc.cfg
4. Free Pascal Compiler version 3.3.1 [2024/10/23] for avr
5. Copyright (c) 1993-2024 by Florian Klaempfl and others
6. Target OS: Embedded
7. Compiling blink.pp
8. Assembling blink
9. Linking blink
10. 52 lines compiled, 0.1 sec, 278 bytes code, 0 bytes data
11. 2 hint(s) issued

[ackarwow]

@ccrause

I have some observations on FPC for Arduino Leonardo:

1. After uploading your .hex file on Windows x64 Arduino Leonardo blinking as expected, but its serial port disappear in the system. When I am doing the same with .hex produced by Arduino IDE - there are no such problems, Arduino port appears correctly. After uploading your .hex I can reset Arduino (by pressing button on the board) and I have about 10 seconds to correctly upload anything to Arduino via Arduino IDE. If I dont make it in this time - port disappear in the system. So probably there are some problems in FPC code produced by your example.
2. I compiled your example on my Win x64 system using -Sg and -Si switches. In details .elf is slightly different (additional code generated for debugger, different names of routines etc.), but .hex file is the same. The result of uploading is also the same.
3. Initially I had some problems with your example. I set controller to ARDUINOLEONARDO (absolutely correctly) which unfortunately does not define  FPC_MCU_ATMEGA32U4 but FPC_MCU_ARDUINOLEONARDO. At the time I can fix this problem by modifying ifdefs in your example:

Code: Pascal  [Select][+][-]

1. const
2.   {$if defined(FPC_MCU_ATMEGA328P) or defined(FPC_MCU_ATTINY104) or defined(FPC_MCU_ATMEGA8)}
3.   // Assume Uno or attiny104 Xplained Nano layout
4.   LEDpin = 1 shl 5;
5.   {$elseif defined(FPC_MCU_ATMEGA32U4) or defined (FPC_MCU_ARDUINOLEONARDO)}
6.   // Assume Leonardo layout
7.   LEDpin = 1 shl 7;
8.   {$elseif defined(FPC_MCU_ATMEGA2560)}
9.   // Assume Mega layout
10.   LEDpin = 1 shl 7;
11.   {$else}
12.   LEDpin = 1 shl 2;
13.   {$endif}
14.  

Maybe I am wrong but in my opinion in such case compiller should automatically define FPC_MCU_ATMEGA32U4 (not using name of controller but the name of used unit). Or better - should define both FPC_MCU_ARDUINOLEONARDO and FPC_MCU_ATMEGA32U4.

[ackarwow]

(...)
Goto is not used, so -Sg does not matter. -Si should be used to inline the blinkOn / blinkOff procedures, however the compiler seems to inline these calls regardless of the inline setting. Whether inlining is explicitly enabled or not the code should still work. -Sm should be specified because the F_CPU should be defined for the delay unit.
(...)

@ccrause, many thanks for explanation. I use the same switches: -Sg -Si for compiling your delay.pas and blink.pas (I renamed them in my system because I have many "blink" files). -Sg is needed for delay (asm labels) and -Si seem to be necessary for inlining. Without -Si I have result as follows:

Code: [Select]

"C:\Programs\avr\avrpascal\bin\x86_64-win64\pp.exe" -n "-FuC:\Programs\avr\avrpascal\lib\avr" "-FuC:\Programs\avr\avrpascal\lib" "-FUC:\Programs\avr\avrpascal\out" -Tembedded -a -al -gw2 -vi -vw -vn -vh -O2 -CpAVR5 -WpARDUINOLEONARDO -XPavr- -Sm -dARDUINOLEONARDO -dAVR5 -dFAMILYMEGA -dF_CPU:=16000000 "C:\Programs\avr\avrpascal\examples\ccrause_blink_leonardo.pas"
Target OS: Embedded
Compiling C:\Programs\avr\avrpascal\examples\ccrause_blink_leonardo.pas
ccrause_blink_leonardo.pas(32,1) Hint: Inlining disabled
ccrause_blink_leonardo.pas(37,1) Hint: Inlining disabled
ccrause_blink_leonardo.pas(38,37) Warning: Range check error while evaluating constants (18446744073709551487 must be between 0 and 255)
Assembling ccrause_blink_leonardo
Linking C:\Programs\avr\avrpascal\examples\ccrause_blink_leonardo
53 lines compiled, 0.1 sec, 294 bytes code, 0 bytes data
1 warning(s) issued
2 hint(s) issued


[ccrause]

(...)
Goto is not used, so -Sg does not matter. -Si should be used to inline the blinkOn / blinkOff procedures, however the compiler seems to inline these calls regardless of the inline setting. Whether inlining is explicitly enabled or not the code should still work. -Sm should be specified because the F_CPU should be defined for the delay unit.
(...)

@ccrause, many thanks for explanation. I use the same switches: -Sg -Si for compiling your delay.pas and blink.pas (I renamed them in my system because I have many "blink" files). -Sg is needed for delay (asm labels) and -Si seem to be necessary for inlining. Without -Si I have result as follows:

Of course you are correct, I finally discovered that -Sgi is set in my fpc.cfg. Apologies for the misinformation!

[ccrause]

1. After uploading your .hex file on Windows x64 Arduino Leonardo blinking as expected, but its serial port disappear in the system. When I am doing the same with .hex produced by Arduino IDE - there are no such problems, Arduino port appears correctly. After uploading your .hex I can reset Arduino (by pressing button on the board) and I have about 10 seconds to correctly upload anything to Arduino via Arduino IDE. If I dont make it in this time - port disappear in the system. So probably there are some problems in FPC code produced by your example.

It isn't really an error, the blink example doesn't include a USB CDC/ACM serial implementation (I don't have a Pascal implementation) so there shouldn't be a serial port.  I think it is included by default in Arduino so that the board can be reset when opening the serial port with a low baud setting.

3. Initially I had some problems with your example. I set controller to ARDUINOLEONARDO (absolutely correctly) which unfortunately does not define  FPC_MCU_ATMEGA32U4 but FPC_MCU_ARDUINOLEONARDO.
...
Maybe I am wrong but in my opinion in such case compiller should automatically define FPC_MCU_ATMEGA32U4 (not using name of controller but the name of used unit). Or better - should define both FPC_MCU_ARDUINOLEONARDO and FPC_MCU_ATMEGA32U4.

I agree that specifying a board alias should also define the controller name.

[ackarwow]

1. After uploading your .hex file on Windows x64 Arduino Leonardo blinking as expected, but its serial port disappear in the system. When I am doing the same with .hex produced by Arduino IDE - there are no such problems, Arduino port appears correctly. After uploading your .hex I can reset Arduino (by pressing button on the board) and I have about 10 seconds to correctly upload anything to Arduino via Arduino IDE. If I dont make it in this time - port disappear in the system. So probably there are some problems in FPC code produced by your example.

It isn't really an error, the blink example doesn't include a USB CDC/ACM serial implementation (I don't have a Pascal implementation) so there shouldn't be a serial port.  I think it is included by default in Arduino so that the board can be reset when opening the serial port with a low baud setting.
(...)

Hm... So when I am programming Arduino Leonardo via FPC I should do it absolutely perfectly. Because I can upload my code only once. Of course it is my joke More seriously - thanks for explanation, I will search in Arduino sources for implementation of Leonardo serial communication.

By the way - I noticed a difference in the size of the binary output file that the compiler reports in your compilation (278 bytes) and my compilation (280 bytes) but I cannot find this 2 extra bytes in .lss dump (attached)...  Maybe compiler mistake? Edit: In the meantime @ccrause modified his source which resulted in smaller binary output. So everything is OK.

[ccrause]

By the way - I noticed a difference in the size of the binary output file that the compiler reports in your compilation (278 bytes) and my compilation (280 bytes) but I cannot find this 2 extra bytes in .lss dump (attached)...  Maybe compiler mistake?

Not a compiler problem, I updated the code yesterday.