\xFF is missing from UART.read()

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
garudaone
Posts: 23
Joined: Fri Jul 08, 2022 9:10 am

Re: \xFF is missing from UART.read()

Post by garudaone » Tue Aug 09, 2022 3:03 pm

if I put the board to sleep, all the data coming correctly into the buffer and I can read after wakeup from time.sleep(). but if data is coming while the board is running, all \xFF are missing. :D

I use this board(a9 gprs). I need to rely on its GPRS/SMS features
https://github.com/pulkin/micropython/t ... ts/gprs_a9

User avatar
karfas
Posts: 193
Joined: Sat Jan 16, 2021 12:53 pm
Location: Vienna, Austria

Re: \xFF is missing from UART.read()

Post by karfas » Tue Aug 09, 2022 3:31 pm

So you are using some 2-year old micropython version most people here never had heard of and ask for help without giving any details ?
Maybe you should try a current version first (with a simple test program). If this works, you can look for differences and solutions.
A few hours of debugging might save you from minutes of reading the documentation! :D
My repositories: https://github.com/karfas

TheSilverBullet
Posts: 50
Joined: Thu Jul 07, 2022 7:40 am

Re: \xFF is missing from UART.read()

Post by TheSilverBullet » Tue Aug 09, 2022 3:37 pm

You might wanna check a few milliseconds after you received the first part of your incoming message:

Code: Select all

time.sleep_ms(20)
print(uart.any())
data = uart.read()
print(f'_{data}_}   {type(data)}'
Uhhh, just saw the remark regarding that ancient version. Cancel everything after Good Morning. 8-)

garudaone
Posts: 23
Joined: Fri Jul 08, 2022 9:10 am

Re: \xFF is missing from UART.read()

Post by garudaone » Wed Aug 10, 2022 1:53 am

TheSilverBullet wrote:
Tue Aug 09, 2022 3:37 pm
You might wanna check a few milliseconds after you received the first part of your incoming message:

Code: Select all

time.sleep_ms(20)
print(uart.any())
data = uart.read()
print(f'_{data}_}   {type(data)}'
Uhhh, just saw the remark regarding that ancient version. Cancel everything after Good Morning. 8-)
It still filter out \xff. The only way to receive this \xff is the board is in time.sleep() while the data is coming. If the board is running,\xff will disspear no matter how long you sleep before reading.

My test is: put the board to time.sleep(5) and send the data from another board within this 5 seconds and after the board back from time sleep and read the data from the receive buffer, the \xff is there.

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: \xFF is missing from UART.read()

Post by Roberthh » Wed Aug 10, 2022 5:49 am

I looked into the UART driver of the SIM board. That driver does not filter any characters.. So it's something or somewhere else. You could try to manually set a UART timeout longer than the default of 1 character time.

garudaone
Posts: 23
Joined: Fri Jul 08, 2022 9:10 am

Re: \xFF is missing from UART.read()

Post by garudaone » Wed Aug 10, 2022 11:02 am

Roberthh wrote:
Wed Aug 10, 2022 5:49 am
I looked into the UART driver of the SIM board. That driver does not filter any characters.. So it's something or somewhere else. You could try to manually set a UART timeout longer than the default of 1 character time.
No, it still not work. I try difference combination of this timeout and timeoutchar.

uart must be doing something while the board is active because if I put the board to sleep before data is coming in, i can get that \xff from the buffer.


I try to look at the c file: https://github.com/pulkin/micropython/b ... ine_uart.c but too complicated to understand.

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: \xFF is missing from UART.read()

Post by Roberthh » Wed Aug 10, 2022 11:17 am

In uart.c, line 110, the else statement, looks wrong. Try to delete that. If mp_interrupt_char() is set to -1, a 0xff will not be put into the ringbuffer. For verification, you could set the mp_interrupt_char() to a different value and see, if the other value then is skipped.

garudaone
Posts: 23
Joined: Fri Jul 08, 2022 9:10 am

Re: \xFF is missing from UART.read()

Post by garudaone » Wed Aug 10, 2022 12:11 pm

Roberthh wrote:
Wed Aug 10, 2022 11:17 am
In uart.c, line 110, the else statement, looks wrong. Try to delete that. If mp_interrupt_char() is set to -1, a 0xff will not be put into the ringbuffer. For verification, you could set the mp_interrupt_char() to a different value and see, if the other value then is skipped.
Thanks you for looking at the code.
I try to set this micropython.kbd_intr(ord('a')) or micropython.kbd_intr(-1). but that still the same

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: \xFF is missing from UART.read()

Post by Roberthh » Wed Aug 10, 2022 12:57 pm

You cannot set that in an interactive session, because it is reset at every Python prompt. You have to set it in a script, which also runs you test.

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: \xFF is missing from UART.read()

Post by Roberthh » 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.

Post Reply