It doesn't have to be exactly the same, forget about TMR2 output/2. Make it FOSC/128. instead of using _usec_delay(), you might make your own procedures like:
-- four instruction cycles procedure _spi_software_delay_4() is pragma inline asm nop asm nop asm nop asm nop end procedure Add it to spi_master_sw_exchange and spi_master_sw get/put procedures. The procedure for FOSC/128 would be quite long, but it can be reduced later with a for loop. The stopwatch library can tell you how many cycles you actually use. I looked over the spi_software library a bit more. I'm going to agree with you that we do need a constant, but I think we also need to keep spi_master_hw_set_speed() procedure so the user may easily switch between spi_software and spi_hardware. Maybe add to the sample: const SPI_MASTER_SW_ENABLE_DELAY = TRUE, which will turn on/off the code you are adding. Matt. On Friday, September 8, 2017 at 5:23:48 AM UTC-4, Alun Jones wrote: > > On Tuesday, 22 August 2017 00:13:25 UTC+1, Matthew Schinkel wrote: >> >> Hi Alun, >> >> Try adding this just before your sd_card include: const >> SD_DELAY_AFTER_WRITE = TRUE >> >> It sounds better to fix spi_master_sw_set_speed then to create a new >> variable. >> >> Matt. >> > > Hi Matt, > > Sorry for the delay replying. I *thought* I'd set this post to notify me > of updates, but that doesn't appear to have worked. > > Thanks for the suggestion about SD_DELAY_AFTER_WRITE. It won't fix my > problem though - the problem is that the software SPI is happening faster > than the card can cope with it. Even reads fail when I don't have a delay > in the software SPI bit shift routine. > > While making spi_master_sw_set_speed work sounds best, making it have the > same semantics as spi_master_set_hw_speed would be a problem, I think. > spi_master_set_speed just takes its argument and assigns it to > SSPCON1_SSPM. The relevant values of this bit field are: > > 0000 = SPI master mode, clock = FOSC/4 > 0001 = SPI master mode, clock = FOSC/16 > 0010 = SPI master mode, clock = FOSC/64 > 0011 = SPI master mode, clock = TMR2 output/2 > > I guess the first three would be easy enough to translate into values for > _usec_delay(). The last one (TMR2/2) would be a lot more complicated. > > What do people think? > > Cheers, > Alun. > > -- 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.
