Elixir_ale question - do I need an interrupt driven solution?

nerves
raspberrypi
spi
interrupt
i2c

#1

Hi All…

I started an embedded project last year and got taken off it, and now I need to jump in again. This project, among many other things, needs to talk to a CAN bus. I’m prototyping on a Raspberry Pi 3 B+ and I have a CAN card that interfaces using SPI.

Having read through some posts, there is an implication that elixir_ale is not interrupt driven. I assume that my code would need to poll the SPI controller. In general, does this work, or will I need an interrupt driven solution?

If I do need an interrupt driven solution, I assume that means a kernel driver. Is there one available or would I have to write one?

Thanks very much…


#2

Elixir is far enough away from hardware that I’m not sure interrupt-driven vs. non-interrupt-driven is going to be the main issue. You can poll GPIOs with elixir_ale or tell elixir_ale to send a message when the GPIO changes. The latter way is “kind of” interrupt-driven since nothing in the system is actively polling the GPIO. There’s a lot of software between the hardware and your Elixir code, so it won’t work as well as you’d expect. I think that it’s passable for event rates under 100 per second.

I’d personally look for a Linux kernel driver for this. Linux kernel drivers just work so much better when dealing with the low-level details of reacting to a GPIO changing and initiating SPI transactions. When the messages are fully received, Elixir makes handling the messages really convenient and is pretty efficient.

Just to add here, there was some work to make a NIF version of elixir_ale. An initial prototype worked really well - it was a couple orders of magnitude faster than elixir_ale. I had been helping someone out on it, but I think they’ve long since lost interest/gotten busy with other things. It would be another option if the kernel driver option won’t work for you and unfinished code doesn’t scare you.

Frank


#3

Thanks Frank, I think you’re right, a device driver is the way to go. I have written serial drivers in the past, I suppose an SPI driver would work about the same way. I suspect there is one available, I’ll hunt around. Seems a common enough need.