HAL vs ATMega328p (Arduino) Pin Change Interrupt

[igor]

Hello,
has anybody tried to implement support for PCInt (Pin Change Interrupt)?
That would enable supporting lots of asynchronous inputs on the popular Arduino UNO / Mini / Nano / MiniPro boards.
I'm thinking to give it a shot, if no one else has tried it.

thanks, igor

[Giovanni]

Moved to the AVR forum.

BTW, it would be nice to have.

Giovanni

[utzig]

Go for it.

[igor]

ok, then I need some help, as I started only a couple of days ago looking at the code and I'm stil ltrying to find my way around it.

Few preliminary questions:
* is there any unofficial port of 3.0.1 to ATMega328p/Arduino UNO? I found only one on github based on a 1-year old release

* I am thinking along the way of having top/bottom halves, with the irq only doing the demuxing of the pins and assigning a timestamp to it.
It could also release a semaphore that is attached to a specific pin upon registration. The idea is that there is a corresponding thread blocked on it.
What I described has several implications:
* need for time-stamping functionality - is that already present in RT/NIL?
* partitioning of the design between OS and HAL - I have no idea of what would be the correct way to do it, staying true to the architecture split
How does this look like?

[utzig]

Few preliminary questions:
* is there any unofficial port of 3.0.1 to ATMega328p/Arduino UNO? I found only one on github based on a 1-year old release

Not that I know of. I contacted Diego, aka devlware, and he said it has one demo running which hopefully he might contribute soon. Also when I made an initial port from 2.6 to 3.0 I converted the Uno demo too but I didn't have a board to test it so it didn't get in. If no external patches come in some days I'll find it here and post it as a patch for you to test and if it's ok I'll add it again.

* I am thinking along the way of having top/bottom halves, with the irq only doing the demuxing of the pins and assigning a timestamp to it.
It could also release a semaphore that is attached to a specific pin upon registration. The idea is that there is a corresponding thread blocked on it.
What I described has several implications:
* need for time-stamping functionality - is that already present in RT/NIL?
* partitioning of the design between OS and HAL - I have no idea of what would be the correct way to do it, staying true to the architecture split
How does this look like?

It's simpler than that I would think!

What you want is an ext driver and I would say your best bet would be to base your code on the ext driver for nRF51x:

https://github.com/ChibiOS/ChibiOS-Cont ... 1/NRF51822

If you have any issues be sure to ask.

Cheers,
Fabio Utzig

[utzig]

Such a nice timing, and the UNO support just got in!

[igor]

Such a nice timing, and the UNO support just got in!

Where?
Is there any git tree I can clone, rather than downloading stuff from SF?

[igor]

Such a nice timing, and the UNO support just got in!

Where?
Is there any git tree I can clone, rather than downloading stuff from SF?

ok, found on SF, but I'll wait for you to replicate it in github

[igor]

Hello again,
I decided to start first with the EXT driver, to get the hang of things, before attacking the PCINT.

Overall it doesn't seem too bad of a task. I already had it working in a non-ChibiOS way and I "just" need to convert it to the same lingo.

There's one thing that is leaving me baffled, though: what is the correct location where to write

#define PLATFORM_EXT_USE_EXT1 TRUE ?

It doesn't seem to belong to mcuconf.h, but neither to halconf.h

thanks, igor

[Giovanni]

Hi,

That kind of macros are found in a dedicated section of all low level drivers (the default) AND in mcuconf.h (the actual setting). You can find lots of examples in existing LLDs.

Giovanni