Hi,
I'd like to use USART0 of my ATSAME70Q21 as SPI master but It does not work.
I'm using CMSIS driver (Keil). If I use UASRT as UART it works well.
The setting for SPI master is this:
case USART_0: Usart[Ch].pDrv->Initialize( Usart0Callback ); Usart[Ch].pDrv->PowerControl( ARM_POWER_FULL ); Usart[Ch].pDrv->Control( ARM_USART_MODE_SYNCHRONOUS_MASTER | ARM_USART_CPOL0 | ARM_USART_CPHA0 | ARM_USART_DATA_BITS_8, BaudRate ); Usart[Ch].pDrv->Control( ARM_USART_SET_DEFAULT_TX_VALUE, 0xFFFF );
Usart[Ch].pDrv->Control( ARM_USART_CONTROL_TX, 1 ); Usart[Ch].pDrv->Control( ARM_USART_CONTROL_RX, 1 ); break;
while(1)
Usart[Ch].pDrv->Send( pData, Size );
Best regards
LB
Maybe Synchronous mode is not supported or maybe it does not work.
It looks like you will have to do some debugging to see what is wrong.
Hi Milorad,
when I call the function Usart[Ch].pDrv->Control(...) no error I receive.
The code is blocked here:
do { status = usart->reg->US_CSR; } while ((status & US_CSR_RXRDY) == 0);
It is strange that the mode SPI is not supported because there are the difenes of ARM_USART_MODE_SYNCHRONOUS_MASTER and ARM_USART_MODE_SYNCHRONOUS_SLAVE.
Hi LB.
I investigated a bit this issue and here is what I found.
CMSIS drivers (USART one also) were developed by Keil, and USART one states it was developed in the year 2015.These drivers, or actually packs they are a part of, are no linger maintained by Keil, but no new ones were provided by Atmel or currently Microchip.
Also, that driver is complying to CMSIS-Driver USART API version 1.02, and CMSIS-Driver USART API is currently at version 2.4.
The code you are mentioning gets stuck as it waits for something to be received which of course will never happen in the Synchronous Master mode until something is transmitted that would generate clocks for the reception.
However, looking at defines, if you were to use RX in IRQ mode which would then provide the USART_IRQ_RX define, and that piece of code would not then be compiled in, it looks like it might work for your situation.You can change this to use IRQ mode in the accompanying RTE_Device.h file by changing RTE_USARTn_RX_MODE (n=0..2) to 1, instead of default value 0.
But in general, you are more or less on your own with using that driver since it is very obsolete and is no longer maintained by Keil.You could ask Microchip if they plan to provide CMSIS drivers for the MCU you are using.
Best regards, Milorad
I have tried to change from polling to interrupt mode but no data exit from USART. Now the code is not blocked in the driver code.
it is very strange that keil has released a driver without test.
I tried to contact Microchip but It told the no know that drivers.
I have noticed that ARM_USART_CPOL1 and ARM_USART_CPHA1 are not managed from driver.
Usart[Ch].pDrv->Control( ARM_USART_MODE_SYNCHRONOUS_MASTER | ARM_USART_CPOL1 | ARM_USART_CPHA1 | ARM_USART_DATA_BITS_8, BaudRate );
Hi LB,
as you are now figuring out for yourself, it is very important on how well the MCU you plan to use is supported by software.Maybe, Microchip / Atmel has some software available for their MCUs.
Regarding this driver, I don't think you have many options, basically: - dig into the driver yourself and update functionality that you need - write the functionality you need by yourself - look for what is available from Microchip / Atmel and integrate that, if there is any - use SPI instead of Synchronous USART and hope that driver works better for master mode - use a different MCU which has better software support
I have contacted Microchip, no solution for CMSIS driver.
I have definitive hardware I can note change nothing.
In this hardware I have 3 different MCUs and I want use CMSIS driver for all
If Keil offers CMISS driver I expect that are all ok (Costumer that has payed the license).
I think the best way is a workaround about your driver as soon as possible.
well, actually, license is for the tool (IDE + Assembler/Compiler/Linker or also Middleware) and CMSIS drivers are just an attempt from Keil to standardize API across multiple MCUs and Vendors to allow better adoption of the MCUs and easier and faster software development.
The license does not guarantee you have latest support for any MCU nor that CMSIS drivers are available for your MCU.
Main motivator for CMSIS driver implementation is MCU's popularity on the market.
I think a workaroud is necessay in front of a macro problem as this: no work completely the SPI and the UART work well in TX ISR but when I receive bytes during tx the driver goes in error.
Luca Bernabei
Hi Luca,
I'd suggest you dig into the driver and fix the things that are not working for you since a lot of functionality is already available.It is, however, not as easy as it sounds as implementing drivers or debugging them is always time consuming.
Good luck!