0

I'm wondering people's thoughts on what happens when SPI timings between master and slave are "a bit" off. A bit being 2.34375 % too slow.

My setup is:

  • Slave device, which I cannot change, wants to be fed a clock of 128000.
  • My master device, which I can change, is currently stuck at 125000 due to the crystal that I have in it, 8 MHz.

I have ordered an 8.192 MHz crystal from RS with capacitors which will arrive in a few days. When that is running my master device, they will be in bitrate harmony.

In the meantime, when I read from the slave, it is returning data but it's a bit of a mess. I don't know if it's my bitrate mismatch or some other comms issue that I've not yet got under control.

What do you think? * Never going to work until bps are matched? * Should get some data coming in correctly but after N bits it'll start going wrong.

I know the latter can apply to UART but I'm unsure of SPI. Of course, in UART there is no shared clock, and in my setup, I'm providing a clock that is 2.34375 % too slow.

Thanks for your thoughts.

Rich

Added: the kit I'm talking to is circa 15 years old. It wont be some modern 32 bit ARM cored thing, it's a car CD player from the turn of the millenium.

Pictures that show 'good' and 'bad' behaviours:

This is the proper behaviour, between my CD player and geniune connected equipment:

enter image description here

This is with my incorrect clock rate:

enter image description here

This makes me wonder if the slave device is infact a real SPI device, or some microcontroller doing bit-banging out of time to me.

RichColours
  • 121
  • 3
  • What is the slave device? Typical SPI devices are not sensitive to clock rate, but yours might be a special case. – The Photon Jan 14 '17 at 19:14
  • We need the actual model number and datasheet to tell. A typical SPI clock rate spec is something like "10 kHz to 3 MHz". But if your CD player is (for some idiotic reason) using the SPI clock as the reference for regenerating the audio then all bets are off. – The Photon Jan 14 '17 at 19:32
  • Thanks Photon. It's the data channel out of the cd player, not the audio. It's not got a datasheet, I've sampled the clock that would be fed into it by a geniune compatable master device and it's 128 kbps. So my pretend device is 125 kbs, 3 k too slow (at the moment). – RichColours Jan 14 '17 at 19:37
  • I agree, my gut is saying that my slave ought not be that sensitive. Mind you, there needs to be _enough_ time between bytes to reload a FIFO (or single byte buffer) to transmit the new data out. – RichColours Jan 14 '17 at 19:42
  • There are ways to generate a 128 kHz clock from an 8 MHz reference. Most SPI systems would allow a bit of variation in clock pulse width, you just need some logic in your clock divider to make 1/2 the cycles divide-by-61, and the other 1/2 divide-by-62. At the extreme you could also use a fractional-N PLL, but that's probably overkill. – The Photon Jan 14 '17 at 19:42
  • 1
    That's not SPI. SPI transfers bits on clock edges and that thing is toggling its data line even when the clock is idle... I'd suspect its some sort of crude bit-banged comms. – brhans Jan 15 '17 at 03:19

1 Answers1

1

Clock difference is no problem with spi since the master generates the clock that eventually is used by the slave. You should check the maximum allowed clock of the slave of course. You are probably looking at configuring the tx clock settings of your spi pheripheral of the slave, but they are not used in slave mode. The settings might influence the maximum allowed clock if is some sort of a clock devider for the pheripheral as a whole. Set it to max speed in slave mode if power consumption is no problem.

martijndb
  • 104
  • 3