Help me with creating device update

[mathdon]

Graham,
I chose the order of the bytes in the fixed and variable data arbitrarily. For this TI2541/MAXQ executor, these byte orders are not important. However, perhaps a S3C80 executor would need a different order, which we can easily change now but once it has been published in the next release we should avoid further changes.

If Rob, or perhaps you, wants to write an S3C80 executor, I can delay issuing the next RMIR release or omit your executor from that release and include it in the following one, depending on the timescale for the S3C80 executor to be ready. S3C80 architecture and its assembler are something that I have never got to grips with. Beloved of some, so I understand, but just plain weird to me, so I have to leave it to one of you two as I am not in a position to write one.

[The Robman]

I didn't realize FieldCopier was a protocols.ini function, so I was Googling it to try to understand what it was. I also didn't know that it only had the ability to add nibbles rather than bytes, so maybe it would be a good idea to add the ability to add bytes together?

I think my personal preference, in the absence of any other samples of this protocol would have been to treat the 3rd byte as another device code as the fact that it is the reverse of the 1st byte may be a coincidence, but as you say, at least that's in protocols.ini rather than the executor.

I agree with adding the fixed bytes outside of the executor if that saves executor space. (Just FYI, it takes 6 bytes of code to add the 2 variable bytes to the checksum, and it would only have taken 10 bytes of code to write a loop to add all 5 of the bytes). This is what that code would look like:

Code: Select all

6C 05     loop: LD    W6,#05
87 56 02        LD    W5,#02h[W6]
04 C5 08        ADD   R08,W5
6A F6           DJNZ  W6,loop

As for the allocation of bytes, thinking of this from an S3C8 executor point of view, I think my preference would be to make this a 6-2 format (ie, 6 fixed, 2 variable) where the bits in the protocol block define it as "all of the fixed bytes and 0 variable bytes). I would populate bytes 1, 3, 5 and 6 from protocols.ini, with bytes 2 and 4 being zero filled and byte 6 being the seeded value for the checksum (ie, the 3 fixed bytes and "4" being added together). Then in the executor, I'd move variable byte1 to data byte2, and variable byte2 to data byte4, then I'd ADD each of them to data byte 6.

Here's an un-tested S3C8 executor as described above:
http://www.hifi-remote.com/forums/dload ... e_id=26342

[3FG]

I'll look at the S3C80 stuff tonight.
Regarding adding a translator to RMIR to sum over bytes is something I'd like to do, and it should be quite simple to do as a modification to the NibbleSumChk translator. I tried to do it yesterday, but I haven't been able to get an Eclipse project without lots of package errors. It is looking for packages that are something like main\com\ etcetera rather than com\etcetera. The Maven build itself works fine, but adding a new Java class is beyond my understanding of pom.xml.

[mathdon]

Sorry, I don't understand. You do not need to modify pom.xml to add a new Java class. You just add a new class in Eclipse in exactly the same way as before the migration to Maven. You will need to check out RMIR afresh from the SVN, though, as the directory structure was changed in the migration. If you have done that and still can't get it to work, can you explain in a little more detail what is going wrong?

[The Robman]

If you know what needs to be done Graham, would you be able to make a clone of the nibble sum process that sums up bytes?

[3FG]

Graham,
The problem is fixed. I used the instructions in https://scriptime.blogspot.com/2014/08/ ... lipse.html
The two non-obvious things to me was to run mvn eclipse:eclipse, and then to do File->Import->General->Existing Projects in Workspace. I had been trying to import a Maven project. I gather there is another way to do this directly from Eclipse using the Maven plug-in, but I didn't get it to work.

Rob,
I understand your S3C80 executor, and once I get a byte sum translator going I'll modify the TI/MAXQ executor to accept 6 fixed bytes (even though two are just space holders).

[The Robman]

Sounds good, and yes, they are placeholders, but it's only wasting 2 bytes, whereas it would take more than 2 bytes of executor code to move all the data around if we didn't use them.

[3FG]

Graham,
I zipped up a protocols.ini entry and the Java class ByteSumCheck. Also a skeleton RMDU file for the robot vacuum. Hopefully user loft will take that MDU file, assign the buttons and fill in a good description before uploading as an upgrade.

I checked these with URC7980, Inteset INT-422-3, and a 1067BC4.
http://www.hifi-remote.com/forums/dload ... e_id=26343

[mathdon]

I zipped up a protocols.ini entry and the Java class ByteSumCheck.

I have included these in RMIR v2.13.0 which I have just released. It also includes the entries needed for RMIR to identify learned signals as Eufy 11s protocol.