Tamas Rudnai wrote:
> My doubt about this is that the other chip may have a different clock
> freq so that all time related stuff would fail.

That's only one of many problems.  I think it would be impossible to
properly track indirect addressing references.  Since often run time math is
used to calculate the target address, you don't know what is ultimately
being addressed.  This means you have to keep all RAM at exactly the same
addresses on the new machine, but of course that is either impossible or
leads to other problems.

I'm having a hard time thinking of purpose for this tool, even if it could
convert the code reliably.  Why would you want to convert PIC 16 code to run
on a PIC 18 at the *binary* level?  With properly written source code it's
not that hard but still takes some human intervention.  But even if this
tool worked mostly, how do you then fix the remaining bugs without source
code?  Normally I would say this is an answer to a question nobody asked,
but in this case it doesn't even seem to be an answer.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist