New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only with interrupts? #2
Comments
This sort of loop works well on the master side. The slave on the other hand is always reacting to requests from master, so an event driven API fits better. Now, instead of callbacks, you could have a loop which polls tl;dr There's room for a more convenient interface, if enough people complain. |
Thanks. Perhaps it was already clear, but to make it crystal clear, the problem with the interrupt approach for my code, is that the request may arrive before the data to be sent is ready: so if there is nothing ready to send when the callback happens, then what? I don't really want to do the data preparation in the callback... Not sure what do you mean by "the bus is stalled". Could it be used by other devices? Or are you implying it can't? But in any case, during the "prepare some stuff", there is nothing to send yet so either the master has to wait (if it does not have anything else to do) or it could do something else, if it posted a non-blocking read which timed out. |
It depends on what you are trying to accomplish. Here's a couple of options:
After a read request, the slave holds SCL low until there's something to transmit. It's stalling until you put something in Tx FIFO, and no other device can use the bus. |
That is not really a good option for this: the data is coming from the ADC (and perhaps via DMA, tbd), so the timing is out of control.
That's what I want to avoid.
Thanks for clarifying that... it might be that the best option is:
Would the bus be released in such a case? What would the master see? Thanks a lot, the conversation in this issue is much more useful than the official documentation for this use case!!! |
No, the slave keeps stalling and asserting
The I2C chapter in RP2040 datasheet covers most of this in detail. "[4.3.10.1] Slave Mode Operation" is definitely worth reading. |
Indeed. I hoped to be spared from that by using the SDK instead (so I could concentrate on the problem at hand, rather than solving low level communication issues). Anyway, I reported the issue at raspberrypi/pico-sdk#708 and mentioned there your very useful repo. If you have time, you should make a PR with this repo as a subdirectory of https://github.com/raspberrypi/pico-examples/tree/master/i2c -- I'm sure that will save poor people like myself lots of headaches for banging the head too much on the keyboard.... Thanks again, and you may close this issue, as far as I am concerned. |
After giving it more thought, here is a minimal example of slave-transmitter in a loop. See Does it solve your issues? |
That works great, and it is very clear (I know all the stuff about critical sections and the likes from other contexts -- to possible other readers of this issue: do some research about critical sections, unspecific to the pico). Thanks a lot! You are the best! |
Thanks for providing this example, in fact the Raspberry Pi Pico C/C++ SDK is really incomplete in this regard!!!
Are interrupts like your library does really the only way to implement I2C slave on the Pico?
I need to do something like the following on my pico slave
Of course I could change that code to use interrupt, but it becomes unnecessary more complicated, so I tried using
i2c_write_blocking()
andi2c_write_raw_blocking()
but those do not seem to be working. Is it really so, or am I doing anything wrong?The text was updated successfully, but these errors were encountered: