rondlh
commented
1 year ago I updated the code a bit, see below. Please make sure to #define IDLE_INTERRUPT if you use the idle interrupt, or just remove the "#ifdef IDLE_INTERRUPT" and "#endif"
QUESTIONS: There is a blocking line in Serial_Get:
// wait until space becomes available, blocking! while ( ( (dmaL1DataTX[port].wIndex + 1) % dmaL1DataTX[port].cacheSize) == dmaL1DataTX[port].rIndex) { }
This line makes the TFT wait for buffer space if it's not available. I wonder if I should put any process in there that could be done safely during the waiting time. adding loopProcess would be a recursive call I guess, but perhaps Serial_Read can continue.
Any suggestions?
void Serial_Put(uint8_t port, const char *s) // send a zero terminated string to uart port
{
while (*s)
{ // copy serial characters to buffer until end of string '/0'
// setup TX DMA, if no '\n' yet, but buffer is full AND DMA is not in progress already (waiting for Transfer Complete interrupt)
if ((((dmaL1DataTX[port].wIndex + 1) % dmaL1DataTX[port].cacheSize) == dmaL1DataTX[port].rIndex) && (((Serial[port].uart->CR1 & (1<<6)) == 0)))
Serial_Send_TX(port);
// wait until space becomes available, blocking!
while ( ( (dmaL1DataTX[port].wIndex + 1) % dmaL1DataTX[port].cacheSize) == dmaL1DataTX[port].rIndex) { }
dmaL1DataTX[port].cache[dmaL1DataTX[port].wIndex] = *s; // copy character to cache
dmaL1DataTX[port].wIndex = (dmaL1DataTX[port].wIndex + 1) % dmaL1DataTX[port].cacheSize; // update wIndex
if ((*s == '\n') && (((Serial[port].uart->CR1 & (1<<6)) == 0)))
Serial_Send_TX(port); // start DMA process if command is complete and DMA is not in progress already
s++; // let the compiler optimize this, no need to do it manually!
}
}And the ISR looks like shown below: Note the #ifdef is for testing only, so I can compare:
- Using or disabling the Serial idle interrupt
- test unbuffered writing
- interrupt based writing
- DMA based writing.
void USART_IRQHandler(uint8_t port) // ISR, serial interrupt handler
{
#ifdef IDLE_INTERRUPT
// handle serial idle interrupt
if ((Serial[port].uart->SR & (1<<4)) != 0) // RX: check for serial Idle interrupt
{
// Serial[port].uart->DR; // done in the guard above already
Serial[port].uart->DR;
dmaL1DataRX[port].wIndex = dmaL1DataRX[port].cacheSize - Serial[port].dma_streamRX->NDTR;
}
#endif
#ifdef INTERRUPT_WRITE // interrupt based serial writing
if ((Serial[port].uart->SR & (1<<7)) != 0) // check for TXE interrupt
{
if (dmaL1DataTX[port].rIndex == dmaL1DataTX[port].wIndex) // no more data?
Serial[port].uart->CR1 &= ~(1<<7); // clear TXE Interrupt bit
else
{
Serial[port].uart->DR = (uint8_t)dmaL1DataTX[port].cache[dmaL1DataTX[port].rIndex]; // write next available character
dmaL1DataTX[port].rIndex = (dmaL1DataTX[port].rIndex + 1) % dmaL1DataTX[port].cacheSize; // Increase read index
}
}
#endif
#ifdef DMA_WRITE // DMA based serial writing
if ((Serial[port].uart->SR & (1<<6)) != 0) // TX: check for Transfer Complete (TC)
{
Serial[port].uart->SR &= ~(1<<6); // clear Transfer Complete (TC) bit
// NOTE: the ISR is sometimes called while DMA is still active, so check NDTR status!
if (Serial[port].dma_streamTX->NDTR == 0) // sending is complete
{
dmaL1DataTX[port].rIndex = (dmaL1DataTX[port].rIndex + Serial[port].txBytes[port]) % dmaL1DataTX[port].cacheSize;
Serial[port].txBytes[port] = 0;
if (dmaL1DataTX[port].wIndex != dmaL1DataTX[port].rIndex) { // is more data available?
Serial_Send_TX(port); // continue sending data
}
else { // removed causes double line transfers
// dmaL1DataTX[port].rIndex = dmaL1DataTX[port].wIndex = 0; // buffer is empty, start from the start to keep transfers in 1 DMA cycle if possible
Serial[port].uart->CR1 &= ~(1<<6); // disable Transfer Complete (TC) interrupt, nothing more to do
}
}
// else: more data is coming, wait for next Transfer Complete (TC) interrupt
}
#endif
}And the DMA send code:
void Serial_Send_TX(uint8_t port)
{
// setup DMA transfer, and wait for serial Transfer Complete (TX) interrupt in ISR
if (dmaL1DataTX[port].wIndex >= dmaL1DataTX[port].rIndex)
Serial[port].txBytes[port] = dmaL1DataTX[port].wIndex - dmaL1DataTX[port].rIndex;
else
Serial[port].txBytes[port] = dmaL1DataTX[port].cacheSize - dmaL1DataTX[port].rIndex; // split transfer into 2 parts
Serial[port].dma_streamTX->M0AR = (uint32_t)(&dmaL1DataTX[port].cache[dmaL1DataTX[port].rIndex]); // start address TX data
Serial_DMAClearInterruptFlagsTX(port); // clear DMA TX interrupt flags
Serial[port].uart->CR1 |= (1<<6); // enable Transfer Complete (TX) serial Interrupt
Serial[port].dma_streamTX->NDTR = Serial[port].txBytes[port]; // no. bytes to transfer
Serial[port].dma_streamTX->CR |= 1<<0; // enable TX DMA
}
digant73
1. Serial reading The current FW uses DMA for reading data from the serial ports, which is done in a very efficient way, the process is started and will run automatically in the background. Interrupts are generated when data is available, this happens when the serial line goes idle. This is overall a very efficient approach, but has a small drawback. The received data only gets processed once the serial line goes idle, under most circumstances this is fine because the received messages are short and fragmented ("ok\n"). But if a long continues message is received, like the response to M43 (pins information), then a TFT buffer overrun can occur and a part of the received message is lost. This issue can be solved by not waiting for the serial idle interrupt, but immediately starting to process the data that is being received. Based on the improvements in #2824 (improvements in Serial_Get) it is quite obvious how to implement this. I will provide some sample code soon.
The advantages:
2. Serial writing Practically the TFT only needs to receive a little bit of data ("ok\n" messages), but needs to write a lot of data to the motherboard (the gcode commands, about 40 characters per command). The current serial write implementation is very slow, the software actually needs to wait after each byte until it's physically send over the serial line. This slows down the TFT response time, especially for lower baud rates and when the workload is high anyway. A buffered DMA based would significantly help to increase the TFT responsiveness.
Currently I have a DMA based serial write solution under test, which works in this way:
The advantages:
A disadvantage is that this code is hardware dependent (DMA setup). I will post the STM32F2_4 sample code here soon for review and discussion.
I have some questions:
Is it acceptable to provide this solution for one hardware platform only?
Who can help test/implement a STM32F10x implementation? BTT TFT24 V1.1 BTT TFT28 V1.0 BTT TFT35 1.0/1.1/1.2/2.0 BTT GD TFT24 V1.1 BTT GD TFT35 V2.0 MKS TFT28 V3.0/4.0 MKS TFT28 NEW GENIUS MKS TFT32 V1.3/1.4 MKS TFT32L V3
Who can help test/implement a gd32f20x implementation? BTT GD TFT35 V3.0 BTT GD TFT35 E3 V3.0 BTT_GD TFT35 B1 V3.0 BTT GD TFT43 V3.0 BTT GD TFT43 V3.0 BTT GD TFT50 V3.0