@evanh Yes, the P2 downloads the new image to itself from the Internet and then reboots. This is an older video, but this is what the process looks like.
@Rayman said:
A bit puzzling because not seeing anything in the source code that is pin# dependent...
I'm not at home at the moment but from memory it uses smartpin serial hardware in some parts and he's not bothered to calculate the clock pin offset pin when setting the smartpin mode.
I wanted to exchange the block level SD driver with something faster and smaller but that hasn't eventuated either. It's quite the tangle in there.
Oh, ouch, offset 5 between SD_MISO and SD_SCK. Not impossible but also not easy to fix the sources with that. That's Roger's 4-bit add-on pinout I presume?
I have not kept up with recent Spin developments, but I can't help wondering who thought mixing SPIN and PASM in this way was a good idea. Surely it makes maintaining, modifying or porting drivers like this far more complicated than it needs to be?
@RossH said:
I have not kept up with recent Spin developments, but I can't help wondering who thought mixing SPIN and PASM in this way was a good idea. Surely it makes maintaining, modifying or porting drivers like this far more complicated than it needs to be?
Stephen may have got a little excessive in misc and redundant routines using ORG/END but I will say, however, it's rather handy to have high-level locals (in registers) directly available to assembly. So I do like the inline Pasm2 ability in Spin2.
@"Stephen Moraco" said:
- will add pin offset computation to the next update after v1.5.0.
MOSI can't do it but, for MISO it gets complicated if wanting to deal with offsets 4,5,6. By using an intermediate smartpin one can then stretch the two input pin numbers up to both a +3 and -3 at once to effect a total offset of up to 6.
Some of the complexity comes from the possibility of having to dodge pin numbers that are assigned another smartpin job. When the offset is 4 or 5 then choosing from more than one smartpin is an option.
And that still doesn't deal with the possibility of trampling on a smartpin that should have been allocated to another driver. But, since there is no smartpin allocation system, there's little that can be done other than don't accommodate beyond +-3 offsets.
The last part is keeping track of the extra pin number used for the MISO smartpin. It's a shuffle and looks messy.
@Rayman said:
Maybe not a problem for 4- bit setup because free to use non- 4 bit pins?
The sdsd.cc 4-bit SD mode driver doesn't use any serial smartpin modes. It only uses a single smartpin for SD clock gen. All CMD and DAT data is transferred with streamer ops.
Other more condensed pin groupings ok?
Yes, of course. It only matters when a smartpin requires a smartB input.
Comments
So you're also storing the programs using the Prop2? It had sounded like you were doing that from the desktop after compiling.
@evanh Yes, the P2 downloads the new image to itself from the Internet and then reboots. This is an older video, but this is what the process looks like.
A tad late.
Tried this out and works great for usual P2 uSD pins. But, doesn't seem to work on other pins...
Tried this:
SD_BASE = 0 SD_SCK = SD_BASE + 5 ' - Serial Clock SD_CS = SD_BASE + 3 ' - Chip Select SD_MOSI = SD_BASE + 4 ' - Master Out, Slave In SD_MISO = SD_BASE + 0 ' - Master In, Slave Outwith no luck...
A bit puzzling because not seeing anything in the source code that is pin# dependent...
I'm not at home at the moment but from memory it uses smartpin serial hardware in some parts and he's not bothered to calculate the clock pin offset pin when setting the smartpin mode.
I wanted to exchange the block level SD driver with something faster and smaller but that hasn't eventuated either. It's quite the tangle in there.
Clock pin offset, guess that would do it…
Oh, ouch, offset 5 between SD_MISO and SD_SCK. Not impossible but also not easy to fix the sources with that. That's Roger's 4-bit add-on pinout I presume?
I have not kept up with recent Spin developments, but I can't help wondering who thought mixing SPIN and PASM in this way was a good idea. Surely it makes maintaining, modifying or porting drivers like this far more complicated than it needs to be?
@evanh yes, that is one of them that didn’t work….
Stephen may have got a little excessive in misc and redundant routines using ORG/END but I will say, however, it's rather handy to have high-level locals (in registers) directly available to assembly. So I do like the inline Pasm2 ability in Spin2.
Inline assembly is awesome and using for uSD drivers makes a lot of sense... You get close to the performance of pure assembly with a lot more ease...
@evanh @Rayman - will add pin offset computation to the next update after v1.5.0. Good catch.
NEWS
I released v1.5.0 a couple of days ago.
Here's what's new/fixed:
Visit the P2 microSD FAT32 Filesystem repository for full documentation, including a driver tutorial, theory of operations, and card catalog.
The release package can be downloaded from the Releases page. Download the sd-card-driver-{version}.zip
file.
If you find issues, please file them at the Issues page.
What's next? Quickly address any reported issues. Likely conditional compile for LFN support.
Enjoy!
Stephen
MOSI can't do it but, for MISO it gets complicated if wanting to deal with offsets 4,5,6. By using an intermediate smartpin one can then stretch the two input pin numbers up to both a +3 and -3 at once to effect a total offset of up to 6.
Some of the complexity comes from the possibility of having to dodge pin numbers that are assigned another smartpin job. When the offset is 4 or 5 then choosing from more than one smartpin is an option.
And that still doesn't deal with the possibility of trampling on a smartpin that should have been allocated to another driver. But, since there is no smartpin allocation system, there's little that can be done other than don't accommodate beyond +-3 offsets.
The last part is keeping track of the extra pin number used for the MISO smartpin. It's a shuffle and looks messy.
Maybe not a problem for 4- bit setup because free to use non- 4 bit pins?
Other more condensed pin groupings ok?
The sdsd.cc 4-bit SD mode driver doesn't use any serial smartpin modes. It only uses a single smartpin for SD clock gen. All CMD and DAT data is transferred with streamer ops.
Yes, of course. It only matters when a smartpin requires a smartB input.
So another option for Stephen is to stop using the serial smartpins and switch to using the streamer for everything.
@evanh meant that for the 4bit setup in 1bit mode there are free pins that can be used…. Maybe that helps…
Yes, fine for that add-on. And it's unlikely there would ever be a design that interleaves pins between uses but you never know for sure.