Use of GPIO interrupts in EX drivers

Discussions and support about ChibiOS/EX, the External Peripherals Abstraction Layer.
User avatar
Giovanni
Site Admin
Posts: 11083
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 367 times
Been thanked: 306 times
Contact:

Re: Use of GPIO interrupts in EX drivers

Postby Giovanni » Sun Jun 05, 2016 10:21 am

Hi,

I merged the patch with few changes:

1) Added a type for the callback.
2) Made functions I-Class because those have to manipulate IRQ sources and that must be atomically done.
3) Various documentation fixes and streamlining.

Giovanni

awygle
Posts: 32
Joined: Sun Apr 03, 2016 8:39 pm
Has thanked: 6 times
Been thanked: 4 times

Re: Use of GPIO interrupts in EX drivers

Postby awygle » Tue Jun 07, 2016 7:41 am

Awesome! I've updated my MSP430X port's PAL driver to support this, once it's tested I'll be committing it to the community repo.

One question - I noticed that you chose to make the callback a void (void) function rather than a void (ioline_t) function. This doesn't bother me for my use case, but I was curious what your reason was. I was envisioning the use case where someone wanted to handle a lot of different lines from the same function to save code space. Maybe that doesn't come up often though?

EDIT: Another thought - it might be convenient to have a hook in place for a "default" callback to be called if nothing else is registered. I am currently registering chSysHalt (basically) for almost all pins (for testing).

User avatar
Giovanni
Site Admin
Posts: 11083
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 367 times
Been thanked: 306 times
Contact:

Re: Use of GPIO interrupts in EX drivers

Postby Giovanni » Tue Jun 07, 2016 8:08 am

Hi,

The reason is: RAM usage, storing an ioline_t for each possible vectors would take space, this why I decided to have parameters-less callbacks.

Giovanni

awygle
Posts: 32
Joined: Sun Apr 03, 2016 8:39 pm
Has thanked: 6 times
Been thanked: 4 times

Re: Use of GPIO interrupts in EX drivers

Postby awygle » Wed Jun 29, 2016 9:59 am

Hi again,

I've spent some time using this now and run into one challenging thing when trying to use the new PAL Event functionality in an EX driver. I thought I'd mention it for discussion.

Specifically I am working on a driver for an RF transmitter, the SX1278 from Semtech. I would like to provide synchronous and asynchronous APIs similar to (e.g.) the SPI driver, that is, sx1278Send and sx1278StartSend. However, I can't quite get StartSend to work the way I want it to.

The vision that I have is, fill the outgoing FIFO with packet data, then either sleep (synchronous) or return (asynchronous) until the FIFO level drops to the point where more data is needed (signaled by an IRQ line going low). Sleeping is easy, I use osalThreadSuspendTimeoutS and call osalThreadResumeI from the callback. For the asynchronous version of the API, I'd like to be able to set up the PAL callback, return, then have my thread continue doing things until the callback is fired. The callback would then use spiStartSendI and the code would bounce around callbacks until the whole packet had been transmitted.

This would work fine if I had only one SX1278Driver, called SX1278D1, that I could reference directly in the PAL callback. However, if I have multiple SX1278 drivers and can't refer directly to them by name (a reasonable use case, I think), then I have no way to get ahold of the driver pointer in the PAL callback since there are no parameters available.

Any suggestions on solving this problem? The obvious solution seems to me to be to make the callback type void (void*) rather than void (void), but of course there are downsides to that as well. I see this problem as likely to come up in many possible EX-style device drivers, but maybe you disagree. At any rate, I'm interested in discussion of this point.

Thanks!

~awygle

User avatar
Giovanni
Site Admin
Posts: 11083
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 367 times
Been thanked: 306 times
Contact:

Re: Use of GPIO interrupts in EX drivers

Postby Giovanni » Wed Jun 29, 2016 10:26 am

Hi,

About your problem, spiStartSend() is asynchronous, a common error is to call spiUnselect() right after spiStartSend(), the call to spiUnselect() should go in the SPI callback:

Code: Select all

spiSelect();
spiStartSend();
.....

spi_callback() {
  spiUnselect();
}


About PAL callbacks, it would take extra RAM to associate a parameter to each callback, this is why those callbacks currently have no parameters. Storing pointer parameters would require 16*sizeof(void *) bytes of RAM, I imagine it could be done if there is no other way.

Giovanni


Return to “ChibiOS/EX”

Who is online

Users browsing this forum: No registered users and 1 guest