Recent

Author Topic: AVRPascal – free code editor for FPC for AVR  (Read 10088 times)

Dzandaa

  • Sr. Member
  • ****
  • Posts: 393
  • From C# to Lazarus
Re: AVRPascal – free code editor for FPC for AVR
« Reply #60 on: November 12, 2024, 12:15:54 pm »
Hi,

@ackarwow:

I tested "writeBuff" and it seems to work:

Compared to the Arduino IDE, I have more acknowledge errors, but I need to look more into my "AVRPascal" code, maybe timing or read errors.

With RS232, asynchronous communications are not always easy.

Thank you.

To be followed :)

B->
Regards,
Dzandaa

ackarwow

  • Jr. Member
  • **
  • Posts: 82
    • Andrzej Karwowski's Homepage
Re: AVRPascal – free code editor for FPC for AVR
« Reply #61 on: November 12, 2024, 08:21:44 pm »
@VisualLab, I performed some test of avrdude 8.0 on Windows, Linux and MacOS. Results are attached.
There is a problem communicating with Arduino Leonardo in general. Probably it can be fixed in AVRPascal code, but my Arduino Leonardo stopped working...
« Last Edit: November 12, 2024, 09:08:25 pm by ackarwow »

ackarwow

  • Jr. Member
  • **
  • Posts: 82
    • Andrzej Karwowski's Homepage
Re: AVRPascal – free code editor for FPC for AVR
« Reply #62 on: November 12, 2024, 08:31:29 pm »
(...)
I tested "writeBuff" and it seems to work:
Compared to the Arduino IDE, I have more acknowledge errors, but I need to look more into my "AVRPascal" code, maybe timing or read errors.
With RS232, asynchronous communications are not always easy.
(...)
@Dzandaa, many thanks for your tests. I am thinking how to realize buffer reading, and because I do not have good testing environment now I will propose some code which should work theoretically, but without testing it...

VisualLab

  • Hero Member
  • *****
  • Posts: 575
Re: AVRPascal – free code editor for FPC for AVR
« Reply #63 on: November 12, 2024, 09:48:30 pm »
@VisualLab, I performed some test of avrdude 8.0 on Windows, Linux and MacOS. Results are attached.

I'm thinking about changing the avrdude version in Arduino IDE (temporarily). Maybe running such tests would lead to some good leads. I will try to do such tests in my free time.

There is a problem communicating with Arduino Leonardo in general. Probably it can be fixed in AVRPascal code, but my Arduino Leonardo stopped working...

Has it been physically damaged (electrical failure)?


ackarwow

  • Jr. Member
  • **
  • Posts: 82
    • Andrzej Karwowski's Homepage
Re: AVRPascal – free code editor for FPC for AVR
« Reply #64 on: November 12, 2024, 10:13:25 pm »
(...)
I'm thinking about changing the avrdude version in Arduino IDE (temporarily). Maybe running such tests would lead to some good leads. I will try to do such tests in my free time.

It seems avrdude 8.0 is OK and will work good. Only exception is Arduino Leonardo - very specific board which need to reset port before programming.

Has it been physically damaged (electrical failure)?

No, fortunately not :) Re-upload any code in Arduino IDE was needed and Leonardo is alive. In AVRPascal code I fixed problem of missing port before programming Leonardo, and uploading seems to go correctly. Leonardo works as expected, but after about 10 seconds is reseting. It looks like end of infinite loop :D Probably my test-code is invalid.

Dzandaa

  • Sr. Member
  • ****
  • Posts: 393
  • From C# to Lazarus
Re: AVRPascal – free code editor for FPC for AVR
« Reply #65 on: November 13, 2024, 12:20:49 pm »
Hi,

@ackarwow:

Acknowledge problem solved by adding a 10Ms delay in the loop.

Another thing, in the editor, if the bottom window is a Tmemo, it would be good if the Scrolling was in 2 directions.



B->
« Last Edit: November 13, 2024, 07:02:47 pm by Dzandaa »
Regards,
Dzandaa

ackarwow

  • Jr. Member
  • **
  • Posts: 82
    • Andrzej Karwowski's Homepage
Re: AVRPascal – free code editor for FPC for AVR
« Reply #66 on: November 13, 2024, 09:19:07 pm »
@Dzandaa

(...)
Acknowledge problem solved by adding a 10Ms delay in the loop.
Great news! Have you modified your code or hardwareserial.pas?

Another thing, in the editor, if the bottom window is a Tmemo, it would be good if the Scrolling was in 2 directions.
No, it is TListBox (owner draw mode), scrolling it horizontally is little bit harder...

I tried to write THardwareSerial.ReadBuff(const aBuff: PUInt8; const aLen: UInt8). It should be tested, especially because I do not know how it will work with larger buffers... Source code attached.
« Last Edit: November 13, 2024, 09:21:30 pm by ackarwow »

VisualLab

  • Hero Member
  • *****
  • Posts: 575
Re: AVRPascal – free code editor for FPC for AVR
« Reply #67 on: November 14, 2024, 01:33:31 am »
...hardwareserial.pas?

I was looking through the attached hardwareserial.pas file and had some thoughts. Since its content is a translation of C++ code into Object Pascal, you had to work around the problem of the clash of function names: begin() and end() (as is known, they clash with keywords in Pascal, but not in C++). You adopted the closest and simplest possible solution, i.e. prefixing the names of both functions with an underscore. To me, these underscores seem a bit inelegant. I think that functions/procedures with names starting with an underscore may seem unusual to some people (not me!), and intended for some special purpose, or to be avoided rather than used (which is of course not true). In any case, these underscores may confuse some people (for example, beginners in programming). This impression may come from the fact that underscores are used quite often in C (and pathologically overused in Python), where they do have some quite specific meanings. So maybe it would be advisable to give these functions different names?

The following approaches come to mind:
  • leaving the current solution (the one you used), i.e. function names that conflict with keywords are preceded by an underscore,
  • replacing conflicting names with other words that are close in meaning, e.g. Start()/Stop() or Run()/Finish(),
  • replacing conflicting names with words that were usually given to old-style Pascal objects, i.e. Init()/Done(),
  • replacing conflicting names with words that are often used when accessing a resource (here: hardware) and releasing that resource, i.e. Open()/Close().
Solution 4 would suit me, i.e. using the names: Open()/Close(). The benefits are:
  • avoiding underscores starting procedure names,
  • names will begin with a capital letter.
Of course, changing the names of these functions from _begin() and _end() to (let's say) Open() and Close(), has the disadvantage that if someone uses code examples coming directly from Arduino (making a change from C++ to Pascal) to write their source code, they will be confused. They may not guess that begin() and end() from C++ code should be replaced (in this case) with Open() and Close() in Object Pascal code. It seems that there is no ideal solution here.

Anyway, these are just some loose thoughts. Maybe other forum members will comment on this.
« Last Edit: November 14, 2024, 04:51:06 pm by VisualLab »

ackarwow

  • Jr. Member
  • **
  • Posts: 82
    • Andrzej Karwowski's Homepage
Re: AVRPascal – free code editor for FPC for AVR
« Reply #68 on: November 14, 2024, 12:14:06 pm »
(...)
Anyway, these are just some loose thoughts. Maybe other forum members will comment on this.

Yes, _begin and _end are not elegant but I think it will be more intuitive for Arduino users. Maybe @Dzandaa could comment it, because I am biased :)

After 3 years since writing this unit something else caught my attention: using 2 type names byte and UInt8, which are the same for AVRs. I think it's better to use one name - maybe UInt8? Although byte is more intuitive...

Another case of translation problems is ReadChar, which returns #0 when no character found, while the original code (int HardwareSerial::read(void)) returns -1. '#0' is not very good solution because such character may exist in reading buffer (even though it is not natural for strings). Maybe I should replace function ReadChar: char by Read: integer as is in the original code. But such type conversion is probably resource-consuming.

VisualLab

  • Hero Member
  • *****
  • Posts: 575
Re: AVRPascal – free code editor for FPC for AVR
« Reply #69 on: November 14, 2024, 03:11:21 pm »
(...)
Anyway, these are just some loose thoughts. Maybe other forum members will comment on this.

Yes, _begin and _end are not elegant but I think it will be more intuitive for Arduino users. Maybe @Dzandaa could comment it, because I am biased :)

I was hoping that regular and long-time participants of this forum would join the discussion on this topic.

After 3 years since writing this unit something else caught my attention: using 2 type names byte and UInt8, which are the same for AVRs. I think it's better to use one name - maybe UInt8? Although byte is more intuitive...

Yes, I definitely think that names like: Int8, Int16, Int32, Int64 and UInt8, UInt16, UInt32, UInt64 are better than: Byte, Word, Cardinal, QuadWord and ShortInt, SmallInt, LongInt. In the early days of Pascal, when computers had a much simpler architecture than today, there was no need to use so many integer types. After many years of development of computers and compilers, tidying up and unifying type names is needed. I would even be willing to use the names: SInt8, SInt16, SInt32, SInt64. Prefix S for signed and U for unsigned. But since specific aliases have already existed in the Pascal library for a long time, there is no need to add any additional confusion.

Another case of translation problems is ReadChar, which returns #0 when no character found, while the original code (int HardwareSerial::read(void)) returns -1. '#0' is not very good solution because such character may exist in reading buffer (even though it is not natural for strings). Maybe I should replace function ReadChar: char by Read: integer as is in the original code. But such type conversion is probably resource-consuming.

You're right. The problem is how the C and C++ compiler for Arduino views the char type. Whether it is a 1-byte signed or unsigned type. In the documentation for Arduino regarding the char type it is stated that:

Quote
The char datatype is a signed type, meaning that it encodes numbers from -128 to 127.

This would mean that it would need to be translated to Int8 in the Pascal library files intended for Arduino. Perhaps other forum members would like to comment on this topic to explain this issue in more detail. PascalDragon in particular.

ackarwow

  • Jr. Member
  • **
  • Posts: 82
    • Andrzej Karwowski's Homepage
Re: AVRPascal – free code editor for FPC for AVR
« Reply #70 on: November 14, 2024, 04:28:24 pm »

Quote
The char datatype is a signed type, meaning that it encodes numbers from -128 to 127.

This would mean that it would need to be translated to Int8 in the Pascal library files intended for Arduino. Perhaps other forum members would like to comment on this topic to explain this issue in more detail. PascalDragon in particular.

Normally the function TSerial.ReadChar or TSerial.ReadByte (the exact name does not matter) should return one byte/char with values 0..255. But - what should return when there is no data in buffer? In this case Arduino code returns -1 but I though this approach require change of return type at least to Int16 (-1 is out fo range of byte/char). The type (int) of return value of Arduino function seems to support my interpretation. If this is true - it is resource-consuming. Another possibility to improve reading function is to change its return type to boolean and add return parameter as variable, e.g. function ReadByte(var Value: UInt8): boolean, but this is not very comfortable.

Dzandaa

  • Sr. Member
  • ****
  • Posts: 393
  • From C# to Lazarus
Re: AVRPascal – free code editor for FPC for AVR
« Reply #71 on: November 14, 2024, 04:41:08 pm »
Hi,
@ackarwow

I don't really like _begin and _end, I prefer Start and Stop.

But, I just wrote 2 programs with AVRPascal, so switching isn't a big deal for me.

There is a communication test I wrote today, AVRTest.zip is the lazarus program, AVRTest.pas is the AVRPascal program.
I use your latest "hardwareserial.pas".

For the Lazarus program, I use "pl_SynapseVS" and "LazSerialPort"

Only tested on Win7 64 and Linux 64, not MacOS.

I'm not an expert in Serial with Lazarus, so it's just a test.

B->
Regards,
Dzandaa

ccrause

  • Hero Member
  • *****
  • Posts: 970
Re: AVRPascal – free code editor for FPC for AVR
« Reply #72 on: November 14, 2024, 05:31:22 pm »
Another case of translation problems is ReadChar, which returns #0 when no character found, while the original code (int HardwareSerial::read(void)) returns -1. '#0' is not very good solution because such character may exist in reading buffer (even though it is not natural for strings). Maybe I should replace function ReadChar: char by Read: integer as is in the original code. But such type conversion is probably resource-consuming.

You're right. The problem is how the C and C++ compiler for Arduino views the char type. Whether it is a 1-byte signed or unsigned type. In the documentation for Arduino regarding the char type it is stated that:

Quote
The char datatype is a signed type, meaning that it encodes numbers from -128 to 127.

This would mean that it would need to be translated to Int8 in the Pascal library files intended for Arduino.
Using a return value that is part of the valid range of the data type to indicate state is in my opinion a bad decision. An alternative option would be to return both the data and a separate state indicator, for example:
Code: Pascal  [Select][+][-]
  1. type
  2.   TUartState = (usValidData, usNoData, usParityError);
  3.  
  4. function ReadChar(out c: char): 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.     c := RXBuffer[RXBufferTail];
  12.     RXBufferTail := (RXBufferTail + 1) mod SERIAL_RX_BUFFER_SIZE;
  13.     Result := usValidData;
  14.   end;
  15. end;
Catching parity errors should happen in RXCompleteIRQ.  With buffered data, a decision needs to be taken whether each buffered byte should have its own parity information, or a single parity state should be stored for the whole buffer.  Or simply ignore the parity error? Not that easy to decide what the best general solution would be.

VisualLab

  • Hero Member
  • *****
  • Posts: 575
Re: AVRPascal – free code editor for FPC for AVR
« Reply #73 on: November 14, 2024, 06:22:12 pm »
Using a return value that is part of the valid range of the data type to indicate state is in my opinion a bad decision. An alternative option would be to return both the data and a separate state indicator...

Yes, you're right. However, there is one more issue - are the AVRPascal library files translated Arduino library files, i.e. from C++ to Pascal? Or rather, the Arduino libraries were only a (loose) inspiration for the development of the AVRPascal libraries? If the AVRPascal libraries are a translation of the Arduino libraries, then you might want to stick to the types as they are declared in the original library, i.e. not the names but the sizes and ranges, e.g. uint8_t → UInt8, char → Int8.

ackarwow

  • Jr. Member
  • **
  • Posts: 82
    • Andrzej Karwowski's Homepage
Re: AVRPascal – free code editor for FPC for AVR
« Reply #74 on: November 14, 2024, 08:26:10 pm »
@Dzandaa
There is a communication test I wrote today, AVRTest.zip is the lazarus program, AVRTest.pas is the AVRPascal program.
I use your latest "hardwareserial.pas".
For the Lazarus program, I use "pl_SynapseVS" and "LazSerialPort"
Only tested on Win7 64 and Linux 64, not MacOS.
I'm not an expert in Serial with Lazarus, so it's just a test.
(...)
Many thanks for your test program :) It's great! It seems that all works as needed! I was little bit confused about the radio button, I suppose that is RS232 usage indicator.
I tested your program on Win64, and I will also test it on Linux and MacOS.

Edit: I just tested your program on Linux and MacOS. On Linux it works perfectly, on MacOS there is problem with RS232 connection.

(...)
I don't really like _begin and _end, I prefer Start and Stop.
But, I just wrote 2 programs with AVRPascal, so switching isn't a big deal for me.
So it will be as you prefer :) hardwareserial.pas attached.
« Last Edit: November 14, 2024, 11:18:59 pm by ackarwow »

 

TinyPortal © 2005-2018