Hello,

does anyone work on a library (embedded RTL) for basic embedded microcontroller units (MCU) like AVR or ARM?
I think, there should be a stable interface along different MCUs for accessing various hardware interfaces.

* MCU compatible/optimized string functions
* I2C
* SPI
* GPIO
* Analog Inputs/Outputs
* PWM
* UART
* Timer
* Watchdog timers

These topics are much more dependant on the individual MCU families. It would be great to have a cross MCU API though.
* MCU setup
* Power Management

As there are some libraries out there on the net, they could inspire the design of the embedded RTL.
Are there any concerns on translating one library as long as it has a less restrictive license than modified LGPL used by the default RTL (e.g. BSD license)?

Kind Regards
Simon Ameis

Simon,

what you are referring to is mostly not the RTL (which is a standardized set of routines necessary to "make pascal work"). but are device drivers that provide a link between the RTL and the underlying hardware, tasks that in a non - embedded environment are performed by the operating system.

An example: the procedure "write / writeln" is part of the RTL. it does all the formatting, calls conversion routines where necessary (from numerical formats to string), and so on - but finally passes the formatted sequence of characters to the operating system's file I/O, which forma an intermediate layer, and finally calls the appropriate device drivers (serial, console, disk, ....).

I completely agree with you that such a library would be highly desirable, but it is a different thing than the RTL.

One exception: string functions, these are part of the RTL. for the AVR, I am working on a unit system, that is mainly writen in assembler.

best regards,
Georg

Hello Georg,

yes, RTL may be the wrong term, so let us call it PEL (Pascal Embedded Library) or any other name which indicates it's usage. Is this the correct mailing list to discuss it or would FPC-Pascal the better place?

kind regards
Simon

Hi Simon, have a look at

https://github.com/yunkot/pxl

there is some work going on right now to make this lib fully support embedded targets.

It today supports Raspberry PI, Intel Galileo and BeagleBone Black and there is already initial support for lpc11xx + stm32f4xx chips and support for mk22xx chips (Teensy 3.x and Frdm-k22f) will follow soon.

Any possible help would be appreciated, either for testing what is already there or helping to port to more/different microcontrollers/sensors/displays

Michael

Simon Ameis wrote

Hello Georg, yes, RTL may be the wrong term, so let us call it PEL (Pascal Embedded Library)

In fact much of this needs to be done by (or at least better is done by) Device drivers, and hence not in the reach of fpc.

-Michael

Device drivers, and hence not in the reach of fpc.

You are aware that the discussion is about FPC's embedded target, thus no device drivers available, because there's no OS running that could host them?

And aside from that it is possible to write device drivers in FPC if one knows how to do it.

Regards,
Sven

I in fact did not know that with the RTL the term "embedded Target" is defined in that way, but it in fact is:
http://wiki.freepascal.org/TARGET_Embedded

Thanks for the pointers.

-Michael

So will FPC provide the compiler (and maybe an FPC-embedded linker for ARM) only?
Or would be a reasonable goal to publish "default" device drivers for embedded targets?

I think, it would be fine to get a full solution by using FPC and Lazarus (and GNU binutils atm). This would make it easier to get into embedded developing because you don't need to the libraries but can instantly start developing you application.

Lazarus then could integrate the tools for uploading the compiled and linked binary to the embedded device.

Regards
Simon

In our previous episode, Simon Ameis said:

It would depend on contributions I guess.

Here is my current contribution (I'd like to do more): http://turbocontrol.com/simpleteensy.htm

Regards,
Paul
www.ControlPascal.com

As Marco said: if somebody contributes patches, they are probably integrated. The best would be probably to create some additional package which contains such units.

@Paul:

Jeppe was so nice to check in a new set of units for stm32f4, teensy and arduino due, this means that my older, much bigger unit for the teensy is now replaced with a much leaner version. Can you please check if this causes issues for your distribution?

I am working on highlevel teensy interfaces for the pxl lib, perhaps you can think about giving those a try as soon as they are ready.

Michael

Michael,

Jeppe was so nice to check in a new set of units for stm32f4, teensy and arduino due, this means that my older, much bigger unit for the teensy is now replaced with a much leaner version. Can you please check if this causes issues for your distribution?

Thanks for that info. I'll try to update this soon: http://turbocontrol.com/simpleteensy.htm

I am working on highlevel teensy interfaces for the pxl lib, perhaps you can think about giving those a try as soon as they are ready.

I've looked at pxl a little, and I'll try to add those ASAP.

Thanks for your support!

Regards,
Paul
www.ControlPascal.com

I hope to have something ready for teensy before the end of the week, it would be great if you could test.

Michael