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
drivers: It is not possible to use transceiver drivers on a shared SPI-bus #2769
Comments
@jremmert-phytec-iot , @haukepetersen , @gebart would be nice if you can check and extend the description if I missed relevant informations! |
Should we add the "bug" or "enhancement" label? |
I discussed that topic with Johann today. We came to the conclusion that 1) could be the a reasonable solution for devices with an exclusive SPI interface for the radio due to the following reasons:
Maybe @haukepetersen will have more ideas for devices without exclusive access when he is implementing the atmel driver. Calculation of the maxACK-timeout (This could be an important fact for the final decision): Whereas:
macAckWaitDuration = 320µs + 192µs + 160µs + 192µs = 864µs [1] https://standards.ieee.org/getieee802/download/802.15.4-2011.pdf |
@jremmert-phytec-iot thanks for the detailed response and the link. In your last point, what do you mean with "block the SPI-Bus for peripheral reasons "? Is it "hardware-blocking" so no other device can use the bus or what was your suggestion? |
Oh true, that sentence was confusing. |
@PeterKietzmann I did not have any particular hardware in mind, at least the kw2x radio will work without locking as long as only one single thread is ever used to communicate with it. The most likely issue that I see is when an SPI transfer is already in progress from thread context and an interrupt occurs and the ISR wants to perform an SPI transfer as well, which may or may not work correctly, depending on the implementation and SPI hardware used. One example off the top of my head: If using the hardware CS feature of the Kinetis processors the kw2x driver can spinlock inside the ISR until the SPI status register says there is free space in the TX buffer and then perform the transfer, but this will probably break if using software controlled CS from thread context as the CS pin will already be asserted when the ISR wants to assert it, and the radio will likely ignore the command. Even if using hardware CS it is still a problem to figure out which of the RX bytes belong to which transfer, since the ISR does not know anything about the transfer that was in progress when the interrupt came. Thinking about this I see only two possible solutions to this:
|
After looking a little bit into the Atmel AT86RF2xx driver, I think I tend to actually go with solution Correct me if I am wrong, but at least for 802.15.4 devices I think all of them support hardware auto-acking, right? So the sending of ACKs we can just leave to the hardware and therefore do not have to worry about timings. A workaround for other time critical events could be to use a timestamp (brainstorming here): in the interrupt routine save the value of What do you think? |
Ok seems so, then for Ack packets we should be fine. They do not throw an interrupt at all and are handled completely in HW. I have thought about the time-span e.g. between an incoming Beacon and the outgoing response. As far as I understand, the timing here is not that important. There is even a minimum time spacing time, LIFS (Long interframe Spacing Period), which is 40symbols (640µs). The timestamps could be essential to enable slottet CSMA. An other possibility beside the hwtimer_now() timestamping could be to use the hardware timestamping, some IEEE802.15.4 radios provide. Since the timestamps are stored in the radios internal registers, they can also be read out after a certain delay.
|
At least if I think of very cheap transceivers, that may support 802.15.4 PHY, but are not necessarily designed for 802.15.4 L2 this may not hold for every device. |
Then these devices would have to handle that in their IRQ with all the implications that come with it for their SPI bus usage. It is still possible to do this - we should just try not to do it if not really really needed. |
Any final conclusion? |
didn't we fix most drivers? @haukepetersen? |
IMHO this is solved by (i) coding convention not to use SPI in interrupt context and (ii) the introduction of |
This issue results from PR #2756.
Problem:
Allowing SPI-transfers for example to receive data in interrupt context could lead to unwanted behavior. Assuming there is an ongoing SPI-transfer and at the same time an external interrupt is triggered by the transceiver. This will lead to two enabled chip selects and undefined behavior on the bus.
Former solution approaches:
Criticism of the above proposals:
1)
The text was updated successfully, but these errors were encountered: