Giovanni wrote:The BaseFlash class is generic, not just meant for SPI devices but also memory mapped flash or other types, the "get id" thing is very specific of the SPI type I think.
All types of flash I know of have some kind of get id. I just browsed through the datasheets of some parallel flash ics of different manufacturers at Digikey and they all have it. And in all types I've seen it was modeled similar with a manufacturer and device id in front. Sometimes there was vendor specific stuff like feature bitmasks following in the output. But the get id command could ignore that.
Also interfaces like eMMC and SD card offer id data. But it is longer than on the SPI flashes. If you want to cover that with this interface too, you'd have to make the id variable length.
Maybe there is some odd flash device out there which does not offer it. But that would really be the exception and not the rule. Then the driver for that oddball device could return 0 as id. You could also add a feature flag telling if a driver returns a proper id or not.
Giovanni wrote:(and an API to send direct commands, all problems solved)
yeah, that would be nice and solve the problems with the custom write protection schemes and other vendor specific stuff.
I'm not sure if the direct command API needs to be limited to SPI. The parallel flashes have commands too, usually implemented with command registers. I don't know how you would implement flash without any kind of commands. You need at least some kind of page erase command. Implementing a read/write like parallel SRAM doesn't make any sense with flash.
Giovanni wrote:BTW, I am working on a QSPI driver while I am at it, it is becoming a standard feature nowadays.