9bit SPI

[tre2020067]

Posted on October 17, 2011 at 21:30

can i but 9 bits in the SPI Tx buffer configured in 8bit mode and have it still clock out all 9 bits???

[Tesla DeLorean]

Posted on October 17, 2011 at 22:17

can i but 9 bits in the SPI Tx buffer configured in 8bit mode and have it still clock out all 9 bits???

 

Doesn't it only support an 8 and 16-bit mode?

The USART has a 9-bit mode, are you thinking about that?

[emalund]

Posted on October 17, 2011 at 22:57

can i but 9 bits in the SPI Tx buffer configured in 8bit mode and have it still clock out all 9 bits???

No, but SPI is dead simple to bit-bang

I do not know if SPI was initially designed as 8-bit or ''any bit'' but a few people make equipment that use different bit counts and the hardware SPI makers only believe in 8

Bang those bits

Erik

PS if the''SPI clock rate'' is low and  if you do it in a loop the overhead can be quite large, in a Timer ISR it will be reasonably efficient.  If you have a 20MHz capable SPI chip a loop will do fine.

PPS the 9 but UART mode is not available in mode 0(?) so only the modes creating start and stop bits (which will upset your SPI ) and do 9 bits

[tre2020067]

Posted on October 17, 2011 at 23:21

Thank you Clive1 and Erik for the prompt responses. 

the reason i ask is i am trying to interface yet another lcd. this one is the Nokia6100(epson)from sparkfun.

i had success with this lcd in the past on the PIC 16f627a by just bit banging. 

 

however with this stm32 its not the case. screen flickers but wont draw. go figure.

ive tried the bit bang routine and can verify the pins are firing but maybe to fast perhaps?(core: 72mhz, GPIO: 50/10/2)

 

 

From: malund.erik

Posted: Monday, October 17, 2011 10:57 PM

Subject: 9bit SPI

can i but 9 bits in the SPI Tx buffer configured in 8bit mode and have it still clock out all 9 bits???

No, but SPI is dead simple to bit-bang

I do not know if SPI was initially designed as 8-bit or ''any bit'' but a few people make equipment that use different bit counts and the hardware SPI makers only believe in 8

Bang those bits

Erik

PS if the''SPI clock rate'' is low and  if you do it in a loop the overhead can be quite large, in a Timer ISR it will be reasonably efficient.  If you have a 20MHz capable SPI chip a loop will do fine.

PPS the 9 but UART mode is not available in mode 0(?) so only the modes creating start and stop bits (which will upset your SPI ) and do 9 bits

[Tesla DeLorean]

Posted on October 18, 2011 at 00:39

@trent the max speed at which you can drive the GPIO is about 1/4 the APB speed. The speed of the IO drive basically defines how strongly the line is driven (slew rate), and the sharpness of the edges. If you need to have a slower SPI bus you'd need to spin in a loop between writing GPIO pins. Either a software loop, or counting core ticks.

@erik, SPI comes in many forms, the 8/16-bit typically has more to do with how it is buffered/staged before being output. It is possible to send out a very long stream of bits, in much the manner of scan-chains, or JTAG, where the loop length isn't known or multiple devices are chained together.

[emalund]

Posted on October 18, 2011 at 18:58

however with this stm32 its not the case. screen flickers but wont draw. go figure.

 

 

ive tried the bit bang routine and can verify the pins are firing but maybe to fast perhaps?(core: 72mhz, GPIO: 50/10/2)

 

 

Very  likely, LCDs are quite often a bit slow.

 

 

An easy test would be to insert some delay to make it run, say ~500kbits.  A Nokia LCD sounds like salvage, so you probably do not have and can not get a datasheet.

 

 

Erik

 

 

Very  likely, LCDs are quite often a bit slow.An easy test would be to insert some delay to make it run, say ~500kbits.  A Nokia LCD sounds like salvage, so you probably do not have and can not get a datasheet.Erik

[Tesla DeLorean]

Posted on October 18, 2011 at 19:30

http://www.classic.nxp.com/acrobat_download2/datasheets/PCF8833_1.pdf

Minimum SPI clock period 150ns, so 6.667 MHz, for the Philips incarnation of the display driver.

http://gnuarm.alexthegeek.com/lcd/Nokia_6100_LCD_Display_Driver.pdf

Maybe you could do this using a synchronous serial mode of the USART?

[tre2020067]

Posted on October 26, 2011 at 10:06

ty for your response and please excuse the delay(school stuff), clive1.

im curious how did u calculate the clock speed 6.667mhz?

as for usart, i havent covered that much ground on this uC but i hope to very soon.

could i just use the systick to add delays so i can get the timing more percise. as of right now, im not sure how fast they are firing. i know my board is set to 72mhz.  so its 18mhz??

is this right?

[tre2020067]

Posted on October 26, 2011 at 10:14

erik, ty for the response. i am working on using a oscope and tuning software delays. i have one tuned to 19.5ms+/-.5 period. maybe if i add a couple of these loops? im also thinking i could use the systick since its pretty accurate.

[emalund]

Posted on October 26, 2011 at 14:52

yes, any timer will do

BEWARE of loop delays in C thgey are TOTALLY unreliable

Erik

[Tesla DeLorean]

Posted on October 26, 2011 at 16:21

I'd use the core cycle counter, it would have a resolution of 72 MHz (13.89 ns).

Standard conversion of period into frequency

1/150e-9 = 6.667 MHz

Figure also 1 MHz = 1000 ns, thus 1000 / 150 = 6.667

Minimum Period translates to Maximum Frequency, ie smaller period, higher frequency.

The SYSTICK interrupt can be set at any period, within the limit of the hardware. If it's too high you'll just saturate the processor. Personally I'd be looking a 1 KHz (1ms) or 10 KHz (100us) for a SYSTICK driven ticker.

As Erik points out pure software spin loops don't always compile or run in a predictable way. That why you'd want to reference some kind of free running timer.

start = current; // current is a volatile time base

while((current - start) < 1000);