Product Idea: USB Flash Drives

[barray]

Unfortunately, that multiplication doesn't apply.   According to the feature list in the BL602 datasheet, the 40 Mbit/s limit applies to the general-purpose SPI interface that the SPI-to-USB bridge would be connected to.  Thus, whatever happens inside the storage device cannot leave it faster than about 4 MB/s, which is slow.  The datasheet actually provides no information about the maximum speed of the quad-SPI flash interface, but the general-purpose SPI already presents a bottleneck.

In theory it could still be connected to the QSPI bus if it's not attached to a DMA buffer or we dynamically allocate DMA buffers to QSPI devices? If re-mapping DMA is fast then this shouldn't be so bad. (This assumes that my four SPI device limit is based on the number of DMA buffers.)

Also if we are running memory mirroring, we could perhaps write to two devices at the same time. The data lines should look identical anyway (it might get complicated if we get bad blocks, but we can cross that bridge later). This would reduce the number of "unique" QSPI devices and increase throughput.

I agree on the risk, with all that requiring a lot of work, and with many things still unknown.  The BL602 "baseboard" might be very well used as a stepping stone, with a clear intention to upgrade to a better "baseboard" down the road.  However, my primary concern is that a lot of work would be poured into creating a storage device that would hardly be much more than a proof of concept, so it might be good to plot a clear path for the "baseboard" upgrade from the beginning.

Well we would eventually want to move towards a single PCB anyway, so perhaps once everything else is working then we can move to a faster board. I still believe there are options to squeeze more speed out of the device though as mentioned above.

I believe a new baseboard would be something much more within Pine64's remit as they will have some internal vision with roadmaps that consider the larger picture, including production.

I also think it's worth seeing what comes of this RISC-V SBC (PineOne?) in a few months as we learn more, it might be too overpowered or just right.

Please, don't get me wrong.  Crafting an open storage device that's built using open-source tools and provides about 4 MB/s through its USB interface is no small feat and I'd be happy to see it ticking.  However, I'm pretty sure that not many other people would share the excitement about those 4 MB/s.

Maybe, but I think such a hat could make the BL602 into some cool projects even at such a low speed, like an MP3 player or micro-server for static files, for example. Or the memory could be used for storing video for some CCTV like IoT device in a circular buffer. I'm sure having a lot of memory attached to such a device could already be interesting, even if the transfer is slow via USB.

[dsimic]

In theory it could still be connected to the QSPI bus if it's not attached to a DMA buffer or we dynamically allocate DMA buffers to QSPI devices? If re-mapping DMA is fast then this shouldn't be so bad. (This assumes that my four SPI device limit is based on the number of DMA buffers.)

Also if we are running memory mirroring, we could perhaps write to two devices at the same time. The data lines should look identical anyway (it might get complicated if we get bad blocks, but we can cross that bridge later). This would reduce the number of "unique" QSPI devices and increase throughput.

All that could be doable, but it all depends on the way quad-SPI IP core actually works and presents itself.  More information should be available from the publicly available source code; I guess it's time to dig into it.

Well we would eventually want to move towards a single PCB anyway, so perhaps once everything else is working then we can move to a faster board. I still believe there are options to squeeze more speed out of the device though as mentioned above.

I believe a new baseboard would be something much more within Pine64's remit as they will have some internal vision with roadmaps that consider the larger picture, including production.

I also think it's worth seeing what comes of this RISC-V SBC (PineOne?) in a few months as we learn more, it might be too overpowered or just right.

I would like to see Pine64 onboard this project/initiative, but for some reason they remain silent to the community inquiries, as we've already discussed.  Regarding the new RISC-V SBC, the whole thing sounds really good; it should bring "full-fledged" RISC-V to the masses.

Maybe, but I think such a hat could make the BL602 into some cool projects even at such a low speed, like an MP3 player or micro-server for static files, for example. Or the memory could be used for storing video for some CCTV like IoT device in a circular buffer. I'm sure having a lot of memory attached to such a device could already be interesting, even if the transfer is slow via USB.

I hope you're right and there are more people sharing the vision and excitement.  For example, it could also be used as a WiFi wardriving device or a WiFi IDS sensor capable of storing packet dumps locally.

[barray]

All that could be doable, but it all depends on the way quad-SPI IP core actually works and presents itself.  More information should be available from the publicly available source code; I guess it's time to dig into it.

For sure - and I suppose we may be the first people to even try to do such a thing, despite what is written in the source. Bare in mind the BL602 is a very new device. In theory though, even if the DMA buffers cannot be remapped, we can enable any chip we like. I can't see how such a thing can be prevented.

I would like to see Pine64 onboard this project/initiative, but for some reason they remain silent to the community inquiries, as we've already discussed.  Regarding the new RISC-V SBC, the whole thing sounds really good; it should bring "full-fledged" RISC-V to the masses.

100%. Before pouring time and effort into this, I really want to hear from them. There's zero point in us guessing at what the bigger picture may be, maybe Pine64 has zero interest in such things. We just don't know.

I hope you're right and there are more people sharing the vision and excitement.  For example, it could also be used as a WiFi wardriving device or a WiFi IDS sensor capable of storing packet dumps locally.

Basically anything that could involve connectivity and reliable/secure storage. And this is just an immediate outcome of having a slow storage device - when it speeds up we could have even more exciting potential projects.

[dsimic]

For sure - and I suppose we may be the first people to even try to do such a thing, despite what is written in the source. Bare in mind the BL602 is a very new device. In theory though, even if the DMA buffers cannot be remapped, we can enable any chip we like. I can't see how such a thing can be prevented.

Basically, it should be up to enabling the right CS (chip select) line, which should equal to using the right SPI lane.  However, it all depends on the way quad-SPI IP core is designed, which we simply don't know.  One of my concerns is that no additional documentation about the BL602 will be available, but the publicly availlable source code should provide the means to fill the gap.

100%. Before pouring time and effort into this, I really want to hear from them. There's zero point in us guessing at what the bigger picture may be, maybe Pine64 has zero interest in such things. We just don't know.

How do we contact Pine64?  All my recent attemps have failed, which included email messages, forum private messages, and pings in forum posts.  They have even remained silent to a thread like this, which is very concerning; why should they ignore an opportunity to improve one of their flagship products?

Also, please keep in mind that I might be able to produce a small batch of devices, once the pandemic is over, but that would need to be a device that people would actually want to buy.  It is good that the BL602 IC is available for purchase separately in the Pine Store, which makes it possible to include it into the BOM.

Basically anything that could involve connectivity and reliable/secure storage. And this is just an immediate outcome of having a slow storage device - when it speeds up we could have even more exciting potential projects.

I agree, there are many uses for such a device.

[barray]

Basically, it should be up to enabling the right CS (chip select) line, which should equal to using the right SPI lane.  However, it all depends on the way quad-SPI IP core is designed, which we simply don't know.  One of my concerns is that no additional documentation about the BL602 will be available, but the publicly availlable source code should provide the means to fill the gap.

As long as the quad SPI works (which I'm sure it does), we will be able to find some solution. QSPI is quite common for anything that wants to talk SPI (comparitively) fast. I know for example in the automotive industry they rely on this quite bit.

How do we contact Pine64?  All my recent attemps have failed, which included email messages, forum private messages, and pings in forum posts.  They have even remained silent to a thread like this, which is very concerning; why should they ignore an opportunity to improve one of their flagship products?

No idea, I think dedicating half hour or so a day to keep an eye on the forum would be manageable.

One thing I was hoping is that we could get a forum section or something, perhaps under "Community Projects" or "Unofficial" or "Prototypes". I did have a quick look last night as well at the possibility of hosting some basic forum too - but I really hate setting up PHP.

Also, please keep in mind that I might be able to produce a small batch of devices, once the pandemic is over, but that would need to be a device that people would actually want to buy.  It is good that the BL602 IC is available for purchase separately in the Pine Store, which makes it possible to include it into the BOM.

How many is a small batch? Also there are pick and place services for common parts, such as those offered by JLPCB. We'd likely need some way to take pre-orders though to judge quantity, and then there's the shipping... And depending on how many you are speaking about creating in a small batch, it could be quite a work-intensive undertaking.

We'd probably need pick and place down the line anyway, as those larger flash chips are quite fine pitch and even quite often have pads/balls underneath that require some oven process.

[dsimic]

How many is a small batch? Also there are pick and place services for common parts, such as those offered by JLPCB. We'd likely need some way to take pre-orders though to judge quantity, and then there's the shipping... And depending on how many you are speaking about creating in a small batch, it could be quite a work-intensive undertaking.

We'd probably need pick and place down the line anyway, as those larger flash chips are quite fine pitch and even quite often have pads/balls underneath that require some oven process.

How many?  A rough estimate for a manageable batch size would be anywhere between 100 and 500.  Component pricing also plays an important role when planning the size of a batch, simply because buying some components in very low quantities results in absurdly high prices.

I've already planned to start making and selling another open-hardware device, but the pandemic threw a wrench into the whole thing.  My intentions were/are to buy a small reflow oven, and do the component placement by hand.  I know, it's far from ideal because of a lot of work involved, but it should suffice for the first few batches.  If the whole thing ramps up, there are somewhat affordable small pick-and-place machines available for purchase.

Regarding the shipping costs, international shipping rates are rather low in my country, and the delivery is reliable despite the low rates.  However, all that can happen only after the pandemic is over.

[barray]

How many?  A rough estimate for a manageable batch size would be anywhere between 100 and 500.  Component pricing also plays an important role when planning the size of a batch, simply because buying some components in very low quantities results in absurdly high prices.

That's nothing to sneeze at, that's probably comparable to what Pine64 does on some of these devices - especially a prototype/early adopter.

I've already planned to start making and selling another open-hardware device, but the pandemic threw a wrench into the whole thing.  My intentions were/are to buy a small reflow oven, and do the component placement by hand.  I know, it's far from ideal because of a lot of work involved, but it should suffice for the first few batches.  If the whole thing ramps up, there are somewhat affordable small pick-and-place machines available for purchase.

Awesome, do you have some details on that project? Just to warn you, these cheap pick and place machines tend not to be some great, so be sure to check it out first!

Regarding the shipping costs, international shipping rates are rather low in my country, and the delivery is reliable despite the low rates.  However, all that can happen only after the pandemic is over.

Awesome, sounds perfect then.

[dsimic]

That's nothing to sneeze at, that's probably comparable to what Pine64 does on some of these devices - especially a prototype/early adopter.

The only, small difference is that Pine64 surely doesn't use fine-tip tweezers to perform component placement manually.

Awesome, do you have some details on that project? Just to warn you, these cheap pick and place machines tend not to be some great, so be sure to check it out first!

I would prefer not to disclose more details publicly, at this moment, although there's actually nothing to hide.

You're right about the cheap pick-and-place machines, they are usually not of high quality, and most of them either do not support high density of components, or cannot handle bigger components.  However, I'd consider buying one only if the sales volume outgrows the "handmade" production, which would be a good problem to have.

By the way, my primary goal is not to make a lot of money.  Sure, some money has to be made in order to keep the whole operation afloat, but my primary motivation is to make open devices available to anyone interested in buying, using and tweaking such devices.

[barray]

The only, small difference is that Pine64 surely doesn't use fine-tip tweezers to perform component placement manually.

Ha! I'm sure some of the production is still more manual than you would hope, especially given the production numbers we're talking about...

I would prefer not to disclose more details publicly, at this moment, although there's actually nothing to hide.

(Confused Pikachu face) Okay, will be interested when you have more details to reveal

You're right about the cheap pick-and-place machines, they are usually not of high quality, and most of them either do not support high density of components, or cannot handle bigger components.  However, I'd consider buying one only if the sales volume outgrows the "handmade" production, which would be a good problem to have.

I think offloading this problem to somebody like JLPCB is quite viable anyway, especially if you source the parts and send them to them - it could end up being quite low cost too. I suppose the only time it's not such a great option is when you are working on something you are trying to keep under-wraps, like a commercial project.

By the way, my primary goal is not to make a lot of money.  Sure, some money has to be made in order to keep the whole operation afloat, but my primary motivation is to make open devices available to anyone interested in buying, using and tweaking such devices.

I think you should actually look to make some money anyway, even if it just sits in a pot. You're going to need some float cash to expand operations and deal with random crap, like parcels going missing or things like this.

Speaking of which, it's quite likely we could setup a Tindie page to deal with buy/sell, hopefully they support backorder on there.

In other news, some interesting numbers for eMMc vs SD in the PienPhone (and likely all other A64 devices): https://xnux.eu/log/#032 In theory we just need to beat these numbers in order for our solution to be viable, which seems quite possible.

[LazLong]

Go Open Source! Flash drives are just another black box nearly everyone has to use on a regular basis.

Enjoying your spitballing and hope it evolves into a successful product.

Feature request if practical: Pass-thru USB functionality maybe with USB condom features would be great for port challenged devices.