Wow, yesterday I started this new message:
http://forum.lazarus.freepascal.org/index.php/topic,28561.0.html

And today Laksen says it's committed to SVN trunk. That was fast!

Thanks to all the FPC developers!

And today I finally made my first release:
http://turbocontrol.com/simpleteensy.htm

Can I put the 3 files (as, ld, objcopy) in my zip?

Since those files were on the freepascal.org site I figured it must be OK so I added all 6 of them and released a new 10 MB zip (also has the entire RTL for the release).

********

I left a message in this forum thread:
https://forum.pjrc.com/threads/28518-Teensy-with-Freepascal

Got a reply with lots of questions:
How easy is it to do all the common hardware things from Freepascal? How much low-level setup is required use digital and analog I/O? Can you use the serial ports? Timers? Capacitive touch sensing? Can you even access the registers without porting a massive header file? Is it possible to link with existing C or C++ libraries?

Any quick summary anyone would like for me to post as a response? Please write back here if you don't want to register on that forum.

My one question would be: how general is this? Specifically, how close is it to being able to program a breadboarded chip as described at http://hackaday.com/2015/10/09/arming-a-breadboard-everyone-should-program-an-arm/

I had a LPC1114 on the breadboard area of a development board for quite a while, fpc (trunk) is able to create binaries for this cpu. For lpc devices you need a linker script that creates a special checksum, besides this it works ootb.

Of course you have to work a lot more low level that with mbed.... But given the fact that the lpc1114 only has 32k of flash you do not want to have much highlevel abstraction anyway as you will run out of memory quite fast.

Michael

Posted a reply there.

But anyway, it's not very positive. There's nothing but the bare core so far.

If anyone is interested in diving into FPC+embedded I can much more readily recommend STM32 micros. In particular the STM32F746GDISCOVERY board is pretty awesome for $50 (208 MHz, 8 MB RAM, eth+lcd+stuff). I have been porting a pretty big part of the firmware library over here: https://github.com/Laksen/fp-stm32f7xx_hal

Wow Jeppe, I am impressed, you used your time much better than I did, your port looks pretty complete!

Please have a look at

https://github.com/yunkot/pxl

this lib was mentioned yesterday on lazarus list, this looks like a good layer above the lowlevel code, there are already implementations for several sensors and displays and it already supports Raspberry Pi.

The Author is also thinking about extending the lib in the direction of microcontrollers, so those two efforts combined could some day get a very user friendly solution that is a lot closer to what mbed is for the C guy today to what we have right now.

Michael

Thanks :)

Yeah, that PXL library looks like it has a lot of code already. Could be a great project to combine it with for sure!

I want to interface my Freedom-K64F code with this lib, on first view this looks pretty straightforward. Any chance to get your great patch for the use on arbitrary system units into trunk ? (the one you wrote for me to make cmsis work)

Not sure what you are referring to here?

The code that makes the compiler work with conf files:

fpc -Fb*.conf

stm32f407vg]$ cat stm32f4xx.conf
STM32F401CB,stm32f401x,stm32f4xx.lkr,%FLASHBASE:0x08000000,%FLASHSIZE:0x00020000,%SRAMBASE:0x20000000,%SRAMSIZE:0x00010000 STM32F401RB,stm32f401x,stm32f4xx.lkr,%FLASHBASE:0x08000000,%FLASHSIZE:0x00020000,%SRAMBASE:0x20000000,%SRAMSIZE:0x00010000 STM32F401VB,stm32f401x,stm32f4xx.lkr,%FLASHBASE:0x08000000,%FLASHSIZE:0x00020000,%SRAMBASE:0x20000000,%SRAMSIZE:0x00010000

Well I think it might be too much for now. Haven't really maintained it since then

Anyway, from what I found last I tried with your headers I think there could be some improvement that might instead warrant their inclusion into SVN.
The main point back then was that the size was pretty tremendous.

To reduce size:
- Similar types be in common records. What I found was that using your generated headers for the STM32F7xx HAL required a lot of casting because all the GPIO records, for example, for all the different ports were different types. This cause duplication of all the helpers too.
- Could the helpers be in external units?
- Have an option to remove comments? Not sure how much this would give

Another thing was things like repeated sub records. CAN mailboxes or DMA channel streams all had the repeated registers, while the existing firmware codebase used arrays of records.
This probably changes from manufacturer to manufacturer but it might be nice to reduce size, and probably wouldn't require a lot of change when porting code.

Actually, maybe also not emit the bitband records? So far I've never once seen it used in normal code, and the places where it could be useful you might just as well calculate the offset yourself, or refer to it in an external unit(maybe one with the helpers? :)

Best Regards,
Jeppe

I've already addressed some of the issues, instead of using records I am using objects now (classes unfortunately do not work) and there's a base class for gpio, spi, i2c, uart.

The idea of having comments was that they show up as context sensitive help in Lazarus, they can easily be left out, same with bitbanded records, they are configurable.

I can see that I can address the issue with the repeated sub-records, they were bugging me too, but never bugging me enough to do something about it.

I will try to fix the headers for Frdm-k64f during the week, perhaps you can have a look if they are OK for inclusion.

Michael