Looks decent. Vgs max is +/- 8V and Vds max is -20V. So certainly plenty safe for 3V switching and a nice low Vt. Very little voltage drop at normal gate voltages. Rds ~ 100milliohms, for 200mA load is only 20mV drop. Nice.
The threshold numbers just seem pointless to me. There's no consistency with respect to the Rds(on) curve. They are wide margin and all look the same, I've not even bothered to read about measuring conditions. And different data entry, for parametric search, uses different ends of the range ... or not entered at all. It certainly fails in parametric searches. MOSFETs are hard to search for. You always end up downloading every datasheet to look at the graphs.
PS: I guess Vth is really about the off state rather than on state of the transistor. It's still a wide range though.
There's a little titbit. I just noticed the rxlag calibration is coming up maybe 1.3 sysclocks (300 MHz sysclock frequency) longer with the 2 GB camera card. Swapping to one of the newer uSD cards, in the same slot I wired up, brings it back to the same shorter rxlag range I'm used to. So it's definitely the old card that is producing the longer slew/latency.
PS: Err, the .3 part might be more lost eye aperture than plain lag. It's erratically reducing to a window of two ticks while using sysclock/3 timings. No errors as yet.
Funny, I am working with an old 2GB card right now for capturing HDMI stuff and examining it. This one works nicely with the P2 compared to some others Sandisk ones I had tried ages ago.
@rogloh said:
Funny, I am working with an old 2GB card right now for capturing HDMI stuff and examining it. This one works nicely with the P2 compared to some others Sandisk ones I had tried ages ago.
That works with my SD mode driver? It must be v2.00 compliant then.
If you enable debugging it'll report the manufacture date. Or maybe it's the firmware date.
Am using it with flexspin's SD mount code through this C lib API.
err := _mount(@"/sd",c._vfs_open_sdcard())
if err
send("Error opening SD card!",13,10)
...
elseif ch=="w" or ch=="W" ' pressing W or w writes the logfile to the SD card
if memptr >= BUFFER_SIZE/2 and not err
send("Enter name of logfile: ")
if getname(@name+4,12)==0
send("Aborted",13,10)
next
send("Writing ",f.str(@name),13,10)
fp:=c.fopen(@name,@"wb")
I didn't know it was that accessible from Spin. So it wouldn't be any different for the SD mode driver. After installing the driver, just change the mount to _vfs_open_sdsdcard(div,clk,cmd,dat0,pwr,led)
Question: How come that _mount() isn't c._mount()?
The driver seems to be ready for another posted update. Not much more done really. It mostly just worked with the v1.0 card. I thought it wasn't interpreting the ACMD13: SD_STATUS correctly but it turns out that Speed Class = C0 UHS Grade = U0 Video Class = V0 App Class = A0 is a perfectly valid case.
Not too surprisingly, write speed is Smile:
CID decode: ManID=1D OEMID=AD Name=SD
Ver=1.0 Serial=A15002BA Date=2007-5
SD Card Init Successful
mount sd: OK
Buffer = 2 kB, Written 64 kB at 22 kB/s, Verified, Read 64 kB at 7615 kB/s
Buffer = 2 kB, Written 64 kB at 22 kB/s, Verified, Read 64 kB at 7633 kB/s
Buffer = 2 kB, Written 64 kB at 22 kB/s, Verified, Read 64 kB at 7639 kB/s
Buffer = 2 kB, Written 64 kB at 22 kB/s, Verified, Read 64 kB at 7648 kB/s
Buffer = 4 kB, Written 128 kB at 34 kB/s, Verified, Read 128 kB at 10963 kB/s
Buffer = 4 kB, Written 128 kB at 33 kB/s, Verified, Read 128 kB at 11011 kB/s
Buffer = 4 kB, Written 128 kB at 34 kB/s, Verified, Read 128 kB at 11017 kB/s
Buffer = 4 kB, Written 128 kB at 34 kB/s, Verified, Read 128 kB at 11027 kB/s
Buffer = 8 kB, Written 256 kB at 68 kB/s, Verified, Read 256 kB at 11958 kB/s
Buffer = 8 kB, Written 256 kB at 67 kB/s, Verified, Read 256 kB at 11974 kB/s
Buffer = 8 kB, Written 256 kB at 67 kB/s, Verified, Read 256 kB at 11978 kB/s
Buffer = 8 kB, Written 256 kB at 67 kB/s, Verified, Read 256 kB at 11984 kB/s
Buffer = 16 kB, Written 512 kB at 134 kB/s, Verified, Read 512 kB at 12259 kB/s
Buffer = 16 kB, Written 512 kB at 132 kB/s, Verified, Read 512 kB at 12262 kB/s
Buffer = 16 kB, Written 512 kB at 132 kB/s, Verified, Read 512 kB at 12266 kB/s
Buffer = 16 kB, Written 512 kB at 132 kB/s, Verified, Read 512 kB at 12266 kB/s
Buffer = 32 kB, Written 1024 kB at 246 kB/s, Verified, Read 1024 kB at 11464 kB/s
Buffer = 32 kB, Written 1024 kB at 242 kB/s, Verified, Read 1024 kB at 11471 kB/s
Buffer = 32 kB, Written 1024 kB at 243 kB/s, Verified, Read 1024 kB at 11476 kB/s
Buffer = 32 kB, Written 1024 kB at 243 kB/s, Verified, Read 1024 kB at 11476 kB/s
Buffer = 64 kB, Written 2048 kB at 499 kB/s, Verified, Read 2048 kB at 12533 kB/s
Buffer = 64 kB, Written 2048 kB at 490 kB/s, Verified, Read 2048 kB at 12589 kB/s
Buffer = 64 kB, Written 2048 kB at 492 kB/s, Verified, Read 2048 kB at 12592 kB/s
Buffer = 64 kB, Written 2048 kB at 492 kB/s, Verified, Read 2048 kB at 12598 kB/s
Buffer = 128 kB, Written 4096 kB at 892 kB/s, Verified, Read 4096 kB at 12649 kB/s
Buffer = 128 kB, Written 4096 kB at 882 kB/s, Verified, Read 4096 kB at 12650 kB/s
Buffer = 128 kB, Written 4096 kB at 881 kB/s, Verified, Read 4096 kB at 12651 kB/s
Buffer = 128 kB, Written 4096 kB at 881 kB/s, Verified, Read 4096 kB at 12652 kB/s
Buffer = 256 kB, Written 8192 kB at 1471 kB/s, Verified, Read 8192 kB at 12682 kB/s
Buffer = 256 kB, Written 8192 kB at 1457 kB/s, Verified, Read 8192 kB at 12684 kB/s
Buffer = 256 kB, Written 8192 kB at 1457 kB/s, Verified, Read 8192 kB at 12688 kB/s
Buffer = 256 kB, Written 8192 kB at 1459 kB/s, Verified, Read 8192 kB at 12687 kB/s
File size compare of Speedtester:
Compiled with Fatfs/SD-SPI: 51040
Compiled with Fatfs/SD-SD: 53460
Compiled with Littlefs/Flash: 71584
These are just compiles only. I've not tried to use Littlefs for example. I'm rather surprised it came out bigger at all, let alone a lot bigger. Maybe it's an optimisation issue - Spin code doesn't optimise maybe?
EDIT: Recompiled with test loop included. Added about 5.5 kB to all three.
The only thing that immediately sticks out without building it myself is this CRC function I don't like the look of:
static uint32_t crc7sd( // SD spec 4.5
uint8_t *buf,
size_t len )
{
uint32_t crc = 0;
uint32_t val;
__asm {
// Reference code courtesy of Ariba
crc7lp
rdlong val, buf
add buf, #4
movbyts val, #0b00_01_10_11 // byte swap within longwords
setq val
crcnib crc, #0x48 // CCITT 7-bit polynomial is x0 + x3 + x7
crcnib crc, #0x48 // 0x09 reversed and shifted for CRCNIB
djz len, #crc7done
crcnib crc, #0x48
crcnib crc, #0x48
djz len, #crc7done
crcnib crc, #0x48
crcnib crc, #0x48
djz len, #crc7done
crcnib crc, #0x48
crcnib crc, #0x48
djnz len, #crc7lp
crc7done
rev crc // correct the bit order to match standard
shr crc, #24
or crc, #1 // add the SD response end-bit as 8th bit
}
return crc;
}
I don't think this a load-bearing high-speed function (only called with lengths 5 and 15), so why is it unrolled? And I don't think it even makes it faster. Whether it gets FCache'd in a plain asm block is up to the optimizer (don't rember if it will cope with that sort of loop structure...), but I don't think this is optimal in either case.
static uint32_t crc7sd( // SD spec 4.5
uint8_t *buf,
size_t len )
{
uint32_t crc = 0;
uint32_t val;
__asm volatile {
rdfast #0, buf
rep @.loop, len
rfbyte val
shl val,#24
setq val
crcnib crc,#0x48
crcnib crc,#0x48
.loop
}
__asm {
rev crc // correct the bit order to match standard
shr crc, #24
or crc, #1 // add the SD response end-bit as 8th bit
}
return crc;
}
Ought to be 64 bytes shorter and similar speed by my guesstimations. RDFAST is the gift that keeps on giving.
64 bytes would clear 2.5% of the RAM deficit.
I never profiled it but the gist was to not need the Fcache loading overhead. It's not huge so size wasn't a concern in the thinking. I guess I should add a const in there since it would defeat the purpose if the optimiser then Fcached it.
I have my doubts. The vast majority of cases is just 5 response bytes to process - Two loop branches and two RDLONGs. The RDFAST also takes time, as does each cycle of RFBYTE. Admittedly, they aren't going to be a lot different speed wise.
Actually, I may have sort of done a rough speed check when I wrote it. Just by observing speed outcomes in the user program. I didn't write anything down so certainly a foggy memory.
Well, those speed results with the 2 GB v1.0 card above were using the FAT16 filesystem. When I reformat to FAT32 the writes then go half as fast again! I feel Flexspin's Fatfs is a tad weak on the writes.
@evanh said:
I have my doubts. The vast majority of cases is just 5 response bytes to process - Two loop branches and two RDLONGs. The RDFAST also takes time, as does each cycle of RFBYTE. Admittedly, they aren't going to be a lot different speed wise.
To belabor the incredibly minor point: For 5 bytes, it seems to be equal, below hubexec measurement noise (sucks flexspin can't do normal function pointers...). For 15 bytes the short version is faster (~47 cycles). Both versions compile with a superfluous MOV instruction. Oh no, time to dive into ReplaceBack H-E-double-hockeysticks.
Also, improved version of the disc_size. The SPI driver has the same thing, so that should get it, too. If anything that widens the gap... I count 76 byte less (with 32 bit LBA_t - much more with 64 bit)
(Note: I fuzz-tested this to make sure it matches the previous version)
Though I now notice the version in the SPI driver is slightly different - it masks CARD_SIZE to 22 bits instead of 24 (as per spec). But it also checks for CSD version 1 specifically. SDUC is version 2 and that would have 28 bits of CARD_SIZE. So really both are slightly wrong. Though those extra bits all get shifted out in LBA32, so it's academical unless one of us gets hold of an elusive 4TB card.
@rogloh One thing just remembered here is that adding vias under the feet of uSD connector seems to help prevent the whole thing from lifting off the PCB.
Used to have that problem, but thinking the vias fixed it.
Are you doing that here?
Maybe it's not as important for a little board with some play at the Eval connector...
@Rayman said:
@rogloh One thing just remembered here is that adding vias under the feet of uSD connector seems to help prevent the whole thing from lifting off the PCB.
Used to have that problem, but thinking the vias fixed it.
Are you doing that here?
Maybe it's not as important for a little board with some play at the Eval connector...
Looking at the pic of the underside of my board made a while back I don't see vias on the mounting tab feet so I didn't do that. Interesting idea though and it probably works well by bringing metal through to the other side. I guess evanh is the best to judge if there's been any movement as he's probably had many cards inserted/removed by now.
@Rayman said:
@rogloh One thing just remembered here is that adding vias under the feet of uSD connector seems to help prevent the whole thing from lifting off the PCB.
Used to have that problem, but thinking the vias fixed it.
Are you doing that here?
Maybe it's not as important for a little board with some play at the Eval connector...
I've been told this same advice by a relatively large electronics manufacturer - put vias through the smd pads on anything vaguely mechanical. It really helps overall reliability
Now it's brought up I do see there is four mechanical surface mount points around the slot assembly. Good idea to via those pads. Of course, if it had mechanical through-hole tabs it'd be even sturdier.
I've not had any strength issues with mine but then I typically am conscientious around fragile things. I've never broken a USB socket, for example, but I keep seeing broken sockets on other people's gear. That said, I have broken a number of full-sized SD cards - by forgetting about them and sitting on them.
@Wuerfel_21 said:
Though I now notice the version in the SPI driver is slightly different - it masks CARD_SIZE to 22 bits instead of 24 (as per spec). But it also checks for CSD version 1 specifically. SDUC is version 2 and that would have 28 bits of CARD_SIZE. So really both are slightly wrong. Though those extra bits all get shifted out in LBA32, so it's academical unless one of us gets hold of an elusive 4TB card.
I've only got the v6.0 document covering up to SDXC, so haven't read about anything further than 22-bit x 0.5 MB. Which equates to 32-bit of 0.5 kB blocks.
EDIT: Ah, of course, there is 6 reserved bits right in front there. EDIT2: Though, supporting beyond LBA32 does seem over the top. What might be better is getting the block size increased. The whole cluster/block layering in FAT is a tad redundant. One block == one cluster should work fine.
Comments
Hell yeah, it still functions at 1.5 volts! And it has the basic built-in snubber diodes.
Looks decent. Vgs max is +/- 8V and Vds max is -20V. So certainly plenty safe for 3V switching and a nice low Vt. Very little voltage drop at normal gate voltages. Rds ~ 100milliohms, for 200mA load is only 20mV drop. Nice.
The threshold numbers just seem pointless to me. There's no consistency with respect to the Rds(on) curve. They are wide margin and all look the same, I've not even bothered to read about measuring conditions. And different data entry, for parametric search, uses different ends of the range ... or not entered at all. It certainly fails in parametric searches. MOSFETs are hard to search for. You always end up downloading every datasheet to look at the graphs.
PS: I guess Vth is really about the off state rather than on state of the transistor. It's still a wide range though.
There's a little titbit. I just noticed the rxlag calibration is coming up maybe 1.3 sysclocks (300 MHz sysclock frequency) longer with the 2 GB camera card. Swapping to one of the newer uSD cards, in the same slot I wired up, brings it back to the same shorter rxlag range I'm used to. So it's definitely the old card that is producing the longer slew/latency.
PS: Err, the .3 part might be more lost eye aperture than plain lag. It's erratically reducing to a window of two ticks while using sysclock/3 timings. No errors as yet.
What type of SD card was this camera card? SDSC?
Yes, 2007 Adata brand. I made the full sized adaptor just for it because it's the only SDSC card I have.
Funny, I am working with an old 2GB card right now for capturing HDMI stuff and examining it. This one works nicely with the P2 compared to some others Sandisk ones I had tried ages ago.
That works with my SD mode driver? It must be v2.00 compliant then.
If you enable debugging it'll report the manufacture date. Or maybe it's the firmware date.
Or are you using some other driver in Spin2?
Am using it with flexspin's SD mount code through this C lib API.
err := _mount(@"/sd",c._vfs_open_sdcard()) if err send("Error opening SD card!",13,10) ... elseif ch=="w" or ch=="W" ' pressing W or w writes the logfile to the SD card if memptr >= BUFFER_SIZE/2 and not err send("Enter name of logfile: ") if getname(@name+4,12)==0 send("Aborted",13,10) next send("Writing ",f.str(@name),13,10) fp:=c.fopen(@name,@"wb")Ah, right, _vfs_open_sdcard() is the SPI mode driver with preset pins. Yep, it handles all card versions.
I didn't know it was that accessible from Spin. So it wouldn't be any different for the SD mode driver. After installing the driver, just change the mount to
_vfs_open_sdsdcard(div,clk,cmd,dat0,pwr,led)Question: How come that
_mount()isn'tc._mount()?Huh. Yeah not actually sure why I didn't add that, doesn't seem to complain though and it lets me access the SD.
The driver seems to be ready for another posted update. Not much more done really. It mostly just worked with the v1.0 card. I thought it wasn't interpreting the ACMD13: SD_STATUS correctly but it turns out that
Speed Class = C0 UHS Grade = U0 Video Class = V0 App Class = A0is a perfectly valid case.Not too surprisingly, write speed is Smile:
Install instructions - https://forums.parallax.com/discussion/comment/1562218/#Comment_1562218
File size compare of Speedtester:
Compiled with Fatfs/SD-SPI: 51040
Compiled with Fatfs/SD-SD: 53460
Compiled with Littlefs/Flash: 71584
These are just compiles only. I've not tried to use Littlefs for example. I'm rather surprised it came out bigger at all, let alone a lot bigger. Maybe it's an optimisation issue - Spin code doesn't optimise maybe?
EDIT: Recompiled with test loop included. Added about 5.5 kB to all three.
Yea the LittleFS is not so little at all (and in my testing never worked properly?). Chip's FS is better, even though it misses some features.
2.4K overhead vs SPI is workable. Might take a look at cutting it all down a bit once it's done and landed in master.
EDIT: Oh, I see you're already using all the level 1 crook tricks like
__builtin_allocaIs littlefs better if power failure while writing?
The only thing that immediately sticks out without building it myself is this CRC function I don't like the look of:
static uint32_t crc7sd( // SD spec 4.5 uint8_t *buf, size_t len ) { uint32_t crc = 0; uint32_t val; __asm { // Reference code courtesy of Ariba crc7lp rdlong val, buf add buf, #4 movbyts val, #0b00_01_10_11 // byte swap within longwords setq val crcnib crc, #0x48 // CCITT 7-bit polynomial is x0 + x3 + x7 crcnib crc, #0x48 // 0x09 reversed and shifted for CRCNIB djz len, #crc7done crcnib crc, #0x48 crcnib crc, #0x48 djz len, #crc7done crcnib crc, #0x48 crcnib crc, #0x48 djz len, #crc7done crcnib crc, #0x48 crcnib crc, #0x48 djnz len, #crc7lp crc7done rev crc // correct the bit order to match standard shr crc, #24 or crc, #1 // add the SD response end-bit as 8th bit } return crc; }I don't think this a load-bearing high-speed function (only called with lengths 5 and 15), so why is it unrolled? And I don't think it even makes it faster. Whether it gets FCache'd in a plain asm block is up to the optimizer (don't rember if it will cope with that sort of loop structure...), but I don't think this is optimal in either case.
static uint32_t crc7sd( // SD spec 4.5 uint8_t *buf, size_t len ) { uint32_t crc = 0; uint32_t val; __asm volatile { rdfast #0, buf rep @.loop, len rfbyte val shl val,#24 setq val crcnib crc,#0x48 crcnib crc,#0x48 .loop } __asm { rev crc // correct the bit order to match standard shr crc, #24 or crc, #1 // add the SD response end-bit as 8th bit } return crc; }Ought to be 64 bytes shorter and similar speed by my guesstimations. RDFAST is the gift that keeps on giving.
64 bytes would clear 2.5% of the RAM deficit.
I never profiled it but the gist was to not need the Fcache loading overhead. It's not huge so size wasn't a concern in the thinking. I guess I should add a
constin there since it would defeat the purpose if the optimiser then Fcached it.The overhead of doing a bunch of hub branches and RDLONGs is higher.
I have my doubts. The vast majority of cases is just 5 response bytes to process - Two loop branches and two RDLONGs. The RDFAST also takes time, as does each cycle of RFBYTE. Admittedly, they aren't going to be a lot different speed wise.
Actually, I may have sort of done a rough speed check when I wrote it. Just by observing speed outcomes in the user program. I didn't write anything down so certainly a foggy memory.
Well, those speed results with the 2 GB v1.0 card above were using the FAT16 filesystem. When I reformat to FAT32 the writes then go half as fast again!
I feel Flexspin's Fatfs is a tad weak on the writes.
To belabor the incredibly minor point: For 5 bytes, it seems to be equal, below hubexec measurement noise (sucks flexspin can't do normal function pointers...). For 15 bytes the short version is faster (~47 cycles). Both versions compile with a superfluous MOV instruction. Oh no, time to dive into ReplaceBack H-E-double-hockeysticks.
_crc7sd_a_0004 mov _var01, #0 LR__0001 ' Note how this is not getting Fcached - optimizer doesn't understand this loop structure. rdlong _var02, arg01 add arg01, #4 movbyts _var02, #27 setq _var02 crcnib _var01, #72 crcnib _var01, #72 djz arg02, #LR__0002 crcnib _var01, #72 crcnib _var01, #72 djz arg02, #LR__0002 crcnib _var01, #72 crcnib _var01, #72 djz arg02, #LR__0002 crcnib _var01, #72 crcnib _var01, #72 djnz arg02, #LR__0001 LR__0002 rev _var01 shr _var01, #24 or _var01, #1 mov result1, _var01 ' <---- WHY????? _crc7sd_a_0004_ret ret _crc7sd_b_0007 mov _var01, #0 callpa #(@LR__0012-@LR__0010)>>2,fcache_load_ptr_ LR__0010 org 0 rdfast #0, arg01 rep @LR__0011, arg02 rfbyte _var02 shl _var02, #24 setq _var02 crcnib _var01, #72 crcnib _var01, #72 LR__0011 LR__0012 orgh rev _var01 shr _var01, #24 or _var01, #1 mov result1, _var01 ' <---- Yes officer this is the one _crc7sd_b_0007_ret retEDIT: Hot new compiler PR to fix the result variable MOV issue: https://github.com/totalspectrum/spin2cpp/pull/451
Also, improved version of the
disc_size. The SPI driver has the same thing, so that should get it, too. If anything that widens the gap... I count 76 byte less (with 32 bit LBA_t - much more with 64 bit)(Note: I fuzz-tested this to make sure it matches the previous version)
LBA_t disc_size( uint8_t *csd ) { uint32_t cs = __builtin_bswap32(*(uint32_t*)(&csd[6])); unsigned n; if( csd[0]>>6 ) { // SDC ver 2.00 cs = (cs & 0xffffff)+1; n = 10; } else { // SDC ver 1.00 cs = (LBA_t)(cs>>14 & 0xfff)+1; n = (csd[5] & 15) + (__builtin_bswap32(*(uint16_t*)(&csd[9]))>>23 & 0x7)+(2-9); } return (LBA_t)cs << n; // 32/64-bit block count }Though I now notice the version in the SPI driver is slightly different - it masks CARD_SIZE to 22 bits instead of 24 (as per spec). But it also checks for CSD version 1 specifically. SDUC is version 2 and that would have 28 bits of CARD_SIZE. So really both are slightly wrong. Though those extra bits all get shifted out in LBA32, so it's academical unless one of us gets hold of an elusive 4TB card.
@rogloh One thing just remembered here is that adding vias under the feet of uSD connector seems to help prevent the whole thing from lifting off the PCB.
Used to have that problem, but thinking the vias fixed it.
Are you doing that here?
Maybe it's not as important for a little board with some play at the Eval connector...
Looking at the pic of the underside of my board made a while back I don't see vias on the mounting tab feet so I didn't do that. Interesting idea though and it probably works well by bringing metal through to the other side. I guess evanh is the best to judge if there's been any movement as he's probably had many cards inserted/removed by now.
@rogloh Think seeing that your uSD socket has two pins on the bottom that need holes for? Mine doesn't have that. That probably helps.
I've been told this same advice by a relatively large electronics manufacturer - put vias through the smd pads on anything vaguely mechanical. It really helps overall reliability
Now it's brought up I do see there is four mechanical surface mount points around the slot assembly. Good idea to via those pads. Of course, if it had mechanical through-hole tabs it'd be even sturdier.
I've not had any strength issues with mine but then I typically am conscientious around fragile things. I've never broken a USB socket, for example, but I keep seeing broken sockets on other people's gear. That said, I have broken a number of full-sized SD cards - by forgetting about them and sitting on them.
I've only got the v6.0 document covering up to SDXC, so haven't read about anything further than 22-bit x 0.5 MB. Which equates to 32-bit of 0.5 kB blocks.
EDIT: Ah, of course, there is 6 reserved bits right in front there. EDIT2: Though, supporting beyond LBA32 does seem over the top. What might be better is getting the block size increased. The whole cluster/block layering in FAT is a tad redundant. One block == one cluster should work fine.