2116 extenders - any way to speed up?

alank2 · Post by **alank2** » Thu Oct 21, 2004 8:15 pm

Hi,

I've been trying out the extenders (1-3) on the 15-2116 as well as the unextended remote. What I've noticed is that the non extended remote can process keys as fast as you can press them, but the extended one is much slower. If I hit 123 on the keypad I will often get 13 because 2 wasn't registered.

After looking at the ASM code I can see that the extenders are done in 2 parts. Am I right in thinking that part 1 loads 255 bytes of part 2, executes it, then loads 255 bytes of part 1 again. Could this be the slow down? Is there a way to implement it without doing it in two parts like this? Is the code being executed in eeprom or in some local ram?

Thanks,

Alan

Nils_Ekberg · Post by **Nils_Ekberg** » Fri Oct 22, 2004 6:45 am

There is no way with the size of the extender and the way ROM gets refreshed to change the load and reload of each section. However, this is not whats making it slow. Truthfully, I have not had a chance to look at it yet but it is not slow in my 2116 so I have to dig deeper to figure out why it is slow in yours.

Maybe you can start by posting a copy of your current IR file so I can try it in mine and see if it reacts the same. Either post it in the jp1 file section and put a link to it here or just e-mail it to me.

alank2 · Post by **alank2** » Fri Oct 22, 2004 6:50 am

Nils_Ekberg wrote:There is no way with the size of the extender and the way ROM gets refreshed to change the load and reload of each section. However, this is not whats making it slow. Truthfully, I have not had a chance to look at it yet but it is not slow in my 2116 so I have to dig deeper to figure out why it is slow in yours.

Maybe you can start by posting a copy of your current IR file so I can try it in mine and see if it reacts the same. Either post it in the jp1 file section and put a link to it here or just e-mail it to me.

Hi Nils,

Thanks for the help--I really appreciate it!!! I'll send you a copy of my IR file to try!

Thanks,

Alan

Nils_Ekberg · Post by **Nils_Ekberg** » Fri Oct 22, 2004 6:09 pm

Well, I loaded it 3 times after various resets etc. and could not get it to run slow and or loose button presses but it did run a little slower than my regular version 2 configuration. My guess is that the large number of keymoves is slowing it down some since it has to search them on every keypress. I did then delete a bunch of keymoves and it did seem to speed up but since I was not loosing anything before then it really did not make much difference.

I need to experiment with this some more so at this time the only thing I can recommend is to try to do a fresh creation of the upgrade using the extender .txt file from the extender zip file and add your upgrades one at a time and see how it progresses. In other words just open the extender.txt file in IR instead of using Extinstall. Oh yeah, I would do that with version 2 unless you really need the backlight control which is the only thing that I think was added in version 3.

alank2 · Post by **alank2** » Sat Oct 23, 2004 6:15 pm

Nils_Ekberg wrote:Well, I loaded it 3 times after various resets etc. and could not get it to run slow and or loose button presses but it did run a little slower than my regular version 2 configuration. My guess is that the large number of keymoves is slowing it down some since it has to search them on every keypress.

Hi Nils,

Thanks for trying it for me. I'm going to try and cut down my number of keymoves - some were added just to fully support the oem remote, but for feature I don't really use. I'll try it on extender2 starting with a new config and then add stuff to it using ir manually.

Nils_Ekberg wrote:I need to experiment with this some more so at this time the only thing I can recommend is to try to do a fresh creation of the upgrade using the extender .txt file from the extender zip file and add your upgrades one at a time and see how it progresses. In other words just open the extender.txt file in IR instead of using Extinstall. Oh yeah, I would do that with version 2 unless you really need the backlight control which is the only thing that I think was added in version 3.

Great, let me know if you come up with anything, I really appreciate your help.

Thanks again,

Alan

Mark Pierson · Post by **Mark Pierson** » Sat Oct 23, 2004 6:35 pm

Just a thought... and I'm not even sure if this would have any impact on performance, but have you tried changing the batteries? I have an extended 15-2104 that becomes sluggish as the batteries get low (if the backlight doesn't drain 'em first

).

vasqued2 · Post by **vasqued2** » Sat Oct 23, 2004 8:41 pm

If there are a lot of keymoves and macros, that's my guess as to playing a part.

Although I never noticed it until I looked for it, when I compared the response of my extended remote w/ ~80 keymoves and macros w/ a non-extended remote w/ no keymoves, the extended remote had a slower - but still very acceptable to me - response time.

Not sure a non-extended remote would perform better if I programmed 80 keymoves, but I wasn't curious enough to try it. Since both the extended and non-extended remotes use a linear search for the keymoves, I'd expect they would behave pretty close to the same. The difference being that a non-extended remote doesn't have enough space to hold 80 keymoves w/o jumping through all sorts of hoops to make it work.

I could see that the jump between part 1 & 2 could cause some delay but if Nils isn't seeing a difference that makes me lean towards the keymoves too.

David

Nils_Ekberg · Post by **Nils_Ekberg** » Sun Oct 24, 2004 10:14 am

I can't find anything in the code that would cause the slowdown and or key lose so that just leaves the amount of macros and keymoves. That still does not explain anything about why I am not loosing keypresses on mine with your IR file other than possibly the battery age since I did just put new batteries in mine this week.

I did one additional test and removed the backlight protocol, light macro and keymove since that is the only difference between versions 2 and 3 and it did speed up a little but I am not sure why. Not necessarily important because you said versions 2 and 3 did the same thing on yours.

If you need to keep the bulk of the keymoves I would just move the ones you use the most to the top of the que but that won't change the speed of the built in codes since it always searches for keymoves etc.

alank2 · Post by **alank2** » Mon Oct 25, 2004 6:29 am

Hi guys,

Can you help me understand how the extender works and how the remote's memory map is mapped? The asm file when compiled puts the eemain and ee_part2 at 0x0752 and 0x03a. Does the part 1 and part 2 get copied to 0xff00 and execute there? Why doesn't it execute in eeprom? Is the eeprom mapped to 0x0000 - 0x07ff ?

Thanks,

Alan

johnsfine · Post by **johnsfine** » Mon Oct 25, 2004 6:32 am

The eeprom isn't mapped into the address space at all and it is impossible to execute code in the eeprom.

The remote can read an write the eeprom by a slow serial protocol, but can't directly address it.

The only way to use eeprom contents is to first copy them to either ram or registers.

alank2 · Post by **alank2** » Mon Oct 25, 2004 6:37 am

johnsfine wrote:The eeprom isn't mapped into the address space at all and it is impossible to execute code in the eeprom.

The remote can read an write the eeprom by a slow serial protocol, but can't directly address it.

The only way to use eeprom contents is to first copy them to either ram or registers.

That makes sense. Is the memory at 0xff00 all that is available? I found the part number of S3P80F9XHU-COC9 on the 2117 schem, but I don't see it mentioned in the S3C8-data-sheet.pdf I downloaded.

Here is my goal: I eliminate the part1/part2 method of the extender by making a smaller foot print extender. I don't need some features and am willing to cut them to get very fast keypress capability.

Can you tell me what ram is available, even if it is not contiguous?

Thanks,

Alan

johnsfine · Post by **johnsfine** » Mon Oct 25, 2004 6:57 am

There is only 256 bytes of ram 0xff00 through 0xffff.

Every protocol load is 255 bytes long starting at 0xff00, whether it needs that much or not. (The last byte of ram is unused. There is no practical way to use it).

An extender loads into the same 255 bytes as every protocol, so it must leave a fake stack frame to cause the remote to reload it after each protocol.

On a human time scale, multiple loads of 255 bytes from eeprom to ram add up to very little. I haven't done all the computations necessary to know exactly how long it takes.

The first few extenders I wrote were limited to 255 bytes so they could load in one part. That design is much simpler, but it's very hard to fit even the basics of an extender in that space.

The key feature you may have to give up to make an extender smaller and faster is the relocation of the KeyMove/Macro area. Without that feature, it would be pretty easy to fit an extender in one part. Also that feature itself runs slowly. Once you have a large number of KeyMoves and Macros, any keys that aren't near the beginning of the KeyMove list run noticably slower (whether they are near the end of the KeyMove list, or built into setup codes). An unrelocated KeyMove list can be searched a little faster and is so limited in size you can't fit enough KeyMoves to measurably slow things down.

Most of us barely notice the inherent slow down of an extender. It is so tiny compared to the macro processing speedup that you need a careful approach to measuring and a good understanding of the issues to detect it at all.

I'm still not convinced that slowdown is the cause of the symptoms you are seeing.

alank2 · Post by **alank2** » Mon Oct 25, 2004 7:11 am

johnsfine wrote:On a human time scale, multiple loads of 255 bytes from eeprom to ram add up to very little. I haven't done all the computations necessary to know exactly how long it takes.

Too bad, I was hoping this might be the reason for the slowness since a previous poster mentioned is eeprom comm was done rather slowly... So, is this any protocol? Even the built in ones in rom? Or just the custom ones stored in eeprom?

johnsfine wrote:The first few extenders I wrote were limited to 255 bytes so they could load in one part. That design is much simpler, but it's very hard to fit even the basics of an extender in that space.

I see.

johnsfine wrote:I'm still not convinced that slowdown is the cause of the symptoms you are seeing.

Maybe I need to do more testing to try and find out where the slowdown occurs. It could be that the extended needing to load ee_main, ee_part2, and then a custom protocol for my receiver is just too many read255's to get back quick enough for my next keystroke, I'm not sure. Someone also mentioned batteries, but these were fresh a couple weeks ago...

I'm having a good time playing around with the remote and code however, thanks for the work on the extenders, it gives me a great place to start and tinker. If I could get the speed up on it, it would be perfect!

Thanks,

Alan

johnsfine · Post by **johnsfine** » Mon Oct 25, 2004 7:28 am

alank2 wrote:So, is this any protocol? Even the built in ones in rom? Or just the custom ones stored in eeprom?

Rom protocols execute directly in rom. They are not copied to ram.

The extender doesn't know whether a protocol comes from rom or eeprom, so it must create a stack frame to reload itself after any protocol, even rom protocols where the extender would still be there without reload.

alank2 · Post by **alank2** » Mon Oct 25, 2004 7:31 am

johnsfine wrote:Rom protocols execute directly in rom. They are not copied to ram. The extender doesn't know whether a protocol comes from rom or eeprom, so it must create a stack frame to reload itself after any protocol, even rom protocols where the extender would still be there without reload.

That might explain why some devices seem faster than others, and gives me something else to try when troubleshooting the speed issue I'm having.

You guys are great on quick technical responses! I am impressed!

Alan