Ciao @geneschroedertech7501. How does the ttys module work for sending binary payloads via UART? Does this only work for UTF-8?
@geneschroedertech7501
3 ай бұрын
@Austin-538 This is a very good question. I *think* the ttys module itself will be OK with binary payloads, including payloads that contain zero-value bytes. And I *think* the Linux-like read()/write() APIs will handle such binary payloads. But this answer is based on briefly looking at the code, and I didn't test this. Of course, the Linux-like printf() API uses zero-terminated strings and isn't suitable for binary payloads (just as in Linux). I did notice that the ttys API uses char for the data. I cannot remember why I used char rather than uint8_t. The char type should be OK but just be aware that char can be either signed or unsigned depending on the compiler. Some of the ttys module test functions (console command "ttys test") are based on zero-terminated strings. But it would be easy to enhance or modify these test functions to use binary data including zero-value bytes. Be certain that when you call ttys_init() that you DO NOT set the option flag "send_cr_after_nl" if you are using binary payloads.
@timothynguyen4305
3 жыл бұрын
Did you intend to have interrupts enabled from the RXNE flag, even if the receive buffer is full? If the Rx buffer is full, I think it'd be better to disable interrupt generation from RXNE until the receive buffer has space available, as you have done with the TXE flag. This may skew the runover error count, however. Thanks for these lessons by the way! Edit: Clearing the RXNE flag could be a solution.
@geneschroedertech7501
3 жыл бұрын
You make an interesting point. It is possible to disable the RXNE interrupt, when the Rx buffer is full, and save some CPU time (prevent interrupts). However, it *might* be more important to record the overrun events, for diagnostic reasons. This is a design decision, and it could be made a configuration option for the ttys module. However, I must say there is a difference between the RXNE and TXE cases. With RXNE, the rate of RXE interrupts is limited by the baud rate of the serial line (one interrupt per received character). But for TXE, if the Tx buffer is empty, I think the TXE interrupts will be continuous, like a tight loop, and use all the CPU time. So for the TXE case, we MUST disable interrupts. Thank you for your comment.
@timothynguyen4305
3 жыл бұрын
@@geneschroedertech7501I'm fairly new to bare metal programming, so please correct me if I'm wrong, but if the RXNE flag is never cleared in the UART ISR, wouldn't RXNE interrupts also be "continuous" and consume all the CPU time?
@geneschroedertech7501
3 жыл бұрын
No, because the RXNE interrupt occurs when a new character is received. So say the Rx buffer is full. You receive a character and get the RXNE interrupt, and read the character (and throw it away). It will take some time until the next character is received, and thus until the next interrupt occurs. If the baud rate is 115200, then the *minimum* time for the next character is 10/115200 s or 86.8 us. Of course, 86.8 us between interrupts is quite short, but much longer than the TXE "tight loop" case. In fact, 86.8 us is the same rate that interrupts occur when characters are being received as fast as possible in the normal case (Rx buffer not full). TXE is different because no data is being transmitted, so the UART *immediately* interrupts again if no data is written to the DR register. BTW, the 10/115200 calculation is because one character takes 10 bits (1 start bit, 8 data bits, 1 stop bit).
@timothynguyen4305
3 жыл бұрын
@@geneschroedertech7501 Thanks for your detailed response, Gene. I tested your module out on my Nucleo-L476RG board using a debugger and PuTTY, and the UART *does* continuously generate interrupts once the receive buffer is full - even when I stopped typing characters into PuTTY. To avoid this, I added the function LL_USART_RequestRxDataFlush() inside the receive buffer overrun condition to clear the RXNE flag. I also dug into the Cortex-M4 programming manual (PM0214) to understand how interrupts are handled. Section 4.3.9 mentions that "for a level-sensitive interrupt, if the signal is *not de-asserted* before the processor returns from the ISR, the interrupt becomes pending again, and the processor must execute its ISR again. This means that the peripheral can hold the interrupt signal asserted until it no longer needs servicing." I believe this is what I encountered.
@geneschroedertech7501
3 жыл бұрын
@Timothy Nguyen Good find! I *thought* that my code *always* reads the DR register, even if there is no room in the receive buffer. But I should have checked my code! It does not read the DR register in the "buffer full" case, which is why the UART continuously generates interrupts. I am going to modify the code to *alway* read DR for RXNE interrupt, because I would like to have accurate performance counts of how many characters were dropped due to buffer overrun. Thank you for following up on this!
Жыл бұрын
hello teacher, I am following your playlist with pleasure. You have made very useful videos. I would like to review the driver development codes in detail in the video. i wonder if the code has a github link? I think you mentioned it piece by piece in each video. Thanks
@geneschroedertech7501
Жыл бұрын
Sorry for the delay in responding... Glad you like the course, and I am happy you want to look at the code in detail - that is how to really understand how it works. The github links are in the notes for the playlist and in first video. There are two repos, one for code and one for documentation. The code is here: github.com/g-schro/mcu-class-1-code The documentation that was used in the class is here: github.com/g-schro/mcu-class-1-external-docs
@TheDambo1
3 жыл бұрын
what app do you use for diagrams like this with ttys Design?
@geneschroedertech7501
3 жыл бұрын
This is all old-school PowerPoint. It is not that well suited for these kinds of diagrams, but I have used it so much over the years, I can get by. I imagine there are many better apps for this kind of thing. By the way, I found out AFTER recording all of the videos that I had the wrong aspect ratio set in PowerPoint for KZitem. That is why you see the black bars on the sides. It really annoyed me.
Пікірлер: 12