I've recently tried to use the software SPI library for writing data to an
SD card. I had weird problems with this, whereby a new card worked fine,
but an older one didn't. After a bit (well, a lot!) of messing around, I
finally realised that, at the speed I was clocking my PIC, the software SPI
was pushing data out faster than the older SD cards could cope with.
Dotting a few _usec_delay() calls around the code allowed my older cards to
work.
The software SPI library has a "spi_master_sw_set_speed" procedure, which
doesn't actually do anything and is "just here for compatibility".
I didn't use that in my modified version of the library - the values
usually used when calling spi_master_hw*_set_speed normally get stored
straight into SSP*CON1_SSPM, so they're not straightforward delay values.
Using spi_master_sw_set_speed, but taking "real" delay values doesn't seem
like a good option (it'd be "incompatible" with the _hw_ variants, and the
name wouldn't be sensible (set_speed with a higher delay would result in a
lower speed!).
Writing a "real" compatible version of spi_master_sw_set_speed, emulating
the various hardware options, seems quite a lot of work.
So, instead, I left the spi_master_sw_set_speed function untouched and
added lines of the form:
if defined(spi_master_sw_usec_delay) == true then
_usec_delay(spi_master_sw_usec_delay)
end if
including spi_master_sw after defining the spi_master_sw_usec_delay
constant allows SPI to be slowed down where needed.
What do people think about this? I'm happy enough to push my changes if
people feel it's a reasonable compromise.
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/jallib.
For more options, visit https://groups.google.com/d/optout.
