3
\$\begingroup\$

I'm trying to figure out a convenient way with which a PC can configure an embedded system. The PC will have a custom app. written that can 'talk' to the embedded uC and configure the various settings and upload some data to it (~ 500 KB). The advantage of this approach is it's simplicity.

My initial thought was to go with a UART to USB bridge and take it from there. However, I'm now considering implementing a usb mass storage device instead. The advantage is that the end-user can simply drag and drop a file which contains the data and the configuration settings. The board will have a flash memory IC of appropriate size mounted on it. The uC will be a low-end STM32 (I have not decided on a specific chip yet).

Since the file will have to be in a specific format for the embedded system, I believe I'll still have to write a custom app. for the PC to write that file from the settings provided by the end-user. This isn't overly difficult.

But what I'm confused about is, how do I mount the flash memory as a FAT disk on the PC? Are there any integrated solutions - perhaps a flash memory which talks to USB directly?

NOTE: I know about LUFA for the AVR. However, I'm not yet sure if I'll be able to use an AVR as I also have to drive a 800x400 RGB display. As a test, I did drive the display using an AVR running at 8 MHz. The update rate was slower than I'd like.

\$\endgroup\$
  • \$\begingroup\$ The USB Mass storage is block level protocol. If you configure your STM32 USB lib correctly, you can make part of your FLASH memory as Mass Storage device. This would allow PC to write to your flash area easily. If this is a controlled environment, this may work well. For example only a simple single file is used for config and you can guarantee that there will only be a single file, you can essentially get away with a ultra simple FAT implementation in CPU to read the file. You can get STM32 to read the data from the flash during boot time and be done with it. \$\endgroup\$ – Ktc Oct 7 '12 at 13:16
  • \$\begingroup\$ You should be able to do this with the usb example code for supporting members of the stm32 family. However, I would join the others in preferring a serial command protocol - for one thing it means you can have a conversation with your code as you debug it, getting status updates immediately, without a remount delay. \$\endgroup\$ – Chris Stratton Oct 7 '12 at 14:48
  • \$\begingroup\$ @ChrisStratton Yes, I am now reconsidering that approach. The UART method has more benefits and is also simpler (which is a big plus!). \$\endgroup\$ – Saad Oct 7 '12 at 14:52
3
\$\begingroup\$

Lookup forebrain code examples, they use NXP LPC1343 chip that has USB mass storage drivers in ROM (so you can program the chip via drag and drop). Forebrain have example where they use internal ROM driver to present an EEPROM chip or simply just piece of RAM as mass storage device. They are closed source, but this gives the idea of how it could be implemented.

In general, you have to implement specific USB mass storage driver hooks.

There is no need to make config file in any special format as you could implement FAT system on your chip so it accesses flash memory as FAT filesystem. You can lookup any SD card reading/writing example for popular microcontrollers - some use low level, some implement FAT. Particulary - this one for LPC1343 implements FAT over SD card: https://github.com/Miceuz/LPC1343CodeBase/tree/master/drivers/fatfs

BTW, have you considered an option to put configuration into a file on SD card? You would have loads of ready made code and examples for broad range of MCUs for that. Config process would involve extracting SD card from device and putting it into computer though.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ The link to forebrain is lost, are there any alternative? \$\endgroup\$ – riscy Nov 25 '15 at 13:34
2
\$\begingroup\$

As long as you have to have a custom application running on the PC anyway, there's no reason you can't implement a drag-and-drop user interface paradigm while still using the USB/UART interface to communicate with the device. If there are pre-configured files (or files previously configured by the user) for the device, the user can just drag one of them and drop it onto your application, at which point, the application reads the file and sends the data to the device through whatever proprietary interface you come up with.

Implementing a USB mass-storage interface just so you can get a drag-and-drop UI "by default" seems like the wrong way to approach this.

|improve this answer|||||
\$\endgroup\$
2
\$\begingroup\$

I'd say go for the USB Mass Storage approach. The benefit here is two fold.

1.) You can have people field update the device, without the configuration program, just by plugging it into a computer. You could push custom updates out to people without having to implement the features in the software, test the software, etc.

2.) You can have your configuration software programmatically delete and re-upload the configuration file as if the device was a local drive. This means you don't have to implement a block-level protocol on top of your UART line. That saves you time.

I've been doing research into the same sort of approach for firmware updates in the field, and here's how most of the USB bootloaders typically work:

  • install USB bootloader into top 64KB of flash
  • bottom 448kb (in my case, 512kb flash) is mapped for storage
  • on reset, if a certain GPIO is held high for 2 seconds, go into programming mode
  • programming mode = enumerate as USB mass storage device
  • drag and drop your firmware binary file
  • once transferred, reset
  • new firmware loads up

I haven't investigated this far, but: I could picture a bootloader when depending on the name of the file being added, it either goes into flash or EEPROM. You could then drag-and-drop not only firmware to allow field updating and but allow configuration files to be dragged-and-dropped directly to EEPROM, essentially.

Just some food for thought. :)

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ Toby, does this method restrict me to the internal EEPROM of the uC? Not sure if any uC has 500 KB of internal EEPROM. I will have an external EEPROM/FLASH on the board and I was hoping I could access that. \$\endgroup\$ – Saad Oct 7 '12 at 16:52
  • \$\begingroup\$ The approach/steps I listed were simply how the bootloaders I've seen work... since in this case, 448KB is plenty of room for firmware. (The LPC1769 has 512KB internal flash) If you want to use an external EEPROM or flash, that's fine. The "bootloader" is just user code that runs before your "main" program, so you can connect to another device over SPI, I2C, parallel, etc, and store the file data on that instead. It's up to you. Again, this is more of a generic approach that you could simply implement for your specific use case. \$\endgroup\$ – Toby Lawrence Oct 7 '12 at 20:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.