←back to thread

90 points LorenDB | 4 comments | | HN request time: 0s | source
Show context
lfmunoz4 ◴[] No.42177184[source]
I first I thought this was a regular storage microSD with an FPGA that allows you change the data live as as it is saved or something. But seems to be an fpga that has microSD connection with no real storage capability like you would have in a reguar microSD (other than storage for fpga bitstream), i.e it is not storage device use case. But why microSD? Is it just because you can load the bitstream without having to use uart or jtag?

"The Signaloid C0-microSD has two main use cases: You can either (1) use it as a hot-pluggable FPGA module, or (2) use it as a hot-pluggable Signaloid C0 RISC-V co-processor module."

That is not really a use case. Use case usually gives examples of how they are used in production, i.e, more specific about applications.

replies(1): >>42177230 #
yjftsjthsd-h ◴[] No.42177230[source]
The SD Card interface spec includes general-purpose IO in the form of https://en.wikipedia.org/wiki/SD_card#SDIO_cards , which has been used for plenty of things that aren't storage. As to why you'd use it here - I assume the appeal is that if you have a SD slot on your computer (which is quite common) then you can plug this in and use it with no additional hardware at all.
replies(1): >>42177357 #
1. lfmunoz4 ◴[] No.42177357[source]
If I buy it and plug into my computer, I guess my computer will see it as a storage device. If I send it a picture, does it overwrite the fpga bitstream? Do I have write custom drivers so that it does something useful?
replies(1): >>42177672 #
2. yjftsjthsd-h ◴[] No.42177672[source]
I would not expect it to show up as a storage device, no; the point of SDIO is that the SD slot is generic like a USB port. You would need software that can use the device you've plugged in just like if you plugged in a separate FPGA programmer.
replies(2): >>42177917 #>>42180482 #
3. whizzter ◴[] No.42177917[source]
I used a Gameboy Flash card that showed up as a blockdevice that was formatted FAT device, writing/overwriting a file upon it will overwrite the flash and inserting it to the Gameboy would then start it.

I suspect that there was some transation firmware that acted as the blockdevice and routed data to the flash as the "file" was written by the computer, it was a pretty clever and frankly painless way of updating since there was nothing beyond connecting, copying and flipping back.

Yes, in the long run you want something directly USB connected (preferably with a debugger) but as for having a no-hassle setup this was quite neat.

And considering that many of the first generation of Gameboy flash-devices had been tied to dodgy paralell-port flash protocols that were hardcoded to even dodgier win95 era flashing programs that required full HW access(and not working well on winNT based systems not to mention osX or Linux) I think a bit of the thinking for this was to future-proof the device by just basing it on some standard block-device technology like SD cards or UMass that was unlikely to become unsupported.

4. amsaltman ◴[] No.42180482[source]
My understanding of the docs is that the device does indeed implement the SD storage protocol and not SD I/O subset.

Their docs say it shows up as an unformatted 20MB disk when you plug it in and that you can interact with the device via `dd`: https://c0-microsd-docs.signaloid.io/