Posted on February 18, 2018 at 06:18It turns out that the Hal example two boards com DMA works only in a simplex mode. The USART is put in DMA rx mode and then, after a packet is received, it reinitializes the USART handle, sends a response, reinitializes the USART handle again and then goes into DMA rx mode again. This works fine for a command response protocol but I needed to be able to transmit packets asynchronously while supporting the cmd/rsp protocol. Note that the Hal implementation CAN handle repeated DMA transmits in succession correctly. (Obviously it should work full duplex but it doesn’t)
So, I could dive into fixing the Hal library but I decided a more pragmatic and faster approach to my solution (full duplex USART functionality) was to use 2 usarts to make a single full duplex channel. Since I had a working cmd/rsp channel, I added a second USART that I would only send on (repeated DMA rx works fine).
So, I disconnected the TX signal from Usart1 that handles the cmd/rsp protocol and I connected the TX signal from Usart2 to the driver chip. So I send the Rsp packet the cmd/rsp channel (USART1) to both USART 1 and USART2. The usart1 tx line is disconnected but we send it to keep the cmd/rsp channel working within the Hal limitations. We also send the rsp packet to USART 2 which is connected to the driver chip so it is transmitted. A sync packets also can be sent to usart2. As I said, multiple DMA transmits work with the Hal libs so in this design,
usart 1 handles incoming commands and usart 2 handles all outgoing responses and a sync packets.
This was a faster way to a full duplex solution versus debugging the Hal libs.
i hope this helps
