GPIO Interrupts handling (ARM)

OP
OP
aragats

aragats

Daemon

Reaction score: 433
Messages: 1,055

Yes, the wiki page I mentioned is referring namely to that. But there is nothing related to interrupts. Just checked gpioctl(8) from FreeBSD 11-CURRENT - it's not mentioning any interrupt configuration either.
In other discussions people advise to poll GPIOs instead, but that makes no sense in an embedded system.
 

Juha Nurmela

Well-Known Member

Reaction score: 121
Messages: 401

I would say 700MHz makes no sense in an embedded system, but who am I to say anything :)

Juha
 
OP
OP
aragats

aragats

Daemon

Reaction score: 433
Messages: 1,055

Exactly! I'd like to operate a Beagleboard at 50MHz, but you can't go below 300Mhz...
 

Daniel McRobb

New Member

Reaction score: 2
Messages: 3

I'm wondering who's working on an overarching framework for GPIO and their corresponding interrupts. I've written a few device drivers for the Raspberry Pi recently that interface to hardware via GPIO pins, and I'm using interrupts (and kqueue to communicate to user space). For my needs, writing a specific device driver is perfectly reasonable since my hardware configurations are fixed (HATs I designed, complete hardware setup is dedicated to a particular set of tasks). But I completely understand the desire to have GPIO interrupt facilities without having to write a device driver.

There are some quirks remaining with GPIO interrupts within the kernel that I haven't dug into yet. There are cases where it's desirable to have separate handlers for rising and falling edge interrupts, but the 11.0-CURRENT I have right now doesn't allow it. On my first pass at my rotary encoder driver, I found that gpio_alloc_intr_resource() failed for the second edge interrupt (order of rising or falling edge didn't matter). I wound up working around it and moving on, but I am hoping to make time to look at it again. Might already be fixed, I haven't had a chance to update in many weeks (or even open a bug report). And of course it's entirely possible that I did something wrong, but from memory I reviewed my code thoroughly before deciding on a workaround.

I have a wish list in my head for GPIO functionality, but haven't written it down. I do know I don't want to see the warts in Raspbian's solution to trickle into FreeBSD. But I'd like to have per-pin permissions per ioctl (i.e. better access control granularity), be able to do more without changing the FDT, etc. And of course efficient interrupts -> userspace.

If someone here know anyone who is working on such things, I'd be willing to help where I can. Even if it's just helping flesh out what would be 'nice to have'. I admit to not having a ton of time to contribute code outside of my immediate needs, but that's true of many of us who target FreeBSD in our spare time. There's been quite a bit of change in the trunk since 10.x with respect to this stuff, but unfortunately I don't seem to be clued in to the set of design goals and I don't have enough different SBCs to understand what will work in the general case versus what only works on the Pis and BeagleBones. :(
 

Daniel McRobb

New Member

Reaction score: 2
Messages: 3

I think a WG is a fine idea. I'm sure that many of us have the same desires, as well as the same ideas. Just coalescing them into something high level but cogent would be a good start and something I haven't yet seen for GPIO.

For some background... my bread and butter today is embedded development in the automotive industry. But I spent 15 years of my career writing software for UNIX and I haven't stopped. I've been running FreeBSD for various things professionally and at home for as long as I can remember (since the a.out and pre-SMP days). My primary language for FreeBSD and UNIX work has been C++ for a long time (coming up on 20 years), but my day job is nearly all C.

Hardware-wise, today's off-the-shelf SBCs are very capable devices at low cost. But there are those of us who'd like to bring the real differentiator of these platforms to bear (versus say a nanoITX x86 or amd64 platform) in our problem domains, on top of a freenix. I want a rock solid TCP/IP stack, filesystem, full POSIX APIs, real security facilities, etc. But I also want at least the minimal set of embedded functionality too: a complete GPIO API, SPI, I2C, CAN. Some higher-level hardware abstractions would be nice for everyone to have as well (quadrature rotary encoders, PWM, others). For most IoT stuff, I don't need a true real-time OS as much as I need real security (ssh, SSL, CryptoPP, etc.), robust TCP/IP and a complete development environment without a huge investment. And I much prefer a BSD license over GPL, which is one of the handful of reasons that FreeBSD remains my primary freenix target.
 
Top