JP1 Remotes

[wwwoholic]

Just a bunch of small questions.
I saw some kind of "device address" tables. Am I right to assume that device/protocol upgrades do not have to immediately follow each other and can be spread around memory with possible holes in between? (unlike macro/keymoves)
Is the same organization supported by extenders or they do something different?
It seems that immediately after upload these addresses are stored at standard locations in the header, and extender's code sits as a device upgrade. After extender got invoked for the first time it modifies those offsets but leaves them at the same place. Is this so?
If yes, then is there exact offset in the extender code where the _future_ addresses for keymove zone, device table etc. are located? If so, are they different in different extenders?
Is there some addresses (except for header's) that are hardcoded in mcu and thus can not be moved?
Are the answers for above questions the same for all remotes known so far?
Sorry for a long list and appreciate your input.

[johnsfine]

I can only speak for the S3C80 models and Mark has told me that my ideas based on those models are not valid for some of the other models. However, I think an improvement that is enabled only for S3C80 models would be better than waiting to find a more general solution that we'll probably never have time for.

The MCU hard codes the start and end of the KeyMove/Macro area and strictly requires all KeyMoves/Macros to lie contiguously between those.

The MCU hard codes the start and end of the Learned signals area and strictly requires all learned signals to lie contiguously between those.

The MCU hard codes the location of the root object of the upgrade area but does not in any way constrain the location, sequence or contiguity of any other objects in the upgrade area.

Some extenders (with significant difficulty) override the MCU rules for KeyMoves/Macros to use a different contiguous range. It is not a simple override, so having more overrides is probably not practical within a 2K eeprom (would take enough code that it would destroy any possible benefits of more flexible use of what eeprom space remains).

Most upgrade objects have lengths that cannot be determined simply by reading the object. The remote has no need to know the length of any upgrade object, so this length problem imposes no additional constraint on object locations from the viewpoint of the remote.

But we need IR to be able to read and understand eeprom images as well as write them. So IR must be able to deduce the length of upgrade objects.

Currently IR writes upgrade objects contiguously in a strict sequence. So that the length of all but the physically last object can be computed by knowing which object is physically next and using its start address to compute the length of the current object. A specific object whose length IS readable was chosen to always go last.

My proposal is to invent a totally new way to arrange the objects such that their lengths can be deduced. With an extender we can create the maximum practical KeyMove/Macro area (not need any flexibility to move the boundary). With or without an extender we could use any unused parts of all other sections for upgrades.

1) Fill the used part of all other sections first before starting to compute upgrade object locations.
2) The address of the root object of the upgrade area is fixed.
3) Compute the size and location of each "area" available for other upgrade, including the rest of the original upgrade area (after the root) and including the free remainder of each other section (with current RDF rules, the only sections that could have free remainders are Keymove and Learned signals).
4) Assign the set of upgrades to the pool of areas by some fitting algorythm. A crude first fit method would be trivial and would be a giant step forward from current status, but some better fit algorythm might be justified. Note this step just assigns an area number to each upgrade object, not an exact address.
5) Within each area consume space from the end first, working backward toward the beginning.
5a) Init an L pointer for each area as one byte beyond the end of the area.
5b) Assign objects in logical sequence, but each to the area decided for it in step 4.
5c) As each object is assigned set its start address to the area's L pointer minus the object's length, then set the L pointer to that start address.

When you read back objects (in logical sequence) you have the address of each object and must deduce its length.
6a) Init an L pointer for each area as one byte beyond the end of the area.
6b) From the address of an object you can easily look up what area it is in.
6c) The length of the object is the L pointer of that area minus the start of the object.
6d) Update that L pointer to equal that start address.

We would also need a simple check to cover the case that the upgrade area is laid out the old way. That would best be done by a look ahead from the second logical object to the third (but it could be safely done on any other objects as well). If the third object lies between the second object and the value of the L pointer (at the time the second object is read) then the old layout is being used.

[wwwoholic]

Eh.. hmmm... I was asking some simple questions and you put the weight of an intellect on my shoulders

Ok, what I'm attempting to write is a framework for eeprom image access and management. The basic concept is that any such image can be split into a set of non-intersecting binary chunks of sertain types (e.g. header, macro, device etc.) If it is possible to formalize the placement rules for these types (e.g. type "macro" must follow other macro, keymove or beginning of macro area) then it should be possible to write a platform-independent memory optimizer. (under "platform" I mean mcu and/or the make of the remote)

Then, the framework would consist of:
- generic memory map components;
- image loader; parses the image and creates a memory map, something like simplified DOM model.
- manager; moves objects around, optimizes memory distribution, allows adding/removing objects. Applications, such as RM, would be able to simply say "add this object" and manager will do the rest.
- optional viewer/editor; this can be made pluggable into any application as additional pane in the UI.

As you can see, only image loader is platform-dependent piece in this picture. If fact, it is the only part related to the remotes, everything else can be used for other equipment e.g. cell phones (is there such thing as JP1 phone? ) Right now I'm considering two possibilities: generic loader that uses RDF file vs. loading drivers. Basically, my questions above were all related to this choice. Unfortunately, I haven't found any complete documents on the memory organization (suppose, there isn't any). So, I have to deduce it form the pieces of source code available at yahoo.

As for your proposal on the memory distribution the fun part is that it produces almost the same result as my "type placement rules", being much simplier to implement at the same time. It's just that I'm afraid it might not be able to cope with all future models of remotes.

Thanks a lot!

[johnsfine]

[wwwoholic]

[johnsfine]

[wwwoholic]