Smallest/lightest FPC capable processor?

[AlanTheBeast]

If I wanted to do a FPC project that had:

- 2 temperature sensors (2 analog inputs)
- 5 solid state to electromechanical relay controls
- support for a simple display (Like a 2 line display) - text only

- RTC desirable
- serial i/o desirable (UART)
- battery backed store or on board flash for parameters desirable.

Processor speed not important - 5 MHz clock would be sufficient - anything higher, ok.
Floating Point not needed

What would be the slowest, cheapest processor that FPC can build code for?
(On a cheap, Arduino-like, breakout kit)

Thx.

[wildfire]

The Raspberry Pi Pico would appear to fit your needs.

[ccrause]

(On a cheap, Arduino-like, breakout kit)

You mentioned it, any AVR based Arduino board: Uno, Nano. Perhaps one of the attiny based boards, but you may run out of IO pins. No build-in RTC though. FPC AVR on wiki: https://wiki.freepascal.org/AVR_Programming

Next up would be esp8266 (only one ADC channel) and esp32: https://wiki.freepascal.org/Xtensa - only supported in fpc 3.3.1, and a bit of hassle to link to an SDK. But you get on-chip WiFi.

Then there are plenty of ARM options, like the RP Pico.

[af0815]

Temperatur Sensors can have a serial interface too. Depending on the type. AVR Arduino board are state of the art and there are a lot of soloutions for external IO ,flash or flashcards. And it is cheap and you can get IO cards complete from stock.

[MarkMLl]

Noted your comment about at least starting off with an Arduino-scale breakout board, but when you say "smallest/lightest" do you literally mean "small" as in some fraction of a mm2 and "light" as in mg?

In any event, even if small etc. should be interpreted as "limited memory and cheap", you are likely to find that your scale is dominated by considerations of how tolerant the MCU chip (and attached peripherals) is to varying supply voltage, whether the chip/board can supply adequate power to supply the peripherals without an external regulator and so on.

As a couple of observations that might or might not help, I've got a little RP2040 board from Waveshare programmed up as a Picoprobe. This is the size of a postage stamp, and its onboard regulator is sufficiently capable that it can drive a larger Pico breakout board with attached LEDs, SD-Card and so on.

I've also got various AVR boards where I've upgraded the loader so that it retains the cause of the last reset, which can be read via a C++ variable. However I don't know whether FPC has the capability of declaring that a (global) variable should retain its value rather than being initialised at startup.

A similar consideration applies to the RP2040: I've not yet seen anybody demonstrate how the chip's distinctive PIOs can be programmed from FPC.

I think that what I'm building up to is that while both the RP2040 and sundry AVRs (plus lots of other chips) can undoubtedly be programmed using FPC, I've got reservations as to whether it's really the right tool for the job in view of the amount of effort that the wider community has devoted to getting them working well with C++.

MarkMLl

[d.ioannidis]

Hi,

  an atmega avr could do the job easily.

  You can have an RTC also if you can solder, and make the circuit in a zero/veroboard pcb, running at 4MHz. Of course you'll need a programmer but you can use an arduino uno / mini nano for that task or buy a USBasp or USBisp which are very cheap .

regards,

[marcov]

I've also got various AVR boards where I've upgraded the loader so that it retains the cause of the last reset, which can be read via a C++ variable. However I don't know whether FPC has the capability of declaring that a (global) variable should retain its value rather than being initialised at startup.

(From similar functionality with dspics, I'd say that is a implementation specific attribute. FPC supports generic attributes, but what they do (placement in a block that isn't zeroed on startup) still will have to implemented)

[MarkMLl]

I've also got various AVR boards where I've upgraded the loader so that it retains the cause of the last reset, which can be read via a C++ variable. However I don't know whether FPC has the capability of declaring that a (global) variable should retain its value rather than being initialised at startup.

(From similar functionality with dspics, I'd say that is a implementation specific attribute. FPC supports generic attributes, but what they do (placement in a block that isn't zeroed on startup) still will have to implemented)

(Skipping the "TBD" bit): yes, agreed. Looking at my notes, the AVR format is

Code: C  [Select][+][-]

1. /*
2.  * If possible, retrieve the reset reason. On an Arduino, Optiboot >=4.6 will save
3.  * this into r2 and then clear MCUSR, other architectures might have something
4.  * similar. In all cases assume that interpretation of the value is target-specific,
5.  * but on an AVR are likely to be some combination of
6.  *
7.  *      0x10  JTAG reset
8.  *      0x08  Watchdog reset
9.  *      0x04  Brownout reset
10.  *      0x02  External (button) reset
11.  *      0x01  Power-on reset
12.  */
13. unsigned char _reset_reason __attribute__ ((section (".noinit")));
14.  
15. void getMCUSR(void) __attribute__((naked)) __attribute__((section(".init0")));
16.  
17. void getMCUSR(void)
18. {
19.    __asm__ __volatile__ ( "mov %0, r2 \n" : "=r" (_reset_reason) : );
20. }
21.  
22.  
23. /* This needs a runtime test that Optiboot is at at least version 4.6. If not
24.  * valid then as a side-effect the saved reason will be set to an "impossible"
25.  * value.
26.  */
27. bool trustResetReason(void) {
28.   if (pgm_read_word(0xfffe) >= 0x0406)
29.     return true;
30.   else {
31.     _reset_reason = 0xff; // Not a valid combination
32.     return false;
33.   }  
34. }
35.  
36. ...
37.  
38.       if (trustResetReason()) { // Needs runtime test against Optiboot version.
39.         Serial.print(FF(" Reset: 0x"));
40.         board_info_hex2(_reset_reason);
41.       }  
42.  

However, I think the bigger point here is that the broader community has organised things such that this sort of thing can be done fairly painlessly on an AVR. They've also arranged things such that PIO programming can be done close to (if not interleaved with) the C++ on an RP2040, while my understanding is that the best that FPC can offer is "stick it into a resource and call the preprocessor using Lazarus" (which is also what we're told is an adequate alternative to embedding SQL blocks in Pascal).

MarkMLl

[ccrause]

I've also got various AVR boards where I've upgraded the loader so that it retains the cause of the last reset, which can be read via a C++ variable. However I don't know whether FPC has the capability of declaring that a (global) variable should retain its value rather than being initialised at startup.

(From similar functionality with dspics, I'd say that is a implementation specific attribute. FPC supports generic attributes, but what they do (placement in a block that isn't zeroed on startup) still will have to implemented)

(Skipping the "TBD" bit): yes, agreed. Looking at my notes, the AVR format is

Code: C  [Select][+][-]

1. /*
2.  * If possible, retrieve the reset reason. On an Arduino, Optiboot >=4.6 will save
3.  * this into r2 and then clear MCUSR, other architectures might have something
4.  * similar. In all cases assume that interpretation of the value is target-specific,
5.  * but on an AVR are likely to be some combination of
6.  *
7.  *      0x10  JTAG reset
8.  *      0x08  Watchdog reset
9.  *      0x04  Brownout reset
10.  *      0x02  External (button) reset
11.  *      0x01  Power-on reset
12.  */
13. unsigned char _reset_reason __attribute__ ((section (".noinit")));
14.  
15. void getMCUSR(void) __attribute__((naked)) __attribute__((section(".init0")));
16.  
17. void getMCUSR(void)
18. {
19.    __asm__ __volatile__ ( "mov %0, r2 \n" : "=r" (_reset_reason) : );
20. }
21.  
22.  
23. /* This needs a runtime test that Optiboot is at at least version 4.6. If not
24.  * valid then as a side-effect the saved reason will be set to an "impossible"
25.  * value.
26.  */
27. bool trustResetReason(void) {
28.   if (pgm_read_word(0xfffe) >= 0x0406)
29.     return true;
30.   else {
31.     _reset_reason = 0xff; // Not a valid combination
32.     return false;
33.   }  
34. }
35.  
36. ...
37.  
38.       if (trustResetReason()) { // Needs runtime test against Optiboot version.
39.         Serial.print(FF(" Reset: 0x"));
40.         board_info_hex2(_reset_reason);
41.       }  
42.  

However, I think the bigger point here is that the broader community has organised things such that this sort of thing can be done fairly painlessly on an AVR. They've also arranged things such that PIO programming can be done close to (if not interleaved with) the C++ on an RP2040, while my understanding is that the best that FPC can offer is "stick it into a resource and call the preprocessor using Lazarus" (which is also what we're told is an adequate alternative to embedding SQL blocks in Pascal).

MarkMLl

I think this conversation is drifting away from the OP, but anyway, here is the FPC way (putting code in a section requires main version for now):

Code: Pascal  [Select][+][-]

1. var
2.   resetReason: byte; section '.noinit';
3.  
4. procedure getMCUSR; assembler; noreturn; section '.init1';
5. asm
6.   sts resetReason, r2
7. end;
8.  
9. begin
10.   Halt(resetReason);
11. end.
12.  

[d.ioannidis]

Hi,

I think this conversation is drifting away from the OP, but anyway, here is the FPC way (putting code in a section requires main version for now):

 I remembered seeing this here https://github.com/ccrause/freepascal/wiki/Better-support-for-address-spaces-in-FPC#section-support-for-procedures

 Maybe it should be in fpc avr wiki ?

regards,

[MarkMLl]

I remembered seeing this here https://github.com/ccrause/freepascal/wiki/Better-support-for-address-spaces-in-FPC#section-support-for-procedures

Maybe it should be in fpc avr wiki ?

In any event, it should specify what versions of the compiler support it, i.e. "Requires a minimum of FPC 3.x.y targetting z and t".

MarkMLl

[AlanTheBeast]

Noted your comment about at least starting off with an Arduino-scale breakout board, but when you say "smallest/lightest" do you literally mean "small" as in some fraction of a mm2 and "light" as in mg?

In any event, even if small etc. should be interpreted as "limited memory and cheap", you are likely to find that your scale is dominated by considerations of how tolerant the MCU chip (and attached peripherals) is to varying supply voltage, whether the chip/board can supply adequate power to supply the peripherals without an external regulator and so on.

Language is fun.

I meant "smallest/lightest" as in a little board that will do what I need it to do.  Arduino size would be fine.  Slightly larger or smaller would be fine.

I'll throw (a) nice power suppl(ies)y at it.

Thx.

[AlanTheBeast]

Thanks everyone for all the replies.  I'll begin my research.  Key thing (which Dimitrios Chr. Ioannidis touched on) is programming it once the image is built...

[d.ioannidis]

Hi,

Key thing (which Dimitrios Chr. Ioannidis touched on) is programming it once the image is built...

All the suggestions above ( arduino uno / nano, esp32, rp pico, etc ), can be programmed "out-of-box", as they aleady have the supporting hardware and/or firmware.

I was talking about the case, you maybe want to use an mcu with your own minimal homemade board i.e. From Arduino to a Microcontroller on a Breadboard.

regards,

[MarkMLl]

I meant "smallest/lightest" as in a little board that will do what I need it to do.  Arduino size would be fine.  Slightly larger or smaller would be fine.

Waveshare RP2040-Zero or equivalent, AVR-based Digispark clone, or depending on the precise number of inputs you need an Arduino Nano or larger.

If you have two RP2040 boards you can use one as a Picoprobe, which can handle both loading and debugging. Otherwise there's a button that boots the RP2040 chip looking like a disc drive, and you just get your host OS to copy the firmware file onto it.

Most Arduinos (except possibly the Nano) have a USB serial interface and preprogrammed loader firmware. However you have to jump through hoops to get a debugging interface.

Beware of the "Blue Pill" which is normally shipped without a bootloader, so you need either an ST-Link adapter or something else that implements the SWD 3-wire bus (e.g. a Picoprobe, but I've not tried this combination). Also beware that even though it might appear to be good value, there's a vast number of elderly "Blue Pill" boards with a bad resistor in the USB circuit, meaning that you've got to start messing around with a soldering iron before you have any real chance of programming it over USB.

For my money, the Pico+Picoprobe combination takes some beating. But I do have reservations about the RP2040 chip itself, since its USP (apart from price) is its PIO subsystems... which are great provided that you have a use for them (in the same way that the low-level processing hardware on a BeagleBone was great if you had a use for them) but for the vast majority of people will turn out to be a "solution looking for a problem" which they don't have.

MarkMLl