SPI: more than 8 bits?

[Vizier87]

Hi guys,

I've been perusing some LCD codes and most of them write their own SPI bit-bang codes. I, however, want to use the peripheral SPI, but some of these LCDs are 9 or 12 bits or more, so I need to know whether it is possible to transfer more than 8 bits using the SPI feature in PICs?

I Gurgled with keywords like "9-bit SPI with 8-bit PIC" and "transmit more than 8-bit SPI PIC" but the returns are all nada....

Thanks for the feedback.
Vizier87.

 

[kubeek]

I would think that it is not possible to use a hw 8bit spi to do anything else than multiples of 8bits. That is beacuse even if you padded the last byte with zeros, the clock will still be there so the lcd will try to interpret the data.

 

[Gobbledok]

No, you can only transfer 8, 16 or 32 bits, depending on the PIC.

Are you able to even it out? Say if it is a 12-bit interface, can you send 2 words (3 bytes) at a time ?

 

[Ian Rogers]

You can shift out multiples of 8 at a time..... so 8, 16, 24 bits.... However if your device only needs 12 just make sure the data is justified before you send .... as long as the 4 bits lost are the correct one's it wont matter..

The devices usually lock on when there has been 8 / 16 / 24 clocks... When I made a Serial Lcd it used 5 bits (4 data and one for RS) it worked well with an external E signal.

 

[Vizier87]

No, you can only transfer 8, 16 or 32 bits, depending on the PIC.

Are you able to even it out? Say if it is a 12-bit interface, can you send 2 words (3 bytes) at a time ?

Well that's another question myself. How do I test that again?

You can shift out multiples of 8 at a time..... so 8, 16, 24 bits.... However if your device only needs 12 just make sure the data is justified before you send .... as long as the 4 bits lost are the correct one's it wont matter..

The devices usually lock on when there has been 8 / 16 / 24 clocks... When I made a Serial Lcd it used 5 bits (4 data and one for RS) it worked well with an external E signal.

Yo Ian thanks for the input. Can you elaborate on that? I don't understand the part when you said it needs to be justified. Is it like the ADRESH:ADRESL kinda justification? How about the external E signal?

Thank you everyone for the input.

 

[Ian Rogers]

Take the example of the shift reg..... Let's say we connect Q0,Q1,Q2,Q3 & Q4, to an LCD 4 bit mode display... D4,D5,D6,D7 * RS.. Five bits but the SPI is gonna send 8 bits so if you make sure the data is left justified.. the SPI module spits out MSB first.... so if your data is in the lower 5 bits... who cares what happens to the first three out... (as long as there zero's and cause no harm) the 5 remaining bits will be where you want them when you clock the E pin...

 

[Nigel Goodwin]

Hi guys,

I've been perusing some LCD codes and most of them write their own SPI bit-bang codes. I, however, want to use the peripheral SPI, but some of these LCDs are 9 or 12 bits or more, so I need to know whether it is possible to transfer more than 8 bits using the SPI feature in PICs?

What LCD's are you talking about?, if they have an SPI interface, then they will work with multiples of 8 bits.

Also, as all the code out there uses software, why on earth would you want to try and use the SPI hardware? (which probably isn't suitable anyway).

 

[Vizier87]

What LCD's are you talking about?, if they have an SPI interface, then they will work with multiples of 8 bits.

Of course they do, but as you said its multiple of 8 bits. The PCF8833 LCD driver is 9 bits.

Also, as all the code out there uses software, why on earth would you want to try and use the SPI hardware? (which probably isn't suitable anyway).

So it is better to write your own SPI software? I just have a problem understanding the codes out there. Modifying the codes out there didn't help my endeavor (and didn't help me understand how it works either) so I thought of trying to write the code myself. It is a big challenge though.

So what do you suggest? Thanks for the input anyway.

Vizier87.

 

[ronsimpson]

I am also looking at 8/9 bit SPI for a LCD from sparkfun.com.
I want to use the hardware SPI in an interrupt and do other tasks while the data is shifting out. A software SPI eats up 100% of the CPU time.
The 9th but is used for data/instruction and will be set to data most of the time. I have thought about using hardware SPI for 8 bits and then in software adding one more bit but that timing is complicated and eats up CPU time.

What bugs me is that the hardware can do parallel, 8 bit or 9 bit but someone only brought out the wires for 9 bit. Maybe I can hack it.

 

[Vizier87]

I am also looking at 8/9 bit SPI for a LCD from sparkfun.com.
I want to use the hardware SPI in an interrupt and do other tasks while the data is shifting out. A software SPI eats up 100% of the CPU time.
The 9th but is used for data/instruction and will be set to data most of the time. I have thought about using hardware SPI for 8 bits and then in software adding one more bit but that timing is complicated and eats up CPU time.

What bugs me is that the hardware can do parallel, 8 bit or 9 bit but someone only brought out the wires for 9 bit. Maybe I can hack it.

Now that part is also a constraint isn't it. Mine's got ADC, UART, and 17 keypad buttons running too. I'm not sure if it can do the task?

 

[Ian Rogers]

Just looking at the datasheet..... If you use the serial port in I2C mode...You will be able to send the data 8 bits.... If you use sendNACk and sendACK this will give you the D/C signal before the 8 bit shift....

I would give it a go, If I were you...

 

[ronsimpson]

If you are only updating a small part of the LCD then speed is not important.
I am trying to update 100% of the LCD fast enough to make real time motion.

 

[3v0]

A bit banged SPI is not near as bad as a bit bang UART. In most cases there are no delays with the SPI.

 

[Vizier87]

Just looking at the datasheet..... If you use the serial port in I2C mode...You will be able to send the data 8 bits.... If you use sendNACk and sendACK this will give you the D/C signal before the 8 bit shift....

I would give it a go, If I were you...

Err did you mean 9 bits?

If you are only updating a small part of the LCD then speed is not important.
I am trying to update 100% of the LCD fast enough to make real time motion.

Yes, it's supposed to be real-time too. I'm want to read my data hopefully as fast as it can.

A bit banged SPI is not near as bad as a bit bang UART. In most cases there are no delays with the SPI.

So....... I should use hardware SPI?


Whoa I'm really dizzy with the options now.

 

[Nigel Goodwin]

Of course they do, but as you said its multiple of 8 bits. The PCF8833 LCD driver is 9 bits.

No where in the PCF8833 data-sheet does it claim to use SPI, it uses a "3-line serial interface"

So it is better to write your own SPI software? I just have a problem understanding the codes out there. Modifying the codes out there didn't help my endeavor (and didn't help me understand how it works either) so I thought of trying to write the code myself. It is a big challenge though.

So what do you suggest? Thanks for the input anyway.

Software serial routines are absolutely trivial to write (and understand), adding a ninth bit (or more if needed) is simple as well - in this case you need to send that one first. Simply place the value you want on the data pin, and then apply a clock pulse to the clock pin, for the 8 data bits, do the same in a loop.

It's pretty well identical to what you do for writing PIC programming software, except it's more than nine bits

 

[Ian Rogers]

Err did you mean 9 bits?

You don't have to stay with convention

 

[DirtyLude]

No where in the PCF8833 data-sheet does it claim to use SPI, it uses a "3-line serial interface"

3 line serial is a version of SPI. I've noticed some datasheets avoid using the terms SPI or I2C even though they support them, possibly due to some trademark issue with the terms. There's no hard standard for SPI that says it has to be 8bits.

If you want to do it software, I would at least throw it into a timer and have a buffer you can throw your screens into to be clocked out.

You could always complicate your life even more and switch to an ARM variant, all the ones I've worked with support 4 to 16bits in 1bit increments with the hardware serial peripheral.

 

[Vizier87]

No where in the PCF8833 data-sheet does it claim to use SPI, it uses a "3-line serial interface"

Software serial routines are absolutely trivial to write (and understand), adding a ninth bit (or more if needed) is simple as well - in this case you need to send that one first. Simply place the value you want on the data pin, and then apply a clock pulse to the clock pin, for the 8 data bits, do the same in a loop.

It's pretty well identical to what you do for writing PIC programming software, except it's more than nine bits

Okay thanks Nigel. So I suppose I'll just start from a software SPI. Will update later... in a thousand years I suppose . I'm just molasses when it comes to programming a bit further than using the peripherals directly. But then comparing to the years I didn't know any C programming (that was 6 months ago) it sure is a big leap for me.


To the rest of the guys: Thanks for your replies, apologies for not quoting them in this post, but rest assured I'll be visiting this link often to recapture info from your replies.

Vizier87

 

[Nigel Goodwin]

3 line serial is a version of SPI.

I would say the exact opposite - SPI is a specific version of a three line serial protocol.