AVRPascal – free code editor for FPC for AVR

[Dzandaa]

Hi,
@ackarwow:

I also have problem on Mac using Arduino's.

I think that the FTDI driver must be installed and also the specific driver of the board.
If the chip is not a genuine Arduino, then you have to install (and recompile sometimes)  the driver from the maker (most of the time in China).

My antimalware does no allow me to access the manufacturer web site.

B->

[ackarwow]

Hi @Dzandaa

(...)
I also have problem on Mac using Arduino's.
I think that the FTDI driver must be installed and also the specific driver of the board.
If the chip is not a genuine Arduino, then you have to install (and recompile sometimes)  the driver from the maker (most of the time in China).
My antimalware does no allow me to access the manufacturer web site.
(...)

Thanks for your comments Interesting thing... I have original (or identical to original) Arduino Uno R3, that uses ATMega16U2, no FTDI chip. AVRPascal and avrdude have no problems to upload your code to my Arduino on MacOS:

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip

avrdude: processing -U flash:w:/Users/andrzej/Programs/avr/avrpascal/tests/Dzandaa/TestAVR.hex:i
avrdude: reading input file /Users/andrzej/Programs/avr/avrpascal/tests/Dzandaa/TestAVR.hex for flash
         with 5588 bytes in 1 section within [0, 0x15d3]
         using 44 pages and 44 pad bytes
avrdude: writing 5588 bytes flash ...
Writing | ################################################## | 100% 1.13s
avrdude: 5588 bytes of flash written

On the same machine I try to test your Lazarus program and it is hanging up. Maybe:
- my MacOS or my Lazarus on MacOS are in some way invalid
- there are some errors on package(s) LazSerial and/or pl_SynapseVS on MacOS
- your Lazarus test code is in some way invalid on MacOS

Maybe one of users of this forum could make independent test of your programs on MacOS...

[Dzandaa]

Hi,

@ackarwow:

Did you try to remove pl_SynapseVS from "project inspector" and re-add it?
I had the same problem on linux the first time (different versions of the library?).

I use lazarus 3.4 FPC 3.2.2

B->

[ackarwow]

(..)
Did you try to remove pl_SynapseVS from "project inspector" and re-add it?
I had the same problem on linux the first time (different versions of the library?).
I use lazarus 3.4 FPC 3.2.2
(...)

@Dzandaa
I reinstalled pl_SynapseVS and nothing changed. I am using an older version of Lazarus (2.2.6) and the same FPC. Yes it is very possible that the problem is caused by some package(s). But it is not very important now. Your test code works fine. Did you tried to increase reading/writing buffer (ComData type)?

[ackarwow]

I would like to return to the issue of reading a byte of data from UART. From the discussion above (thanks to @VisualLab, @ccrause) it seems to me that there are 4 possibilities:

1. Leave the ReadChar function unchanged, being aware that #0 may mean there is no data in the buffer (quite comfortable, maybe good enough?)

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

1. function THardwareSerial.ReadChar: char;
2. var
3.   b: byte;
4. begin
5.   // if the head isn't ahead of the tail, we don't have any characters
6.   if (RXBufferHead = RXBufferTail) then
7.     Result := #0 //-1
8.   else
9.   begin
10.     b := RXBuffer[RXBufferTail];
11.     RXBufferTail := (RXBufferTail + 1) mod SERIAL_RX_BUFFER_SIZE;
12.     Result := Chr(b);
13.   end;
14. end;
15.  

2. Add a Read function returning Int16, which is a more accurate translation of the Arduino code. Due to the type change, it may be more resource-consuming(?)

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

1. function THardwareSerial.Read: Int16;
2. var
3.   b: byte;
4. begin
5.   // if the head isn't ahead of the tail, we don't have any characters
6.   if (RXBufferHead = RXBufferTail) then
7.     Result := -1
8.   else
9.   begin
10.     b := RXBuffer[RXBufferTail];
11.     RXBufferTail := (RXBufferTail + 1) mod SERIAL_RX_BUFFER_SIZE;
12.     Result := b;
13.   end;
14. end;
15.  

3. Add a function returning Boolean type and pasing value via parameter, according to my proposal (not very comfortable):

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

1. function THardwareSerial.Read(out Value: UInt8): boolean;
2. begin
3.   // if the head isn't ahead of the tail, we don't have any characters
4.   if (RXBufferHead = RXBufferTail) then
5.     Result := false
6.   else
7.   begin
8.     Value := RXBuffer[RXBufferTail];
9.     RXBufferTail := (RXBufferTail + 1) mod SERIAL_RX_BUFFER_SIZE;
10.     Result := true;
11.   end;
12. end;
13.  

4. Add a function returning an enumerative type and passing value via parameter (more precise, not very comfortable), as proposed by @ccrause:

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

1. type
2.   TUartState = (usValidData, usNoData, usParityError);
3.      
4. function THardwareSerial.Read(out Value: UInt8): TUartState;
5. begin
6.   // if the head isn't ahead of the tail, we don't have any characters
7.   if (RXBufferHead = RXBufferTail) then
8.      Result := usNoData
9.   else
10.   begin
11.     Value := RXBuffer[RXBufferTail];
12.     RXBufferTail := (RXBufferTail + 1) mod SERIAL_RX_BUFFER_SIZE;
13.     Result := usValidData;
14.   end;
15. end;
16.  

What do you think  (@VisualLab, @ccrause, other users of forum)? Maybe @Dzandaa could comment it?

[Dzandaa]

Hi,
For me, it's the speed, and then the size of the code that counts in serial communications.

I use

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

1. function THardwareSerial.ReadByte: byte;
2. var
3.   b: byte;
4. begin
5.   // if the head isn't ahead of the tail, we don't have any characters
6.   if (RXBufferHead = RXBufferTail) then exit(0);
7.  
8.   b := RXBuffer[RXBufferTail];
9.   RXBufferTail := (RXBufferTail + 1) mod SERIAL_RX_BUFFER_SIZE;
10.   exit(b);
11. end;  
12.  

And

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

1.     if (Serial.Available > 0) then
2.     begin
3.       b := Serial.ReadByte;                
4.  

B->

[Dzandaa]

Hi,

@ackarwow:

I reinstalled pl_SynapseVS and nothing changed. I am using an older version of Lazarus (2.2.6) and the same FPC. Yes it is very possible that the problem is caused by some package(s). But it is not very important now. Your test code works fine. Did you tried to increase reading/writing buffer (ComData type)?

I try it on MacOS Sierra with:
Lazarus 3.4 FPC 3.2.2 pl_SynapseVS 6.7.1.0

And it compile and run.

I just have to change from Dwarf3 to Dwarf2 for the debugger.

B->

[ccrause]

I would like to return to the issue of reading a byte of data from UART. From the discussion above (thanks to @VisualLab, @ccrause) it seems to me that there are 4 possibilities:

1. Leave the ReadChar function unchanged, being aware that #0 may mean there is no data in the buffer (quite comfortable, maybe good enough?)

0 is a valid value to transmit over serial, it cannot in general be reserved for status.  If a user transmits for example a C style null terminated character string the end of string is a null character (0).

2. Add a Read function returning Int16, which is a more accurate translation of the Arduino code. Due to the type change, it may be more resource-consuming(?)

To be Arduino compatible this is the only option. However it is then the user's responsibility to only use the low byte for data.  I do not prefer the Arduino route because to respect the result type requires silliness:

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

1. int incomingByte = 0; // for incoming serial data

So to receive a single byte the user has to declare a 16 bit variable.

3. Add a function returning Boolean type and pasing value via parameter, according to my proposal (not very comfortable)

4. Add a function returning an enumerative type and passing value via parameter (more precise, not very comfortable), as proposed by @ccrause

These two options are actually similar, option 3 is merely when the status can only be two possible states, while option 4 is when there are more than two possible states (data read, not data, data but parity error).  Since there is little to be done about a parity error[1] one could just as well drop the data in the receive method and pretend nothing was received, as per current implementation.

Another option is to consider Dzandaa's use case of first checking Serial.Available and then decide whether to call Read or not.  This separates the logic into two methods which makes it a bit easier to implement, however the user now has to follow this pattern else run into issues at some point. Also the downside to this approach is that two method calls needs to be made before the received byte is available.

[1] Not strictly true, but I'm considering single byte level errors since the Read method is not aware of any higher protocol. If a user wants to implement a more sophisticated error correction/recovery protocol the RXCompleteIRQ method needs to be overridden.

[ackarwow]

(...)
I try it on MacOS Sierra with:
Lazarus 3.4 FPC 3.2.2 pl_SynapseVS 6.7.1.0
And it compile and run.
I just have to change from Dwarf3 to Dwarf2 for the debugger.
(...)

Thanks for suggestion. I have the same versions of FPC and pl_SynapseVS and older Lazarus version. I just tried to change Dwarf3 to Dwarf2. Nothing is better. Of course your test program runs, but after pressing "Start RS232" button it hangs up. Maybe I should update my Lazarus version, but not now. I will do it later for Windows, Linux and MacOS, when AVRPascal code will be ready for this change.

[CM630]

Hi, I have not tried it and I have not read all the comments.
But I got the impression that AVRPascal is for Arduino like controllers.
Is it usable for STM (blue/baclk pill) or ESP32? If not, is support for them on the roadmap?

[VisualLab]

But I got the impression that AVRPascal is for Arduino like controllers.

Not only for Arduino. First of all for microcontrollers from the ARV family. And since Arduino contains a microcontroller from the ARV family, it would be a "sin" not to support it

For example, you prepare an electronic circuit on a breadboard (as a prototype) and test different versions of your project. Or you have any board with AVR (and ISP connector) and you program it.

Is it usable for STM (blue/baclk pill) or ESP32? If not, is support for them on the roadmap?

But which STM? Do you mean the STM32 family? They use a 32-bit ARM core, different from AVR (which are 8-bit and have a different architecture than ARM). In turn, ESPs have a different core than AVR (and ARM), they are also 32-bit. Their support would require a separate compiler and libraries capable of supporting them. FPC supports ARM family, but probably not ESP.

[af0815]

FPC supports ARM family, but probably not ESP.

BTW: https://wiki.lazarus.freepascal.org/Xtensa
https://forum.lazarus.freepascal.org/index.php?topic=43412.0
https://forum.lazarus.freepascal.org/index.php?topic=57725.30

[ackarwow]

Many thanks for @ccrause and @Dzandaa for comments. I am considering the issue and it seems for me that I should add excact translation of Arduino Read function (which returns Int16). Only for Arduino compatibility (as indirectly suggested @VisualLab), probably without practical sense (of course @ccrause is right about necessity of use 16-bit variables instead 8-bit). I think that other changes in the module are not necessary, because the way to check the availability of data in serial buffer used by @Dzandaa is absolutley OK and useful. So my and @ccrause functions (no 3 and 4) are not very useful in practice (although @ccrause function is very precise).

Also I think that for @Dzandaa my ReadChar function could be sufficient eg. in this way:

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

1. var
2.   b: UInt8; //or byte
3. begin
4.   if (Serial.Available>0) then
5.   begin
6.     b:=UInt8(Serial.ReadChar); //or b:=Ord(Serial.ReadChar);
7.   end;
8. end;
9.  

Updated hardwareserial.pas is attached.

[VisualLab]

FPC supports ARM family, but probably not ESP.

BTW: https://wiki.lazarus.freepascal.org/Xtensa
https://forum.lazarus.freepascal.org/index.php?topic=43412.0
https://forum.lazarus.freepascal.org/index.php?topic=57725.30

I didn't know that there was an FPC version for the Xtensa (ESP32) architecture. Nice to know that it is supported.

[ackarwow]

Hi, I have not tried it and I have not read all the comments.
But I got the impression that AVRPascal is for Arduino like controllers.
Is it usable for STM (blue/baclk pill) or ESP32? If not, is support for them on the roadmap?

@CM630
Yes, AVRPascal (as sugested by name) is for AVR microcontrollers (with ISP insterface) and some Arduinos, as @VisualLab kindly explained. The program is kind of environment (mainly editor) using FPC, although not as complex as Lazarus. At the moment there are no plans to add support for other MCU architectures, but in the future... who knows?
P.S. I published AVRPascal about 2 years ago. Later I found project with the same name in the internet, probably abandoned https://avrpascal.com/.