Flash Options

Showroom for MicroPython related hardware projects.
Target audience: Users wanting to show off their project!
Post Reply
marc4444
Posts: 2
Joined: Sat Aug 03, 2019 12:16 pm

Flash Options

Post by marc4444 » Sat Aug 03, 2019 12:56 pm

Hi All,

I'm a new MicroPython forum member but have been using the Pyboards for a while (and other IoT projects).

I'm trying to develop an environmental data logger for a school that is going to be deployed for up to 10 years collecting data and reporting it to a web server over the mobile networks. The files I've written are getting fairly big (350KB) and I anticipate I may have to update firmware (so there could be two file sets) and store data files occasionally on the device so am looking for 2MB+ of storage. I want to keep cost as low as possible as I plan to make quite a few of these and reliability is important as it will be difficult to replace faulty parts once deployed.

What is the easiest way of adding flash memory to the STM M4 range of chips? As I see it I have the following options:

-By a 2MB STM M4 chip (eg STM32F427) that costs around £11.22 compared to £6.00 for the cheaper chip in the Pyblite - v reliable but quite expensive, need to port Micropython to the F427 and doesn't have loads of space.

-Use a basic SD card - lots of space, easy to develop and can be cheap, but I have concerns around reliability if it's going to be deployed for years.

-Use an industrial SD card - lots of space, easy to develop and reliability should be better than basic SD card, but they start at £10 so v expensive.

-SPI flash - plenty of space, very cheap (£0.50) and very reliable, but it isn't readily supported by the looks of it so would need to do a fair bit of development in an area I don't know much about.

Does anyone have any thoughts on the above or other ideas? Any help is appreciated.

Thanks,
Marc

Online
User avatar
jimmo
Posts: 665
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia

Re: Flash Options

Post by jimmo » Sat Aug 03, 2019 2:33 pm

marc4444 wrote:
Sat Aug 03, 2019 12:56 pm
-SPI flash - plenty of space, very cheap (£0.50) and very reliable, but it isn't readily supported by the looks of it so would need to do a fair bit of development in an area I don't know much about.
I think this is probably your best option, and it should be fairly straightforward to implement this in a custom firmware build that enables a spiflash bdev rather than using internal flash.

If you take a look at ports/stm32/boards/STM32L476DISC you can see an example that does exactly this. The relevant parts are bdev.c, board_init.c and the first section of mpconfigboard.h (disable internal flash, define spi pins, define ioctl/read/write). You could adapt this into the pyblite board config.

marc4444
Posts: 2
Joined: Sat Aug 03, 2019 12:16 pm

Re: Flash Options

Post by marc4444 » Sat Aug 03, 2019 3:19 pm

Thanks Jimmo - so following the example you link would mean the full SPI flash would show up like the internal memory? Is saving files a more involved process using SPI flash or does it work the same as SD card/internal flash?

Also I saw a previous poster talk about it being slow - do you know if this is still the case? (viewtopic.php?t=2970).

Thanks

Online
User avatar
jimmo
Posts: 665
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia

Re: Flash Options

Post by jimmo » Thu Aug 08, 2019 12:17 pm

marc4444 wrote:
Sat Aug 03, 2019 3:19 pm
Thanks Jimmo - so following the example you link would mean the full SPI flash would show up like the internal memory? Is saving files a more involved process using SPI flash or does it work the same as SD card/internal flash?
It works the same as internal flash -- it essentially takes the place of internal flash for the purpose of providing the block device for the filesystem.
marc4444 wrote:
Sat Aug 03, 2019 3:19 pm
Also I saw a previous poster talk about it being slow - do you know if this is still the case? (viewtopic.php?t=2970).
I can't tell if that post is suggesting that the internal flash or external spiflash is slower? Given that the internal flash isn't really designed for this purpose (it's for storing code not frequently-written data), it doesn't suprise me that it would be slow.

Post Reply