Page 1 of 1

Protocol to send 3 commads (like a macro).

Posted: Tue Apr 27, 2010 6:19 am
by javier
I want a NEC1 protocol that send a fixed command before the command of the button pressed, and another one fixed command after that.
Total 3 commands: Fixed prev-command, normal button command, and fixed post-command. Is like a macro, but since all button commands require this fixed command before it, and after it, I prefer do not use macro for each button (memory capacity problems).
Is there any executor to do that?
I think that an example it would be enough, since I know how assembler works, more or less.
Thank you very much.

Re: Protocol to send 3 commads (like a macro).

Posted: Tue Apr 27, 2010 6:45 am
by vickyg2003
javier wrote:I want a NEC1 protocol that send a fixed command before the command of the button pressed, and another one fixed command after that.
Total 3 commands: Fixed prev-command, normal button command, and fixed post-command. Is like a macro, but since all button commands require this fixed command before it, and after it, I prefer do not use macro for each button (memory capacity problems).
Is there any executor to do that?

Not that I know of, but I was working on something like that for the Apple guy, who wanted 3 command sequences to do XMBC signals last December. I believe I posted the PB files along with the upgrades in the diagnosis area.

Since it appears that you want to learn how to fish, I'd start by looking at PB and figuring out how to work that. Its a bit of a challenge, as there are a bunch of buttons that I can't figure out what they are used for, so the only buttons I use are the decode and assemble buttons.

Then you want to look at some of the PB files that are posted there, just to get a handle on how some things are done.

The NEC1 protocol is pretty big so you are going to want to strip out all the stuff in there that you don't need before you start doing the multiple signals work.

Do you need any repeat frames in this signal? Or is just the first single frame required?

What processor are you targeting?

Re: Protocol to send 3 commads (like a macro).

Posted: Tue Apr 27, 2010 6:57 am
by javier
vickyg2003 wrote:
javier wrote:I want a NEC1 protocol that send a fixed command before the command of the button pressed, and another one fixed command after that.
Total 3 commands: Fixed prev-command, normal button command, and fixed post-command. Is like a macro, but since all button commands require this fixed command before it, and after it, I prefer do not use macro for each button (memory capacity problems).
Is there any executor to do that?

Not that I know of, but I was working on something like that for the Apple guy, who wanted 3 command sequences to do XMBC signals last December. I believe I posted the PB files along with the upgrades in the diagnosis area.

Since it appears that you want to learn how to fish, I'd start by looking at PB and figuring out how to work that. Its a bit of a challenge, as there are a bunch of buttons that I can't figure out what they are used for, so the only buttons I use are the decode and assemble buttons.

Then you want to look at some of the PB files that are posted there, just to get a handle on how some things are done.

The NEC1 protocol is pretty big so you are going to want to strip out all the stuff in there that you don't need before you start doing the multiple signals work.

Do you need any repeat frames in this signal? Or is just the first single frame required?

What processor are you targeting?
I need only de NEC1 simple executor. Only one device. Only one frame, but three times with different commads.
Processor S3C8+
I saw in the assembler the JMP 0146 (transmit). What I need is jump to this address three times, changing the byte of the command to transmit.
Actually, since data protocol are going to be changed between transmits, I need jump to 0149 instead 0146, which calls preprocess protocol data as well.
Can I "call" three times this address instead of "jump"? (changing the commad byte between calls, of course)

Posted: Tue Apr 27, 2010 7:23 am
by vickyg2003
initialize data
Call transmit
change data
Call transmit
change data
JMP transmit

Posted: Tue Apr 27, 2010 7:45 am
by The Robman
Will all three "buttons" use the same fixed data?
Do you want the normal "button" held while the button is pressed?
Do you have a list of all the codes that would be in the upgrade?

Posted: Tue Apr 27, 2010 4:24 pm
by unclemiltie
vickyg2003 wrote:initialize data
Call transmit
change data
Call transmit
change data
JMP transmit
What Vicky says here is right. The first two "calls" to transmit have to be CALLs since they will then return to the protocol. The last one has to be a JMP since the way the remote works is that the protocol is CALLed from the button processing and expects that the protocol will return when done.

(or you could do three calls and a RET but why waste the extra byte)

Posted: Wed Apr 28, 2010 3:37 am
by javier
Thank you everybody.
I think that I get it.
What I want with this, is sending commands to a HDMI-MATRIX which is NEC1 device 0, but without changing anything in the TV, which unfortunately is NEC1 device 0 as well.
To do that, I am going to use NEC1 device 0 command 85H before and after the real command of the button of the HDMI-Matrix. Command 85H has no function in the HDMI-Matrix, but it puts the TV in a special Source Mode, so only accepts arrows keys and 85H again to exit.
So, each code to the matrix sends a 085h first, so the TV goes to a special Source Mode to ignore the next command, then the code to the HDMI-matrix can be transmitted since does not match none of the codes accepted in the TV at this time, and finally, the 85H again to the TV to exit the special Source mode.
I know it: I could use macros, but due to a memory restrictions this protocol is better.

As soon as I arrive at home I will test it and put the results.
If necessary, I could put loops between IR transmits to make a little pause between the three commands.

Now what I did:
REMOTE S3C8+
DB 41H,8DH ;38.1 kHz 31%
DB 21H ;2 dev, 1 cmd
JR start
DB E5H ;pf0: 11100101=1-dev,1-cmd,dev-!dev-cmd-!cmd,OffAsTotal
DB 46H ;pf1: 01000111= Not-RptHeld,LI-same,1on-LO
DB 08H ;pd00: DevBits1=8
DB 08H ;pd01: CmdBits1=8
DW 0118H ;pd02/03: 1-burst on=560 uS
DW 0106H ;pd04/05: 1-burst off=564 uS
DW 0118H ;pd06/07: 0-burst on=560 uS
DW 0339H ;pd08/09: 0-burst off=1690 uS
DW D2DCH ;pd0A/0B: Leadout off=107960 uS
DW 1194H ;pd0C/0D: Leadin on=9000 uS
DW 08B6H ;pd0E/0F: Leadin off=4500 uS

push r06 ;save the command to use later

ld r06,#85H ;prepare and send a Hex 85 command
call 0149H ;which is used to put the TV in a Source Menu

pop r06 ;load the command saved at begining
call 0149H ;transmit the command

ld r06,#85H ;prepare and send a Hex 85 command again
jp 0149H ;which is used to put back the TV in normal mode

Posted: Fri Apr 30, 2010 12:30 am
by javier
It worked.
I had to modify the protocol a bit, but finally it worked.
This is the assembler that I used:
REMOTE S3C8+
DB 41H,8DH ;38.1 kHz 31%
DB 31H
JR start
DB E5H ;pf0: 11001111=devs,cmds,dev-cmd,OffAsTotal
DB 46H ;pf1: 01000111= Not-RptHeld,LI-same,1on-LO
DB 08H ;pd00: DevBits1=8
DB 08H ;pd01: CmdBits1=8
DW 0118H ;pd02/03: 1-burst on=560 uS
DW 0106H ;pd04/05: 1-burst off=564 uS
DW 0118H ;pd06/07: 0-burst on=560 uS
DW 0339H ;pd08/09: 0-burst off=1690 uS
DW D2DCH ;pd0A/0B: Leadout off=107960 uS
DW 1194H ;pd0C/0D: Leadin on=9000 uS
DW 08B6H ;pd0E/0F: Leadin off=4500 uS

start: inc R01 ; skip first byte

push r06 ;save the command to use later

ld r06,#85H ;prepare and send a Hex 85 command
call 0149H ;which is used to put the TV in a Source Menu

pop r06 ;load the command saved at begining
call 0149H ;transmit the command

ld r06,#85H ;prepare and send a Hex 85 command again
jp 0149H ;which is used to put back the TV in normal mode

Thank you everybody.

Posted: Fri Apr 30, 2010 4:16 am
by vickyg2003
Congratulations on solving such a complicated problem. That makes a lot of sense to me. You are really LUCKY that the push/pop instructions worked. Quite often what I push on is not what I pop back outl.

Posted: Fri Apr 30, 2010 6:26 am
by The Robman
You could avoid the POP and PUSH by loading the variable byte to scratch register W6 (as that survives the call to the engine).

If you want the HDMI button to be repeatable, you could turn on the repeat before the 2nd engine call like this "OR R29, #01h" then after the call you can turn it off again (which is needed for the last engine call) like this "OR R29, #FEh" (ie, you're just flipping the rightmost bit).

Posted: Fri Apr 30, 2010 6:34 am
by vickyg2003
You could avoid the POP and PUSH by loading the variable byte to scratch register W6 (as that survives the call to the engine).
In the hcs08 I like to use part of the DCBuf area for my variables, because I've had issues with the push/pop not being paired correctly. [/quote]

Posted: Fri Apr 30, 2010 6:35 am
by javier
I will try this improvements.
But, why to use W6? can I save memory? What is W6 and where must be defined?
Thank you for the idea of making the hdmi button repeatable. Just one comment: I think the last instruction must be AND R29,#FE instead of OR.

Posted: Fri Apr 30, 2010 11:36 am
by The Robman
Yeah, it should be AND.

W6 is a scratch register (aka RC6). The S3C8 code has a bunch of these, the main advantage of using them is that they often generate less hex code, and some functions (like DJNZ, etc) require them. You don't need to define them anywhere, they come with the chip.

Many UEI routines (accessed via vector calls) use them as input, and they use a lot of them in their various routines, so generally speaking, it's not safe to store something in them and expect the data to still be there when you return from a routine. W6 is the only scratch register that I know of that survives a call to the IR engine. We originally discovered this when we saw UEI using it in the old $007E (Pioneer DVD) executor.

Why would you use it instead of POP/PUSH? No reason, I'm just throwing it out there as an alternative. There may be a time in the future where POP and PUSH get thrown out of sync by a called routine, in which case using W6 might make more sense. Both functions use 2 bytes, so there's no difference from a memory usage POV.