The Arduino language is kind of C++, and C++ classes have plenty of
advantages for this sort of thing.  There are also plenty of pitfalls
for embedded apps.

It turns out I have recently been dealing with a similar problem for a
temperature sensor.  My solution was to have an initialization routing
that gets the port, pin and a user assigned ID or handle.  The routine
maintains a small array indexed by the ID so to get the value subsequent
calls only need to pass in the ID.  Some of the references to the
individual pins get pretty ugly, but they are buried in the library so
you only have to work through them the first time.

As far as I can tell, you can't really pass a bit address into a
function, so you need the port address and bit number.  What used to be
a simple bit test becomes a rather arcane masking operation through a
pointer.  Fortunately, at least XC16 is pretty reasonable at generating
decent code for this sort of thing.

This is a realistic thing to do on the 16 or 32 bit PICs that tend to
have plenty of RAM.  On an 8 bit part, you would need to be pretty
careful.

Of course, if you are willing to compile in the pin numbers things get a
lot simpler.  I prefer pre-compiled and pre-tested libraries so I don't
introduce odd effects later when I've forgotten the details of the code.

--McD


On Thu, 2015-03-19 at 13:21 -0400, Josh Koffman wrote:
> Hi all,
>=20
> So as you may have guessed, I'm working on some rotary encoder routines i=
n XC8.
>=20
> I've been looking around, and I've actually found a pretty neat
> Arduino library. It handles the encoder, acceleration (values change
> faster if you spin faster), encoder switch status (click, double
> click, held, etc). I'm considering trying to port it to XC8 as I think
> it would be useful, but also a really good exercise in coding.
>=20
> I have no Arduino experience, but from what I've been reading, it
> appears that in their ecosystem you can define multiple instances of a
> class. So in my case if I made one routine that dealt with a single
> encoder, I could create 2 instances to deal with 2 encoders, etc. As
> far as I understand it, I can't do that in straight C.
>=20
> So, what is the preferred way of dealing with this? I could make the
> original function deal with total number of encoders that I have. Or I
> could make multiple copies of a function that dealt with a single
> encoder. In both cases I'll need to deal with variables carefully.
>=20
> Is there another (possibly better) way? I'm interested in this in the
> abstract as eventually I will likely run into this situation with
> other routines (switch debounce, for instance).
>=20
> Thanks!
>=20
> Josh
> --=20
> A common mistake that people make when trying to design something
> completely foolproof is to underestimate the ingenuity of complete
> fools.
>         -Douglas Adams


--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.