# Adafruit QT Py - SAMD21 Dev Board

### Help Support The Rocketry Forum:

#### Winston

##### Lorenzo von Matterhorn
Out of stock which is the usual for them with new products.

Adafruit QT Py - SAMD21 Dev Board

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:

#### jry

##### Member
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

##### Well-Known Member
TRF Supporter
Its good to see FRAM replacing flash memory. Much greater number if write cycles, by up to 8 orders of magnitude or so.

#### Winston

##### Lorenzo von Matterhorn
Uses the new Raspberry Pi Pico processor.

Adafruit QT Py RP2040 - Coming soon!

#### SparkyVTFlyer

##### Senior Member
TRF Supporter
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

##### Owner, Eggtimer Rocketry
TRF Sponsor
TRF Supporter
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

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

#### KilroySmith

##### Well-Known Member
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

##### Owner, Eggtimer Rocketry
TRF Sponsor
TRF Supporter
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

##### Member
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

##### FlightSketch - flightsketch.com
TRF Sponsor
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.