I have to send 9 bits and only 9 bits to a device on the SPI interface. It seems that the SPI interface will only send 8 or 16 bits, but is there a way to send just one bit? I tried to bit bang the 9th bit but I don't know of any way of turning off the hardware SPI interface. :(
Any help would be appreciated.
perry
Administrator
hi wilson,
The hardware spi peripheral on the stm32 doesn't support 9-bit spi, only 8-bit and 16-bit data frames. It appears that you can use the USART to generate 9-bit frames, take a look at this post:
http://www.micromouseonline.com/forum/viewtopic.php?f=7&p=2756
It seems that getting the USART port to send 9 bit serial data isn't as easy as I thought it would be. I thought I would alter the serial/usart setup routines in lib but I'm not sure that this would be a good idea since i would have to do work every time a new version of the maple IDE was released. Is there any plans to add more options to the SerialN.begin(baudrate) command?
poslathian
LeafLabs
I believe i2c can be configured with a 9 bit frame (were working on adding a hw interface to i2c). does your device support i2c? If not, there still might be a way to hack something together. I have actually seen a few reference implementations of driving various nokia lcd's via stm32, Ill take a look.
I am trying to use the usart in the synchronous mode with 9 bits but I can't seem to get the external clock signal to work. Here is some of the code I added to usart.c
I set the M bit to get a 9bit frame, and CLKEN to get the external clock signal. any idea why I get just data but don't get the external clock?
port->CR1 = USART_TE | // transmitter enable
USART_M | // 9 bit data enable (I added this)
USART_RE | // receiver enable
USART_RXNEIE; // receive interrupt enable
port->CR2 |= USART_CLKEN; // enable the SCK clock pin (I added this)
/* Enable the USART and set mode to 9 synchronous mode */
port->CR1 |= USART_UE;
poslathian
LeafLabs
did you appropriately configure the sck pin into AF_OUTPUT?
when you configure a peripheral to use external pins (like spi or i2c or usart) the pins need to be enabled in the GPIO control regs, as well as enabling the peripheral register, as well as enabling the clock control (rcc) register corresponding to the used GPIO bank and the peripheral itself. It sounds a bit much, but we do this for you in most cases.
For example, to use Serial1.begin(), the wirish library is setting up the tx and rx pins first and then calling usart_init which calls the rcc (clock config) init, and then finally enables the usart peripheral itself.
in HardwareSerial.cpp:
in function HardwareSerial::begin
on line 75, see how gpio_set_mode is called to init the pins? add to that a call to setup your sclk pin, set it to GPIO_MODE_AF_OUTPUT and you should be all set!
we will have to think of the right way to integrate this into the library, since by default the sclk pin isnt used.
Thanks for the help. I thought setting the clock pin as an output using pinMode would be enough but as it turns out I needed to use GPIO_MODE_AF_OUTPUT. I was able to get the the lcd display working but I still have a problem with the chip select (CS) going high when the usart is still sending data. Is there any way to be sure that all the data has been sent from the usart port before I set the CS high? I am using a delay right now but that will slow things down too much.
poslathian
LeafLabs
There should be some low level registers that indicate when transmission is busy/completed, and these can be configured to fire interrupts if you want them to. This is probably best configured with the DMA (so you can toggle CS around mutli-byte transmissions), which will have library support soon. But the temporary hack solution is to just poll the status registers. I should point out that the USART's can be configured to automatically control the CS lines, with some more hacking - since the frontend for that is not provided by the library.
the register you want is the "SR" register of the given USART port you are using (1, 2, or 3). The TC bit (bit 6) of the SR register indicates whether or not the transfer is complete (which you can use to determine when to manually toggle any CS line).
The standard USART regmap can be typedefed like this:
/* peripheral register struct */
typedef struct usart_port {
volatile uint32 SR; // Status register
volatile uint32 DR; // Data register
volatile uint32 BRR; // Baud rate register
volatile uint32 CR1; // Control register 1
volatile uint32 CR2; // Control register 2
volatile uint32 CR3; // Control register 3
volatile uint32 GTPR; // Guard time and prescaler register
} usart_port;
and youll want to setup the object like this:
usart_port *myPort = (usart_port*)(ADDR);
where ADDR is one of:
#define USART1_BASE 0x40013800
#define USART2_BASE 0x40004400
#define USART3_BASE 0x40004800
#define UART4_BASE 0x40004C00 // High-density devices only (Maple Native)
#define UART5_BASE 0x40005000 // High-density devices only (Maple Native)
Finally got the display working. http://www.flickr.com/photos/55765056@N06/5164571962/
We are still having problems with detecting if the last data bit has been transmitted. I have been waiting for the TC flag to go high but that has made the whole system a little unreliable on reset.
Is there some reason why checking the TC flag, to see if the last byte has been sent by the USART, would cause other problems. for example does the usb port routines use the TC flag, since reading the TC flag clears it as well. we seem to have a problem at reset where maple will go into limbo and it take three resets to get it going again. Could be my code, since I don't do a lot of C programming, but I just wanted to be sure. thanks
poslathian
LeafLabs
Hmm, nope the TC flag belongs wholly to the usart port, which libmaple nor the bootloader should be touching at startup. Is there a code dump somewhere? Perhaps you are querying the TC flag before sending any data. According to the datasheet, the reset value of the usart status register is 0xxxxx00C0 where the x's are reserved and you shouldnt care about them.
However, the "C0" is 11000000, and that second 1 happens to be the TC bit. Long story short, TC *should* be high on reset.
You must log in to post.
