AVRPascal – free code editor for FPC for AVR

[ackarwow]

New version of AVRPascal (2.9) is available on http://akarwowski.pl/index.php?page=electronics&lang=en

Changes:
New version of AVRdude (8.0)
New version of UnoLib (0.7; see https://sourceforge.net/projects/unolib/ for details)
New features:
- remembering the location of the last opened directory after using menu functions: "Open File", "Save File", "Save File As", "Export to HTML", "Upload from File", "Download to File".
- added compiler parameters -Sg (enable goto) and -Si (enable inlining); labels and inlining are enabled by default
Bug fixes:
- improved working of "Tab" and "Shift+Tab"; using them changes the indent of selected text
- improved compiler command line, making it possible to use files with paths containing spaces (Linux, MacOS)

Many thanks for @Dzandaa, @ccrause and @VisualLab for valuable suggestions and help with testing.

Edit: updated manual attached.

[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.
(...)

I think I found the necessary sources in Arduino and I modified blink for Leonardo so that after uploading to the board the device (port) would still be visible in the system. My code/translation is not perfect (the device is visible as "Arduino Leon" instead of "Arduino Leonardo"), but I hope that after some improvements it will work 100% correctly.

I modified blink example written by @ccrause and I wrote new modules: cdc.pas and usb.pas.

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

1. program ccrause_blink_leonardo;
2.  
3. {
4.   source: https://github.com/ccrause/fpc-avr/blob/master/src/examples/blink1/blink.pp
5.   USB CDC serial implementation for Arduino Leonardo by A. Karwowski (25.11.2024)
6. }
7. uses
8.   ccrause_delay
9.  {$if defined(FPC_MCU_ARDUINOLEONARDO)}
10.   ,cdc, usb // modified by ackarwow
11.   {$endif}
12.   ;
13.  
14. const
15.   {$if defined(FPC_MCU_ATMEGA328P) or defined(FPC_MCU_ATTINY104) or defined(FPC_MCU_ATMEGA8)}
16.   // Assume Uno or attiny104 Xplained Nano layout
17.   LEDpin = 1 shl 5;
18.   {$elseif defined(FPC_MCU_ATMEGA32U4) or defined (FPC_MCU_ARDUINOLEONARDO)}
19.   // Assume Leonardo layout
20.   LEDpin = 1 shl 7;
21.   {$elseif defined(FPC_MCU_ATMEGA2560)}
22.   // Assume Mega layout
23.   LEDpin = 1 shl 7;
24.   {$else}
25.   LEDpin = 1 shl 2;
26.   {$endif}
27. var
28. {$if defined(FPC_MCU_ATTINY104)}
29.   LEDport: byte absolute PORTA;
30.   LEDdir: byte absolute DDRA;
31. {$elseif defined(FPC_MCU_ATMEGA32U4) or defined(FPC_MCU_ARDUINOLEONARDO)}
32.   LEDport: byte absolute PORTC;
33.   LEDdir: byte absolute DDRC;
34. {$else}
35.   LEDport: byte absolute PORTB;
36.   LEDdir: byte absolute DDRB;
37. {$endif}
38.  
39. procedure blinkOn; inline;
40. begin
41.   LEDport := LEDport or LEDpin;
42. end;
43.  
44. procedure blinkOff; inline;
45. begin
46.   LEDport := LEDport and not(LEDpin);
47. end;
48.  
49. //disable interrputs, added by ackarwow
50. procedure Cli; assembler; inline;
51. asm
52.   CLI
53. end;
54.  
55. //enable interrupts
56. procedure Sei; assembler; inline;
57. asm
58.   SEI
59. end;
60.  
61. begin
62.   {$if defined(FPC_MCU_ARDUINOLEONARDO)} //added by ackarwow
63.   USBDevice.Attach;
64.  
65.   Sei;
66.   {$endif}
67.  
68.   LEDdir := LEDpin;
69.   blinkOff;
70.  
71.   while True do
72.   begin
73.      blinkOn;
74.      delay_ms(500);
75.      blinkOff;
76.      delay_ms(250);
77.   end;
78. end.
79.  
80.  

Pascal code attached.

Edit "Arduino Leon" is very easy to correct, but thanks to it I know that my code is running on the board. Of course the rest of the code needs to be checked, but I am optimistic.

[ccrause]

Edit "Arduino Leon" is very easy to correct, but thanks to it I know that my code is running on the board. Of course the rest of the code needs to be checked, but I am optimistic.

This code is also potentially buggy, although the two constants happens to be identical:

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

1. Exit(USB_SendStringDescriptor(STRING_MANUFACTURER, strlen(USB_MANUFACTURER), 0))

The use of PChar is probably a straight translation from C++, I would suggest using shortstrings, then the length is embedded and the above type of bug is avoided.

Declaring TUSBDevice as a class and using USBDevice without calling Create happens to work by accident. Rather declare it as type object or record.

[ackarwow]

This code is also potentially buggy, although the two constants happens to be identical:

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

1. Exit(USB_SendStringDescriptor(STRING_MANUFACTURER, strlen(USB_MANUFACTURER), 0))

The use of PChar is probably a straight translation from C++, I would suggest using shortstrings, then the length is embedded and the above type of bug is avoided.

@ccrause, thanks for your comment. Yes, this code is strange even in the original:

Code: C  [Select][+][-]

1.                 else if (setup.wValueL == IMANUFACTURER) {
2.                         return USB_SendStringDescriptor(STRING_MANUFACTURER, strlen(USB_MANUFACTURER), TRANSFER_PGM);
3.                 }  
4.  

Declaring TUSBDevice as a class and using USBDevice without calling Create happens to work by accident. Rather declare it as type object or record.

Thank you, I will change classes to objects, my mistake.

[ccrause]

I modified blink example written by @ccrause and I wrote new modules: cdc.pas and usb.pas.

Do you have plans to host this code on a public repository (e.g. GitHub or one of the free alternatives)?

[ackarwow]

Do you have plans to host this code on a public repository (e.g. GitHub or one of the free alternatives)?

Yes, I just created account on GitHub (https://github.com/ackarwow. Also UnoLib - my Arduino code translation to Pascal is available on SourceForge (https://sourceforge.net/projects/unolib/). Perhaps I will update sources on GitHub more frequently, and to SourceForge I will put only releases. I think it will be comfortable this way. The code for Arduino Leonardo is a side (extra, somewhat unexpected) issue, UnoLib is mainly code for Arduino Uno.

Edit. Added source code of UnoLib to GitHub repository https://github.com/ackarwow/unolib. Code for Arduino Leonardo is in "extras" directory.

[ccrause]

Do you have plans to host this code on a public repository (e.g. GitHub or one of the free alternatives)?

Yes, I just created account on GitHub (https://github.com/ackarwow. Also UnoLib - my Arduino code translation to Pascal is available on SourceForge (https://sourceforge.net/projects/unolib/). Perhaps I will update sources on GitHub more frequently, and to SourceForge I will put only releases. I think it will be comfortable this way. The code for Arduino Leonardo is a side (extra, somewhat unexpected) issue, UnoLib is mainly code for Arduino Uno.

Great news, thank you!  I am interested in the Leonardo USB code (for later, I have other things occupying my time at the moment), so it would be good if that sits in its own repository.

[ackarwow]

There will be some self-criticism. Struggles with Arduino Leonardo forced me to write more code in AVRPascal and try the new version "in combat". It is possible to use the editor, but for convenience I miss:
1. Better jump to interface/implementation sections. If I have an incorrect fragment in the code (e.g. in C) the program raises an exception. I show such exceptions to see in what situations they appear and now I know that I should move them to the Messages area and not interrupt the program. Example of such exception:

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

1. Exception "expected end., but static found" of class ECodeToolError in module avrpascal.exe at
2.   $0000000100468335  RAISEEXCEPTIONINSTANCE,  line 2493 of customcodetool.pas

2. Better finding of declaration of keyword/module performance. Some declarations are not found at all, especially if they are in IFDEF blocks.
3. I really miss jump history to e.g. go back to the previously found declaration/definition. The jump list doesn't have to be displayed anywhere, but shortcuts like in Lazarus are needed (Ctr+H/Ctr+Shift+H).

Good news: thanks to additional code (https://github.com/ackarwow/unolib) AVRPascal works with Arduino Leonardo without any problems (I haven't found any). Also I believe the program can work with the Arduino Uno clone that @VisualLab has.

Maybe you (@Dzandaa, @VisualLab, other users of the forum) have other, additional impressions?

[VisualLab]

Maybe you (@Dzandaa, @VisualLab, other users of the forum) have other, additional impressions?

Recently I didn't have time for anything during the week (work). I plan that on Saturday and Sunday I will be able to test/experiment a bit again under Windows and Linux. However, I don't have an Arduino Leonardo, so the tests/experiments will include:

• Arduino Uno clone (from Waveshare),
• ATTINY13A and ATMEGA16A microcontrollers (circuits built on breadboards).

[ackarwow]

Recently I didn't have time for anything during the week (work). I plan that on Saturday and Sunday I will be able to test/experiment a bit again under Windows and Linux.
(...)

Thank you very much, I appreciate you taking your time. Of course there is no rush

[VisualLab]

I performed AVRPascal tests on the following hardware:

• Arduino Uno R3 clone (from Waveshare), and
• ATTINY13A and ATMEGA16A microcontrollers (circuits built on breadboards).

The tests were carried out in the Windows 10 64-bit operating system. For Arduino Uno R3 (clone), I used the source files from the examples subdirectory in the AVR Pascal program working directory:

• TestBlink.pas,
• TestDigital.pas,
• TestSerial.pas.

To test the ATTINY13A microcontroller, I used the file: attiny13_blink1.pas provided with the AVRPascal manuals. To test the ATMEGA16A microcontroller, I used a slightly modified file: attiny13_blink1.pas.

I used a clone of the USBasp programmer to program both microcontrollers. Programming the Arduino board and both AVR microcontrollers using AVRPascal (in Windows) is quick and efficient. There are no stutters or delays. There are also no messages about avrdude trying to communicate with the Arduino board or the USBasp programmer. Both the board and the microcontrollers are programmed immediately.

All that remains is to conduct similar tests in Linux. Except that I have Linux installed on a separate test computer (Up Squared) and it would be necessary to update it.

[Dzandaa]

Hi,

I tested AVRPascal on Windows 7 pro 64 bits and Linux Mint 64 using Serial, Digital on an Arduino Uno R2 and Nano without problem.
The size if greater than Arduino's IDE but the compilation and download is very fast.

B->

[ackarwow]

@VisualLab, @Dzandaa
Many thanks for your tests. These are great news! What about coding - what are your impressions on working with code?

(...)The size if greater than Arduino's IDE but the compilation and download is very fast.(...)

Yes, size of compiled binary is greater than Arduino's. I thought about it and it seems to me that the reasons may be as follows:
1) Functions for preprocessor are frequently used in Arduino. There is no equivalent macros in Pascal so I changed them into regular procedures/functions in UnoLib library, which (I suppose) increased their binary size
2) Some procedures/functions of UnoLib can be inlined to reduce binary output
Maybe you have other/better ideas?
 

[marcov]

Keep in mind that Pascal supports cross-unit inlining. That can in some cases substitute macros.

Making aliases for e.g. a pin is a bit harder though.

[ackarwow]

@marcov
Thank you for your comment

Keep in mind that Pascal supports cross-unit inlining. That can in some cases substitute macros.

Yes, I am thinking exactly the same. It potentially can reduce output size, but needs some experiments... I will try to do it.

Making aliases for e.g. a pin is a bit harder though.

UnoLib (my translation of part of Arduino library for Arduino Uno) uses ATMega328p aliases of pins from FPC RTL definitions for AVRs. There is probably no need to redefine them.