Just the four DAT pins have to be in order as either the high or low four pins.
Either way-- if it keeps a single header, I'll be looking to resolve that 240R speed-bump!
I note the existing #64009 pinout is such it can be used as the primary boot when slotted into accessory header P56..P63. And hence the 240R in case there is also a boot EEPROM in place.
This particular pinout precludes a 4-bit pinout on the same header.
Thanks evanh... Also, yeah, that primary boot resistor is a PITA requirement. I intend to come up with a better workaround this time.
I got pinged to re-order the Parallax microSD breakout (#64009)
Feels like if I'm doing that, I should add 4-bit support and the power control FET ?
Anything else preferable?
Yes, a card detection input pin, activity LED, power LED when FET is active. If you have 8 pins on the breakout why not use them - they are optional in the driver so you don't have to use them but are useful if you want them. My circuit in post #1 of this thread showed how I did it.
Yes, @rogloh has a clever design where inserting the uSD turns on the power by default.
And, it works in 1-bit mode just fine.
An official Parallax version would be very welcome.
Not sure what they would do for code though...
Guess @evanh helped out with a new 1-bit and 4-bit version of the "bashed" code that can work with both FSRW and FAT32.
Maybe there's no reason not to use FAT32 with P2 given the vastly increased resources.
But, FSRW keeps things dirt simple.
Still for the super high speed, appears need to use FlexProp at the moment.
Was just doing the numbers on what should sell my version for...
Looking like $11.99
@evanh said:
Nooo! not the dastardly $xx.99 pricing!
And do add a little headroom, there's always unaccounted costs.
Don’t really care about profit, just trying to be reasonable…. Somebody once advised to count actual cost and just double it…
Meanwhile most mass market electronics have some ~400% profit margin and the OS is full of ads and spyware...
Maybe you could preload your P2 boards with ads :P
@Rayman said:
Don’t really care about profit, just trying to be reasonable…. Somebody once advised to count actual cost and just double it…
If you're feeling generous, Eric and Ada could both really benefit from a freebie each.
A little self serving of me of course. I'm quite chuffed and want to see others enjoy it.
Used Handbreak to render the free Sintel movie from Blender to 640x364 (so as to have correct aspect ratio when stretched on 16:9 HDTV.
Then, used ffmpeg to create 16bpp, vertically flipped, bmp frames.
Used custom code to extract bmp data from ~9000 frames into one ~4 GB file.
It plays perfectly on the TV. The upscaler is definitely doing something...
Didn't see a single dropped frame and calculated frame rate was 29.99 fps.
@Rayman said:
Used Handbreak to render the free Sintel movie from Blender to 640x364 (so as to have correct aspect ratio when stretched on 16:9 HDTV.
Then, used ffmpeg to create 16bpp, vertically flipped, bmp frames.
Used custom code to extract bmp data from ~9000 frames into one ~4 GB file.
You can do all of these things in a single ffmpeg command, btw. Something like (untested) ffmpeg -i source_file.whatever -vf scale=640:364 -f rawvideo -pix_fmt rgb565le output.bin
LOL, those decimal places reminded me, I once converted an Amiga demo video, acquired off Youtube, into a selection of different frame rates so as to test the behaviour playback with a "Variable Refresh Rate" capable monitor. The nice part about using a video of an old demo is they contain smoothly frame sync'd text scrollers that don't judder. The old CRT monitors, being analogue, just beam sync'd to the computer. And someone had gone to the trouble of making such recording to put on Youtube as well.
Anyway, the point was to not remove, add, telecine, or interpolate any frames. Keep every original frame but lie about the frame rate so as to convince the player to play back at that specified frame rate and see if the monitor adapted to it. The audio track I just left as it was. There wasn't any need to stay in lip-sync when it was just a chip-tune playing.
Regarding the outcome: Testing on my Linux box produced as expected - the copy that was set to 60 Hz (Original being 50 Hz) ran smoothly but faster than original. All others had various degrees of judder from added or dropped frames. I don't have a VRR capable monitor so off I went to a shop ... Sadly, my tests on a Windoze box at the shop was no different. M$'s Media Player didn't appear to use VRR at all. Alas, I wasn't allowed to fiddle with any settings. Maybe VRR is only a D3D games thing on Windoze anyway. Dunno.
Used Handbreak to render the free Sintel movie from Blender to 640x364 (so as to have correct aspect ratio when stretched on 16:9 HDTV.
Then, used ffmpeg to create 16bpp, vertically flipped, bmp frames.
Used custom code to extract bmp data from ~9000 frames into one ~4 GB file.
It plays perfectly on the TV. The upscaler is definitely doing something...
Didn't see a single dropped frame and calculated frame rate was 29.99 fps.
This is a great first result and what I sort of wanted to be able to do with uncompressed video and a P2. Eventually I'd like to try it out with PSRAM enabled and 24bpp colour depths (possibly using YUV 4:2:2) at similar or higher resolutions. I know my video+memory drivers and some PSRAM will have the bandwidth to display and capacity to store the increased frame size and we can use another COG write the frame data from an SD card, as long as the card can sustain its requirements - that's the last real unknown right now.
Roger,
Right, give this a whirl. Driver placement is simplified now - No longer requires using the includes path. But you will need to build the latest Flexspin compiler. Eric has kindly filled all my requests to get it here.
It defaults to sysclock divider of 4, and block read CRC processing is enabled. These can be adjusted at run-time with ioctl() calls. Examples provided in the mountsd() function of tester program.
SD init and error debug can be enabled with -D SD_DEBUG when compiling. More verbose block level logging is enabled with -D SD_DEBUG_PERFORMANCE
Oh, correct. Can use a generic compile line when using the latest compiler build. Eric didn't think the default limit was needed to be so low at 128 and so raised it back to the documented value of 256.
PS: Pnut's "inline" limit is 288 so their defaults are a lot closer together now. Which is a big improvement.
@evanh said:
Roger,
Right, give this a whirl. Driver placement is simplified now - No longer requires using the includes path. But you will need to build the latest Flexspin compiler. Eric has kindly filled all my requests to get it here.
It defaults to sysclock divider of 4, and block read CRC processing is enabled. These can be adjusted at run-time with ioctl() calls. Examples provided in the mountsd() function of tester program.
SD init and error debug can be enabled with -D SD_DEBUG when compiling. More verbose block level logging is enabled with -D SD_DEBUG_PERFORMANCE
Out at the moment enjoying good beach weather in Oz so am away from any HW but when I get back I'll try to take a look.
@evanh
I updated my spin2cpp folder from latest github with "git pull", rebuilt it, and then ran your code posted above with my uSD breakout board fitted on pin 0 (SD_BASE_PIN altered accoringly). Immediately encountered an error 10 "invalid argument", although it also reports CRC read error earlier. Here's the output with SD_DEBUG defined. Do you know what might be wrong?
❯ l -b 230400 -t sdfat-speedtest.binary
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
clkfreq = 200000000 clkmode = 0x10009fb
Compiled with FlexC v7.0.0
Assign pins: CLK_PIN=5 CMD_PIN=4 DAT_PIN=0 PWR_PIN=7 LED_PIN=6
Card detected ... power cycle of SD card
power-down threshold = 37 pin state = 1
power-down slope = 101773 us pin state = 0
power-up threshold = 209 pin state = 0
power-up slope = 1133 us pin state = 1
SD clock-divider set to sysclock/500 (400 kHz)
Card idle OK
OCR register c0ff8000 - SDHC/SDXC Card
Data Transfer Mode entered - Published RCA 59b40000
CID register backed up
4-bit data interface engaged
BlockReadError: err=1 CRC failed!
Speed Class = C10 UHS Grade = U1 Video Class = V0 App Class = A1
BlockReadError: err=1 CRC failed!
Card User Capacity = 60874 MiB
High-Speed access mode engaged
SD clock-divider set to sysclock/4 (50.0 MHz)
.
.
.
.
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
. CMD10 error! rxlag=9 selected Lowest=5 Highest=13
CID decode: ManID=03 OEMID=SD Name=SD64G
Ver=8.5 Serial=FAD08A61 Date=2023-5
SD Card Init Successful
fopen() for writing failed! errno = 10: Invalid argument
Clear pins: 5 4 0 7 6
exit
That's peculiar. Arguments are the filename and access mode. Access mode is a literal "wb", the first filename is "/sd/speed2.bin". Dunno how those could be in error. Maybe card is corrupted?
PS: When building Flexspin, always do a "make clean" first.
PPS: Those few CRC errors are normal. For some odd reason fetching the 64 byte function table from CMD6 and 64 byte SD status register from ACMD13 both require a data read instead of a response on the command pin like everything else. The data block read routine only accepts 512 byte blocks. I've made no accommodation for 64 byte blocks so it errors on the CRC.
I suppose, now that it's runtime switchable, it wouldn't be hard to have the init code momentarily disable the CRC until after those registers are sorted in the init routine.
That was easy. The flag to enable block read CRC processing was being explicitly set at the beginning of init sequence. All I had to do was move that to the end of init sequence instead. No more CRC errors in the debug messages.
@evanh said:
That's peculiar. Arguments are the filename and access mode. Access mode is a literal "wb", the first filename is "/sd/speed2.bin". Dunno how those could be in error. Maybe card is corrupted?
Card seems fine under MacOS. It's a 64GB card with reported filesystem as exFAT though. That's probably the problem. I'll dig up another card.
@evanh , just now I got it working by reformatting this exFAT card as FAT32, results of test are captured below. This was indeed using a 64GB SanDisk Ultra UHS-1 marked Class C10 Speed, A1 Application Class card, matching your report below.
I still see a CMD10 error below, if that happens to be unrelated to your known CRC errors mentioned above (not sure). Hopefully that's not some indication of another problem.
❯ l -b 230400 -t sdfat-speedtest.binary
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
clkfreq = 200000000 clkmode = 0x10009fb
Compiled with FlexC v7.0.0
Assign pins: CLK_PIN=5 CMD_PIN=4 DAT_PIN=0 PWR_PIN=7 LED_PIN=6
Card detected ... power cycle of SD card
power-down threshold = 37 pin state = 1
power-down slope = 65692 us pin state = 0
power-up threshold = 209 pin state = 0
power-up slope = 1133 us pin state = 1
SD clock-divider set to sysclock/500 (400 kHz)
Card idle OK
OCR register c0ff8000 - SDHC/SDXC Card
Data Transfer Mode entered - Published RCA 59b40000
CID register backed up
4-bit data interface engaged
BlockReadError: err=1 CRC failed!
Speed Class = C10 UHS Grade = U1 Video Class = V0 App Class = A1
BlockReadError: err=1 CRC failed!
Card User Capacity = 60874 MiB
High-Speed access mode engaged
SD clock-divider set to sysclock/4 (50.0 MHz)
.
.
.
.
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
. CMD10 error! rxlag=9 selected Lowest=5 Highest=13
CID decode: ManID=03 OEMID=SD Name=SD64G
Ver=8.5 Serial=FAD08A61 Date=2023-5
SD Card Init Successful
Buffer = 4 kB, Written 2048 kB at 981 kB/s, Verified, Read 2048 kB at 7694 kB/s
Buffer = 4 kB, Written 2048 kB at 1295 kB/s, Verified, Read 2048 kB at 7432 kB/s
Buffer = 4 kB, Written 2048 kB at 1166 kB/s, Verified, Read 2048 kB at 7132 kB/s
Buffer = 4 kB, Written 2048 kB at 1279 kB/s, Verified, Read 2048 kB at 6995 kB/s
Buffer = 64 kB, Written 8192 kB at 5547 kB/s, Verified, Read 8192 kB at 17617 kB/s
Buffer = 64 kB, Written 8192 kB at 5776 kB/s, Verified, Read 8192 kB at 16510 kB/s
Buffer = 64 kB, Written 8192 kB at 5817 kB/s, Verified, Read 8192 kB at 17872 kB/s
Buffer = 64 kB, Written 8192 kB at 5804 kB/s, Verified, Read 8192 kB at 17242 kB/s
Clear pins: 5 4 0 7 6
exit
@rogloh said:
I still see a CMD10 error below, if that happens to be unrelated to your known CRC errors mentioned above (not sure). Hopefully that's not some indication of another problem.
I'm so used to them in the init sequence I don't even notice. The CMD10 error is the calibration routine finding its limits. Sometimes there is failed responses that timeout, other times not. I won't attempt to hide those.
Actually, I'd like to read whole data blocks instead of just the measly CMD10 response but deciding on where to find decent data isn't trivial. Writing a block to the drive is not wise and the official method of using CMD19 (SEND_TUNING_BLOCK) is not available until switched into UHS-1.
Maybe a little overkill but in an attempt to compensate for the small amount of bits to work with I've bolstered the rxlag calibration routine from issuing 80 x CMD10 per setting (80 dot line) to now 960 x CMD10 per setting (12 times per dot).
It still appears in a blink, with diag enabled, as there's no busy flag to wait on with house keeping commands like this.
Yep, one per CMD10 issued. It shows progress of the calibrating routine. Each line is the next incremental value of rxlag, starting from 1. Least significant bit holds data pin registration enable (inverted and timing compensated), similar to your method with the PSRAM boards.
Comments
Thanks evanh... Also, yeah, that primary boot resistor is a PITA requirement. I intend to come up with a better workaround this time.
Yes, a card detection input pin, activity LED, power LED when FET is active. If you have 8 pins on the breakout why not use them - they are optional in the driver so you don't have to use them but are useful if you want them. My circuit in post #1 of this thread showed how I did it.
Yes, @rogloh has a clever design where inserting the uSD turns on the power by default.
And, it works in 1-bit mode just fine.
An official Parallax version would be very welcome.
Not sure what they would do for code though...
Guess @evanh helped out with a new 1-bit and 4-bit version of the "bashed" code that can work with both FSRW and FAT32.
Maybe there's no reason not to use FAT32 with P2 given the vastly increased resources.
But, FSRW keeps things dirt simple.
Still for the super high speed, appears need to use FlexProp at the moment.
Was just doing the numbers on what should sell my version for...
Looking like $11.99
Nooo! not the dastardly $xx.99 pricing!
And do add a little headroom, there's always unaccounted costs.
As I understand it, the updated adapter will be a springboard for a certain genius to get working on new code!
Don’t really care about profit, just trying to be reasonable…. Somebody once advised to count actual cost and just double it…
Meanwhile most mass market electronics have some ~400% profit margin and the OS is full of ads and spyware...
Maybe you could preload your P2 boards with ads :P
Probably should test the flash boot with something... @Wuerfel_21 Excellent idea!
Ideally something that's fun for the user (i.e. not an ad).
Maybe I could make a Bad Apple demo that fits exactly on the 16MB boot flash...
@Wuerfel_21 that would be great
If you're feeling generous, Eric and Ada could both really benefit from a freebie each.
A little self serving of me of course. I'm quite chuffed and want to see others enjoy it.
Did a more extensive video test...
Used Handbreak to render the free Sintel movie from Blender to 640x364 (so as to have correct aspect ratio when stretched on 16:9 HDTV.
Then, used ffmpeg to create 16bpp, vertically flipped, bmp frames.
Used custom code to extract bmp data from ~9000 frames into one ~4 GB file.
It plays perfectly on the TV. The upscaler is definitely doing something...
Didn't see a single dropped frame and calculated frame rate was 29.99 fps.
You can do all of these things in a single ffmpeg command, btw. Something like (untested)
ffmpeg -i source_file.whatever -vf scale=640:364 -f rawvideo -pix_fmt rgb565le output.binLOL, those decimal places reminded me, I once converted an Amiga demo video, acquired off Youtube, into a selection of different frame rates so as to test the behaviour playback with a "Variable Refresh Rate" capable monitor. The nice part about using a video of an old demo is they contain smoothly frame sync'd text scrollers that don't judder. The old CRT monitors, being analogue, just beam sync'd to the computer. And someone had gone to the trouble of making such recording to put on Youtube as well.
Anyway, the point was to not remove, add, telecine, or interpolate any frames. Keep every original frame but lie about the frame rate so as to convince the player to play back at that specified frame rate and see if the monitor adapted to it. The audio track I just left as it was. There wasn't any need to stay in lip-sync when it was just a chip-tune playing.
Regarding the outcome: Testing on my Linux box produced as expected - the copy that was set to 60 Hz (Original being 50 Hz) ran smoothly but faster than original. All others had various degrees of judder from added or dropped frames. I don't have a VRR capable monitor so off I went to a shop ... Sadly, my tests on a Windoze box at the shop was no different. M$'s Media Player didn't appear to use VRR at all. Alas, I wasn't allowed to fiddle with any settings. Maybe VRR is only a D3D games thing on Windoze anyway. Dunno.
Wishing exFat was enabled in FlexProp, so could have entire video in one file...
Might have to try that out soon...
This is a great first result and what I sort of wanted to be able to do with uncompressed video and a P2. Eventually I'd like to try it out with PSRAM enabled and 24bpp colour depths (possibly using YUV 4:2:2) at similar or higher resolutions. I know my video+memory drivers and some PSRAM will have the bandwidth to display and capacity to store the increased frame size and we can use another COG write the frame data from an SD card, as long as the card can sustain its requirements - that's the last real unknown right now.
Roger,
Right, give this a whirl. Driver placement is simplified now - No longer requires using the includes path. But you will need to build the latest Flexspin compiler. Eric has kindly filled all my requests to get it here.
It defaults to sysclock divider of 4, and block read CRC processing is enabled. These can be adjusted at run-time with ioctl() calls. Examples provided in the mountsd() function of tester program.
SD init and error debug can be enabled with
-D SD_DEBUGwhen compiling. More verbose block level logging is enabled with-D SD_DEBUG_PERFORMANCECompiling with "fcache" no longer needed?
Oh, correct. Can use a generic compile line when using the latest compiler build. Eric didn't think the default limit was needed to be so low at 128 and so raised it back to the documented value of 256.
PS: Pnut's "inline" limit is 288 so their defaults are a lot closer together now. Which is a big improvement.
Out at the moment enjoying good beach weather in Oz so am away from any HW but when I get back I'll try to take a look.
That sounds nice. Weather is a tad gloomy here. Been raining on and off quite a bit.
@evanh
I updated my spin2cpp folder from latest github with "git pull", rebuilt it, and then ran your code posted above with my uSD breakout board fitted on pin 0 (SD_BASE_PIN altered accoringly). Immediately encountered an error 10 "invalid argument", although it also reports CRC read error earlier. Here's the output with SD_DEBUG defined. Do you know what might be wrong?
That's peculiar. Arguments are the filename and access mode. Access mode is a literal "wb", the first filename is "/sd/speed2.bin". Dunno how those could be in error. Maybe card is corrupted?
PS: When building Flexspin, always do a "make clean" first.
PPS: Those few CRC errors are normal. For some odd reason fetching the 64 byte function table from CMD6 and 64 byte SD status register from ACMD13 both require a data read instead of a response on the command pin like everything else. The data block read routine only accepts 512 byte blocks. I've made no accommodation for 64 byte blocks so it errors on the CRC.
I suppose, now that it's runtime switchable, it wouldn't be hard to have the init code momentarily disable the CRC until after those registers are sorted in the init routine.
That was easy. The flag to enable block read CRC processing was being explicitly set at the beginning of init sequence. All I had to do was move that to the end of init sequence instead. No more CRC errors in the debug messages.
Card seems fine under MacOS. It's a 64GB card with reported filesystem as exFAT though. That's probably the problem. I'll dig up another card.
@evanh , just now I got it working by reformatting this exFAT card as FAT32, results of test are captured below. This was indeed using a 64GB SanDisk Ultra UHS-1 marked Class C10 Speed, A1 Application Class card, matching your report below.
I still see a CMD10 error below, if that happens to be unrelated to your known CRC errors mentioned above (not sure). Hopefully that's not some indication of another problem.
Looks good.
I'm so used to them in the init sequence I don't even notice. The CMD10 error is the calibration routine finding its limits. Sometimes there is failed responses that timeout, other times not. I won't attempt to hide those.
Actually, I'd like to read whole data blocks instead of just the measly CMD10 response but deciding on where to find decent data isn't trivial. Writing a block to the drive is not wise and the official method of using CMD19 (SEND_TUNING_BLOCK) is not available until switched into UHS-1.
Maybe a little overkill but in an attempt to compensate for the small amount of bits to work with I've bolstered the rxlag calibration routine from issuing 80 x CMD10 per setting (80 dot line) to now 960 x CMD10 per setting (12 times per dot).
It still appears in a blink, with diag enabled, as there's no busy flag to wait on with house keeping commands like this.
Are these printed dots in any way useful? For example is it in there to show code might be hanging in some certain place?
Yep, one per CMD10 issued. It shows progress of the calibrating routine. Each line is the next incremental value of rxlag, starting from 1. Least significant bit holds data pin registration enable (inverted and timing compensated), similar to your method with the PSRAM boards.