Si l'on génère un .asm à partir des données de calibration (instruction DATA) ,et que l'on génère le .hex associé, on remarque qu'il y a ces 2 lignes au début du fichier :
:020000040000FA
:0200000400F00A
Voici la méthode pour générer ce .hex :
gpasm -c -p 18f1320 kconv.asm -o kconv.o
gplink --map -c -S2 -s /usr/local/share/gputils/lkr/18f1320_g.lkr -o kconv.hex kconv.o
emacs kconv.hex &
Or, il s'avère que GPSIM n'accepte pas ces 2 lignes. En effet, GPSIM prend par défaut l'adresse de l'EEPROM de départ à 0x0000 (voir §2.11 de http://gpsim.sourceforge.net/gpsim.pdf)
Si bien que les 2 lignes (générées par gpasm et gplink) ne sont effectivement pas nécessaires pour GPSIM.
Qu'en sera t'il sur la cible réelle ?
Il faut implémenter un flag de debug, permettant de facilement générer les 2 types de fichiers dans calibrator.
Si l'on génère un .asm à partir des données de calibration (instruction DATA) ,et que l'on génère le .hex associé, on remarque qu'il y a ces 2 lignes au début du fichier : :020000040000FA :0200000400F00A
Voici la méthode pour générer ce .hex : gpasm -c -p 18f1320 kconv.asm -o kconv.o gplink --map -c -S2 -s /usr/local/share/gputils/lkr/18f1320_g.lkr -o kconv.hex kconv.o emacs kconv.hex &
Or, il s'avère que GPSIM n'accepte pas ces 2 lignes. En effet, GPSIM prend par défaut l'adresse de l'EEPROM de départ à 0x0000 (voir §2.11 de http://gpsim.sourceforge.net/gpsim.pdf) Si bien que les 2 lignes (générées par gpasm et gplink) ne sont effectivement pas nécessaires pour GPSIM.
Qu'en sera t'il sur la cible réelle ?
Il faut implémenter un flag de debug, permettant de facilement générer les 2 types de fichiers dans calibrator.