Multiple receivers about rc-switch HOT 5 OPEN

After considering how to port my changes, perhaps it would be better to have a macro #define for the max number of receiver pins a user might require? This would simplify things a lot, and appears to be an appropriate use for a #define.

from rc-switch.

In principle, I think it would be nice to support more than one receiver, if this does not impose a penalty for people using a single receiver or no receiver at all, and if it is done well :-).

Using std::vector (or any other kind of dynamically resized arrayed) sounds like both unnecessary, and also bad from a technical view point.

It is unnecessary, as the number of supported receivers would likely need to be hardcoded at compile time anyway (to facilitate the interrupt handlers, one per input source). Moreover, the developer using rc-switch will know how many receivers there are going to be anyway.

It has technical drawbacks, because any form of dynamic memory management incurs a severe resource overhead (severe at least for restricted platforms like Arduino, ATTiny etc): it uses up more RAM increases the binary size (i.e. needs more flash), increasse CPU requirements, increases the overall complexity (and thus likelihood for bugs -- e.g. if an interrupt handlers accesses a std::vector, it must not be resized during that time -- so locking issues may need to be considered).

And even if somebody is willing to make all these tradeoffs for their particular use case, it seems like a bad idea to burden existing users with all that overhead when they don't need it.

Luckily, all of that is not necessary. Using #define macros and some clever coding, one can allow support for multiple receivers with little work, little overhead, and no impact at all on people who only need a single receiver. I very roughly sketched a plan for that on issue #63.

from rc-switch.

Fortunately, it turns out that's what I eventually ended up doing :)

Unfortunately, I was modifying Particle's version of the library (found here), which is horrifically outdated (and unformatted). I do have a working implementation right now that I can send to you, but I will need a bit to update it to work with the current version of the library.

from rc-switch.

Well, I don't really have a need for it myself, so even if you sent me something, I wouldn't do anything with it.
But feel free to push whatever you have already to a github repo, and post a link to it here, then I can perhaps give some feedback already.
Otherwise, if you at some point in the future manage to update it to the latest rc-switch, we'd definitely welcome a pull request for this feature :-).

from rc-switch.

I pasted a quick version of what I have so far here, complete with debugging statements and commented out code. :P I'm currently working on cleaning it up and testing it, after which I will work on updating it to what the library currently uses... Then I'll be able to submit a proper pull request.

Or maybe I should just fork the current repo and port over the changes. I'm not sure which is less work.

from rc-switch.