Product Idea: USB Flash Drives

[barray]

Sorry for lack of reply, for some reason I didn't get a notification...

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.

Sure, but we can get support from the community. Also any improvements/fixes also benefit the community. I imagine we will need a more powerful controller, but I think the BL602 is a great place to start. Even getting something working at a slow speed will be a massive achievement.

Perhaps we look at this differently - we're not aiming to build the final product, merely a proof of concept? If it even half works and we start to get some interest, I think we could attract more support.

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.

Hacking about on a Cortex-M7 will be non-trivial... I've done this sort of work before and it took a lot of engineers several months getting even a basic framework up and running reliably.

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.

Yeah, that would be the way to go.

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.

We can always swap it out for something else at a later date - it's just cheap and simple. Once we have something basic up and running we could look to make it more complex.

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.

I recently got some PCBs made with PCBway, colour didn't make a different in price at all (unless you wanted some special variant).

Related to this recent project, I also got automated schematic building and circuit verification working, export to Kicad and autorouting. I used this to build the recent project - will verify it all works when the PCB comes in a week's time or so.

Nice find.  They seem to charge about 40 EUR for a single 32 GB USB flash drive?  We might be able to match that price, but it would depend on the size of the initial batch.

I think that would be roughly where we're aiming for.

[dsimic]

Sorry for lack of reply, for some reason I didn't get a notification...

No worries, I've also experienced a couple of forum alerts that disappeared on their own.

Sure, but we can get support from the community. Also any improvements/fixes also benefit the community. I imagine we will need a more powerful controller, but I think the BL602 is a great place to start. Even getting something working at a slow speed will be a massive achievement.

Perhaps we look at this differently - we're not aiming to build the final product, merely a proof of concept? If it even half works and we start to get some interest, I think we could attract more support.

Hmm...  Let's recall the OpenSSD project, which pretty much remains to be a proof of concept, simply because it's impossible to buy the required hardware and have an OpenSSD "instance" running on one's desk.  Thus, as a proof of concept, OpenSSD hasn't gained a lot of traction; as we know, only an inexpensive product that can be purchased by pretty much anyone has the potential to gain a lot of traction in the community.

Thus, I agree that the BL602 would be a good starting point for making a proof of concept, but it would remain at that level (i.e., a schematic, a bunch of code, a few pictures, and some benchmarks) until it becomes a final product.  However, if you agree, a BL602-based storage device would be just too slow to become a viable product that can have a price tag on it.  Very few people would actually buy it, out of which at least 10% wouldn't understand the purpose of the device, so they would leave very bad reviews and effectively thrash the whole project.

Please, don't get me wrong, I'm not a negative Nancy.  I'm just trying to look at the whole idea from as many points as possible.

Hacking about on a Cortex-M7 will be non-trivial... I've done this sort of work before and it took a lot of engineers several months getting even a basic framework up and running reliably.

Nobody said that it would be trivial.   By the way, please have a look at the AltOS, which might serve as a good starting point.

[xalius]

Maybe you can find some single core A9 with USB3 interface, something similar to https://www.cypress.com/products/ez-usb-...controller, sadly this one doesn't have a flash interface, it's more meant to be a USB3 bridge to some other MCU/AP

[barray]

Hmm...  Let's recall the OpenSSD project, which pretty much remains to be a proof of concept, simply because it's impossible to buy the required hardware and have an OpenSSD "instance" running on one's desk.  Thus, as a proof of concept, OpenSSD hasn't gained a lot of traction; as we know, only an inexpensive product that can be purchased by pretty much anyone has the potential to gain a lot of traction in the community.

I don't think the OpenSSD project ever planned to actually be a consumer device, rather just a platform for research. There's of course nothing wrong with that and it's extremely valuable, but it limits its use to others.

Thus, I agree that the BL602 would be a good starting point for making a proof of concept, but it would remain at that level (i.e., a schematic, a bunch of code, a few pictures, and some benchmarks) until it becomes a final product.  However, if you agree, a BL602-based storage device would be just too slow to become a viable product that can have a price tag on it.  Very few people would actually buy it, out of which at least 10% wouldn't understand the purpose of the device, so they would leave very bad reviews and effectively thrash the whole project.

Oh for sure, the BL602 will be highly unlikely to end up in the final design - but we're not even going to be getting close to meeting the limitations of the BL602 in our first design I don't imagine. If we can get it working at any kind of speed, that's already useful.

Please, don't get me wrong, I'm not a negative Nancy.  I'm just trying to look at the whole idea from as many points as possible.

No I understand

Nobody said that it would be trivial.   By the way, please have a look at the AltOS, which might serve as a good starting point.

Interesting. I think it would be good to have an OS and the USB decoupled, especially as we are looking to port. Using FreeRTOS for example would get us tonnes of platforms, leaving only the need to port the USB library. I linked also to a pretty good library above which supports mass storage.

Maybe you can find some single core A9 with USB3 interface, something similar to https://www.cypress.com/products/ez-usb-...controller, sadly this one doesn't have a flash interface, it's more meant to be a USB3 bridge to some other MCU/AP

Yeah something with a dedicated USB bus would be the way to go I imagine. I think we would be ideally looking for something RISC-V if possible - maybe something like this? https://wiki.seeedstudio.com/SeeedStudio...Dev-Board/

[xalius]

I was looking for something like this https://www.hyperstone.com/en/USB-31-Con...-2129.html which is an integrated USB flash drive controller with some RISC core. The problem is that sourcing those in low volumes is usually pretty hard, Mouser seems to at least list them for 5-6EUR per piece, but I doubt that you can actually order only a few...

[dsimic]

I don't think the OpenSSD project ever planned to actually be a consumer device, rather just a platform for research. There's of course nothing wrong with that and it's extremely valuable, but it limits its use to others.

I agree that OpenSSD was probably made as a research platform only.  That's perfectly fine.  However, who's going to do some research on a hardware platform that pretty much cannot be purchased?

Oh for sure, the BL602 will be highly unlikely to end up in the final design - but we're not even going to be getting close to meeting the limitations of the BL602 in our first design I don't imagine. If we can get it working at any kind of speed, that's already useful.

Alright, let's take the first step with the BL602 as a PoC platform, if you agree.  Let's find out how the Quad-SPI interface on the BL602 actually works, how is it used on the software side, and if there any limitations to the total size of the SPI flash that can be connected that way.  Sounds like a plan?

Interesting. I think it would be good to have an OS and the USB decoupled, especially as we are looking to port. Using FreeRTOS for example would get us tonnes of platforms, leaving only the need to port the USB library. I linked also to a pretty good library above which supports mass storage.

It would be ideal to make the firmware modular, independent of the underlying hardware, and thus reusable as much as possible.  I'm unable to find the link to the library you've mentioned above in any of your recent posts...  Could you, please, post that link again?

I was looking for something like this https://www.hyperstone.com/en/USB-31-Con...-2129.html which is an integrated USB flash drive controller with some RISC core. The problem is that sourcing those in low volumes is usually pretty hard, Mouser seems to at least list them for 5-6EUR per piece, but I doubt that you can actually order only a few...

This looks very interesting.  According to Mouser, it is possible to have it ordered in low quantities.  Now, I wonder how could we get access to the API and SDK mentioned on the product web page?  Also, I wonder how far the "firmware customizations", as described by the manufacturer, can go on this controller?

[barray]

Alright, let's take the first step with the BL602 as a PoC platform, if you agree.  Let's find out how the Quad-SPI interface on the BL602 actually works, how is it used on the software side, and if there any limitations to the total size of the SPI flash that can be connected that way.  Sounds like a plan?

I think creating a hat for this device already means that Pine are manufacturing half of the prototype for us. It also means we could then swap out the BL602 at a later date and make it a hat for another device.

It would be ideal to make the firmware modular, independent of the underlying hardware, and thus reusable as much as possible.  I'm unable to find the link to the library you've mentioned above in any of your recent posts...  Could you, please, post that link again?

https://github.com/hathach/tinyusb

I was looking for something like this https://www.hyperstone.com/en/USB-31-Con...-2129.html which is an integrated USB flash drive controller with some RISC core. The problem is that sourcing those in low volumes is usually pretty hard, Mouser seems to at least list them for 5-6EUR per piece, but I doubt that you can actually order only a few...

This looks very interesting.  According to Mouser, it is possible to have it ordered in low quantities.  Now, I wonder how could we get access to the API and SDK mentioned on the product web page?  Also, I wonder how far the "firmware customizations", as described by the manufacturer, can go on this controller?
[/quote]

It looks very interesting for sure, but I also have concerns about how much firmware customization can be done. For example, we would probably have to sign an NDA just to get the documentation (just from the fact I cannot find it online) and we would be bound to a specific closed-source compiler to get their "special instructions". In any case, it will be a massive reverse-engineering undertaking. This is exactly what we're trying to get away from.

They do kindly sell an 8GB dev board for $250 USD: https://nz.mouser.com/ProductDetail/Hype...kmaQ%3D%3D

The controller is towards what we are trying to create, but it's just not aligned with how we want to get there.

[dsimic]

Alright, let's take the first step with the BL602 as a PoC platform, if you agree.  Let's find out how the Quad-SPI interface on the BL602 actually works, how is it used on the software side, and if there any limitations to the total size of the SPI flash that can be connected that way.  Sounds like a plan?

I think creating a hat for this device already means that Pine are manufacturing half of the prototype for us. It also means we could then swap out the BL602 at a later date and make it a hat for another device.

Agreed.  So, let's move forward and get the answers to the questions above, if you agree.

I'm unable to find the link to the library you've mentioned above in any of your recent posts...  Could you, please, post that link again?

https://github.com/hathach/tinyusb

Woo-hoo, nice find!  The STM32 H7, which we already discussed about, is on the list of supported microcontrollers!

It looks very interesting for sure, but I also have concerns about how much firmware customization can be done. For example, we would probably have to sign an NDA just to get the documentation (just from the fact I cannot find it online) and we would be bound to a specific closed-source compiler to get their "special instructions". In any case, it will be a massive reverse-engineering undertaking. This is exactly what we're trying to get away from.

The controller is towards what we are trying to create, but it's just not aligned with how we want to get there.

In other words, we'd probably end up with just another closed storage device that only promises to do something, which is not what we want to make.

[barray]

What the hell is up with the notifications? Sorry for the late reply.

Agreed.  So, let's move forward and get the answers to the questions above, if you agree.

Yep. Perhaps you can hang out in IRC? https://kiwiirc.com/nextclient/coffeespa...#pineflash

An update on my behalf is that my side project that makes use of auto-generated schematics, connections and routing has been successful. We should be able to utilize this for our project.

Woo-hoo, nice find!  The STM32 H7, which we already discussed about, is on the list of supported microcontrollers!

Yeah it seems like a nice project - in theory it should already do most of the things we are looking for

In other words, we'd probably end up with just another closed storage device that only promises to do something, which is not what we want to make.

Exactly.

[dsimic]

What the hell is up with the notifications? Sorry for the late reply.

No worries.  Forum notifications don't always work as expected.

Yep. Perhaps you can hang out in IRC? https://kiwiirc.com/nextclient/coffeespa...#pineflash

I might come over from time to time.

An update on my behalf is that my side project that makes use of auto-generated schematics, connections and routing has been successful. We should be able to utilize this for our project.

Sounds good.  Another reusable component, so to speak.

Woo-hoo, nice find!  The STM32 H7, which we already discussed about, is on the list of supported microcontrollers!

Yeah it seems like a nice project - in theory it should already do most of the things we are looking for

We just need to research a bit more about the target microcontroller.