help request about synchronous serial interface

[roby]

I need to read the position from an absolute encoder with synchronous serial interface (called SSI) with a PIC micro.
Do You know how I can do?
Does SSI means SPI? Or, as I read in some datasheets found in internet with google, SSI is a RS-422 interface?
And if it is RS-422, what can I do? Is it possible to use UART? Is the same as RS485?
Is there somewhere in internet an example code? (even not in C but in assembler)

Thank you

[Ttelmah]

RS-232, and 432 etc., are _signalling voltage specifications_, _not_ descriptions of the actual data format used. Conversely, SPI, synchronous serial, and asynchronous serial, are descriptions of a data 'format'. Some titles cover both (I2C for example).
Unfortunately, the terms do get 'crossed', so we have the CCS "#use rs232" statement, which actually has nothing to do with 'RS232', but can equally well be used over RS485, just with different driver chips used. It in fact controls the setup of the hardware port for asynchronous TTL serial, which can be converted to 'RS232', using a suitable bus driver...
Now 'SSI', describes a bus, using RS422 signal levels, and a synchronous clocking scheme. However on it's own, it still does not describe the full data format used. There are other titles, normally attached to this, such as "Stegmann SSI Norm", which then give the packet format as well. You can drive a SSI bus, depending on the clocking scheme, from the USART module, or the SPI module, with in both cases RS422 transceivers added. For the USART, this will have to be setup for synchronous operation, which is not the default configuration for the CCS drivers.
Alternatively, this type of bus can be driven by 'bit banging, and because it is a synchronous bus, this is relatively easy to get working.
Unfortunately, many of the SSI position encoders, use a format with an unusual number of bits (in computer terms), often with values like 25 bits required, which cannot be implemented usng the hardware solutions, hence the bit bang solution becomes necessary. You need to start by getting the full data sheet for your encoder, which will include which edge the data shuld be sampled on, how many bits are send, and the format used (usually either straight binary, or a grey code).

Best Wishes

[Guest]

Thank you for your useful reply.
I have another question: if I use a 12 bit SSI encoder, using a pic 24f, with 16 bit buffer, can I use pic hardware or I need bit bang?

Thank Yuo again

[Ttelmah]

It'll depend on the unit. Some support a 16bit 'mode', where 12 data bits are sent, with an extra four padding bits. However it is worth not being 'afraid' ofthe bit-banging solution. Most of these devices a relatively simple to drive (the synchronous interface, means that breaks/delays in the master timing, don't matter), and the basic method of bit banging a sequence is shown in a couple of the CCS examples.

Best Wishes

[Guest]

Please, do know konw which examples I can read to understand the problem?

Thank you

[Ttelmah]

Seriously, a hell of a lot of them!. As a typical example, look at the driver file 'ltc1298.c', which clocks in a byte using the function 'read_adc_byte', with the number of bits to use, software definable. Change this to use an int16, and up the clock rate to the limit in the data sheet for your sensor, and you have a read function. Similar functions exist in a lot of the other drivers, including some ofthe SPI ones, which are written to be able to work on chips wthout the SPI hardware.

Best Wishes

[roby]

I need another information (I hope that it is the last).
On the datasheet of the encoder I read that in the data bits there is an even parity checksum. Do you know if there is an example that shows to me how I can calculate it?

Thank You

[Ttelmah]

Um.
A checksum, and parity, are two different things. Even parity, just means adjusting the total number of 'ones' in the sent data, to make this even.
If you are receiving the data, you don't calculate the parity, but just _check_ it.
So in the serial routine, when a new word starts, set a counter to zero. Then for each bit, if it is a '1', increment the counter. When you finish, the result should be 'even' (have nothing in the bottom bit). If it is not, then you need to read again.
If it has a checksum, you will need to know the algorithm. There are thousands of different types.

Best Wishes