Remapping USART3 to SPI3 @STM32F107 not possible?

[dbeken]

Posted on August 22, 2012 at 20:57

Hello everyone,

I am working with the STM32F107 chip on the STM32F107VC board from IAR.

The evaualtion board has an LCD which has as its inputs SPI3_MOSI and SPI3_SKC. But since it needs to have 9 bit inputs, i can communicate with the LCD either by manually

bit-banging or USART (which has a 9 bit output option).

But according to the datasheet, i can only remap USART3_SCK to SPI3_MOSI and USART3_TX to SPI3_SCK.

First of all, i can not understand, what the purpose of the above remap option can be. Is there a way, I can remap the TX of any USART to the SPI3_MOSI pin (and the Clock signals respectively)?

I hope to get an answer. If USART to SPI is not possible with STM32F107, I will do bit banging, not to loose any more time.

I am very new at embedded programming and this is my first post. I am sorry if i did not follow any rules or forgot gave any necessary information.

Thanks in advance. 

#spi-usart-stm32f107

[Tesla DeLorean]

Posted on August 22, 2012 at 21:35

Your remapping choices are limited, you appear to have identified them correctly.

Seems odd IAR would have connected an LCD in a manner you couldn't communicate with it, have you looked over their demo code, or inquired further with them?

Not sure 9-bit synchronous USART is an ideal replacement for SPI

Can you not send 9x 8-bit bytes in place of 8x 9-bit values?

[dbeken]

Posted on August 22, 2012 at 22:50

Hi Clive,

first of all, thank you for your quick response, as always.

To honestly answer your question about 9x8bits instead of 8x9 bits: I don't know.

In the example code of ST, SPI3_MOSI and SPI3_SCK pins (connected to the LCD), are mapped straight to the GPIO. So for each bit to transfer to the LCD, the GPIO Pins are manually set high and low. The timing is establishedby software loops. After reading your older posts, I decided to use Timers, if I have to implement the Bit-Banging option (because of the unreliability of the software loops).

But besides my least favorite option, Bit-Banging: here are my questions about using the SPI-TDR or the USART:

The LCD is a Nokia 6610 using an Epson Microcontroller (S1D15G00). The first bit indicates either data or command, and the rest 8 bits contain the information. I hoped that maybe, the LCD controller can wait for the completion of the current command/data when I use the SPI TX Buffer of 8 or 16 Bits. So I could send maybe 9x16 bits (which would be unfortunately a lot overhead for some short data/commands), and the LCD Controller puts it all together. If so, I could use the ST-Firmware with the SPI_I2S_SendData function.

But then, yesterday, I discovered this post in the STM32 Forum:

/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/9bit SPI&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=846

After reading the responses, I thought that it is not possible to control the LCD over the 8/16 bit SPI peripheral (by using dummy bytes etc). Reason i thought of was, that if a SPI-RX expects 9 bit SPI data, the SPI-Tx needs to send 9bit data (the Atmel Controllers with ARM processor have the 9 bit option).

Unfortunately, from the Epson Datashet (in the attachement), I can not read it directly out, if the Microcontroller is clever enough to wait for the completion of the inputs, and then stores valid data for representing a pixel into its RAM or issues a respective command.

Unfortunately, i spent my time understanding the material instead of experimenting, but this is what I will do next.

But to summarize:

1- You confirm, that in deed if the mapping to the SPI3_MOSI (Pin 80) and SPI3_SCK (Pin 78), which is as following picture (this is from the IAR Board Schematic but the same is in the Datasheet of the STM32F107), does not allow mapping USART3 to them?

2- So from what I understand from your direct open question is that you advice me try to put maybe like 9 bits into the 16 Bit SPI-TDR (Transmit Buffer) and try out different configurations and see if maybe something works with the Epson Microcontroller (at least, there is nothing in your mind speaking obviously against it.). But then, I can not understand, in the Link I gave, this was not mentioned. Also in the example code of IAR, bit banging is used.

Can you answer please these 2 urgent questions?

Cheers,

Dincer

________________

Attachments :

EpsonDS_S1D15G00_REV1_0.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HztW&d=%2Fa%2F0X0000000bQp%2FU2lccpJew_08UyjvEJFFI.9QqWd8WkPbOoifOO3tNTE&asPdf=false

[dbeken]

Posted on August 23, 2012 at 02:18

Hi again,

i just wanted to keep it short and ask my question about different sized SPI Peripherals again (in addition to the USART mapping question above):

If my STM32F107 has a built in SPI that i

s only for 8 or 

16bit, 

could I use this 

16bit

 SPI HW interface 

with

 only 9bits of valid data? Irregard to the LCD controller, would 7 extra clocks of bogus data cause problems? I gave this a try and it didn't work. I just wanted to see if there might be a way to hack around this.

Thank you,

[Tesla DeLorean]

Posted on August 23, 2012 at 17:08

I haven't played with these displays.

The placement of the -CS would appear to complicate things, probably making the 72-bit transfer method impractical.

How the part deals with the CS, and how it demarcates the 9-bit, it's hard to know. I suspect the part doesn't count bits, most silicon doesn't. Instead it probably latches the 9-bit internal shift register at the rising edge of -CS. You'd have to experiment with the bit alignment within the 16-bit sent by the STM32. I'd focus on the last 9-bit sent.

The 9-bit USART might be usable, but again you have to deal with -CS pin. I think there was some discussion some time back about using it with an RC controller or display, that had used 9-bit serial on an AVR.

For a SW delay loop, using the trace unit's cycle counter would be a way to enforce a minimum signal time on the pin, but the maximum would be hard to control, and the duty would also likely be rather rough. The part may not care too much.

[dbeken]

Posted on August 23, 2012 at 18:20

Hi Clive,

again thank you for your response and thanks that you throw an eye on the EPSON manual in the attachements.

I understand with what you mean by the CS Pin and i will keep experimenting.

What I did not understand was what you meant with 

''The 9-bit USART might be usable, but again you have to deal with -CS pin.''

If the mapping of the USARTs to the SPI is as in the caps above, how can you use them? How can you use the USART_Tx on the SPI_SCK or the USART_SCK on the SPI_MOSI?

I fundamentally can not understand that.

Does not this configuration basically kills the option of using USART on SPI?

Thank you.

[Tesla DeLorean]

Posted on August 23, 2012 at 19:21

I don't think the USART is at all practical in your circumstances, in the other thread I don't think they were hog-tied to a specific board and wiring. It's usable in the ''general'' sense of getting 9-bits of clocked data out of the STM32's.

The placement of CS is also problematic with the USART, because nothing is going to do that automatically.

I suppose one might be able to DMA 32-bit values into GPIOC->BSRR and drive patterns onto the pins.

There are a number of weak design choices made in the peripherals in the part, for the sake of a fractional number of gates.