Done. Checked at 360 MHz sysclock with all my SD cards.
PS: Also now checked at 360 MHz sysclock on the Eval Board's built-in SD slot. Still works even with that protective inline resistor slowing things down.
Looking at the error numbers in "FAT32" I see there is no distinction or meaning to individual numbers at the driver level. Any negative return code becomes error1, "Disk IO Error".
As a result, I haven't tried to assign any meaning to the error numbers in the driver.
Have so many copies of speed_test.c, but only latest seems to work, probably messed around too much trying to make work.
Had to add --fcache=256 again. Not sure how that keeps getting turned off...
Had to substitute 0603 1uF for 0402 4.7uF, but pretty sure that's OK...
@Rayman said:
Did you see the cogged version of the 1-bit driver?
I remember seeing it be faster with that...
But, it's been a while since looked at it...
Prop2 can do the driver just fine cog-less. If the filesystem object could make use of concurrency sure add the extra cog then, but that would also burn more RAM both in the buffering requirements and the code bloat managing it.
PS: That's where Command-Queuing becomes useful too. When the filesystem object can make multiple requests and able to work with completion notifications rather than doing everything sequentially. But it is a lot for the code to manage so memory needs blow out.
Rayman,
You've been using a "platform" config file of some sort haven't you? How does that work? Does it get loaded somehow?
I've just added a pin map setting mechanism to the driver init that can be passed through the filesystem handler without it knowing the pins explicitly. I now have a growing table of pinout configs to choose from. It's done as a small DAT set built from larger sets of CONstants at the top of the tester program but it's obviously better if it was separated to be a general selection file or one file for each platform build.
@Rayman said:
Is the 4-bit speed test good enough to say breakouts are 100% good?
For it to be used as a quality tester? Yeah, don't see why not. It does lots of checks. And especially with the basic debug set on it also says why it had any trouble.
I've got FSRW hooked up and seems to work. Haven't had it mess up anything on its own.
I'm planning on merging the function/method naming of the two APIs. They don't seem to be all that far apart even though they appear drastically different at first look.
@Rayman said:
Is that 4-bit mode?
Looks like 1-bit speeds ?
It's both. sdsd_dma is 4-bit SD mode, and sdspi_bashed3 is 1-bit SPI mode.
Yes, the performance sucks at the filesystem layer. Neither FSRW nor FAT32FS have block level API. And both only work with a single block at a time.
The P1 block driver for fsrw speculatively prefetches the next sector. Multi-block transfers into contiguous memory aren't so useful on P1, that's why neither of the spin FAT drivers really optimizes it.
@Wuerfel_21 said:
The P1 block driver for fsrw speculatively prefetches the next sector. Multi-block transfers into contiguous memory aren't so useful on P1, that's why neither of the spin FAT drivers really optimizes it.
Ah, I had seen comments alone those lines but I never understood it was the driver doing it.
Actually, that smartpins version ain't any better than what bit-bashed could achieve. Maybe worse in fact. I'm temped to have another blast at that sdmm.cc driver again. Bound to end up smaller without all the smartpins config.
@evanh said:
Okay, is using a Flexspin feature then.
Here's my current top level developer presentation:
DAT
'------------------------------------------------------------------------------
' *** PINOUTS ***
'------------------------------------------------------------------------------
' Choose one: Uncomment one SD_PIN_ARGS line from the following pinout selections
'
' Pinouts for the SPI mode SD card driver "sdspi_bashed3.spin2": cog-less
'
' SD_PIN_ARGS byte SDTYPE_SPI, MISO_EVAL, MOSI_EVAL, CS_EVAL, CLK_EVAL
' SD_PIN_ARGS byte SDTYPE_SPI, MISO_RL, MOSI_RL, CS_RL, CLK_RL
' SD_PIN_ARGS byte SDTYPE_SPI, MISO_EH, MOSI_EH, CS_EH, CLK_EH
'
' Pinouts for the 4-bit SD mode driver "sdsd_dma.spin2": cog-less
'
SD_PIN_ARGS byte SDTYPE_SD, SD_CLK_DIV, CLK_RL, CMD_RL, DAT0_RL, PWR_RL, LED_RL
' SD_PIN_ARGS byte SDTYPE_SD, SD_CLK_DIV, CLK_EH, CMD_EH, DAT0_EH, -1, -1
CON
'
' Used by the filesystem layer to select internal driver
'
SDTYPE_SPI = 1 ' "sdspi_bashed3.spin2" 1-bit SPI mode driver
SDTYPE_SD = 2 ' "sdsd_dma.spin2" 4-bit SD driver
'
' Prop2 boot pins, set in the Prop2 ROM
'
#58, MISO_EVAL, MOSI_EVAL, CS_EVAL, CLK_EVAL
'
' Clock divider used by "sdsd_dma.spin2" 4-bit SD driver
'
SD_CLK_DIV = 4
'
' Roger Loh's 4-bit add-on board
'
RL_BASE_PIN = 16
DAT0_RL = RL_BASE_PIN+0 ' MISO, DO
DAT1_RL = RL_BASE_PIN+1
DAT2_RL = RL_BASE_PIN+2
DAT3_RL = RL_BASE_PIN+3 ' CS
CMD_RL = RL_BASE_PIN+4 ' MOSI, DI
CLK_RL = RL_BASE_PIN+5 ' SCLK
LED_RL = RL_BASE_PIN+6 ' output to red LED
PWR_RL = RL_BASE_PIN+7 ' Card-Detect input, and power switch, and green LED
CS_RL = DAT3_RL
MOSI_RL = CMD_RL
MISO_RL = DAT0_RL
'
' My hand wired full sized 4-bit SD slot
'
EH_BASE_PIN = 40
CMD_EH = EH_BASE_PIN+2 ' MOSI, DI
CLK_EH = EH_BASE_PIN+3 ' SCLK
DAT0_EH = EH_BASE_PIN+4 ' MISO, DO
DAT1_EH = EH_BASE_PIN+5
DAT2_EH = EH_BASE_PIN+6
DAT3_EH = EH_BASE_PIN+7 ' CS
CS_EH = DAT3_EH
MOSI_EH = CMD_EH
MISO_EH = DAT0_EH
'------------------------------------------------------------------------------
@evanh, very impressive speed test results!
Are there any advanges / drawbacks in using your hand wire pins sequence vs rloh add on board sequence? Are them 100% equivalent?
Sorry for jumping in the topic but I'm designing a P2 board with uSD card slot and I would appreciate your suggestions to choose the best hardware solution.
Is that for doing c type things in spin2?
Haven’t used that.
But, this sounds like a good case for it…
Yeah, I didn't know about it until recently either. It's literally using C's libc. Flexspin allows importing objects from all three supported languages. Although "libc" is special in that it's the whole standard C library and then some. The device registering functions are extra for example.
Anyway, it's unique to Flexspin so won't compile on any other Spin2 compiler.
@MXX said:
@evanh, very impressive speed test results!
Are there any advanges / drawbacks in using your hand wire pins sequence vs rloh add on board sequence? Are them 100% equivalent?
No power switch, and no indicator LED. Otherwise they function the same, yes. LED is unimportant but I would advise to have the power switch.
Placing the DAT pins first or last doesn't matter, no. I was just proving it as part of doing the hand wiring.
Comments
Same, but only worked for me in latest PNut before...
Hehe, I'm ripping up the old sdspi_bashed code big time. Nothing is untouched. Amazingly no bugs. It's already a whole lot more reliable in fact.
@evanh Fixing up the 1-bit code too?
Could definitely use improvement.
Done. Checked at 360 MHz sysclock with all my SD cards.
PS: Also now checked at 360 MHz sysclock on the Eval Board's built-in SD slot. Still works even with that protective inline resistor slowing things down.
Looking at the error numbers in "FAT32" I see there is no distinction or meaning to individual numbers at the driver level. Any negative return code becomes error1, "Disk IO Error".
As a result, I haven't tried to assign any meaning to the error numbers in the driver.
@evanh Did you see the cogged version of the 1-bit driver?
I remember seeing it be faster with that...
But, it's been a while since looked at it...
Product!
One just tested even seems to work!
Have so many copies of speed_test.c, but only latest seems to work, probably messed around too much trying to make work.
Had to add --fcache=256 again. Not sure how that keeps getting turned off...
Had to substitute 0603 1uF for 0402 4.7uF, but pretty sure that's OK...
You got those fully assembled, right? Six in one lot. Price?
Prop2 can do the driver just fine cog-less. If the filesystem object could make use of concurrency sure add the extra cog then, but that would also burn more RAM both in the buffering requirements and the code bloat managing it.
PS: That's where Command-Queuing becomes useful too. When the filesystem object can make multiple requests and able to work with completion notifications rather than doing everything sequentially. But it is a lot for the code to manage so memory needs blow out.
Rayman,
You've been using a "platform" config file of some sort haven't you? How does that work? Does it get loaded somehow?
I've just added a pin map setting mechanism to the driver init that can be passed through the filesystem handler without it knowing the pins explicitly. I now have a growing table of pinout configs to choose from. It's done as a small DAT set built from larger sets of CONstants at the top of the tester program but it's obviously better if it was separated to be a general selection file or one file for each platform build.
Been doing include “platform.h”
Thinking about switching to config.spin2 or config.h though …
Is the 4-bit speed test good enough to say breakouts are 100% good?
How is it used? Have you got an example for me to look at? Spin example preferably.
For it to be used as a quality tester? Yeah, don't see why not. It does lots of checks. And especially with the basic debug set on it also says why it had any trouble.
I've got FSRW hooked up and seems to work. Haven't had it mess up anything on its own.
I'm planning on merging the function/method naming of the two APIs. They don't seem to be all that far apart even though they appear drastically different at first look.
200 MHz sysclock, 2017 32GB Sandisk Extreme, compiled with Flexspin
fat32fs + sdspi_bashed3
fsrw + sdspi_bashed3
fat32fs + sdsd_dma
fsrw + sdsd_dma
Is that 4-bit mode?
Looks like 1-bit speeds ?
200 MHz sysclock, 2017 32GB Sandisk Extreme, compiled with Pnut
fat32fs + sdspi_bashed3
fsrw + sdspi_bashed3
fat32fs + sdsd_dma
fsrw + sdsd_dma
It's both. sdsd_dma is 4-bit SD mode, and sdspi_bashed3 is 1-bit SPI mode.
Yes, the performance sucks at the filesystem layer. Neither FSRW nor FAT32FS have block level API. And both only work with a single block at a time.
The P1 block driver for fsrw speculatively prefetches the next sector. Multi-block transfers into contiguous memory aren't so useful on P1, that's why neither of the spin FAT drivers really optimizes it.
Ah, I had seen comments alone those lines but I never understood it was the driver doing it.
Well, at least around 2X faster. That's something.
Guess really need to use FlexProp for the high speed then...
Here's an example of a platform.h with sorta relevant stuff in it.
The top .c file starts with:
#include "Platform.h"@Wuerfel_21 does something similar with MegaYume, but the main file is .spin2 and the top CON section there does:
#include "config.spin2"I may change mine to be called config.h at some point for C work.
But, still use Prop Tool for Spin2 and guess can't do #include
On the other hand, if want to use new structures, may switch to SpinIDE and maybe #include works there...
Okay, is using a Flexspin feature then.
Here's my current top level developer presentation:
DAT '------------------------------------------------------------------------------ ' *** PINOUTS *** '------------------------------------------------------------------------------ ' Choose one: Uncomment one SD_PIN_ARGS line from the following pinout selections ' ' Pinouts for the SPI mode SD card driver "sdspi_bashed3.spin2": cog-less ' ' SD_PIN_ARGS byte SDTYPE_SPI, MISO_EVAL, MOSI_EVAL, CS_EVAL, CLK_EVAL ' SD_PIN_ARGS byte SDTYPE_SPI, MISO_RL, MOSI_RL, CS_RL, CLK_RL ' SD_PIN_ARGS byte SDTYPE_SPI, MISO_EH, MOSI_EH, CS_EH, CLK_EH ' ' Pinouts for the 4-bit SD mode driver "sdsd_dma.spin2": cog-less ' SD_PIN_ARGS byte SDTYPE_SD, SD_CLK_DIV, CLK_RL, CMD_RL, DAT0_RL, PWR_RL, LED_RL ' SD_PIN_ARGS byte SDTYPE_SD, SD_CLK_DIV, CLK_EH, CMD_EH, DAT0_EH, -1, -1 CON ' ' Used by the filesystem layer to select internal driver ' SDTYPE_SPI = 1 ' "sdspi_bashed3.spin2" 1-bit SPI mode driver SDTYPE_SD = 2 ' "sdsd_dma.spin2" 4-bit SD driver ' ' Prop2 boot pins, set in the Prop2 ROM ' #58, MISO_EVAL, MOSI_EVAL, CS_EVAL, CLK_EVAL ' ' Clock divider used by "sdsd_dma.spin2" 4-bit SD driver ' SD_CLK_DIV = 4 ' ' Roger Loh's 4-bit add-on board ' RL_BASE_PIN = 16 DAT0_RL = RL_BASE_PIN+0 ' MISO, DO DAT1_RL = RL_BASE_PIN+1 DAT2_RL = RL_BASE_PIN+2 DAT3_RL = RL_BASE_PIN+3 ' CS CMD_RL = RL_BASE_PIN+4 ' MOSI, DI CLK_RL = RL_BASE_PIN+5 ' SCLK LED_RL = RL_BASE_PIN+6 ' output to red LED PWR_RL = RL_BASE_PIN+7 ' Card-Detect input, and power switch, and green LED CS_RL = DAT3_RL MOSI_RL = CMD_RL MISO_RL = DAT0_RL ' ' My hand wired full sized 4-bit SD slot ' EH_BASE_PIN = 40 CMD_EH = EH_BASE_PIN+2 ' MOSI, DI CLK_EH = EH_BASE_PIN+3 ' SCLK DAT0_EH = EH_BASE_PIN+4 ' MISO, DO DAT1_EH = EH_BASE_PIN+5 DAT2_EH = EH_BASE_PIN+6 DAT3_EH = EH_BASE_PIN+7 ' CS CS_EH = DAT3_EH MOSI_EH = CMD_EH MISO_EH = DAT0_EH '------------------------------------------------------------------------------I wrote a version of the speed tester in Spin2 that uses Flexspin's "libc.spin2" object for its file read/write and FAT32 layer.
200 MHz sysclock, 2017 32GB Sandisk Extreme:
libc + sdmm (1-bit SPI mode via smartpins)
libc + sdsd_dma (4-bit SD mode via streamer)
Actually, that smartpins version ain't any better than what bit-bashed could achieve. Maybe worse in fact. I'm temped to have another blast at that sdmm.cc driver again. Bound to end up smaller without all the smartpins config.
@evanh, very impressive speed test results!
Are there any advanges / drawbacks in using your hand wire pins sequence vs rloh add on board sequence? Are them 100% equivalent?
Sorry for jumping in the topic but I'm designing a P2 board with uSD card slot and I would appreciate your suggestions to choose the best hardware solution.
Thanks
Massimo
@evanh
Libc.spin2 ?
Is that for doing c type things in spin2?
Haven’t used that.
But, this sounds like a good case for it…
Yeah, I didn't know about it until recently either. It's literally using C's libc. Flexspin allows importing objects from all three supported languages. Although "libc" is special in that it's the whole standard C library and then some. The device registering functions are extra for example.
Anyway, it's unique to Flexspin so won't compile on any other Spin2 compiler.
No power switch, and no indicator LED. Otherwise they function the same, yes. LED is unimportant but I would advise to have the power switch.
Placing the DAT pins first or last doesn't matter, no. I was just proving it as part of doing the hand wiring.