esp8266: Making esp.flash_id() more useful

[owens-bill]

The esp8266 port exposes the SDK function that reads out the ID of the SPI flash module; it produces a result like this:

>>> esp.flash_id()
1261768

Unfortunately, that's not terribly helpful because it isn't the representation of the ID that people actually use. To get that we can use esptool:

./esptool.py -p /dev/tty.usbserial flash_id
Connecting...
Manufacturer: c8
Device: 4013

Or the code for the flash_id method could be enhanced to do some simple parsing and spit out the same thing. The question I have is whether this is useful. The different ESP8266 modules do have different sized flash, and it might be handy to know how big they are, but this result doesn't directly tell you that; instead, you have to search for the result, or know that you can go grab a big file of flash IDs (http://code.coreboot.org/svn/flashrom/trunk/flashchips.h) and grep through it, and then look up the manufacturer's datasheet. We could work around that by building in a table of the most-commonly-used SPI flash modules, but I could see that getting out of hand pretty quickly!

It would be nicer to have an SDK function that simply told you how big the flash is. There is a new SDK function in 1.1.0 called system_get_flash_size_map but it seems to report what was configured when the software was linked, not what is actually on the board. I added a simple wrapper for it and tested on modules with 512 KB, 2 MB and 4 MB, and it always reported map 0, which is 512 KB. Assuming I wrote the wrapper correctly, that is not helpful ;)

So the questions are these, IMO:

• Is it useful to be able to retrieve the flash ROM size from within MicroPython, or will people just look up the spec sheet or use esptool?
• Is the current flash_id method sufficient?
• If not, should it parse the answer to display the manufacturer and device codes?
• Or should it have a lookup table of known flash chips, so it can also report the size?

[dpgeorge]

The manufacturer and device can be obtained from flash_id() by using simple bit manipulation in Python, so I don't see that it's worth doing this on the C side.

When do you need to know these things from a running script? Knowing the flash size is not useful unless you can write to it. The unused parts of the flash should eventually contain a filesystem, and the size of that filesystem is what's important (free and used bytes), and that information will come from some filesystem query function.

Summary: I'd say flash_id() as it is provides just enough information to be useful, and not more. Development time and bytes should be spent on other non-existent features like a filesystem :)

[pfalcon]

Development time and bytes should be spent on other non-existent features like a filesystem :)

And before that, already started low-hanging-fruit efforts should be finished: moving stuff to "network" module, implementing iwconfig() call (or how it would be called) in cooperation with other ports.

[owens-bill]

For me, the fruit has to hang awfully low ;) I am happy to keep moving things to network, and I can start piecing together iwconfig. A filesystem is definitely not something I will be trying to implement, or even copy from one of the other ports...

[danicampora]

The filesystem is actually not hard. You would use FatFs as the other ports and just write a thin layer to write and read from the external flash.
You need to write and read in blocks, the block must be of the size of the minimum area that you can erase in your external flash. FatFs wants an inteface to read and write blocks of 512 bytes. Translate this block size to your internal bigger (probably 2048 bytes) block size and then send the appropiate commands to the serial flash.

Good luck :-)

On Jun 18, 2015, at 1:53 PM, Bill Owens notifications@github.com wrote:

For me, the fruit has to hang awfully low ;) I am happy to keep moving things to network, and I can start piecing together iwconfig. A filesystem is definitely not something I will be trying to implement, or even copy from one of the other ports...

—
Reply to this email directly or view it on GitHub.

[owens-bill]

Before leaving this method behind, I'd like to write up what I've learned about it in the docs, just to keep someone else from having to reinvent this wheel. I want to include a scrap of Python to format the code; does this look reasonable?

id = '{0:x}'.format(esp.flash_id())
print('Manufacturer:', id[-2:], '\nDevice:', id[2:4] + id[0:2])

I've also gathered flash_id values for a few common chips, to save people having to look them up, and I'll include those so it's easy to tell what you have. And then move on to other delicious fruits that are within my reach ;)

[pfalcon]

I'd like to write up what I've learned about it in the docs

Not sure what docs you mean, but all that would be a perfect content for a blog post in your blog.

[owens-bill]

I meant the project docs for esp.flash_id(), which is currently undocumented, but your point is taken; nobody else cares about this particular function, so I'll plunk everything into a blog post and let Google point the way in the event that someone else wants to play with it in the future...

[pfalcon]

nobody else cares about this particular function

It's not exactly like that, but the following statement is almost certainly true: "perfectalizing a single function which probably will be used once on average won't make the port better". The docs also should follow some criteria, one example could be limiting what Wikipedia calls "original research", another staying in a close scope. So, documenting function is good, saying what each byte of return value mean is good, but "few common chips" is rather subjective, and we can't list all existing chips - there're other resources for that. On the other hand, blog is just perfect media for such information and commentary. And that's actually one of the suggested way to help spread a word about MicroPython - there should not be just one central place for all things MicroPython, there should be community and ecosystem, which meets at the central place - core MicroPython, but otherwise individual member do a lot of different things in a lot of different ways.

P.S. Thanks for contributions so far. Sorry, I respond less than I'd myself wish to your comments/questions (for various reasons - working on wrapping up other uPy things, summer kicking in, some points were already discussed previously, etc.) I recently started #1331 in the hope to guide novices and avoid confusion cases (like actually happened). Let me know if you'd find similar ticket for esp8266 useful (to state the obvious, it wouldn't a list of things somebody "should do", it would be a list anyone can consider, and if they like something from there/think it makes sense, can contribute to that area).