> This is a little bit annoying, but I have been changing the codes
> manually in the .hex file using piklab in order to overcome the
> problem. I decided to comment now because I am starting to suspect
> this could be related to other problems I am having with the .hex
> recorded into the device differing its behavior from the .cod tested
> in gpsim.
Had the same idea just now (see previous mail).
>
> The code:
> -=-=-=-=-=-
> #include <pic18fregs.h>
> typedef unsigned int word;
> Any idea why?
Well, this is bad... CONFIG 'words' are `unsigned char' (8 bit) rather
than `unsigned int' (16 bit). This explains part of the problems.
>
On my box I currently seem not to be able to set CONFIG bits correctly
from within SDCC: the gemerated .asm code looks not that bad (creating
absolute sections with initialized data at the config word locations),
but gpasm divides their addresses by two... So maybe using
unsigned char __at(__CONFIG2L<<1) conf2l = ...;
instead of
unsigned char __at(__CONFIG2L) conf2l = ...;
helps for now, but this needs more looking into and possibly a bug
report to the gputils team (if confirmed).
Regards,
Raphael
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
