* ZipCPU
smiles smugly, enjoying the feeling that he knows everything. He then turns to his own project and the feeling gets crushed. ;)
<shapr>
or do other companies make grove connector stuff?
<ZipCPU>
I think I saw a grove connector from xess.com
<shapr>
ZipCPU: any recommended general purpose pmod accessories?
<shapr>
like, what should I buy that I'm likely to use?
<ZipCPU>
Hmm ...
<ZipCPU>
I like the audio PWM output, and I use my GPS and UART pmods all over the place
<ZipCPU>
I love the LED8 pmod for difficult debugging on a device without enough LEDs
<ZipCPU>
I have the MEMs microphone, but despite writing code for it I've never actually fired it up.
zino has joined #yosys
<shapr>
near unto too many pmod boards on this site
<gruetzkopf>
led pmod is very useful
<gruetzkopf>
so is a microsd one for certain applications
X-Scale has joined #yosys
<ZipCPU>
I've got the SD card Pmod --- it just requires so much logic to get it going that ... I haven't done that much with it.
<ZipCPU>
I managed to get it to the point where I could read or write sectors on the SD card, just not far enough to get past the file system so as to be able to read and write files.
<cr1901>
FAT file system support in FPGA logic alone seems ambitious
<shapr>
I got four pmods for starting with the beaglewire, thanks for the advice!
<shapr>
mic, seven segment, stereo input and output, and wire terminal connectors
<shapr>
I may order more once I've had time to see how much the beaglewire can use the beaglebone
<sorear>
Dunno, seems simpler than tcp+ip+ssh
<ZipCPU>
cr1901: Not in FPGA logic alone. In software. I've since found a library I can use, I just haven't tried it.
<ZipCPU>
shapr: I've looked at the I2S controller for stereo I/O, I've written an I2S interface, but ... just haven't figured out how to configure the rest of the chip for success.
<ZipCPU>
The PWM output was just too easy to use.
cemerick_ has quit [Ping timeout: 244 seconds]
<cr1901>
sorear: From what the creator of ssh himself says, a ssh impl can be done in 1000-2000 lines if you have a good crypto lib
<cr1901>
(source: Twitter search from:tjssh to:cr1901 b/c I'm too lazy to grab it)
<sorear>
so can fat
<sorear>
reminder: azonenberg wants to do ssh entirely in logic
gruetzkopf has quit [Read error: Connection reset by peer]
<cr1901>
Yea I know.
gruetzkopf has joined #yosys
gruetzkopf has quit [Read error: Connection reset by peer]
gruetzkopf has joined #yosys
<cr1901>
Both ssh and fat seem bad, tbh... have to do parsing (even if it's simple) in the FPGA
<cr1901>
And well, I hate parsing period
<cr1901>
With a FAT core, you'd need some way to keep track of currently open files. Perhaps a harcoded limit of "2^n files open", and send an ID to the core for which file you want to manipulate
<sorear>
ew
* sorear
does not like Unix open file semantics
<cr1901>
This isn't really Unix specific? Need some way to keep track of open files. An integer seems easiest and most efficient.
AlexDaniel has joined #yosys
AlexDaniel has quit [Remote host closed the connection]
AlexDaniel has joined #yosys
seldridge has joined #yosys
mjoldfie_ has quit [Read error: Connection reset by peer]
mjoldfield has joined #yosys
fsasm has quit [Remote host closed the connection]
fsasm has joined #yosys
<qu1j0t3>
What Would BASIC Do!
mjoldfield has quit [Read error: Connection reset by peer]
mjoldfield has joined #yosys
cemerick_ has joined #yosys
cemerick has joined #yosys
maikmerten has joined #yosys
cemerick_ has quit [Ping timeout: 268 seconds]
pie_ has quit [Ping timeout: 244 seconds]
seldridge has quit [Ping timeout: 256 seconds]
seldridge has joined #yosys
fsasm has quit [Ping timeout: 245 seconds]
AlexDaniel has quit [Read error: Connection reset by peer]
AlexDaniel has joined #yosys
<awygle>
FatFs is Good when it comes to embedded FAT libraries
<awygle>
i feel like FAT isn't bad for FPGAs tbh
<awygle>
provided you can impose some common-sense restrictions
FL4SHK has joined #yosys
<awygle>
actually the more i think about it the more i'm surprised there isn't already an hdl fat ip core
<awygle>
doesn't the tinyfpga ex have an sd card on it? might be a good platform to develop one, plenty of room for logic
<ZipCPU>
Yes, it does, and I'm looking forward to getting one once it becomes available.
<daveshah>
Yes HyperRAM is also useful for those kind of situations
<awygle>
daveshah: why is that? i don't immediately see the relevance
<daveshah>
As a nice buffer or memory for a processor
<awygle>
ah, i'm thinking of a non-processor approach
<awygle>
more in the sense of streaming file processing rather than random-access
<daveshah>
I think quite a few applications that involve realtime processing without a processor will need a fair buffer
<daveshah>
I wouldn't trust realtime determinism of sd cards
<awygle>
hm yeah okay. it's hard to really discuss without a specific use case. but the basic "gimme a file a byte at a time" IP core i'm talking about would at least be a prereq for anything else.
<knielsen>
Hm, I actually wrote (in C) a FAT (readonly) library that is fully event-driven and uses constant space. I wonder if that would translate more or less directly into RTL with simple req/ack interface
<awygle>
i did something similar except it was OLE and not FAT. but OLE is just "FAT inside a file" so same difference, mostly
<knielsen>
Oh, it is? Hm...
<TD-Linux>
I once wrote a realtime SD datalogger on a device with less than 512 bytes of RAM
<TD-Linux>
you have to write a sector at a time, I just wrote it slowly :)
<knielsen>
yes, in fact the SD-card specification explicitly says that you are allowed to access slowly and pause during a sector access, to make sure small systems with < 512 bytes of buffering can work
<TD-Linux>
but actually doing FAT with that would be pretty inefficient, you would constantly need to reread the FAT tables
<knielsen>
but it's not just the FAT layer, one also would need to implement the SD-card layer, initialising and setting speed and so on
<awygle>
idk the SD spec very well but if it's anything like eMMC then almost everything is host-controlled as far as timing
<sorear>
you can do random access to the FAT
<TD-Linux>
the SD card layer is pretty easy to do with a simple state machine
<sorear>
you could also have like, 16 bytes of look-ahead storage so that reading an unfragmented file only has to hit the FAT for every 4th cluster
<awygle>
yeah the area-vs-speed tradeoff is very clear here
<awygle>
for an ice40 you can do the extremely slow thing, for an ecp5 or bigger you can add caching pretty trivially
<knielsen>
I guess most cards you can buy these days are so big that a cluster is >> one 512 byte FAT read?
<awygle>
fat12 and fat16 both use 64 KiB clusters iirc
<sorear>
the cluster size is variable
<awygle>
yeah i meant the max size
<awygle>
my bad
<sorear>
fat32 gives you 2^28 clusters, total, I think the baseline size is a few kB
<sorear>
fat12 is used on floppies, fat16 was DOS-era hard disks, i haven't personally seen anything formatted for windows not fat32 or later
<awygle>
fat32 has max cluster size 16kb it looks like
<awygle>
i might use fat16 for something intended to be read/written on an fpga
<awygle>
iirc windows can still read it
<awygle>
i don't know anything about exFAT but it seems to have a 128KB max cluster size
<sorear>
afaik exFAT is much more complicated, also microsoft is actively doing software patents on anything that supports it
<knielsen>
Apparently default cluster size is 4KB for >= 256 MB capacity, so even there a FAT read per cluster is not too much overhead (12.5%)
<knielsen>
Hm, my old FAT read code really looks like a simple state machine, not even any loops except constant iterations over 8+3 filenames
<knielsen>
Would actually be interesting to see if it translates directly into RTL, or if there is some devil hidden in the details somewhere
<knielsen>
TD-Linux: Do you know of any existing RTL for an SD-card state machine?
<sorear>
writing will of course be *slightly* more of a challenge
<TD-Linux>
I don't.
<knielsen>
TD-Linux: But yes, it's probably rather simple to do, as you said
<TD-Linux>
this might actually be kind of handy for a tinyfpga-style bootloader, but one that uses sd cards instead.
develonepi3 has joined #yosys
<sorear>
do you need a bootloader for a sd card? sd cards can emulate spi flash natively
<awygle>
there's a wishbone sd card controller on opencores
<ZipCPU>
There's a separate protocol needed, though, to handle the SD protocol over SPI.
<sorear>
ZipCPU: my question was about connecting the fpga directly to the sd card spi interface, no cores involved, it either works or doesn't
<ZipCPU>
TD-Linux: Yes.
<daveshah>
imo, if writing an fpga core, might as well use proper mmc mode rather than spi
<ZipCPU>
sorear: I have yet to see an FPGA support such a protocol
<ZipCPU>
That said, a small boot "ROM" in block (ram) could easily boot off of an SD-Card.
<awygle>
but then you still need spi flash to store the bitstream
<ZipCPU>
daveshah: That's on my list. I would've done that originally, only ... the SD-card interface I had only offered SPI control (XuLA2-LX25 from Xess.com)
<TD-Linux>
yeah this seems more useful as a way to rewrite spi flash than a direct bootloader
<ZipCPU>
Daveshah: the interface you are discussing is often called "SDIO". Now that I have hardware supporting it, I'm hoping to build a core for it with nearly the same interface--I just haven't gotten that far yet.
<daveshah>
ZipCPU: sounds fun
<ZipCPU>
:D
<daveshah>
I think the tinyfpga board is fully wired too
* awygle
has that "quit job, do fpgas all day" daydream again
<ZipCPU>
Only thing is ... there's a lot of work to do to do so. You have to build the core, formally verify the core, build the simulator, demonstrate the core in the simulator .... all the good steps of building a (rather complex) core.
<daveshah>
Indeed
<daveshah>
Ended up writing simulation of a small part of the high level sd protocol a few years ago
pie_ has joined #yosys
<daveshah>
As part of an emulator for an obscure SunPlus SoC I never finished
<ZipCPU>
awygle: While I'm now "doing fpgas all day", getting paid kind of requires you do someone else's fpga job all day. :D
<awygle>
ZipCPU: that's why it's a fantasy ;)
fsasm has joined #yosys
<ZipCPU>
I may come back to the SDIO core after I get the ZipCPU running on the TinyFPGA BX
develonepi3 has quit [Remote host closed the connection]