@rogloh said:
You'll have to start to overclock this now and see what speeds you can hit without series resistors fitted etc.
I'll just be happy if it doesn't go to custard. My oldest uSD card shows signs of weaker drive strength than the other cards. The rxlag mapping for it fades into oblivion above 360 MHz sysclock on the worst case intersect of pin modes - Which was primarily having both clock and data pins registered together. It didn't matter what the clock divider was, oddly.
@rogloh said:
You'll have to start to overclock this now and see what speeds you can hit without series resistors fitted etc.
I'll just be happy if it doesn't go to custard. My oldest uSD card shows signs of weaker drive strength than the other cards. The rxlag mapping for it fades into oblivion above 360 MHz sysclock on the worst case intersect of pin modes - Which was primarily having both clock and data pins registered together. It didn't matter what the clock divider was, oddly.
I was thinking of Rayman's board without the resistors. IIRC I've had your board transferring nibbles at 175MHz or so - recorded in this thread somewhere early on when I was messing with it.
That's what I should do. Rewrite the mapper to use the C file API instead of the currently built-in block direct SD mode. Can then write a file that doesn't corrupt the filesystem on the card.
Tempting to add more parameters to the driver init so it can runtime reconfigure the pin modes when mounting. I've already made the clock divider a parameter ...
Wow, it wouldn't be hard either. The only compiled enum that would pose any difficulty would be CLK_POL. It has one occurrence embedded in tx_datablock() that would add a ninth entry to the r_params in cogRAM. All the others could effortlessly become dynamic without incurring overhead beyond a little extra config code during init and calibration.
Those r_params have made the Fcached code a lot less cumbersome. Fetching the components and computing each parameter for every command, then every response, then every block, one by one, was so wasteful on a repeating basis.
At the top of the driver source file there is this entry:
This creates a tidy compile-time allocation of cogRAM that I place persistent data in that is independent of Fcache use. They're just like the PRx register set that are publicly allotted for user programs to use as desired. In fact there is still a compile option for using the PRs instead of the r_params.
There is a way in HW using a smartpin mode (PWM SMPS) where you can influence the output state from an adjacent pin so if you want to have the CMD or CLK or CS pin control a LED automatically you can. This PWM SMPS is the only known smartpin mode that can do this.
@Rayman said:
Some pretty amazing speeds with P2 at 300 MHz and SD at 100 MHz with same industrial card:
Buffer = 256 kB, Written 16384 kB at 9540 kB/s, Verified, Read 16384 kB at 28461 kB/s
Buffer = 256 kB, Written 16384 kB at 9096 kB/s, Verified, Read 16384 kB at 28403 kB/s
Buffer = 256 kB, Written 16384 kB at 9087 kB/s, Verified, Read 16384 kB at 28449 kB/s
Buffer = 256 kB, Written 16384 kB at 9048 kB/s, Verified, Read 16384 kB at 28341 kB/s
Yeah 4 bit IO for SD is pretty neat isn't it. The resistors are helpful for high speed.
We just need to figure out some ways to try to best leverage it with the filesystem and a P2 otherwise we lose much of the advantages of this. I'd like to be able to use it to stream uncompressed SDTV resolution video off a card and at the raw rates it offers it seems to show some promise there.
@Rayman said:
Was thinking of direct connection…
Blue led with big resistor should have little effect…
One nice thing I found about the LED being software controlled is the driver can limit its activity status to just data blocks. All the housekeeping/polling commands and responses can be invisible. It definitely makes the LED more lively looking. Otherwise it tends to look solid for the duration.
@Rayman said:
Or maybe spi mode should have power cycling option added?
Easy enough to add to the driver but it requires everyone to have the hardware. Which includes using an extra I/O pin. I can understand Chip thinking it was unnecessary. And now Parallax has shipped lots of the SPI solutions that don't have the hardware.
@Rayman said:
Same card without the series resistors or pullups still works:
The lower measured performance, for a given clock rate, will be because of the missing pull-ups alone. The series resistors are not going to impact the measured performance other than potentially get errors.
Comments
You'll have to start to overclock this now and see what speeds you can hit without series resistors fitted etc.
Excellent. Good to see. Hurdle crossed.
I'll just be happy if it doesn't go to custard. My oldest uSD card shows signs of weaker drive strength than the other cards. The rxlag mapping for it fades into oblivion above 360 MHz sysclock on the worst case intersect of pin modes - Which was primarily having both clock and data pins registered together. It didn't matter what the clock divider was, oddly.
I was thinking of Rayman's board without the resistors. IIRC I've had your board transferring nibbles at 175MHz or so - recorded in this thread somewhere early on when I was messing with it.
That's what I should do. Rewrite the mapper to use the C file API instead of the currently built-in block direct SD mode. Can then write a file that doesn't corrupt the filesystem on the card.
Tempting to add more parameters to the driver init so it can runtime reconfigure the pin modes when mounting. I've already made the clock divider a parameter ...
Wow, it wouldn't be hard either. The only compiled enum that would pose any difficulty would be CLK_POL. It has one occurrence embedded in tx_datablock() that would add a ninth entry to the r_params in cogRAM. All the others could effortlessly become dynamic without incurring overhead beyond a little extra config code during init and calibration.
Those r_params have made the Fcached code a lot less cumbersome. Fetching the components and computing each parameter for every command, then every response, then every block, one by one, was so wasteful on a repeating basis.
At the top of the driver source file there is this entry:
extern register uint32_t *r_param1, *r_param2, *r_param3, *r_param4, *r_param5, *r_param6, *r_param7, *r_param8;This creates a tidy compile-time allocation of cogRAM that I place persistent data in that is independent of Fcache use. They're just like the PRx register set that are publicly allotted for user programs to use as desired. In fact there is still a compile option for using the PRs instead of the r_params.
@evanh wondering if the power cycling code should be somewhere else or an option…
Wouldn’t it be nicer to use either spi or sd modes the same way?
Is power cycling absolutely required here?
Or maybe spi mode should have power cycling option added?
Also, do you see an easy way to add activity led?
Thinking about led on either cs or clk signals…
There is a way in HW using a smartpin mode (PWM SMPS) where you can influence the output state from an adjacent pin so if you want to have the CMD or CLK or CS pin control a LED automatically you can. This PWM SMPS is the only known smartpin mode that can do this.
Back in this post there are details of this:
https://forums.parallax.com/discussion/comment/1545310/#Comment_1545310
Was thinking of direct connection…
Blue led with big resistor should have little effect…
What is up with the clock divider? Should it be fixed at 4 or 3 ?
Or, is it something to play with?
Same card without the series resistors or pullups still works:
But, seems the mosfet switch is required...
Looks like resistors needed at 300 MHz P2, 75 MHz SD though...
Getting good results with resistors though:
That was a 32GB PNY "Elite" card.
A Sandisk 8GB Industrial card is a bit slower:
Some pretty amazing speeds with P2 at 300 MHz and SD at 100 MHz with same industrial card:
Feeling the need to design a new p2 board with this onboard …
Yeah 4 bit IO for SD is pretty neat isn't it. The resistors are helpful for high speed.
We just need to figure out some ways to try to best leverage it with the filesystem and a P2 otherwise we lose much of the advantages of this. I'd like to be able to use it to stream uncompressed SDTV resolution video off a card and at the raw rates it offers it seems to show some promise there.
PNY 32GB @100 MHz looks good with the series resistors removed:
I've got two identical looking industrial 8 GB cards, bought as part of a 5 pack.
One of them is faster at writing than the other...
Not sure how that is..
It could certainly be made optional. It compiles to 76 instructions (304 bytes). How wise not using it is, is another question.
Both freshly formatted?
Have you had any errors because of speed, with or without the resistors?
One nice thing I found about the LED being software controlled is the driver can limit its activity status to just data blocks. All the housekeeping/polling commands and responses can be invisible. It definitely makes the LED more lively looking. Otherwise it tends to look solid for the duration.
Easy enough to add to the driver but it requires everyone to have the hardware. Which includes using an extra I/O pin. I can understand Chip thinking it was unnecessary. And now Parallax has shipped lots of the SPI solutions that don't have the hardware.
Not settled. Something to play with. There is, at least, potential for using sysclock/2 for super fast reads with CRC processing disabled.
The lower measured performance, for a given clock rate, will be because of the missing pull-ups alone. The series resistors are not going to impact the measured performance other than potentially get errors.
Not seen any errors at all since fixing command line with pull-ups
Good.
I found a bug in the speed tester's file verify routine. If it aborts early, from a read error, then that makes it more likely to pass the test.
PS: I've not had any read errors. I just noticed the bug when reusing the code for the rxlag mapper program.
Fixed version attached.
Just thinking about the pull-up situation …
Can we not turn off p2 internal pull-ups during power cycle and then turn on after?
Not a big deal just curious…