Page 3 of 3
Re: \xFF is missing from UART.read()
Posted: Wed Aug 10, 2022 3:28 pm
by garudaone
Roberthh wrote: ↑Wed Aug 10, 2022 1:20 pm
To explain that problem. This is the interrupt handler:
Code: Select all
static void uart_rx_intr_handler(UART_Callback_Param_t param) {
// handles rx interrupts
ringbuf_t *ringbuf = uart_ringbuf + param.port - 1;
int* to_dupterm = uart_attached_to_dupterm + param.port - 1;
for (uint32_t i=0; i<param.length; i++) {
if (param.buf[i] == mp_interrupt_char) {
if (*to_dupterm)
mp_keyboard_interrupt();
}
else
ringbuf_put(ringbuf, param.buf[i]);
}
}
mp_interrupt_char is a signed int. param.buf is declared at signed char*. So a 0xff in the buffer expands in a comparison with an int to -1. That might explain, why 0xff is missing when mp_interrupt_char is -1. Usually the receive buffer would be set to an unsigned data type. In that case 0xff is expanded to 255, and the compare with -1 fails.
But that is only the first part of the problem. The other part consist in the path of "if (*to_dupterm)...". If that is true, an keyboard interrupt is raised. If that is false, the character from the buffer is NOT put into the ring buffer, but simply discarded.
Thanks, you are right
Actually, at first \x03 are missing and by setting micropython.kbd_intr(-1) helps to get back \x03. but unknowingly, it makes me missed the \xff.
SO I am fixing one problem while creating another problem. By trying micropython.kbd_intr(-2), I missed \xFE. What is your suggestion? I have recompile the python build?
Re: \xFF is missing from UART.read()
Posted: Wed Aug 10, 2022 3:54 pm
by Roberthh
Option 1: Fix the firmware.
Option 2: Avoid the bug. If you can control both sides, exchange the data coded, e.g. as Ascii-Hex, which contains neither 0x03 nor 0xff.
Option 1 is the better choice. You can for instance leave the SDK as is is and just change uart.c:
Code: Select all
static void uart_rx_intr_handler(UART_Callback_Param_t param) {
// handles rx interrupts
ringbuf_t *ringbuf = uart_ringbuf + param.port - 1;
int* to_dupterm = uart_attached_to_dupterm + param.port - 1;
for (uint32_t i=0; i<param.length; i++) {
if (*to_dupterm && param.buf[i] == mp_interrupt_char) {
mp_keyboard_interrupt();
}
ringbuf_put(ringbuf, param.buf[i]);
}
}
Re: \xFF is missing from UART.read()
Posted: Wed Aug 10, 2022 3:57 pm
by garudaone
Roberthh wrote: ↑Wed Aug 10, 2022 3:54 pm
Option 1: Fix the firmware.
Option 2: Avoid the bug. If you can control both sides, exchange the data coded, e.g. as Ascii-Hex, which contains neither 0x03 nor 0xff.
Option 1 is the better choice. You can for instance leave the SDK as is is and just change uart.c:
Code: Select all
static void uart_rx_intr_handler(UART_Callback_Param_t param) {
// handles rx interrupts
ringbuf_t *ringbuf = uart_ringbuf + param.port - 1;
int* to_dupterm = uart_attached_to_dupterm + param.port - 1;
for (uint32_t i=0; i<param.length; i++) {
if (*to_dupterm && param.buf[i] == mp_interrupt_char) {
mp_keyboard_interrupt();
}
ringbuf_put(ringbuf, param.buf[i]);
}
}
Thanks a lot for your effort to help. I will have to recompile this(Option 1) because sometimes I read data from Modbus sensor.
Re: \xFF is missing from UART.read()
Posted: Thu Aug 11, 2022 7:02 am
by garudaone
Roberthh wrote: ↑Wed Aug 10, 2022 3:54 pm
Option 1: Fix the firmware.
Option 2: Avoid the bug. If you can control both sides, exchange the data coded, e.g. as Ascii-Hex, which contains neither 0x03 nor 0xff.
Option 1 is the better choice. You can for instance leave the SDK as is is and just change uart.c:
Code: Select all
static void uart_rx_intr_handler(UART_Callback_Param_t param) {
// handles rx interrupts
ringbuf_t *ringbuf = uart_ringbuf + param.port - 1;
int* to_dupterm = uart_attached_to_dupterm + param.port - 1;
for (uint32_t i=0; i<param.length; i++) {
if (*to_dupterm && param.buf[i] == mp_interrupt_char) {
mp_keyboard_interrupt();
}
ringbuf_put(ringbuf, param.buf[i]);
}
}
Ok, problem solved after I updated and recompile the build.
Thank you very much
Re: \xFF is missing from UART.read()
Posted: Thu Aug 11, 2022 7:07 am
by Roberthh
That's very good. I also left a note at the repository issue you have created, to leave that issue open.. That is a reminder to fix the bug in the main line, and a help for other people stumbling over the same problem.