Page 3 of 4
Posted: Thu Feb 25, 2016 12:38 pm
by Carl
That's great, I will test it at work tomorrow. Will it be complicated to make it work for other remote with different processor as the URC8820?
I will start by testing all the functions with my atlas and report back.
It's really appreciated.
Posted: Thu Feb 25, 2016 9:50 pm
by The Robman
I have done a commented version of the S3C8 assembler code, to assist in the effort of writing a HCS08 executor
http://www.hifi-remote.com/forums/dload ... e_id=13948
Posted: Thu Feb 25, 2016 10:18 pm
by The Robman
Carl, I have also updated the RM file that I created:
http://www.hifi-remote.com/forums/dload ... e_id=13947
I hadn't accounted for the fact that the arrow buttons have a different lead out time, and the last bit of binary is used to control that. Plus, you got the LEFT and RIGHT buttons backwards when you learned them, so that threw me for a bit too. So, bottom line, the UEI arrow buttons now match yours.
Posted: Fri Feb 26, 2016 5:43 am
by vickyg2003
Thanks Rob. Your commented code will be a big help.
I had a look at this raw code last night, It seems I've forgotten a lot about both assembler languages. I'm going to work on this, but it is going to take me some time to get back up to speed. I then went looking for the HCS08 compiler and realize I don't have it on this machine. I left the disks up north so I don't have lots of examples to look at. So I think it will take me several days to get this going.
Posted: Fri Feb 26, 2016 10:43 am
by Carl
I have tested the last upgrade with my atlas remote and everything is working, but there is no way to turn off the projector because the discrete off function is missing. Here is the output of a learned key that work:
Code: Select all
+2314 -600 +574 -588 +1154 -592 +574 -588 +574 -1174 +574 -588 +1154 -1176 +574 -1174 +1154 -592 +574 -588 +574 -588 +574 -588 +574 -588 +574 -588 +574 -76362
It was also on the stop button in my original file that I posted for doing the upgrades.
Posted: Fri Feb 26, 2016 11:44 am
by The Robman
I don't know how the discrete off button fell of the file, because I have the code for it, so I just re-added it.
Or, you can add it yourself, the hex is "84 D8 00"
Posted: Fri Feb 26, 2016 9:03 pm
by The Robman
Vicky, looking at the HCS08 code in the following file, it appears that there is a flag that you can set to tell the engine that it's a base 4 code, so that makes it sounds like creating an HCS08 executor should be fairly easy (if you know what you're doing)
http://www.hifi-remote.com/forums/dload ... le_id=8135
Posted: Sun Feb 28, 2016 4:08 pm
by The Robman
vickyg2003 wrote:I had a look at this raw code last night, It seems I've forgotten a lot about both assembler languages. I'm going to work on this, but it is going to take me some time to get back up to speed. I then went looking for the HCS08 compiler and realize I don't have it on this machine. I left the disks up north so I don't have lots of examples to look at. So I think it will take me several days to get this going.
Vicky, Protocol Builder can compile and verify HCS08 code, so that should be the only tool that you need. Having read several of your old posts on the subject, it appears that HCS08 can handle quad protocols in the engine and that last PB file that I posted appears to be an example of this, so maybe it won't be that hard to convert this to HCS08. I've just never written anything in HCS08 and I don't know the specifics of the IR engine, or I'd try it myself.
Posted: Fri Mar 04, 2016 12:03 pm
by vickyg2003
Rob, after 300 attempts TODAY! I finally found my error in those 6 lines of code. Now that I know what I was doing wrong with my code, I need to pare down the size of my executor. When looking at your code, I see that you divided this up into
1 2 bit device
3 8 bit device
1 hard coded 2 bit pair of zero.
00 = +572 -572
01 = +572 -1144
10 = +1144 -572
11 = +1144 -1144
Here's the binary
+2288 -572 00100001010000000000000000 +572 -78364 - discrete on
+2288 -572 00100001001101100000000000 +572 -76648 - discrete off
+2288 -572 00100001001010000000000000 +572 -77792 - Menu
+2288 -572 00100000001000000001000010 +572 -32032 - Down
+2288 -572 00100000010000000001000000 +572 -32604 - Up
+2288 -572 00100000010100000000000000 +572 -32604 - Left
+2288 -572 00100000011100001001000000 +572 -30888 - Right
+2288 -572 00100000010000010000000000 +572 -78364 - OK
+2288 -572 00100001000000100010000000 +572 -77792 - VOL+
+2288 -572 00100001011010100010000000 +572 -75504 - VOL-
+2288 -572 00100001010001010000000000 +572 -77220 - computer
+2288 -572 00100001001100011000000000 +572 -76648 - BNC
+2288 -572 00100001000011110000000000 +572 -76648 - DisplayPort
+2288 -572 00100001011000011000000000 +572 -76648 - Video
+2288 -572 00100001010010011000000000 +572 -76648 - s-video
+2288 -572 00100001011111010000000000 +572 -74932 - HDMI
+2288 -572 00100001001001011000000000 +572 -76648 - LAN
+2288 -572 00100001011101110000000000 +572 -74932 - HDBaseT
+2288 -572 00100001001001110000000000 +572 -76648 - SDI
+2288 -572 00100000010000000100000000 +572 -78364 - Exit
+2288 -572 00100001001000000010000000 +572 -77792 - CH+
+2288 -572 00100001000010000010000000 +572 -77792 - CH-
+2288 -572 00100001000000101000000000 +572 -77792 - Format
+2288 -572 00100001001111111000000000 +572 -74360 - Input
Looking at the codes you decoded, it would seem that it would that it would be more efficient to use 1 4 bit device instead of hard coding, the two bit process.
Any reason not to use a 4 bit device?
---------------------------------------------
And for those of you that think I'm an old curmudgeon, when I say that PB with IR is a lot easier than RMIR, let me point out that for every attempt you make at a protocol using RMIR, you need to change the executor's PID to something unique.... Any wonder I regularly give RMIR a nervous breakdown!?!
I know that a lot of you are engineers, and wouldn't ever have to try something 300 times to get it right, but I got into this because I wanted to have a clean coffee table, not because of my programming skills!
Posted: Fri Mar 04, 2016 12:33 pm
by The Robman
vickyg2003 wrote:Looking at the codes you decoded, it would seem that it would that it would be more efficient to use 1 4 bit device instead of hard coding, the two bit process.
Any reason not to use a 4 bit device?
Here's how I looked at it. The minimum number of variable bytes needed is 3, so 3 times 8 gives 24, so I used 24 bits for the variable bytes and the remainder, which is 2 bits, is the fixed data. And it just so happened that this is exactly how UEI did it also. The commented executor that I posted was written by UEI, I just added the comments.
If you increase the fixed bits to 4, that would leave 22 variable bits to be divided across 3 bytes and there's no easy way to do it. It would be better to make it 5 fixed bits and 21 variable because then you can do 7 bits per byte. But regardless, I don't see how there's any benefit to doing any of that. Why were you thinking that 4 bits is better than 2?
Posted: Fri Mar 04, 2016 4:12 pm
by vickyg2003
Why were you thinking that 4 bits is better than 2?
I can't count and didn't understand one of your comments, lol.
I do have a working protocol, for this. I've checked the number 1, and 2 and I see the leadout time is changing for the
Code: Select all
Upgrade protocol 0 = 01 73 (HCS08) Epson PowerLite Pro G6270W (PB v4.02)
20 1F 22 48 13 8D 45 04 08 01 0D 01 35 01 0D 02
57 02 2F 01 35 02 2F 02 57 01 0D 94 5C 04 86 01
35 01 63 07 45 3E 5D 35 7E 11 63 45 00 80 CD FF
65 3F 64 6E 03 65 AD 11 3C 64 05 64 F9 45 00 7C
CD FF 65 CD FF 92 25 E3 81 BE 64 E6 60 B7 66 AD
17 AD 15 B6 66 A4 03 AE 04 42 AB 6C 97 CD FF 65
3C 65 05 65 EA 3F 65 81 38 66 24 02 10 66 81
End
But, now that I have it I think I can do much better.
I am already using a bit counter, and a byte counter, and rotating the bytes into position, and then multiplying, the 2 bit value by 4, the same as you do,
Instead of rotating the bit and masking off the last 2 bits and looking up a timing pair,
Just left shift the working variable.
if the carry bit is set
Point at the 1148 time,
otherwise
set the pointer to the 568 time.
If the 0 bit in the bit counter is 0,
send IR on by pointer
otherwise
send space by pointer
I haven't coded it, but it seems like this would be smaller code, you wouldn't have to have 12 bytes of timing pairs. No masking, no multiplying by 4, and in my language the rotate is a PITA. That is what took me so much time, I thought it would just rotate around, but it didn't!
Posted: Fri Mar 04, 2016 7:21 pm
by The Robman
I think the way you are planning to do it is how John Fine would do it, and it would use less code. And I didn't write the S3C8 executor, UEI wrote it.
Posted: Fri Mar 04, 2016 9:40 pm
by The Robman
Carl, I have updated the original RMDU file to include Vicky's new executor for HCS08 remotes, like your URC-8820N. I also included the MaxQ executor
http://www.hifi-remote.com/forums/dload ... e_id=13947
Posted: Sat Mar 05, 2016 5:51 am
by vickyg2003
The Robman wrote:I think the way you are planning to do it is how John Fine would do it, and it would use less code. And I didn't write the S3C8 executor, UEI wrote it.
You are doing John Fine a disservice there! Inspect the code for ToadTog, and you will see what I mean!!! The man is a genius at
small!
When PB works with the on-off times, it does calculate slightly different Hex code for the time-off, so perhaps this isn't a precise enough way to do it, but the code decreases from 111 bytes to 96, a savings of 15 bytes. If people are using a gray-ok JP1.2 remote, that 15 bytes is significant!
I did find when doing this, that PB is buggy. At one point, it generated the wrong code for an instruction, that it would compile just fine on another place in the code. I never have seen that before! Perhaps that's part of the reason I had so much trouble with this protocol. But no that is unfair, it was my misunderstanding of the ROL instruction that was causing me most of my difficulties.
Code: Select all
Upgrade protocol 0 = 01 73 (HCS08) Epson PowerLite Pro G6270W (PB v4.02)
20 11 22 48 13 8D 45 04 08 02 2F 01 0D 94 5C 04
86 01 35 01 63 07 45 3E 5D 35 70 11 63 45 00 72
CD FF 65 3F 64 6E 06 65 AD 11 3C 64 05 64 F9 45
00 6E CD FF 65 CD FF 92 25 E3 81 BE 64 E6 60 B7
66 38 66 25 05 45 00 6E 20 03 45 00 6C 00 65 05
CD FF 68 20 03 CD FF 83 3C 65 07 65 E4 3F 65 81
End
Posted: Sat Mar 05, 2016 9:40 am
by The Robman
John is indeed the master of small code, that is what I was implying. I learned most of what I can do in S3C8 code from watching what he would do. If I get a chance, I intend to try writing a smaller version of the S3C8 code following that idea.
As I mentioned via PM, my JP1.x stuff isn't working anymore, so I can't test your execs, so does the new one work? Should I replace the old one with it?