Adafruit QT Py - SAMD21 Dev Board

[Winston]

Out of stock which is the usual for them with new products.

Adafruit QT Py - SAMD21 Dev Board

https://www.adafruit.com/qtpy
Same size, form-factor, and pin-out as Seeed Xiao [which I never knew about until Adafruit pretty much copied it with some improvements]
ATSAMD21E18 32-bit Cortex M0+ - 48 MHz 32 bit processor with 256KB Flash and 32 KB RAM
Native USB supported by every OS - can be used in Arduino or CircuitPython as USB serial console, MIDI, Keyboard/Mouse HID, even a little disk drive for storing Python scripts.
Can be used with Arduino IDE or CircuitPython
Built in RGB NeoPixel LED
11 GPIO pins:
True analog output on one I/O pin - can be used to play 10-bit quality audio clips in Arduino (CircuitPython does not have storage for audio clips)
9 x 12-bit analog inputs (SDA/SCL do not have analog inputs)
1 x Optional AREF on A1
9 x PWM outputs (A0 is analog out, A1 is not PWM capable)
Hardware I2C port with STEMMA QT plug-n-play connector
Hardware UART
Hardware SPI
Hardware I2S
6 x Capacitive Touch with no additional components required
3.3V regulator with 600mA peak output
Optional SOIC-8 SPI Flash chip on bottom
Reset switch for starting your project code over or entering bootloader mode
USB Type C connector
Really really small

The Seeed XIAO:

 

[Winston]

 

[jry]

The pads on the back also work with SPI bus FRAM chips since the pinouts are the same. I did a 2-channel layout of a baro-only altimeter with logging to a 2Mbit FRAM which gives enough for several flights. Decimating logs during descent makes it last much longer. No flights yet but the same code base and electronics are working well on other Arduino platforms.

Lovely little "Arduino" boards! I can post pix of some altimeters I made using QtPy and xiao.

 

[OverTheTop]

Its good to see FRAM replacing flash memory. Much greater number if write cycles, by up to 8 orders of magnitude or so.

 

[Winston]

Uses the new Raspberry Pi Pico processor.

Adafruit QT Py RP2040 - Coming soon!

https://www.adafruit.com/product/4900

 

[SparkyVT]

I saw these and thought they were interesting. Probably useful for some single sensor data recorder projects. Probably not enough pinouts for something more without getting complicated.

I find the M0 processors less useful since they don't have EEPROM, which I use to hold sensor calibration values. EEPROM can be emulated with Flash, but the way I understand it, the Flash is overwritten whenever new code is uploaded. I'm not sure if FRAM could solve that problem.

 

[cerving]

Its good to see FRAM replacing flash memory. Much greater number if write cycles, by up to 8 orders of magnitude or so.

Yup... if only it wasn't ridiculously expensive.

 

[KilroySmith]

Its good to see FRAM replacing flash memory. Much greater number if write cycles, by up to 8 orders of magnitude or so.

Are you really running up against write cycle limitations? A Samsung Endurance MicroSD flash is good for 4000 cycles. That's a lot of telemetry on a $15 32 GB card, and it's likely physically smaller than the 8-32KB FRAM you're thinking about.

 

[OverTheTop]

Are you really running up against write cycle limitations?

We used FLASH chips for recording data in intelligent modules in our spectrometer and had to be careful to not run into write life issues over the life of the products. FRAM is a no-brainer in our situation. Depending on how much you record and how long you expect the altimeter to remain functional, it may or may not make sense to use FRAM in rocketry electronics. It does need to be considered on a case-by-case basis. The price will come down over time too.

 

[cerving]

The biggest advantage of FRAM over flash is that you don't have to write an entire block at a time, and the biggest advantage of FRAM over EEPROM is that there's no settling time (which adds 3-5ms to a write cycle). Unfortunately, a 1 Mb FRAM is about $10 and an 8 Mb FRAM is about $30. Compare that to a 1 Mb EEPROM for a buck or an 8 Mb flash for about 50 cents and you'll see why FRAM is not in more widespread use. A good compromise would be to use a small FRAM as a buffer and write blocks to EEPROM/flash... it wouldn't be that hard to do, but of course it would take more board space (and processor program flash memory).

 

[KilroySmith]

I guess as a product development engineer myself, I'd have to ask how 4000 cycles on a 32GB flash compares lifecycle- and cost-wise with that 128KB FRAM that's roughly the same cost. Having 250,000 times the storage space makes up for a heck of a lot of erase cycles. In either case, expanding SRAM to use as a buffer is cheap (especially if you're building your own chips).

 

[cerving]

It would depend if your software would get anywhere near the 4,000 cycle limit or not. If it's writing flight data and not repeating writes to the same blocks very often (if ever), then it makes sense to go with flash. We use EEPROM, that's good for 1M cycles, but it's primarily because we can write a few bytes at a time if we want without having to rewrite an entire block like you do for flash. It's better for data integrity. FRAM as a buffer makes sense... the whole idea is to write everything to NVM, using SRAM as a buffer wouldn't do that. FRAM is also I2C just like EEPROM, which makes integrating it much easier than either SPI SRAM or flash.

 

[jry]

FRAM can be had in SPI or I2C. Also check out the new kid on the block: ReRAM! Fujitsu's MB85AS4MTPF has the same interface as their FRAM, and a bit lower cost. Wide-body SOIC. Fresh parts are all foxes (0xFF0xFF, you know) rather then zeroes like with FRAM.

 

[gtg738w]

It would depend if your software would get anywhere near the 4,000 cycle limit or not. If it's writing flight data and not repeating writes to the same blocks very often (if ever), then it makes sense to go with flash. We use EEPROM, that's good for 1M cycles, but it's primarily because we can write a few bytes at a time if we want without having to rewrite an entire block like you do for flash. It's better for data integrity. FRAM as a buffer makes sense... the whole idea is to write everything to NVM, using SRAM as a buffer wouldn't do that. FRAM is also I2C just like EEPROM, which makes integrating it much easier than either SPI SRAM or flash.

Flash can be written to one byte at a time but must be erased first by the page. You can stream flight data easily but things like settings we just read the entire page to RAM and then erase/write with the new values.