Forum > Embedded

Running a minimal fpc on a microcontroller

<< < (3/4) > >>

SymbolicFrank:
Thanks for the suggestions. I'll go through them.

Why would the fpc.exe be 3 MB? On my PC it's only 131 kB. Symbols?

I want to try and make an "interactive" microcontroller, so I can have a dashboard and change functions while it is running. It isn't meant as a replacement for a PC, like a Raspberry Pi, (all communication through USB / Ethernet), but as an interactive way to build your circuit.

The most common MCU's have 64 kB of Flash and 20 kB of RAM. That's not much. The largest practical MCU's are like this: https://uk.farnell.com/stmicroelectronics/nucleo-l432kc/dev-board-nucleo-32/dp/2580786. It has 256 kB of Flash and 64 kB of RAM.

There are ARM  MCU's with 2 MB Flash and 1 MB RAM on-board, but they are around 4 cm2 in size and have 100+ pins, so they're hard to fit on a bread-board. Adding external Flash and RAM just to get the compiler running would be counter-productive and make it reasonably expensive.

My options for programming would be:

1. External compiler. Possible, but not interactive enough. A dashboard is like a debugger running on the device.

2. Assembler. Doable, but too low-level.

3. Interpreter: Slow but doable. But Pascal, no Basic or whatever. It would mess up your timing and be unusable for handling interrupts. Meh.

4. Tiny compiler, with the code split in units / objects and interactive debugging. Actually, something like Turbo Pascal 1.0 would work.

Optimally, the program is stored in P-code, for example like a ZX_Spectrum did it. It might be interesting to see if I could make a parse tree editor. And units / objects are loaded and linked in memory on demand. Objects would simplify memory management as well. Ok, that's a lot of work. But with a lot of re-use probably doable.

howardpc:

--- Quote from: SymbolicFrank on May 29, 2019, 09:44:29 am ---Why would the fpc.exe be 3 MB? On my PC it's only 131 kB. Symbols?

--- End quote ---
fpc(.exe) is not the compiler, it does some checks and set-up, and calls e.g. ppcx64 which is the "real" compiler.

SymbolicFrank:
Ah, thanks. That size was the first thing I checked. It looked small, but not impossible for a console application. I should have looked better.

I'll check all the suggestions first.

SymbolicFrank:
That P-5 compiler documentation was interesting.

After reading the above and thinking about it, it seems to me, that the goal is to store the program as compact as possible, to minimize overhead. And if I do that by analyzing it, the parsing is already done.

Store everything that is not a constant,  variable or set / array / list as a record (minimalist object), try to simplify expressions as much as possible while retaining object names and use a JIT for code generation.

Most everything else is either operating system or user interface. And I think it's probably simpler to just write everything myself, than to try and reuse as much existing code as possible. Although the source code of an ARM assembler would be useful. For the OS I'm going to look at RTOS, but probably I'll do that myself as well.

Edson:
I was trying doing something similar but running in a MOS6502. The idea is to make a compiler/interpreter running in a Operative System writen using the same compiler.

Currently I'm improving my 6502 compiler and I'm experimenting building a simple bootstraping compiler.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version