Clearing SPI buffer ?

[mindstorm88]

Hi guys, I have to synchronise my slave with incoming data, data is 24 bits, if on power up I do receive lets say the last 5 bits (not a complete bytes) how do I clear the buffer to be ready for the next incoming burst ???

It seems that spiread() will wait to receive bits to complete the byte before clearing the buffer !!!!

Thanks

[Ttelmah]

This is where a slave select line really comes in.
It allows you to synchronise the slave with the master. Without this, you always have the potential problem of one starting at the wrong 'point' in the data.
Assuming you can't implement such a line, then what you need to do, is not start the SPI, till you are in the 'gap' between the bursts. Don't setup the SPI, at the start of the code (don't use the #use SPI option), instead monitor the clock line as a normal 'input'. Look for the gap between clocks. You will probably have something like 3 groups of eight clocks, then a pause. So, if you monitor the clock line, timing how long it is between the edges, till you see a gap 'longer' than the time between characters, then you are now in the gap. At this point call the setup_spi function to configure the SPI.

Best Wishes

[mindstorm88]

Thanks Ttelmah

I'll try it !!! The reality is that I don't really need spi !!!
I'm receiving burst of 24 bits coordinate about every 200 ms from the
sensor. If I would know how to do it without spi it would be better as I
will have to hookup two of these sensors on the same micro then display
it on LED display !!!!

I'm newbie with serial communication !!!

[Ttelmah]

It is not clear from your post, what the 'sensor' actually sends?.
SPI, is a synchronous protocol. If the sensor is sending SPI data as a master, then it _must_ generate the clock for the data as well. Hence my post.
If it is not sending a clock, but uses SPI, then it will expect _you_ to send the clock, so the synchronisation comes under your control.
If there is no clock at all, then the inteface is not SPI.
Standard async serial, generates independant clocks at each end. With this, in your example, the first packet would be garbage, but soon as there is a break in the stream, the link would resynchronise.

Best Wishes

[mindstorm88]

[RLScott]

[mindstorm88]

how do you disable it ???

[FvM]

I don't see a specific CCS C built-in function for this, setting continuous receive bit in RCSTA directly should do

[Ttelmah]

Wrong peripheral Fvm. The CREN bit is for the UART, not the MSSP.

You can do it with the CCS functions, as:

[FvM]

You're right, sorry for that. SSPEN should be the correct SFR bit to disable MSSP, hopefully not affecting the other settings.

[mindstorm88]

[Ttelmah]

That is SPI.....
It may only be part of the interface, but that is all that SPI involves. The key is though that somewhere in the sensor's data sheet, there must be data saying whether the line idles high or low, and which edge of the clock data should be sampled on. These two bits of data are 'essential'.
Software SPI, does not really support slave operation, only master.

Best Wishes

[FvM]

[Ttelmah]

Yes.
This is why I said 'does not really', rather than 'does not'.
In slave mode, using software, the chip has to be sitting _waiting_ for the first active edge, in the read routine. It cannot do anything else, without losing data. It won't handle anywhere near the required 80KHz, even on the fastest PIC.
With the SS line, it can be used, by having the select line, trigger an interrupt, and then in the interrupt handler, waiting for the byte. However the speed still means you are in the routine for a long time...
Seriously, two solutions. Either choose a PIC with two hardware SPI ports. A few of the 18 chips have these, or use an external shift register to latch the data. The latter is really easy, then load the data in parallel from this.
You can also use the same approach outlined right at the start, of looking for the gap between the data packets, then releasing the clear line on the shift register, to synchronise.

Best Wishes

[mindstorm88]

Thanks guys, I succeeded in creating my own receiving firmware, synchronisation is good now, worst case is losing the first packet when switching from 1 sensor to the other as I don't know how I could read both at the same time !!!