Då original programmet är skrivet för PIC16F628 men kan även köras på PIC16F628A och eftersom PIC16F648A ligger med i samma PDF dokument som PIC16F628A.
Har kollat igenom stycket "INSTRUCTION SET" för PIC16F628A och PIC16F648A och inte hittat några undantag.
Då borde original programmet även gå att köra fint även på 16F648A och ha mer minne tillgängligt.
Är mitt antagande rätt?
Notera dock att 628/628A har allt programminne i en 2 Kword "page"
medan 648A sitt 4K minne uppdelat på 2 "pages". D.v.s att CALL,
GOTO o.s.v som sker mellan dessa två pages måste inkludera
justering av PCLATH innan, annars går det hela fel.
Antingen gör en en generell (t.ex ett macro) för att alltid hantera
PCLATH vid alla CALL/GOTO, eller så ser man över koden och
strukturerar det mellan minnessidorna och justerar PCLATH då
det behövs. Notera att MPLINK alltid lägger en "section" på samma
sida, så alla CALL/GOTO inom samma "section" kommer alltid att
ske på rätt sätt. Sen kan man lägga till hantering av PCLATH för
anrop mellan olika sections. RETURN är aldrig något problem eftersom
stacken håller den fulla returadressen, däremot får man se upp så
att man återställer PCLATH om RETURN sker till en annan page,
annars kommer det första CALL/GOTO efter RETURN att gå fel...
Absolut! Om koden är skriven för 628:an och inte utnyttjar några av dom utökade minnesareorna i 648:an, så går koden som vanligt även på 648:an. När du sedan vill utnyttja dom utökade mineesareorna, så är det bara att lägga nya funktioner där. Det viktiga är bara att hålla rätt på minnesbankerna vid anropen till funktionerna i den nya banken. Och kanske då ta ett helhetstag i det där med banker, precis som Sodjan säger.