Product Idea: USB Flash Drives

[dsimic]

Eh, one problem at a time - for now I'll settle for writing data unreliably.

Absolutely.  It's just that we need to keep the big picture in mind, and make the right decisions and choices at the important points in the development.

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!

You've laid it out very well, but the second point is the blocker.  We have to select the main chip first, but I'm really not sure which way to go.  Our direction so far has been to use the BL602, which seems rather fine, but it's still a can of worms that would surely come with more than a few issues, unknowns and unforeseen constraints.  We should also keep in mind that a BL602-based storage device would be rather slow, and at this point in time I'm pretty sure that we'll, unfortunately, end up getting no support from Pine64.

Also, please have a look at the STM32 H7 microcontrollers.  The specs look very good, there's support for SDR/DDR quad-SPI interface (up to 256 MB), two 1-/4-/8-bit SD/MMC SDR104/HS200 interfaces (hmm, RAID1 across two microSD cards or, even better, two eMMC modules?), high-speed (480 Mbit/s) USB 2.0 device interface, and even an Ethernet MAC (100 Mbit/s only, though), but where would we start from the software side?  Though, a complete and very detailed reference manual is available and the GNU toolchain for Cortex-M7 is readily available.

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.

Not a problem.   According to the Rock64 v3 schematic, it is possible to control (i.e. cut) the power supply to its USB ports, using one of the GPIO pins of the SoC.  I'd also suggest that we use Rock64, because it's a more powerful SBC than Pine A64-LTS, and has a USB 3.0 port as well.

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.

Quite frankly, somehow I missed that link, but now I had a look at the W25N datasheet.  As far as I can see, the W25N has on-chip ECC and management of bad blocks, but doesn't do wear leveling on its own.  Based on that, all acknowledged write operations should actually reach the flash.  Thus, I'd say that it strikes a good balance.

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 haven't researched eMMC storage in detail yet, but I'd say that it might be treated as more reliable than microSD cards, for example.  Some information is available in this PDF file, but in general not much freely available information is floating around.  This PDF file provides some more information, including a description of the power-off procedure, cache flushing, and cache barriers.  These three features are critical for any storage device that aims to store data reliably.

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.

It's very easily possible that the price difference becomes negligible in larger quantities.  My remark was based on a limited insight into the prices quoted by JLCPCB for different PCB colors.