Replies: 2 comments
-
Wow! I personally would prefer your first approach. With an additional (default) parameter for repeat handling and an implementation which allows the compiler to easily omit the code not used when called with a constant parameter value, I think we will get a simple, versatile and consistent sending library, which does not depend on the receiving part 😀. Thank you very much for your analysis and your effort, and thank you for your offer to implement this! |
Beta Was this translation helpful? Give feedback.
-
Please rebase your repo, since I added the convenience function isIRReceiverAttachedForTinyReceiver(). |
Beta Was this translation helpful? Give feedback.
-
When I submitted my pull request to add Extended NEC support to TinyIR, I was under the impression that TinyIRSender already supported Extended NEC as the sendNEC() function will accept 8 or 16 bits for both the address and command fields. However, I encountered a case where an issue is encountered; if a device uses Extended NEC but expects an address of 0x00FF or below, sendNEC() will convert this into an 8 bit address with an inverted 8 bits afterwards. An ExtendedNEC device will interpret this as an entirely different address. Therefore a separate sendExtendedNEC function is necessary.
I am happy to implement this function within the current design myself, however partway through doing so I noticed a design inconsistency which I figure I may as well fix at the same time. The TinyIRReceiver by design can only receive one protocol per script; which protocol is determined at compile time with the USE_[Protocol]_PROTOCOL compile flags and the ENABLE_NEC2_REPEATS flag. However, protocol selection for TinyIRSender is primarily determined by which send function is used; sendFAST(), sendONKYO() or sendNEC(). This theoretically allows the usage of sending using multiple different protocols in the one script. The issue is that the ENABLE_NEC2_REPEATS flag IS used by TinyIRSender, so all NEC variant protocols used must have the same repeat handling. The TinySender.ino example script further confuses this by recognizing the same USE_[Protocol]_PROTOCOL compile flags as the TinyIRReceiver library, but handling them in the example script by selecting which send function is used.
It seems to me that it would be a good idea to commit to one of two design approaches for TinyIRSender:
The advantage of the first approach is that it allows TinyIRSender to be used in situations which require sending multiple protocols in the one program. However, there's an argument to be made that if you want to send multiple protocols, you should probably just use the full IRRemote library, especially given TinyIR can never receive multiple protocols. The advantage of the second approach is that it is more consistent with TinyIRReciever, and a single set of flags will be applicable across both sending and receiving.
Alternatively of course, everything can just be left as is.
I am happy to try and implement whichever approach people think is the best.
Beta Was this translation helpful? Give feedback.
All reactions