\xFF is missing from UART.read()

[garudaone]

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.

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

[karfas]

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.

[TheSilverBullet]

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.

[garudaone]

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.

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.

[Roberthh]

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]

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.

[Roberthh]

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]

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

[Roberthh]

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.

[Roberthh]

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.