Quantcast

Adafruit QT Py - SAMD21 Dev Board

The Rocketry Forum

Help Support The Rocketry Forum:

Winston

Lorenzo von Matterhorn
Joined
Jan 31, 2009
Messages
9,050
Reaction score
1,160
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

New Member
Joined
Jan 4, 2015
Messages
4
Reaction score
2
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
Joined
Jul 10, 2007
Messages
4,883
Reaction score
2,125
Location
Melbourne Australia
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
Joined
Jan 31, 2009
Messages
9,050
Reaction score
1,160
Uses the new Raspberry Pi Pico processor.

Adafruit QT Py RP2040 - Coming soon!

 

SparkyVTFlyer

Senior Member
TRF Supporter
Joined
Feb 8, 2009
Messages
207
Reaction score
28
Location
Yorktown, VA
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.
 

KilroySmith

Well-Known Member
Joined
Oct 29, 2015
Messages
156
Reaction score
78
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

Well-Known Member
TRF Supporter
Joined
Jul 10, 2007
Messages
4,883
Reaction score
2,125
Location
Melbourne Australia
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

Owner, Eggtimer Rocketry
TRF Sponsor
TRF Supporter
Joined
Feb 3, 2012
Messages
4,162
Reaction score
1,438
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

Well-Known Member
Joined
Oct 29, 2015
Messages
156
Reaction score
78
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
Joined
Feb 3, 2012
Messages
4,162
Reaction score
1,438
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.
 
Top