I'm trying to get a minimal embedded example working, but there seems to be some issues with the linker script and the startup code. Is there a working (simple) example I can study? Or are further tweaks needed to get the embedded target working for ESP8266?

Christo Crause wrote

I'm trying to get a minimal embedded example working, but there seems to be some issues with the linker script and the startup code. Is there a working (simple) example I can study? Or are further tweaks needed to get the embedded target working for ESP8266?

Not sure if it ever worked. I guess you looked already at the (little) information in the wiki?

On Mon, Sep 19, 2022 at 8:52 PM Florian Klämpfl via fpc-devel <

Thanks, I suspected the current state wasn't quite working, just wanted to make sure I'm not missing something obvious. This probably explains why the xtensa-embedded section on the wiki is empty.

I managed to get a simple message printed over serial and blink an LED, so there is a bit of progress.

Does this process use gcc to do the compile, instead of fpc directly? If it does, I will dig into making it compatible with Parallax's line of propeller boards, since it now supports GCC to generate code for the propeller 1 and 2 boards.  Being able to program these in pascal would be wonderful.  Parallax has a series of SBC products, including the basic stamp, a java stamp, (no longer produced), and as mentioned, the propeller boards.  They also have several robot packages that can be programmed via the propeller or basic stamps, so if the esp board code does work, and it calls gcc for it's work, I'll certainly be interested in tackling making it work with the propeller boards, I think that could help some folks start using those boards.

On Tue, 4 Oct 2022, 01:15 Travis Siegel via fpc-devel, <

The compiler typically generates target CPU specific assembler code, which requires an external assembler and linker to generate the executable code. I don't know much about the Parallax controllers, but it appears to be a distinct architecture (not ARM or MIPS for example) not yet supported by FPC, so would require a new compiler backend AFAIU.

Yeah, it's a custom board, but it has 8 cores, which makes multitasking real simple.  They call them cogs, and you can spin up another cog at any time.  It also uses a language called spin (their version of assembly), so I guess it could be supported, but how much work is adding a whole new architecture to FPC?  They do have a version of gcc that works for their boards, so I was hoping we could piggyback on that, but I guess that would be a GPC thing not FPC, and since gpc requires a specific version of GCC to do it's work, and it's not really supported anymore as far as I can tell, that would be a nonstarter.

Ok, well, just thought I'd check, I personally would enjoy programming in pascal for some of these SBC boards, but I can stick with the existing tools as well, they do work, it would be more convenient for me if pascal was an option, that's all.

I know a lot of compilers use gcc as their backend, and didn't know if fpc did this or not, so figured I'd ask.

Thanks for the info.

For someone who is familiar with the compiler design, adding a new architecture would be easy but would probably still take a few weeks worth of effort. This assumes existing knowledge of the low level functioning of the target. I have patched a few bugs in the past, but it took me many days to figure out how seemingly simple functionality integrated into the overall compiler design. It would probably be worthwhile to get a compiler developer interested in this exercise from the start to help speed up the effort.