Significant updates coming along

[z3t0]

Information

This issue is to note that I will be spending a significant amount of time over the next three weeks to add features, documentation and guides/tutorials to this library.

If anyone has any requests then I would love to add it to my list below. I will also be looking through past issues/tasks that have been requested, though repeating anything important will bring it to the front of my mind.

Below are some ideas and at the bottom of the issue is going to be a list of tasks I will continue to update.

Ideas

These are some ideas for features that I would like to incorporate. They are up for discussion and may not be very realistic.

• Protocol code generator: I would like to use a single file as a database of protocol implementations in a format such as IRP notation. Then we could write a script / program to parse this information and generate the protocol specific code for this library. This means there will be an extra build step when releasing the library, but the end user will receive a fully working copy of the library with the protocol files as generated source code.

Tasks

The following are tasks that will be completed, roughly in the order presented. As I begin each task, or extensive discussion is required I will be creating new issues and provided the links in the relevant parts of this document.

• #464 source file layout, i.e. non-exported includes in subdirectories
• #463 nuke dead code
• #462 nuke LED blinking
• #466 nuke Pronto
• #461 getting started with Doxygen (not writing all documentation, just getting started)
• #445 determine formatting guidelines
• Implement Pronto Hex properly, see What is the purpose of the Pronto protocol? #502
• #444 reorganize boarddefs.h, I think one file per board would be best
• Simplified API #458 Rewriting and cleaning up the API as well as writing better code
• Documenting protocol implementations
• Adding new protocols, a new issue with a list will be published once I begin work on this. In the meantime suggestions for any needed protocols along with their respective specs should be mentioned here.
• Automated tests, will look at IRRemote-SIL once I figure out the build errors on my system.
• Test the soft carrier implementation in Cleanup of hardware dependencies. Merge in SAM support.  #437
• Add support for new boards, e.g. Added Esp32 IrSend Support #491 #498 Add support for ATmega8515, ATmega162, ATmega1281 and ATmega2561 #440

Mentioning important contributors for their thoughts @bengtmartensson @AnalysIR @MCUdude @crankyoldgit @AbelHu @electronicdrops

[bengtmartensson]

Actually, I would suggest instead working "bottom-up", first getting the low-level things right (hardware and raw signals), then the high-level things like protocols. For this, I would recommend giving the following stuff first priority -- they should all be fairly quick

• #464 source file layout, i.e. non-exported includes in subdirectories
• #463 nuke dead code
• #462 nuke LED blinking
• #466 nuke Pronto
• #461 getting started with Doxygen (not writing all documentation, just getting started)
• #445 determine formatting guidelines
• #444 reorganize boarddefs.h, I think one file per board would be best,

And then there is of course #458, with a lot of good stuff, in particular, do not use platform dependent types like (unsigned) int, except for when it is explicitly desired.

Will write more about protocols later.

[z3t0]

Actually, I would suggest instead working "bottom-up", first getting the low-level things right (hardware and raw signals), then the high-level things like protocols.

Sure, that sounds like a good way to handle things. The tasks in the original post were just those I happened to think of at the time.

I will update the original post with tasks you mentioned.

[crankyoldgit]

A meta-language sounds interesting. Let me know if you get around to that. I've been trying to reduce commonalities in protocols by using common methods/functions. Something like what you've described is needed but, TBH, is a lower priority compared to other things you've listed.

I took the step of going to platform independent types on IRremoteESP8266, and frankly haven't looked back. It also allowed me to implement extensive off-board unit testing with a fair degree of certainty that things would behave the same as on the micro-controller vs. generic CPU. Usual caveats etc.

That really helped with development/testing time frames, as well as being able to simulate user reported issues, mostly cutting out the device flashing cycle entirely. It also allowed integrating it into the Travis process, which was also a huge boon.

I used the Google Unit Test framework and implemented it here. Feel free to borrow/take/back-port whatever you need.

[bengtmartensson]

Protocol generation etc: I have actually been working along these lines for some time. This is the project IrpTransmogrifier. At its heart, there is a database of IR protocols with the protocols in IRP format, some additional information (keyword-value pairs, thus extendable), and documentation as embedded (X)HTML fragments, everything embedded in an XML file. It can. among other things, generate code for different targets, like IRremote. Back ends are written in the template language StringTemplate, making it relatively easy to write a new backend/target. (Unfortunately, the back end for IRremote is not written yet :-.)

Unfortunately, there are a number of issues here: IRremote does not use standard parametrization even of standard protocols, but everything is just lumped into one data parameter, interpreted most-significant-bit first. There is no systematic treatment of intro-, repeat-, and ending sequences. Etc. API needs to be determined -- see some of the other treads (#458?)

@crankyoldgit : the testing framework looks interesting, I will have a look. IRremote-SIL is "just" a test rig, tests in the modern sense not integrated yet.

[z3t0]

Protocol generation etc: I have actually been working along these lines

for some time. This is the project IrpTransmogrifier <https://github.com/bengtmartensson/IrpTransmogrifier>. At its heart, there is a database of IR protocols <https://github.com/bengtmartensson/IrpTransmogrifier/blob/master/src/main/resources/IrpProtocols.xml> with the protocols in IRP format, some additional information (keyword-value pairs, thus extendable), and documentation as embedded (X)HTML fragments, everything embedded in an XML file. It can. among other things, generate code for different targets, like IRremote. Back ends are written in the template language StringTemplate <http://www.stringtemplate.org/>, making it relatively easy to write a new backend/target. (Unfortunately, the back end for IRremote is not written yet :-.) Thanks I will definitely be following that project and do what I can once I figure out the macOS build issues.

Unfortunately, there are a number of issues here: IRremote does not use

standard parametrization even of standard protocols, but everything is just lumped into one data parameter, interpreted most-significant-bit first. There is no systematic treatment of intro-, repeat-, and ending sequences. Etc. If you have any suggestions then I would love to hear them! You clearly have a lot more experience in this field.

…

On Mon, Aug 14, 2017 at 12:59 PM, Bengt Martensson ***@***.*** > wrote: Protocol generation etc: I have actually been working along these lines for some time. This is the project IrpTransmogrifier <https://github.com/bengtmartensson/IrpTransmogrifier>. At its heart, there is a database of IR protocols <https://github.com/bengtmartensson/IrpTransmogrifier/blob/master/src/main/resources/IrpProtocols.xml> with the protocols in IRP format, some additional information (keyword-value pairs, thus extendable), and documentation as embedded (X)HTML fragments, everything embedded in an XML file. It can. among other things, generate code for different targets, like IRremote. Back ends are written in the template language StringTemplate <http://www.stringtemplate.org/>, making it relatively easy to write a new backend/target. (Unfortunately, the back end for IRremote is not written yet :-.) Unfortunately, there are a number of issues here: IRremote does not use standard parametrization even of standard protocols, but everything is just lumped into one data parameter, interpreted most-significant-bit first. There is no systematic treatment of intro-, repeat-, and ending sequences. Etc. API needs to be determined -- see some of the other treads (#458 <#458>?) @crankyoldgit <https://github.com/crankyoldgit> : the testing framework looks interesting, I will have a look. IRremote-SIL is "just" a test rig, tests in the modern sense not integrated yet. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#500 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIlUfZbXvNkLV3tDa4DkI2u_qHW8kbKWks5sYJkcgaJpZM4O1ltu> .

[bengtmartensson]

If you have any suggestions then I would love to hear them!

As I wrote above, my main suggestion is this:

I would suggest instead working "bottom-up", first getting the low-level things right (hardware and raw signals), then the high-level things like protocols.

Then the API related stuff, there are a lot of details in #458.