Planned PR for interrupt-based SPISlave

[bmcdonnell-ionx]

Description

• Type: Enhancement | Question
• Priority: Minor

The main reason I'm posting this as an issue instead of just submitting the pull request (PR) is because of the rumored "upcoming SPI spec", and the fact that I can't post the PR right away. Details below.

---

Enhancement

I have (as-yet unpublished) changes to the SPISlave class and spi_api which allow for interrupt-based SPI handling. I plan to offer this as a PR, maybe in a couple weeks or so, as I have a little vacation coming up, and some other priorities going on.

Reason to enhance or problem with existing solution

A SPISlave needs to keep up with the serial clock driven by master. I'm not sure how the current polling implementation could be used so as to guarantee it could keep up. Polling in a high priority thread? Then how do you get anything else done?

Plus it's much more efficient to idle/sleep and wake on interrupts as needed.

Suggested enhancement

Allow attaching interrupt handlers to SPISlave. (This is what I did. It's modeled after the CAN driver and can_api.)

Pros

• Enable an application to keep up
• Allows a more "traditional" embedded implementation, I think (compared to whatever non-interrupt workaround there may be)
• More efficient than polling

Cons

• I've only implemented spi_api.c for LPC4088. However, I modeled it after can_api, so I think adding other targets would be straightforward, if not even "easy".

---

Question

In #6365 (comment), @0xc0170 mentions that there is an

upcoming SPI spec (to define well the API, tests and then targets implementation).

When will the Mbed OS team start work on this, and what interface changes may it make?

What's the best way forward to keep my upcoming PR and your SPI spec aligned? I hope not to have you start/finish work on changing the existing SPISlave/spi_api interfaces before I submit my PR.

[0xc0170]

@bulislaw Please review

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-203

[deepikabhavnani]

@bmcdonnell-ionx - SPI enhancements and queries were addressed in SPI HAL specs? Do you want this issue to be open to track interrupt based PR?

[bmcdonnell-ionx]

We're redesigning the project where I was going to use this feature, so I don't plan to keep working on it. With the upcoming SPI enhancements (#7671), I don't think it makes much sense to try to sync up there with what I've already done here.