What do you need to write your own protocol executor
Posted: Wed Nov 14, 2018 4:26 am
What do you need to write your own protocol executor? The information is scattered all over the place, this is my attempt to take hide and seek out of the equation.
EDUCATION;
Ideally you'll have some programming experience but where there is enough desire, that shouldn't be a showstopper. You will need to learn how to use the Assembly language of your target chip, and you should learn the Samsung Assembly language, at least enough to read it. Almost every protocol executor exists for the Samsung chip. Although writing in assembler is tedious, an executor's code typically will fit on one screen, so it's not a horrible task.
If you learn to read IRP, you can find examples of other signals that do something similar, and see the assembly code that was used to accomplish the task in something similar.
There are chip datasheets on Rob's website. Some describe the chips assembler language:
http://www.hifi-remote.com/files/
http://www.hifi-remote.com/forums/dload ... cat_id=162
HARDWARE
You will need a UEI remote to shoot your signals. Ideally you'll have some way to capture your output for debugging purposes. I found an IRWidget to be ideal, but if you have some other tool that will capture timings such as a spare UEI learning remote that will do.
SOFTWARE TOOLS
The JP1 community has two tools that will help you write a protocol executor.
1) If you have Microsoft Office (not the starter version) you can use ProtcolBuilder (PB) with KeymapMaster (KM) .
2) You can also create/edit a protocol executor in RemoteMaster (RM).
Each executor building tool allows you to save a text file with your assembly code, but they will not import that text from each other.
Each tool has its own strength and weakness.
I find PB, KM and IR easier for me to experiment with because repeated attempts don't cause anything to crash.
In my opinion, RM has a superior disassembly tool, it has settings that allow you to have meaningful mnemonics in the code it generates..
The PB feature in RM has not been heavily used, so as of version 2.07 build 2, there are still some major bugs. If you use RM, I recommend that you do your development in an RM session that was NOT started off the RMIR File New.
The link for the current version of RM will be found in a Sticky in the software forum.
http://www.hifi-remote.com/forums/viewforum.php?f=9
RMPB_Readme.html is included in the RemoteMaster zip file. You'll want that readme file even if your are using PB. The RMPB readme file gives some insight about what the IRengine can do in the various remotes.
ProtocolBuilder (PB) is an excel spreadsheet run by macros, so it requires genuine MS Excel. The link for the last version of PB will be found with protocol file section. You can also find PB txt files that give you commented examples of executors, but these are only for PB not RM.
http://www.hifi-remote.com/forums/dload ... le_id=2305
"Variable and vector chart" - You need that information to write a protocol executor. That “variables and vectors chart” spreadsheet can be opened by any spreadsheet program. Without this key piece of information, you can't write code to send a signal.
http://www.hifi-remote.com/forums/dload ... le_id=6879
KM version 9.22 KM is a another macro driven Excel spreadsheet requiring genuine Excel. Upgrades created with KM can be opened by both KM and RM, RM upgrades can not be opened by KM (this tool has been archived, at this time RM does a better job with KM files, than it does with its own format)
http://www.hifi-remote.com/forums/dload ... le_id=1888
IR version 8.04 (this tool has been archived, when working trial and error, this tool is way more forgiving than RMIR)
http://www.hifi-remote.com/forums/dload ... e_id=11605
GETTING STARTED
In order to write a protocol executor you are going to need to know the timing pattern and the frequency of the signal. The timing data can come from many sources. Learned signals, ICT files, LIRC files manufactures documents.....
The following beginners document gives you some idea of what the numbers represent, including terms that may make it easier to understand some of the terminology you'll see in the protocol executor building tools .
http://www.hifi-remote.com/forums/dload ... le_id=6996
The next step of the process decode the signal. Decoding includes finding the stationary parts of the signal, vs the parts that change with each function. Sometimes the pattern will be very simple, sometimes the pattern is diabolically clever. To fully understand the pattern we need as many samples of the signal as possible. Getting these from the person that actually needs the signals, is like pulling teeth.
You should also read this PB help document from Rob. It gives an example for using PB. The same information applies to RM's pb functionality.
http://www.hifi-remote.com/forums/dload ... le_id=2304
In addition there are lots of timing decoding examples of this in the protocol forum. If you find the pattern recognition part over your head, you can always post the timing data in the protocol decode forum and ask for help.
The tools to create a device upgrade are used by most everyone in the JP1 community. It is assumed that you have already created a few device upgrades, and have observed how they have some fixed data, and then data that changes with each command. The device upgrade holds the signal data necessary to create the on-off pattern.
The executor holds the timing data, Protocol Flags, Protocol data, and object code. When you write an executor, you decide how many variables you need and how the hex is going to be loaded.
Fortunately the protocol executor building tools go a long way towards automating the process of creating a protocol executor and answer some questions, and the tools can build you a skeletal upgrade, that will send a signal based on those answers.
SIZE MATTERS
We want to see how small we can make the combination of the executor and upgrade that calls it.
Tip: One of the tricks we often use on a NEC signal, is to make a complement of the second command byte in the code, instead of storing an extra byte for each and every command in the device upgrade.
There are 2 bytes of protocol flags, that are going to set a bunch of bits that tell the remote how to load the data into the buffer, and how to send the data. In a situation like the NEC to compute the protocol flags, set the device and command count to the size of the signal you want to send before you create your skeletal upgrade, then change protocol data values to use the number of device and commands to match your input for loading purposes. In the code where you manipulate the databuffer, change the value of the device and command count bytes to match the value you had when you calculated the protocol flags.
Besides making the overall size of the device upgrade smaller, we also want the function portion to be 1 byte if possible, because some older remotes can't handle a 2byte keymoves.
MSB LSB COMP
For a standalone upgrade with a manual executor, both KM and RM only allow you to specify if the hex is going to be calculated MSB LSB or Comp or NonComp. If there is already a translator for this signal, we want to make the LSB or MSB match the decoded values. If your exploring new uncharted territory, choose your settings based on if there is a way to make the number OBC values appear in numerical order.
KM lets you change the LSB and Comp settings after the fact preserving the hex and changing the OBC , RM does too, but you need to turn on the "Allow Preserve Control" feature from the Options menu or the hex will change.
In addition, in RM you can also make an entry in Protocols.ini to get advanced translators for your hex, but nobody can use the upgrade unless their protocols.ini has also been altered.
WRITE
I usually start by writing comments on what my code is going to do.
Next write the code outlined by the comments.
TEST
Load up a remote, and send the signal.
OPTIMIZE
Your code should be as small as you can get it. See if rearranging the code can save some steps. Look to see if there are instructions that generate fewer bytes.
FINAL TEST
Perform one more test, to make sure everything is working.
SHARE.
Post your upgrade so that someone else can enjoy your work.
EDUCATION;
Ideally you'll have some programming experience but where there is enough desire, that shouldn't be a showstopper. You will need to learn how to use the Assembly language of your target chip, and you should learn the Samsung Assembly language, at least enough to read it. Almost every protocol executor exists for the Samsung chip. Although writing in assembler is tedious, an executor's code typically will fit on one screen, so it's not a horrible task.
If you learn to read IRP, you can find examples of other signals that do something similar, and see the assembly code that was used to accomplish the task in something similar.
There are chip datasheets on Rob's website. Some describe the chips assembler language:
http://www.hifi-remote.com/files/
http://www.hifi-remote.com/forums/dload ... cat_id=162
HARDWARE
You will need a UEI remote to shoot your signals. Ideally you'll have some way to capture your output for debugging purposes. I found an IRWidget to be ideal, but if you have some other tool that will capture timings such as a spare UEI learning remote that will do.
SOFTWARE TOOLS
The JP1 community has two tools that will help you write a protocol executor.
1) If you have Microsoft Office (not the starter version) you can use ProtcolBuilder (PB) with KeymapMaster (KM) .
2) You can also create/edit a protocol executor in RemoteMaster (RM).
Each executor building tool allows you to save a text file with your assembly code, but they will not import that text from each other.
Each tool has its own strength and weakness.
I find PB, KM and IR easier for me to experiment with because repeated attempts don't cause anything to crash.
In my opinion, RM has a superior disassembly tool, it has settings that allow you to have meaningful mnemonics in the code it generates..
The PB feature in RM has not been heavily used, so as of version 2.07 build 2, there are still some major bugs. If you use RM, I recommend that you do your development in an RM session that was NOT started off the RMIR File New.
The link for the current version of RM will be found in a Sticky in the software forum.
http://www.hifi-remote.com/forums/viewforum.php?f=9
RMPB_Readme.html is included in the RemoteMaster zip file. You'll want that readme file even if your are using PB. The RMPB readme file gives some insight about what the IRengine can do in the various remotes.
ProtocolBuilder (PB) is an excel spreadsheet run by macros, so it requires genuine MS Excel. The link for the last version of PB will be found with protocol file section. You can also find PB txt files that give you commented examples of executors, but these are only for PB not RM.
http://www.hifi-remote.com/forums/dload ... le_id=2305
"Variable and vector chart" - You need that information to write a protocol executor. That “variables and vectors chart” spreadsheet can be opened by any spreadsheet program. Without this key piece of information, you can't write code to send a signal.
http://www.hifi-remote.com/forums/dload ... le_id=6879
KM version 9.22 KM is a another macro driven Excel spreadsheet requiring genuine Excel. Upgrades created with KM can be opened by both KM and RM, RM upgrades can not be opened by KM (this tool has been archived, at this time RM does a better job with KM files, than it does with its own format)
http://www.hifi-remote.com/forums/dload ... le_id=1888
IR version 8.04 (this tool has been archived, when working trial and error, this tool is way more forgiving than RMIR)
http://www.hifi-remote.com/forums/dload ... e_id=11605
GETTING STARTED
In order to write a protocol executor you are going to need to know the timing pattern and the frequency of the signal. The timing data can come from many sources. Learned signals, ICT files, LIRC files manufactures documents.....
The following beginners document gives you some idea of what the numbers represent, including terms that may make it easier to understand some of the terminology you'll see in the protocol executor building tools .
http://www.hifi-remote.com/forums/dload ... le_id=6996
The next step of the process decode the signal. Decoding includes finding the stationary parts of the signal, vs the parts that change with each function. Sometimes the pattern will be very simple, sometimes the pattern is diabolically clever. To fully understand the pattern we need as many samples of the signal as possible. Getting these from the person that actually needs the signals, is like pulling teeth.
You should also read this PB help document from Rob. It gives an example for using PB. The same information applies to RM's pb functionality.
http://www.hifi-remote.com/forums/dload ... le_id=2304
In addition there are lots of timing decoding examples of this in the protocol forum. If you find the pattern recognition part over your head, you can always post the timing data in the protocol decode forum and ask for help.
The tools to create a device upgrade are used by most everyone in the JP1 community. It is assumed that you have already created a few device upgrades, and have observed how they have some fixed data, and then data that changes with each command. The device upgrade holds the signal data necessary to create the on-off pattern.
The executor holds the timing data, Protocol Flags, Protocol data, and object code. When you write an executor, you decide how many variables you need and how the hex is going to be loaded.
Fortunately the protocol executor building tools go a long way towards automating the process of creating a protocol executor and answer some questions, and the tools can build you a skeletal upgrade, that will send a signal based on those answers.
SIZE MATTERS
We want to see how small we can make the combination of the executor and upgrade that calls it.
Tip: One of the tricks we often use on a NEC signal, is to make a complement of the second command byte in the code, instead of storing an extra byte for each and every command in the device upgrade.
There are 2 bytes of protocol flags, that are going to set a bunch of bits that tell the remote how to load the data into the buffer, and how to send the data. In a situation like the NEC to compute the protocol flags, set the device and command count to the size of the signal you want to send before you create your skeletal upgrade, then change protocol data values to use the number of device and commands to match your input for loading purposes. In the code where you manipulate the databuffer, change the value of the device and command count bytes to match the value you had when you calculated the protocol flags.
Besides making the overall size of the device upgrade smaller, we also want the function portion to be 1 byte if possible, because some older remotes can't handle a 2byte keymoves.
MSB LSB COMP
For a standalone upgrade with a manual executor, both KM and RM only allow you to specify if the hex is going to be calculated MSB LSB or Comp or NonComp. If there is already a translator for this signal, we want to make the LSB or MSB match the decoded values. If your exploring new uncharted territory, choose your settings based on if there is a way to make the number OBC values appear in numerical order.
KM lets you change the LSB and Comp settings after the fact preserving the hex and changing the OBC , RM does too, but you need to turn on the "Allow Preserve Control" feature from the Options menu or the hex will change.
In addition, in RM you can also make an entry in Protocols.ini to get advanced translators for your hex, but nobody can use the upgrade unless their protocols.ini has also been altered.
WRITE
I usually start by writing comments on what my code is going to do.
Next write the code outlined by the comments.
TEST
Load up a remote, and send the signal.
OPTIMIZE
Your code should be as small as you can get it. See if rearranging the code can save some steps. Look to see if there are instructions that generate fewer bytes.
FINAL TEST
Perform one more test, to make sure everything is working.
SHARE.
Post your upgrade so that someone else can enjoy your work.
Some thoughts:
, due to the nature of remotes with very limited memory, tweaking may be needed anyhow,... etc.