status LED's controlled by a user callback

[tbowmo]

Just a thought, could we have a user provided callback routine, to handle the status LED's in the GW?

This way we could use different LED driver types (like ws2812b RGB led's f.ex) for status LED.

[rickmontana83]

Haven't looked at the code for the gateway, but in c++ if the functionality is implemented in a public or protected class member that is declared virtual then subclasses can redefine the behavior by overriding that method. Might be a workable avenue...

[rickmontana83]

Oof... Looked at the code. It's probably possible, but not with a trivial mod. The logic is handled across several functions. Best bet would prob be to factor digitalWrite() calls in ledTimersInterrupt to a replaceable function pointer. You'll have more global data lying around, but that's already being done in the library, so it doesn't really compromise design integrity much.

[tbowmo]

@rickmontana83

Well, it's arduino, so not C++ (Ok, the libraries are c++ if I remember right, but the rest isn't)

I'm just asking for a generic way to plug in whatever you want for status indication on the GW (could also be a LCD display for that matter)

[rickmontana83]

@tbowmo
The Arduino ide hides some things (like main()), and some features of the language are disabled throughout to keep code size down, but it's all fed through the C++ compiler in the end. So all the normal C++ OO concepts work both in libraries and in sketches.

I think a lot of times sketches don't use classes because it's overkill and it's really easy to accidentally blow through all your memory if you don't really understand what the compiler generates, but it's definitely possible.

[blacey]

@thozza recently reworked the LED implementation in the core library so he would be a good one to chime in on the options.

[tbowmo]

@blacey

Yup, @hek also pointed me in the directions of those changes.

However, while reading up on the communication specs for the ws2812b (as I had in mind using for the GW), I found them to be very timing critical, so I think it would be too much trouble to implement this type of controller for the status LED's, and therefore I have dropped that idea again. :)