Extension of the SAMD21 port.

[robert-hh]

Now that external flash support is enabled, how should the extra 64k flash space used at SAMD21 devices. Options:

• Use LFS2 instead of LFS1: 6k
  Observation: Using LFS2 in addition to LFS1 increases the flash by 16k. That's strange.
• Framebuffer support: 4k
• Set Python feature level to FULL_FEATURES instead of CORE_FEATURES: 25k
• Support onewire, dht_readinto with scripts: 3.5 k
• Complex math: 3.2 K (not yet enabled for SAMD51)
• UART flow control 300 Bytes
• Viper and Native code: 21k
• More frozen bytecode by default.

The available RAM did not grow. So using a lot of static data is bad,

[rkompass]

6k + 16k + 4k + 25k + 3.5k + 3.2k + 0.3k +21k = 79k < 80k = 64k + 16k ???. I would then suggest to include all of the above options.

[robert-hh]

The LFS options are either 6k OR 16k, not both. And CMATH support may be questionable, since it is not enabled at SAM51.
So with LFS2 only and no CMATH it adds to ~60k. It still should be considered that the SAMD21 is pretty low on RAM, like 20k for the heap.

[Skunky-One]

Hi. Silly me. I'm trying to connect a display to a SAMD21 in Micropython. I didn't realize this was going to be a problem, and I'm already pretty deep in my code.

I really wanted to use an SSD1306, but only with text. There's nothing sexier than a monochrome screen with text IMO. It looks to me like the paths to success are:

1. Rewrite the SSD1306 module and remove the framebuf module. Am I right in thinking this is only used for pixel art?

2. Get / make some firmware that allows use of the framebuf module. How hard is this? How does one custom brew boot code? I tried all of the versions that were available, and none of them have framebuf.

3. Adapt the Circuitpython version called Adafruit_CircuitPython_framebuf to work in Micropython. Is this a crazy idea?

Am I missing anything?

[scruss]

… remove the framebuf module. Am I right in thinking this is only used for pixel art?

No. Text functions come from framebuf.

It would probably be better to start a new discussion than tacking on to a maintainer's query from several years ago.

[robert-hh]

It depends on which board you use. SAMD21 boards with external flash have the framebuf module enabled. Boards without external flash do not support framebuf. You can enable it when creating your custom firmware, but you have to drop other features or reduce the size of the vfs file system. Framebuf takes about 4k flash space.

[Skunky-One]

Thanks scruss and robert-hh. I didn't know about the external flash changing enabling framebuf, or that framebuf was used with text.

I suppose there's another option too.

4. Use MP's superpower of code portability and switch processors.

Thank you both. You've given me some great direction.

[robert-hh]

As for other platform, you could use SAMD51, or Raspberr Pi Pico, or ESP32, etc. All of these provide the framebuf module.

[ricksorensen]

How many SAMD21 boards have the external flash? (the itsybitsy and feather boards do I see).

I would think for those SAMD21 boards without WiFi/BLE/.. the framebuffer should be included for basic display of changing info. I use a small I2C OLED for GPS and simple environmental app using a SAMD21 without external Flash for example. I add framebuf to my build which reduces my onboard flash filesystem to 48K.

And sensor processing options (dht, onewire) ... And code(speed) optimizations (Viper, Native) could be useful for lower power MCUs.

I would bias onboard usage towards the compiled C code since the added external Flash gives room for python code.

My 2 cents, if even that.

[robert-hh]

I made a first package including:

• Set Python feature level to EXTRA_FEATURES instead of CORE_FEATURES.
  EXTRA_FEATURES was needed to enable Viper & Native, but less may be possible. I have to check what exactly is needed.
• Viper and Native code. While on a relatively slow device Viper and Native code is helpful, it might not need all MicroPyton features.
• Support onewire, dht_readinto
• Framebuffer support
• UART flow control