Advantages of using PASCAL to develop embedded programs

[gasensor]

1. It's hard to get out of bounds when accessing arrays/string.
2. The compiler is free for commercial use.
3. It is effective to avoid the macro hell of the C language.
4. It can effectively avoid the trap of local variables in C language.
5. The program is highly readable, even if it lacks comments.
6. This kind of question does not appear: j=++j + ++j;  j= what?

[marcov]

Tool selection is a multi facetted question, and general language is only one factor, e.g.

• licensing, as you said
• The usual language differences, like you said in most other options
• Extensions to the language for embedded, both general and target specific, how more embedded the target, the more important this is
• library support, including per target headers
• cross compilation
• IDE integration
• Debugger support

[gasensor]

I agree.

For FPC installation and crossinstall issues, I'll write a separate topic.

[bobihot]

I very need, but can`t for now - is not possibly practically. If possibly and visual programming like
A visual programming environment

https://www.mitov.com/products/visuino#overview

[gasensor]

I very need, but can`t for now - is not possibly practically. If possibly and visual programming like
A visual programming environment

https://www.mitov.com/products/visuino#overview

"A visual programming environment" = Labview

This type of graphical programming language struggles to handle complex logical relationships. I've used Labview, and simple stuff is fine. Once the program is complicated, it's hell.

[ccrause]

I very need, but can`t for now - is not possibly practically. If possibly and visual programming like
A visual programming environment

https://www.mitov.com/products/visuino#overview

"A visual programming environment" = Labview

This type of graphical programming language struggles to handle complex logical relationships. I've used Labview, and simple stuff is fine. Once the program is complicated, it's hell.

Another example is Node-RED.  But this has nothing to do with Pascal (or any other traditional language), since the "language" is based on visual representation.

[ccrause]

Tool selection is a multi facetted question, and general language is only one factor, e.g.

• licensing, as you said
• The usual language differences, like you said in most other options
• Extensions to the language for embedded, both general and target specific, how more embedded the target, the more important this is
• library support, including per target headers
• cross compilation
• IDE integration
• Debugger support

Marco, can you expand on examples where fpc/Lazarus falls short compared to other options? It may help in improving the situation eventually.

For example fpc does not support handling of variables placed in sections for AVR target. I have proposed something to support this, but it isn't making progress.  On the other hand a patch to place code in various sections, and dropping RTL initialization, has been accepted (also AVR specific).

There is a very long list of controller headers available in fpc, however it is not exhaustive.  Often these headers can be generated automatically, so adding them is mostly a matter of knowing what is missing. This is not coordinated AFAIK, so contributions trickle in when an interested party investigates a particular new target.

A serious shortcoming I think is standard hardware support libraries for example I2C, USART, LCD etc.

Pascal specific debugger support for embedded is slowly growing via fpdebug. At this point only AVR is reasonably tested, with ESP32 support at an experimental level.

If we make the embedded specific needs better known, there is a chance of improving the status quo.

[ojz0r]

I very need, but can`t for now - is not possibly practically. If possibly and visual programming like
A visual programming environment

https://www.mitov.com/products/visuino#overview

"A visual programming environment" = Labview

This type of graphical programming language struggles to handle complex logical relationships. I've used Labview, and simple stuff is fine. Once the program is complicated, it's hell.

Another example is Node-RED.  But this has nothing to do with Pascal (or any other traditional language), since the "language" is based on visual representation.

One could let the function blocks be created in pascal and provide a visual means to connect them.
I've been tempted to create such an editor, but i lack the time and knowledge (again time). But its on my ever expanding todo list.

[ccrause]

I very need, but can`t for now - is not possibly practically. If possibly and visual programming like
A visual programming environment

https://www.mitov.com/products/visuino#overview

"A visual programming environment" = Labview

This type of graphical programming language struggles to handle complex logical relationships. I've used Labview, and simple stuff is fine. Once the program is complicated, it's hell.

Another example is Node-RED.  But this has nothing to do with Pascal (or any other traditional language), since the "language" is based on visual representation.

One could let the function blocks be created in pascal and provide a visual means to connect them.
I've been tempted to create such an editor, but i lack the time and knowledge (again time). But its on my ever expanding todo list.

Yes, that is true. But then the general question is still how good is fpc for embedded programming, since that will produce the final executable code. Compared to the Arduino framework (the engine below Visuino AFAIK) fpc lacks hardware support libraries and the range of targets supported.  On the positive side fpc is fast, so the compiling phase should be quick, particularly if most of the code sits in precompiled units.

Thinking about this more, Node-RED is not relevant for this discussion of embedded microcontroller since it runs JavaScript. It is only relevant for application level platforms than can run the JavaScript engine.

[marcov]

I was speaking in general. But specifically, I use dspic33E :-)

[ccrause]

I was speaking in general. But specifically, I use dspic33E :-)

Unfortunately not even a whiff of PIC support in fpc...

Edit: removed nonfunctional emoji

[VisualLab]

1. It's hard to get out of bounds when accessing arrays/string.
2. The compiler is free for commercial use.
3. It is effective to avoid the macro hell of the C language.
4. It can effectively avoid the trap of local variables in C language.
5. The program is highly readable, even if it lacks comments.
6. This kind of question does not appear: j=++j + ++j;  j= what?

For myself I would add:

7. a system for building executable files that is much more convenient than those used in C and C++.

An exception may be the building system used in Visual Studio (for C++), provided that someone makes the entire project only using this tool and only for Windows. The opposite of this is CMake - crap created probably just to annoy users (programmers) and increase the already considerable costs of developing software written in C or C++. But OK, ultimately you can understand it if it is a commercial solution, intended for a large number of users, which is supposed to run on several OSes (especially on servers).

However, in other applications it is stupidity, masochism and malice all in one. Example: Raspberry Pi Pico SDK. Why the hell was there a need to use such a piece of crap (and a classic, shoddy and underdeveloped makeshift solution at that) like CMake for a project intended for only one microcontroller? And not even a family, just: 1 type of microcontroller. And the alternative is... Python! From one extreme idiocy to another extreme idiocy. And yet it could be done relatively cheaply and painlessly. This is shown by the example of Arduino (also the new one, Uno R4).

[VisualLab]

I very need, but can`t for now - is not possibly practically. If possibly and visual programming like
A visual programming environment

https://www.mitov.com/products/visuino#overview

"A visual programming environment" = Labview

This type of graphical programming language struggles to handle complex logical relationships. I've used Labview, and simple stuff is fine. Once the program is complicated, it's hell.

Maybe the problem is not very well refined modularity. In addition, the source code (a sequence of instructions) can be presented graphically in various ways. Maybe another way would be better. But now this can no longer be done due to the existing code base (as is the case with other programming languages).

[VisualLab]

I was speaking in general. But specifically, I use dspic33E :-)

Unfortunately not even a whiff of PIC support in fpc...

Edit: removed nonfunctional emoji

If someone really wants Pascal for microcontrollers from several different PIC families, all they have left is microPascal.

[marcov]

If someone really wants Pascal for microcontrollers from several different PIC families, all they have left is microPascal.

Education, not production oriented.   Anyway, while I still curse at typical C gotchas and annoyances, for these relative small (2k-3k lines per project with 20000 lines own generic code compiling to 27kb) programs, it doesn't matter that much in the long run.