Interrupt FIFO Level Select Register (ifls) Behavior for Transmission Threshold Interrupts #2318
Labels
No labels
bazel
bluetooth
board settings
boot_stage2
bug
build
c++
can't reproduce
clang
clib-interface
cmsis
code cleanliness
code size
compiler version issues
cyw43_driver
debug
discussion
documentation
duplicate
dynamic_clock
elf2uf2
enhancement
errata
filesystem
flash layout
floating point
FreeRTOS
hardware_adc
hardware_claim
hardware_clocks
hardware_dma
hardware_exception
hardware_flash
hardware_gpio
hardware_i2c
hardware_irq
hardware_pio
hardware_pwm
hardware_rcp
hardware_rtc
hardware_spi
hardware_sync
hardware_uart
hardware_vreg
hardware_watchdog
hardware_xosc
help wanted
host
IAR
installation
invalid
linker scripts
lto
lwip
mbedtls
missing API
needs reporter detail
networking
newlib
newlib-multicore
non-c
non-cmake
non-gcc
openocd
orphan PR
OS integration
pico_async_context
pico_base
pico_binary_info
pico_flash
picolibc
pico_lwip
pico_malloc
pico_multicore
pico_printf
pico_runtime
pico_stdio
pico_stdio_usb
pico_sync
pico_time
pico_util
pioasm
port
question
review
review2
rtos interop
runtime init
static library
svd
test
tinyusb
vscode
wifi integration
wontfix
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-raspberrypi/pico-sdk#2318
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I am seeking clarification regarding the behavior of the
Interrupt FIFO Level Select Register(ifls), specifically in relation to transmission threshold interrupts. Here are my observations:iflsis set to 0x02 (b010), meaning the Transmit FIFO becomes <= 1/2 full.uart_openfunction resets the serial interface each time, restoring this value.uart_set_irqs_enabledfunction setsiflsto 0 (b000 = Receive FIFO becomes >= 1/8 full) after enabling interrupts.During testing focused on transmission threshold interrupts, it appears that once the threshold for
iflsis set, the interrupt handler only considers it after the threshold has been reached. This results in the first interrupt occurring after 8 characters are transmitted, and subsequent interrupts occur at every character thereafter, even ififlsis changed to 0.I have also tried setting
iflsbefore enabling interrupts withinuart_set_irqs_enabled, but this does not alter the behavior. Wheniflsis set to 0, the interrupt seems to trigger for each character transmitted.Has anyone conducted similar tests or can provide insights into this behavior? I am a bit confused as this pattern is consistently observed across multiple tests.
Are you using the RP2040 or the RP2350? Which version of pico-sdk are you using? Could you attach some example code that demonstrates your problem? (and please explain the difference between expected and observed behaviour)
How many new characters are you adding to the transmit FIFO each time you get the interrupt?
The RP2040 datasheet says "The transmit FIFO is an 8-bit wide, 32 location deep, FIFO memory buffer." so it seems strange that the first interrupt occurs after 8 characters rather than after 32 characters?
Thank you for your response. I am working with the RP2040 microcontroller and using Pico SDK version 2.1.1.
Check this example: I'm trying to integrate RS-485 communication using interrupts. By monitoring PIN 15 (RS_485_DE) and PIN 16 (UART_0_TX), the results are displayed in the image below.
Varibale
SendandChemulate a queue mechanism.If you remove
workaround();no interrupt rise.In your
uart_irqfunction you're only loading one character at a time into the UART's FIFO, so why are you surprised by the "subsequent interrupts occur at every character thereafter" behaviour?Have you looked at the examples here? https://github.com/raspberrypi/pico-examples/?tab=readme-ov-file#uart
I began with that example, but I couldn't find an explicit RS-485 example. Why might it be missing? The issue isn't just about loading one character into the queue. My question is why the interrupt doesn't trigger when the workaround function is not called. I'm quite sure there's a mistake on my part somewhere, as this situation seems unusual to me.
Additionally, using two queues—one software and one hardware—instead of a single software queue with interrupts appears more efficient. On other ARM Cortex platforms, simply enabling TX interrupt trigger immediately TX_QUEUE_EMPTY. Here happen after sending 8 bytes...
Because nobody wrote one yet? 😉 If you'd like to see a specific example, you should create an issue at https://github.com/raspberrypi/pico-examples/ requesting it (but that's obviously no guarantee that such an example will get written).
Page 426 of https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf says:
"NOTE
The transmit interrupt is based on a transition through a level, rather than on the level itself. When the interrupt and
the UART is enabled before any data is written to the transmit FIFO the interrupt is not set. The interrupt is only set,
after written data leaves the single location of the transmit FIFO and it becomes empty."
It is a bit curious that you have to transmit a few (>5 in my testing) characters before the transmit irq goes off. I can't explain that.