rondlh
commented
1 year ago Serial reading Here the current Serial_Get, which has the "flag" update, it remembers what part of the serial read data was already scanned to see if the command is clear (commands end with '\n').
1. uint16_t Serial_Get(SERIAL_PORT_INDEX portIndex, char * buf, uint16_t bufSize)
2. {
3. // if port index is out of range or no data to read from L1 cache
4. if (!WITHIN(portIndex, PORT_1, SERIAL_PORT_COUNT - 1) || dmaL1Data[portIndex].flag == dmaL1Data[portIndex].wIndex)
5. return 0;
6.
7. DMA_CIRCULAR_BUFFER * dmaL1Data_ptr = &dmaL1Data[portIndex];
8.
9. // make a static access to dynamically changed (by L1 cache's interrupt handler) variables/attributes
10. uint16_t wIndex = dmaL1Data_ptr->wIndex;
11.
12. // L1 cache's reading index (not dynamically changed (by L1 cache's interrupt handler) variables/attributes)
13. uint16_t rIndex = dmaL1Data_ptr->rIndex;
14.
15. while (dmaL1Data_ptr->cache[rIndex] == ' ' && rIndex != wIndex) // remove leading empty space, if any
16. {
17. rIndex = (rIndex + 1) % dmaL1Data_ptr->cacheSize;
18. }
19.
20. for (uint16_t i = 0; i < (bufSize - 1) && rIndex != wIndex; ) // retrieve data until buf is full or L1 cache is empty
21. {
22. buf[i] = dmaL1Data_ptr->cache[rIndex];
23. rIndex = (rIndex + 1) % dmaL1Data_ptr->cacheSize;
24.
25. if (buf[i++] == '\n') // if data end marker is found
26. {
27. buf[i] = '\0'; // end character
28. dmaL1Data_ptr->flag = dmaL1Data_ptr->rIndex = rIndex; // update queue's custom flag and reading index with rIndex
29.
30. return i; // return the number of bytes stored in buf
31. }
32. }
33.
34. // if here, a partial message is present on the L1 cache (message not terminated by "\n").
35. // We temporary skip the message until it is fully received updating also dmaL1Data_ptr->flag to
36. // prevent to read again (multiple times) the same partial message on next function invokation
37.
38. dmaL1Data_ptr->flag = wIndex; // update queue's custom flag with wIndex
39.
40. return 0; // return the number of bytes stored in buf
41. }Line 4 checks if new data is available: dmaL1Data[portIndex].flag == dmaL1Data[portIndex].wIndex
dmaL1Data[portIndex].wIndex is updated by the serial idle interrupt, which happens 1 serial frame time after the last serial byte was received. This means that during the time that serial data is being received you are not aware of any new data. Usually that is fine if it's an "ok\n" message for example. But for long messages this is not optimal.
wIndex could be updated every time that Serial_Get is executed (line 3):
dmaL1Data[portIndex].wIndex = dmaL1Data[portIndex].cacheSize - DMA_CHCNT(Serial[portIndex].dma_stream, Serial[portIndex].dma_channel);
The serial interrupt routine handling the wIndex update would not be needed anymore (line 3 to 9 below),
1. void USART_IRQHandler(uint8_t port)
2. {
3. if ((USART_STAT0(Serial[port].uart) & (1<<4)) != 0)
4. {
5. USART_STAT0(Serial[port].uart); // Clear interrupt flag
6. USART_DATA(Serial[port].uart);
7.
8. dmaL1Data[port].wIndex = dmaL1Data[port].cacheSize - DMA_CHCNT(Serial[port].dma_stream, Serial[port].dma_channel);
9. }
10. }And of course the serial idle interrupt setup can be cancelled too:
USART_ITConfig(uart[port], usart_it, ENABLE);
USART_ClearITPendingBit(uart[port], usart_it);Actually, much more can be cancelled, but I don't do that here, because it will be needed for the faster writing part...
digant73
kisslorand
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