multicore_fifo_get_status and multicore_fifo_clear_irq functions do not make sense. #459

Open
opened 2021-05-30 13:08:59 -05:00 by Gerriko · 1 comment
Gerriko commented 2021-05-30 13:08:59 -05:00 (Migrated from github.com)

I have successfully tested the blocking (multicore_fifo_pop_blocking and multicore_fifo_push_blocking) and non-blocking (multicore_fifo_rvalid and multicore_fifo_wready) functions and I have managed to replicate the behaviour as per SDK.

I am now reading the Pico C SDK documentation about the function multicore_fifo_get_status and the description about the setting of bits does not quite make sense to me.

Maybe someone can help.

So am I correct in my understanding that the setting of bit 0 to 1 is equivalent to multicore_fifo_rvalid returning true and similarly if bit 1 is set to 1 that this is equivalent to multicore_fifo_wready returning true.

Then my point of confusion.

According to the documentation, for bit 2 to be set (and remain set, as in it's sticky) means that the TX FIFO was written to when full and that this write was ignored by the FIFO. Does that mean that somehow the multicore_fifo_push_blocking function did not work (as in it did not block the write event). If that is the case is this not an error code.

Similarly for bit 3 to be set (and remain set, as in it's sticky) means that the RX FIFO was read when empty, as in multicore_fifo_pop_blocking did not block, and thus this read was ignored by the FIFO.

Then if bits 2 and bits 3 are sticky, and then remain set, how do these bits then clear assuming that this is not automated. Is that not the function of multicore_fifo_clear_irq or is there some other method of clearing, which is not documented.

I have successfully tested the blocking (multicore_fifo_pop_blocking and multicore_fifo_push_blocking) and non-blocking (multicore_fifo_rvalid and multicore_fifo_wready) functions and I have managed to replicate the behaviour as per SDK. I am now reading the Pico C SDK documentation about the function **multicore_fifo_get_status** and the description about the setting of bits does not quite make sense to me. Maybe someone can help. So am I correct in my understanding that the setting of bit 0 to 1 is equivalent to multicore_fifo_rvalid returning true and similarly if bit 1 is set to 1 that this is equivalent to multicore_fifo_wready returning true. Then my point of confusion. According to the documentation, for bit 2 to be set (and remain set, as in it's sticky) means that the TX FIFO was written to when full and that this write was ignored by the FIFO. Does that mean that somehow the multicore_fifo_push_blocking function did not work (as in it did not block the write event). If that is the case is this not an error code. Similarly for bit 3 to be set (and remain set, as in it's sticky) means that the RX FIFO was read when empty, as in multicore_fifo_pop_blocking did not block, and thus this read was ignored by the FIFO. Then if bits 2 and bits 3 are sticky, and then remain set, how do these bits then clear assuming that this is not automated. Is that not the function of multicore_fifo_clear_irq or is there some other method of clearing, which is not documented.
lurch commented 2021-05-30 18:09:29 -05:00 (Migrated from github.com)

Does that mean that somehow the multicore_fifo_push_blocking function did not work

The "wrapper functions" in the SDK don't stop you accessing the lower-level registers directly, if you really wanted to 😉

From an ease-of-use aspect it's not ideal; but I think the answers to most of your questions can be answered by comparing the code in multicore.h and multicore.c with sections 2.1.3.4 and 2.1.3.7 in the RP2040 datasheet?

(Apologies if this is rather a short answer, but I've had a very long day!)

> Does that mean that somehow the multicore_fifo_push_blocking function did not work The "wrapper functions" in the [SDK](https://datasheets.raspberrypi.org/pico/raspberry-pi-pico-c-sdk.pdf) don't stop you accessing the lower-level [registers directly](https://github.com/raspberrypi/pico-sdk/blob/develop/src/rp2040/hardware_structs/include/hardware/structs/sio.h), if you really wanted to :wink: From an ease-of-use aspect it's not ideal; but I think the answers to most of your questions can be answered by comparing the code in [multicore.h](https://github.com/raspberrypi/pico-sdk/blob/develop/src/rp2_common/pico_multicore/include/pico/multicore.h) and [multicore.c](https://github.com/raspberrypi/pico-sdk/blob/develop/src/rp2_common/pico_multicore/multicore.c) with sections 2.1.3.4 and 2.1.3.7 in the [RP2040 datasheet](https://datasheets.raspberrypi.org/rp2040/rp2040-datasheet.pdf)? (Apologies if this is rather a short answer, but I've had a very long day!)
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-raspberrypi/pico-sdk#459
No description provided.