But not yet confident. I've found a second SD card, of eight now, that's not entirely happy. This one works when I enable the block logging though.
I used to have a bunch of full-sized SD cards too, but haven't found even one of those. I suspect I threw them all out a long time ago because they probably all got smashed. I remember sitting on some and cracking the thin PCB material.
@evanh said:
Whoa! I found a bug (Every second join became disjointed) that was slowing it down still. And I've got writes working with lazy CMD12 too! Don't need no big buffers any longer. Fast recording here we come.
Wow that's what I want to see! These sorts of speeds will let me get back to the HDMI capture stuff I started a while back. I'd sort of assumed we'd hit a fundamental limit somewhere but didn't know why.
@evanh said:
Certainly is. I hadn't imagined such a big jump.
But not yet confident. I've found a second SD card, of eight now, that's not entirely happy. This one works when I enable the block logging though.
I used to have a bunch of full-sized SD cards too, but haven't found even one of those. I suspect I threw them all out a long time ago because they probably all got smashed. I remember sitting on some and cracking the thin PCB material.
Keep at it. You'll probably figure out what the real limitation is there eventually and what feature the card needs to be able to do what we want.
The scope is at work at the moment. I'm unsure what I'll be able to see but I need some inspiration at least, or just plain insight into what's actually occurring. The fact that the newer cards seem happy might be telling.
Uh-oh again, I've messed something up along the way. None of the cards work using portA now. There must be a typo or something similar. I don't know how far back this occurred, since the stable v1.2 release, because I've been using pin base of 40 all this time.
PS: Hehe, I just double checked v1.2 to be sure it's okay. No problem there.
The good news is that just by verbatim copying the two disk_read()/disk_write() functions from v1.2 everything returns to normal. So all my problems appear to be contained inside those two - Which is of course where 99% of the edits have occurred.
PS: The new code structure makes the two of them act as one unit. They share state tracking of where CMD12 next needs to be issued. They look identical at first glance. Just a couple of differences like CMD18 for reads vs CMD25 for writes. CMD17 and CMD24 have been removed. In fact, if I get this to work cleanly, I think I'll be making them one function with two hooks for FS handler.
Err, I guess it would need two wrapper functions to specify read vs write. Direct hooks won't provided that. I'll test it out before deciding.
Huh, found a weakness in tx_datablock() low level routine where it was failing to report unknown errors with debugging enabled. Something odd is happening with the card's CRC response. Definitely want to get the scope on to it now.
Comments
Uh-oh, one of my seven SD cards doesn't like it ... getting a busy timeout following the first write ...
It's happy with the older v1.2 driver, so can't blame the card.
IIRC while the write is ongoing, the result isn't guaranteed to be flushed, so you might need to plumb through the flushing from the FS layer.
Yup, my updated CTRL_SYNC ioctl() issues a CMD12 and then waits on card busy before returning. An fclose() on an open write generates this sync.
@evanh That's pretty awesome speeds there!
Certainly is. I hadn't imagined such a big jump.
But not yet confident. I've found a second SD card, of eight now, that's not entirely happy. This one works when I enable the block logging though.
I used to have a bunch of full-sized SD cards too, but haven't found even one of those. I suspect I threw them all out a long time ago because they probably all got smashed. I remember sitting on some and cracking the thin PCB material.
Wow that's what I want to see! These sorts of speeds will let me get back to the HDMI capture stuff I started a while back. I'd sort of assumed we'd hit a fundamental limit somewhere but didn't know why.
Keep at it. You'll probably figure out what the real limitation is there eventually and what feature the card needs to be able to do what we want.
Appreciated, thanks.
The scope is at work at the moment. I'm unsure what I'll be able to see but I need some inspiration at least, or just plain insight into what's actually occurring. The fact that the newer cards seem happy might be telling.
Uh-oh again, I've messed something up along the way. None of the cards work using portA now. There must be a typo or something similar. I don't know how far back this occurred, since the stable v1.2 release, because I've been using pin base of 40 all this time.
PS: Hehe, I just double checked v1.2 to be sure it's okay. No problem there.
One step forward two steps back
The good news is that just by verbatim copying the two disk_read()/disk_write() functions from v1.2 everything returns to normal. So all my problems appear to be contained inside those two - Which is of course where 99% of the edits have occurred.
PS: The new code structure makes the two of them act as one unit. They share state tracking of where CMD12 next needs to be issued. They look identical at first glance. Just a couple of differences like CMD18 for reads vs CMD25 for writes. CMD17 and CMD24 have been removed. In fact, if I get this to work cleanly, I think I'll be making them one function with two hooks for FS handler.
Err, I guess it would need two wrapper functions to specify read vs write. Direct hooks won't provided that. I'll test it out before deciding.
Huh, found a weakness in tx_datablock() low level routine where it was failing to report unknown errors with debugging enabled. Something odd is happening with the card's CRC response. Definitely want to get the scope on to it now.