AVRPascal – free code editor for FPC for AVR

[ackarwow]

Hi,

@ackarwow:

In hardwareserial.pas,
The procedure:
Serial.write(buf, len);
could be useful.

for example to send a structure and its size.

I use it with Arduino IDE to send commands to a linear stepper controlled rail.

in the editor, the "TAB" key has a strange behavior.

it would be nice to have the possibility to indent a block with "TAB" and "SHIFT TAB"

B->

@Dzandaa, I realized some of your suggestions (remembering the last used directory by open dialog, working of TAB and SHIFT+TAB) and fixed error in Linux you reported (unable to work with files/directories with space in name). I am testing them and they will appear the next AVRPascal version.

Also I added simple WriteBuff(const aBuff: PUInt8; const aLen: UInt8) method to THardwareSerial. I hope it is sufficient for you. Eventually, I can change buffer type to PChar. Source code is attached.

[Dzandaa]

Hi,
@ackarwow:

Thank you very much, I'll test it this week.

B->

[Dzandaa]

Hi,

@ackarwow:

Also I added simple WriteBuff(const aBuff: PUInt8; const aLen: UInt8) method to THardwareSerial. I hope it is sufficient for you. Eventually, I can change buffer type to PChar. Source code is attached.

Both method would be fine.

Also a ReadBuff would be fine, but perhaps more complicated to implement.

This is the type of data I use:

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

1. type
2.   ComData = packed record
3.    Command: Char; // Header Command
4.    Value: Int16; // Command Value
5.    Data: Int16; // Data
6.    DataEx: Int32; // Data Extended
7.    Code: Int16; // Error Code
8.    Count: Int16; // Count
9. end;
10.  
11. // Easy to add new data in ComData
12.  
13. const StructSize = SizeOf(ComData);
14.  
15.  
16. type
17.  BufferData = packed record
18.   case boolean of
19.    true: (Values: ComData);
20.    false: (DataBuffer: array[0..StructSize-1] of char); // changed to byte
21. end;  
22.  
23. // And the command I use in AVRPascal (not tested yet):
24.  
25.  Serial.WriteBuff(Buff.DataBuffer, StructSize);
26.  

And once again thank you.



B->

[VisualLab]

I also performed a test for the ATTINY13A microcontroller. On the breadboard I prepared a very simple circuit consisting of a microcontroller, LED, resistor and IDC connector through which I connected the USBasp programmer. The programmer is recognized by AVRPascal. I loaded the file TestBlink.pas. In the AVRPascal compiler options I selected the ATTINY13A microcontroller. The upload was successful, the microcontroller was programmed (I had to set the jumper in the programmer: SLOW SCK). After disconnecting the programmer and connecting the power supply to the breadboard, the microcontroller works according to the program (i.e. the LED lights up).

As for ATTimy13 - yes, it's a good choice for various experiments. It's a bit strange that you managed to compile and run TestBlink.pas, because it's for ATMega328 and not ATTiny13, so you should get a compilation error "TestBlink.pas(4,3) Fatal: User defined: Invalid controller type, expected: atmega328p, arduinouno, or arduinonano". On my website there are pfds with examples of using ATTiny13 (including Blink) with code, but unfortunately these texts are are only in Polish...

Sorry, my fault. There was a mistake in the description. In the ATTINY13A test I used the file: attiny13_blink1.pas. Writing a message late at night is not a good idea.

[ackarwow]

Sorry, my fault. There was a mistake in the description. In the ATTINY13A test I used the file: attiny13_blink1.pas. Writing a message late at night is not a good idea.

No problem, we are humans (in text you cited I made a mistake - I wrote "ATTimy" instead of "ATTiny" ). If you are writing a message late at night - I appreciate it even more.

[VisualLab]

(...)
„avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 1 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 2 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 3 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 4 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 5 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 6 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 7 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 8 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 9 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 10 of 10: not in sync: resp=0x54

avrdude.exe done.  Thank you.”

@VisualLab thanks for further tests. Hm... generally the error looks like incorrect boud rate (rather impossible) or impossibility to access to  the port.

Probably not. I made a comparison of the avrdude.exe call between Arduino IDE and AVR Pascal. I am attaching it in a PDF file (making a table in HTML is cumbersome). Apart from obvious differences like fragments of file paths, you can see some minor differences in the calls. Interestingly, there is no difference in the transmission speed during programming (baud rate). In both cases it is: -b115200.

If it is not a avrdude version problem, then the way to run avrdude remains, for example due of incorrect parameters. If you have the latest version of AVRPascal ( 2.8 ) show the parameters of the avrdude call in Messages area. In Options window, Uploader tab, select "Show command line" and then try to upload your binary (F9). The calling parameters should appear on the top of the messages list.

Another possibility - maybe for some reason AVRPascal incorrectly calls the external avrdude process(?)... Try to copy the AVRPascal command line from the Messages area ("Copy to Clipboard" in context menu) and run it in the console or by a .bat file. Try to do the same with the Arduino IDE command line.

Calling avrdude according to the syntax generated by the Arduino IDE works without problems. However, calling avrdude according to the syntax generated by AVRPascal produces the following messages:

avrdude error: programmer is not responding
avrdude warning: attempt 1 of 10: not in sync: resp=0x00
avrdude error: programmer is not responding
avrdude warning: attempt 2 of 10: not in sync: resp=0x00
avrdude error: programmer is not responding
avrdude warning: attempt 3 of 10: not in sync: resp=0x00
avrdude error: programmer is not responding
avrdude warning: attempt 4 of 10: not in sync: resp=0x00
avrdude error: programmer is not responding
avrdude warning: attempt 5 of 10: not in sync: resp=0x00
avrdude error: programmer is not responding
avrdude warning: attempt 6 of 10: not in sync: resp=0x00
avrdude error: programmer is not responding
avrdude warning: attempt 7 of 10: not in sync: resp=0x00
avrdude error: programmer is not responding
avrdude warning: attempt 8 of 10: not in sync: resp=0x00
avrdude error: programmer is not responding
avrdude warning: attempt 9 of 10: not in sync: resp=0x00
avrdude error: programmer is not responding
avrdude warning: attempt 10 of 10: not in sync: resp=0x00
avrdude error: unable to open programmer arduino on port com5

avrdude done.  Thank you.

It seems to me that the reason must lie in some other parameters of the avrdude call. I also wonder whether the detection of the board by the IDE and the PC-Arduino communication is influenced by what integrated circuit is used for USB-UART communication on the Arduino board (or its clone). The original Arduino board has an additional ATMEGA16U2 microcontroller. The Waveshare clone board I use has the FT232RL (FTDI) system. There are also clones using other ICs, for example:

• Seeduino (Seeedstudio), uses CH340G (WCH),
• RedBoard (Sparkfun), uses CP2102N (Silicon Labs).

On my website there are pfds with examples of using ATTiny13 (including Blink) with code, but unfortunately these texts are are only in Polish...

In this case it's not a problem

[VisualLab]

I made a simple attempt using the command generated by Arduino IDE but with changed paths to avrdude files and compiled batch for Arduino board. I used the FastBlink.pas file. Original path from Arduino IDE:

"C:\Users\Ja\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude" "-CC:\Users\Ja\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf" -v  -patmega328p -carduino "-PCOM5" -b115200 -D "-Uflash:w:C:\Users\Ja\AppData\Local\Temp\arduino\sketches\2EA4A341383756C7852978801EA8BA99/FastBlink.ino.hex:i"

Original path from AVRPascal:

C:\Program Files\AVRPascal\bin\win64\avrdude.exe -C "C:\Program Files\AVRPascal\bin\win64\avrdude.conf" -p m328p -P com5 -c arduino -V -q -b115200 -Uflash:w:"C:\Program Files\AVRPascal\examples\TestSerial.hex":i

Calling avrdude from the Arduino IDE modified to use files located in the AVRPascal directories:

"C:\Program Files\AVRPascal\bin\win64\avrdude" "-CC:\Program Files\AVRPascal\bin\win64\avrdude.conf" -v  -patmega328p -carduino "-PCOM5" -b115200 -D "-Uflash:w:C:\Program Files\AVRPascal\examples\TestSerial.hex:i"

Green color indicates the modified path to the files: avrdude and the compiled batch.

The upload process went smoothly (it worked immediately). But that could have been a coincidence. So I disconnected the USB cable from the Arduino board. Then I reconnected it. This time I compiled the TestSerial.pas file. Then I ran the upload:

h:w:C:\Program Files\AVRPascal\examples\TestBlink.hex:i""C:\Program Files\AVRPascal\bin\win64\avrdude" "-CC:\Program Files\AVRPascal\bin\win64\avrdude.conf" -v  -patmega328p -carduino "-PCOM5" -b115200 -D "-Uflas

Unfortunately, programming failed (avrdude reported 10 attempts, no success). Again: I disconnected the USB cable and connected it. I once again invoked the last upload command from the command line. Avrdude reported 6 attempts to communicate with the Arduino board. On the 7th attempt it managed to successfully upload the compiled input to the board.

I also noticed that there were reports of similar problems with uploading to the board on the Arduino IDE forum. Some people reported that they used clones that had integrated circuits for USB-UART communication other than the original Arduino board.

[ackarwow]

I made a simple attempt using the command generated by Arduino IDE but with changed paths to avrdude files and compiled batch for Arduino board.

(...)

@VisualLab, many thanks for the comparison! This is fascinating... I do not see any serious errors in calling parameters of AVRPascal, however I wanted to propose to modify them a bit:

"C:\Program Files\AVRPascal\bin\win64\avrdude.exe"
"-CC:\Program Files\AVRPascal\bin\win64\avrdude.conf"
-patmega328p
-carduino
"-PCOM5"
-b115200
"-Uflash:w:C:\Program Files\AVRPascal\examples\TestSerial.hex:i"

But your similar tests prove that avrdude works irregularly or even randomly. Is it possible to repeat such irregularity in parameters taken from Arduino IDE or -better - in Arduino IDE itself? I know that in case of Arduino Leonardo and Arduino Nano Every the Arduino IDE resets serial port before connecting and uploading...

In this case it's not a problem

Great!/Znakomicie!

[VisualLab]

But your similar tests prove that avrdude works irregularly or even randomly. Is it possible to repeat such irregularity in parameters taken from Arduino IDE or -better - in Arduino IDE itself? I know that in case of Arduino Leonardo and Arduino Nano Every the Arduino IDE resets serial port before connecting and uploading...

I tried to download information about the Arduino board using avrdude (in the command line). And there was a problem with communication (a series of attempts ended in failure, similarly to uploading). I decided to check what versions of avrdude are available and whether the authors write anything about problems or limitations with their use. The avrdude project page contains 32 and 64 bit versions, compiled with the mingw and msvc. I downloaded the latest available versions of avrdude for Windows, which is 8.0 (64-bit versions: mingw and msvc).

I copied the avrdude executable and its configuration file to the AVRPascal directory, i.e.: C:\Program Files\AVRPascal\bin\win64. I did some compilation and upload tests with AVRPascal. The tests were performed one after the other:

• without disconnecting the USB cable,
• with disconnecting and reconnecting the USB cable.

Each time the upload was done immediately, without any breaks, delays or problems. Of course, further tests will have to be done, both for Arduino and for circuits with microcontrollers connected on a breadboard. Probably such tests would have to be done under Linux as well (I'll try to do it when I have some free time). But it seems that the cause lies in the previous version of avrdude, which has some internal errors.

It would be nice if users of other versions of Arduino boards (i.e. original and clones with different integrated circuits for USB-UART communication) could perform upload tests.

[ackarwow]

But your similar tests prove that avrdude works irregularly or even randomly. Is it possible to repeat such irregularity in parameters taken from Arduino IDE or -better - in Arduino IDE itself? I know that in case of Arduino Leonardo and Arduino Nano Every the Arduino IDE resets serial port before connecting and uploading...

I tried to download information about the Arduino board using avrdude (in the command line). And there was a problem with communication (a series of attempts ended in failure, similarly to uploading). I decided to check what versions of avrdude are available and whether the authors write anything about problems or limitations with their use. The avrdude project page contains 32 and 64 bit versions, compiled with the mingw and msvc. I downloaded the latest available versions of avrdude for Windows, which is 8.0 (64-bit versions: mingw and msvc).

I copied the avrdude executable and its configuration file to the AVRPascal directory, i.e.: C:\Program Files\AVRPascal\bin\win64. I did some compilation and upload tests with AVRPascal. The tests were performed one after the other:

• without disconnecting the USB cable,
• with disconnecting and reconnecting the USB cable.

Each time the upload was done immediately, without any breaks, delays or problems. Of course, further tests will have to be done, both for Arduino and for circuits with microcontrollers connected on a breadboard. Probably such tests would have to be done under Linux as well (I'll try to do it when I have some free time). But it seems that the cause lies in the previous version of avrdude, which has some internal errors.

It would be nice if users of other versions of Arduino boards (i.e. original and clones with different integrated circuits for USB-UART communication) could perform upload tests.

Very good news, thank you I will look for the latest version of avrdude. AVRPascal needs not only Windows but also Linux and MacOS (64-bit), I hope I will find the binaries. Some time ago I changed the version of avrdude from 6.3 to 7.2, because version 6.3 had problems communicating with Arduino Leonardo and Arduino Nano Every. I hope that version 8.0 will not have new bugs. If I find the binaries I will test the communication with the boards I have (original Arduino Uno, Leonardo, Nano, Nano Every) and of course with USBAsp.

[dseligo]

It would be nice if users of other versions of Arduino boards (i.e. original and clones with different integrated circuits for USB-UART communication) could perform upload tests.

I am watching this thread and didn't react sooner because I see you use STK500, while I am using USBasp.
I use various Arduino boards and different AVRs (such as ATtiny85 and ATmega2560). I program them directly from Lazarus (with command after build: C:\avrdude\avrdude.exe -patmega328p -cusbasp -V -Uflash:w:$NameOnly($(ProjFile)).hex:i).

Unfortunately, I didn't have chance to try AVRpascal yet, due to the lack of time.

Maybe important for this thread is that I also had problems with avrdude. I can't remember what problems I had, but previous version of avrdude I have on disk is avrdude-6.3-mingw32, and now I use version 8.0.

[VisualLab]

It would be nice if users of other versions of Arduino boards (i.e. original and clones with different integrated circuits for USB-UART communication) could perform upload tests.

I am watching this thread and didn't react sooner because I see you use STK500, while I am using USBasp. I also use USBasp (or rather a clone).

No, I do not have an STK500 programmer. This is an error that appeared yesterday during tests, done late at night.

I use various Arduino boards and different AVRs (such as ATtiny85 and ATmega2560). I program them directly from Lazarus (with command after build: C:\avrdude\avrdude.exe -patmega328p -cusbasp -V -Uflash:w:$NameOnly($(ProjFile)).hex:i).

Unfortunately, I didn't have chance to try AVRpascal yet, due to the lack of time.

Maybe important for this thread is that I also had problems with avrdude. I can't remember what problems I had, but previous version of avrdude I have on disk is avrdude-6.3-mingw32, and now I use version 8.0.

I have only one Arduino board, a clone from Waveshare. And two Atmel microcontrollers: ATTINY13A and ATMEGA16A (bought a few days ago together with the USBasp programmer), which I test on a breadboard using Arduino IDE and AVRPascal. It seems that you encountered similar problems in avrdude as I did.

@VisualLab, that's really very interesting... I have an idea: could you replace avrdude.exe and avrdude.conf near AVRPascal.exe with the files from Arduino 2.3.3 and try to upload your binary? I suppose the problem is in avrdude 7.2...

I renamed the file avrdude.exe located in the directory: C:\Program Files\AVRPascal\bin\win64. Then I copied the file avrdude.exe from the directory belonging to the Arduino IDE (directory:

C:\Users\Me\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17\etc

Then I ran AVRPascal and loaded the file: TestBlink.pas from the directory containing the examples. The compilation was fast and correct. However, when trying to upload, the following message appears:

avrdude.exe: error at C:\Program Files\AVRPascal\bin\win64\avrdude.conf:421: syntax error
avrdude.exe: error reading system wide configuration file "C:\Program Files\AVRPascal\bin\win64\avrdude.conf"

Line 421 is: default_spi = "";. Of course, this is included in the arvdude.exe configuration file in version 7.2. However, in the configuration file for version 6.3 (used by Arduino IDE) there is no default_spi parameter.

I renamed the file arvdude.conf located in the directory: C:\Program Files\AVRPascal\bin\win64. Then I copied the file arvdude.conf from the directory belonging to the Arduino IDE. I started the upload, but AVRPascal stopped responding for some time (the mouse cursor indicated that the program is busy), and after some time (1-2 minutes) the message appeared:

„avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 1 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 2 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 3 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 4 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 5 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 6 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 7 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 8 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 9 of 10: not in sync: resp=0x54
avrdude.exe: stk500_recv(): programmer is not responding
avrdude.exe: stk500_getsync() attempt 10 of 10: not in sync: resp=0x54

avrdude.exe done.  Thank you.”

I analyzed the tests from message no. 43 again. Yesterday's avrdude file swap was not a good idea. As a result of the file swap, something went wrong during the test and avrdude stated that my programmer is STK500. Most likely I confused the CONF files between versions 6.3 and 7.2.

I am using a clone of the USBasp programmer. Today's test was done correctly, i.e.:

• first I changed the names of both avrdude files: EXE and CONF,
• only then I copied the new (8.0) versions of avrdude.
  

A moment ago I also did a test of the ATTINY13A on a breadboard. I used a clone of the USBasp programmer and AVRPascal version 2.8. The program compiled without any problems. The programmer was also detected without problems. The upload was done immediately, without any jams or problems. In my next free time, I will also try to test the ATMEGA16A microcontroller, also on a breadboard.

[VisualLab]

I connected a simple circuit with an ATMEGA16A microcontroller and an LED (with a series resistor of about 220 ohms) connected between port PB0 (pin 1 in the IC) and ground on a breadboard. In AVRPascal (under Windows), I wrote a simple program that was supposed to light up the LED. After compiling this code, uploading (from AVRPascal) the compiled batch to the microcontroller was quick and efficient. The microcontroller lit up the LED. In order to additionally verify the operation of the microcontroller, I disconnected the programmer and then connected a separate power supply (5 V). The microcontroller (as before) lit up the LED, according to the program. Changing the avrdude version from 7.2 to 8.0 does not cause any problems. We will see how the next tests go.

[ackarwow]

I connected a simple circuit with an ATMEGA16A microcontroller and an LED (with a series resistor of about 220 ohms) connected between port PB0 (pin 1 in the IC) and ground on a breadboard. In AVRPascal (under Windows), I wrote a simple program that was supposed to light up the LED. After compiling this code, uploading (from AVRPascal) the compiled batch to the microcontroller was quick and efficient. The microcontroller lit up the LED. In order to additionally verify the operation of the microcontroller, I disconnected the programmer and then connected a separate power supply (5 V). The microcontroller (as before) lit up the LED, according to the program. Changing the avrdude version from 7.2 to 8.0 does not cause any problems. We will see how the next tests go.

Which version of avrdude 8.0 did you choose for testing on 64-bit Windows: mingw or msvc? I should use the same one for testing my Arduino boards.

[VisualLab]

I connected a simple circuit with an ATMEGA16A microcontroller and an LED (with a series resistor of about 220 ohms) connected between port PB0 (pin 1 in the IC) and ground on a breadboard. In AVRPascal (under Windows), I wrote a simple program that was supposed to light up the LED. After compiling this code, uploading (from AVRPascal) the compiled batch to the microcontroller was quick and efficient. The microcontroller lit up the LED. In order to additionally verify the operation of the microcontroller, I disconnected the programmer and then connected a separate power supply (5 V). The microcontroller (as before) lit up the LED, according to the program. Changing the avrdude version from 7.2 to 8.0 does not cause any problems. We will see how the next tests go.

Which version of avrdude 8.0 did you choose for testing on 64-bit Windows: mingw or msvc? I should use the same one for testing my Arduino boards.

The one compiled with msvc. I'll have to check the one compiled with mingw too. But that's tomorrow.