Product Idea: USB Flash Drives

[barray]

This is just another confirmation of the need to use raw flash, instead of using "managed" flash.  Only raw flash can be told exactly what to do and when, instead of having the embedded flash microcontroller doing things nondeterministically on its own.  Using raw flash would make it possible to use the inherent CoW nature of flash to provide higher-level CoW, for the stored data.

In other words, combining the CoW nature of flash and our own wear levelling algorithms would make it possible to ensure guaranteed data reliability, and even to provide the ability for the host to define write barriers, which would trickle the data reliability up to the OS and filesystem level.  That would be awesome!

Eh, one problem at a time - for now I'll settle for writing data unreliably. We need to start the process of creating a prototype, otherwise this project will never get off the ground. The way I see it, the milestones are:

1. Block diagram - How will this be roughly put together? (I think we are mostly there in terms of written ideas, but I think a diagram will say more than words)

2. BOM - Exactly what chips will we use and how much will this cost? Are the specs up to scratch to give us a viable path forwards?

3. Schematic - What gets connected and where. (I'm currently experimenting with another project to do this programmatically.)

4. Layout - Design the PCB to be made.

5. Prototype manufacture - Lets get the prototype built!

As already described, cutting power to a USB device is doable on recent PC motherboards, so no additional hardware or a dedicated testbed would be required.  Though, that would cover just cutting the power to a USB device, instead of simulating the unplugging of a device as a whole.  However, having the ability to cut power on demand should be good enough for a while.

It would 100% be better if we could do this using some Pine hardware, like the A64 LTS board.

I've spent some more time tidying up the main wiki page, and this edit introduced a link to the PineFlash page.

Good stuff

Unfortunately, there's no "magic" there to rely upon, only the simple but fundamental rules to follow.  As an example, you can find quite a few descriptions of the real-word issues with using microSD cards in embedded systems, caused by their nondeterministic nature.

Using flash chips that provide the ECC functionality internally would be good, as long as it's still raw flash.

I don't know if you checked the memory I linked to in the wiki, but it's really not as raw as you're thinking. I am up for using raw flash but would want to understand exactly what the memory controller is actually doing. For example, given the number of pins on raw flash, I am not even entirely sure it can be controlled with just QSPI. If that's so, it means we'll need alot more complex controller, something we will get zero support for in the community.

If on the other hand we stuck with the automotive NAND flash, we get ECC, QSPI, etc, of course, at a cost. It's also tonnes easier to interface with.

The other option is potentially we link tonnes of eMMc memory together, although again I would need to understand exactly how that works - it feels like we lose control again.

I see no possible copyright issues with the color of the PCB, and the association with Flash Gordon might be mentioned somewhere unofficially, as a funny note.   However, please keep in mind that PCB manufacturers charge much more for red PCBs than the green ones.

I think if you're producing PCBs en mass it doesn't matter too much. Back when I used to be involved in the automotive side of things we would purposely make the prototype boards a different colour anyway, to visually see they were different from one another. When you are doing low-run production, the colour of the PCB is the least of your worries. I know these days many people like to get their PCBs made in black (probably to hide the burn marks from soldering).