NOR Flash as mass storage with cortex M Series.
Started by 5 years ago●8 replies●latest reply 5 years ago●504 viewsI have a 4MB NOR Flash. i want to show this memory as Mass storage on a PC when connected as a USB device.
I have some confusions regarding the need of Filesystems on a NOR flash. I have a reference device (a data logger which mounts its NOR FLASH as USB storage when connected to PC. It uses FAT as the file system).
What i am trying to do is create a File on the NOR flash with an MCU. and Mount this flash memory as a Mass storage device to a computer through an MCU. And to be able to copy the file from the PC.
So far what i have concluded is that i need an MCU with USB_OTG_FS support , a File system for the NOR flash , and a way to Generate a PDF file through the MCU.
1) Is Mass storage class is a good approach to access a file stored in the NOR flash ?
2) Do i need a File system Translational Layer on the MCU side ? or the PC will handle all by it self ?
3) Is anyone familiar with handling a PDF file with an MCU ? i know a little bit about editing the source of the pdf file but not much.
I just need some expert opinion on whether i am going in the right direction or not.
Answers for your question:
1. Yes, you have to use Mass Storage class, and it is the approach for interfacing any flash, NOR or NAND.
2. Yes you need file system translation layer on MCU side. There are 2 approaches here:
A: You can download already implemented FAT file system code to MCU. OR
B: You can write a layer yourself following the Flash file system documentation and to be safe use FAT32 file system.
In either cases you have to provide low level functions of read page, write page, block erase, etc..
The easy flash file system you can work on is FAT32.
The FAT32 flash file system has a long legacy, started with PC's as FAT12, FAT16 and FAT32, the latest is FAT32. The acronym 'FAT' is 'File allocation Table'
3. Here do you mean PDF as 'Portable document File' ? If it is true, then you have to get all the details of PDF from Acrobat, then you have to implement simple text editor on MCU, and on top of this you have to write a layer to both ways translate PDF format. This is a very difficult task on MCU's as you may have to deal with graphics and fonts etc..
All The Best,
BV Ramesh.
Hi Ramesh , I really appreciate your opinion on this.
Regarding the PDF i will have to deal with the fonts and images as well. i will get a predefined template of the PDF and i will have to write data at certain locations in the pdf. i believe the pdf source code is constructed with tags similar to html right ? i will look into it.
PDF is a bit more complex than HTML. PDF has its roots in PostScript. PS is a full-blown stack based language, Turing complete an all. That is very cool, because you can send a program to the printer and that program will generate the final page. But the problem with that approach is that if your program has a bug and it goes into a infinite loop, the printer is dead. So PDF got rid of programmability, but retained a lot of other things from PS and added a bunch of new stuff, embedded media and the like. But even if you are only interested in text, you need to take care of the font metrics, positioning and all that. If you want to embed bitmap or vector graphics images, you can, but positioning and transformations (clipping, for example) are all your responsibility. Plus you need to maintain an object catalog at the end of the PDF file, which is actually an array that maps object IDs to absolute seek positions within the file.
Another solution to access files from PC is the MTP (Media Transfer Protocol). This protocol is used by cameras and some Android phones too. The MTP provides file operations for the host, not sector operations like mass storage.
Pros:
You can use any file system on your MCU. But if you use FAT, you need an FTL too. Proprietary file systems take care of wear leveling if they are designed to flash devices.
The PC and embedded side can write the same file system at the same time. (When mass storage device is mounted by host, the embedded side cannot write to it.)
Cons:
Usually much slower access of data.
Regards,
Peter
Hi Peter, Thanks for the suggestion
Wear leveling wont be an issue because the pdf will be generated once a month or once a week. i will try this approach as well. btw the size of the PDF generated will be under 4MB so i think slower access of the file wont be an issue. Maybe Writing the PDF from MCU to the flash will be slower ?! only experiments can tell which solution will be ideal for this particular requirement.
It sounds like the PDF is going to be your biggest effort. The rest is just glue.
My one piece of advice is: CODE THIS ON A PC. This is a benign environment. Keep the code simple. If you try to write and debug the PDF stuff on the embedded system, you will go insane for anything complex.
Isolate the I/O. Think about your memory allocation.
Use the normal PC tools for doing tricky things.
When you are doing the PC side, you can easily check your results. You have a PDF viewer on the PC - you can tell *if* something went wrong.
Edit :
I found this library for generating and handling PDF. https://github.com/AndreRenaud/PDFGen
I think this will work on an MCU as well.the dependencies are not very complicated. Now i just have to figure out how much ram does it needs. Maybe an mcu with >= 256KB of SRAM can do the job.
If you write vanilla C, it should be easy to port. Pay attention to the undefined and unspecified lists in C (get the latest draft standard - it's free and close enough to the official standard. They should also be in the back of any good C book.
Doing the PDF on a PC will give you the memory size you need to choose an MPU.
Keep your memory management simple. Keep your code simple. Success to you!