cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 - Serial Comms with 9 bit data PLUS parity - How to go about it..

gmamo
Associate II
Posted on January 23, 2011 at 01:34

STM32 - Serial Comms with 9 bit data PLUS parity - How to go about it..

34 REPLIES 34
Posted on May 17, 2011 at 14:22

''I think I must generate the signal by hand without hw support.''

From the foregoing discussion, it seems that the AVR is unique in the facility to support both  9-bit data and  parity simultaneously - so, if you want hardware support, that hardware must be (or include) an AVR!

The OP says that this display unit is widely used in RC circles - so I guess those would be the places to search for help...

Have you tried contacting the manufacturer?

Are you really tied to this particular display?
krk2
Associate II
Posted on May 17, 2011 at 14:22

Switching to another controller is not possible for me because HW is fixed now.

I have not contacted the manufacturer because I think that they will not modify there protocol just for me and a few other guys :)

Yes I am tied to this particular display because it is the display unit for a specific RC transmitter / receiver combination. The other option would be to replace the firmware of these parts too. But this is now too time expensive for me.

Posted on May 17, 2011 at 14:22

''Switching to another controller is not possible for me because HW is fixed now.''

I wasn't necessarily suggesting that you switch processor - just noting that the AVR seems to be the only thing that can do this in hardware!

However, have you considered adding a (tiny) AVR as a ''protocol adaptor'' between your STM32 and the display...?

''I have not contacted the manufacturer because I think that they will not modify there protocol just for me and a few other guys :)''

 

I can't imagine that the market is that big anyhow...?!

(and that fact that 2 users have turned up in the same week on this one forum does tend to suggest that it's not an isolated problem)

But, unless you contact them, they won't know how much grief they're causing - will they?

Also, they may be able to offer advice on how to implement their protocol on ''normal'' processors.

''it is the display unit for a specific RC transmitter / receiver combination.''

 

So the implementors of that system must have managed to do it...

gmamo
Associate II
Posted on May 17, 2011 at 14:22

 

Posted on May 17, 2011 at 14:22

''as the suggestion to make use of an AVR to translate from 8N1 to 9O1+ extra bit.... one must make sure to use an AVR microcontroller that has at least 2 HW Uarts''

Indeed.

But one could also use SPI, I2C, or suchlike between the AVR and STM32...

Perhaps there's a market for such a device...
krk2
Associate II
Posted on May 17, 2011 at 14:22

Sure, the transfer chain is as follows:

STM <-a-> AVR <-b-> RF <-> AIR <-> RF <-b-> AVR <-a-> AVR

-a-: This is always the known strange 9 bit protocol

-b-: This is communication protocol between the transmitter AVR and the used RF chipset. But the used ''internal'' protocol and system behaviour is not public and unknown. Finally the right AVR is the controller within the display unit.

What I really do not want is to add an additional protocol translater AVR between STM and left AVR :) The best solution would be to replace the firmware of the AVR´s by an own one. But I have not time for this job.

Posted on May 17, 2011 at 14:22

 I am still intrigued, as to how to manage to clock in the SPI from an outside source ( I would not like to release a timer from its use to make the timebase... I'd use my unused UART clocking out 0x55 as my timebase ;) which is a continuous 101010101010...

 

Can you shed some light, as this might be a real elegant kludge, as you kindly inspired. I havent managed to clock SPI low enough to be able to reach 9600. Would really prefer not to use a special crystal and higher PLL multiplier.

 

Otherwise, it will have to remain software interrupt Uart. ??

This was a back-of-a-napkin thought. But you should be able to use the input clock when in slave mode. A quick look at the reference manual

24.3.2 Configuring the SPI in slave mode

 

In the slave configuration, the serial clock is received on the SCK pin from the master device. The value set in the BR[2:0] bits in the SPI_CR1 register, does not affect the data transfer rate.

You should be able to generate a synchronous baud clock from a USART CK pin.

The following pin is required to interface in synchronous mode:

 

�? CK: Transmitter clock output. This pin outputs the transmitter data clock for

 

synchronous transmission corresponding to SPI master mode (no clock pulses on start bit and stop bit, and a software option to send a clock pulse on the last data bit). In parallel data can be received synchronously on RX. This can be used to control peripherals that have shift registers (e.g. LCD drivers). The clock phase and polarity are software programmable. In smartcard mode, CK can provide the clock to the smartcard.

The thought was also predicated on the STM32 simply sending to the display, not receiving back from it.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
gmamo
Associate II
Posted on May 17, 2011 at 14:22

 

gmamo
Associate II
Posted on May 17, 2011 at 14:22

gmamo
Associate II
Posted on May 17, 2011 at 14:22