Oh sorry, v2.46a
|
Oh sorry, v2.46a
|
This is what I see for PBP 2.47 that might relate to your problem...Originally Posted by nverma
--Adds minor optimizations for PIC18Xxxxx.
--Changes internal bit names to avoid possible conflicts.
--Fixes possible memory allocation of word-sized variable at odd address on page boundary for PIC18Xxxxx.
Will any of these have an effect? Who knows...
Have you thought about swapping out the '8720 for an '8722?
|
Well I would replace the 8720 with the 8722 if I had a choice, however I am working on an existing design which uses a 8720, so I am forced to use 8720 and PORTD. I would have changed the port as well, but I no choice.
|
The '8722 is pin compatible and software compatible with the '8720 and it's only got a couple of different registers to worry about. I would think it would be an easy replacement. And removing an TQFP isn't all that hard, if you do it one pin at a time (at least that's what they teach in the class I just got back from).
|
Well I guess if I can't get it working soon, I'll most probably do that. Thanks, please let me know if anyone else knows what im doing wrong.
|
For grins, try changing your variable names and accessing registers like the MEMCON, PSPCON, etc. with the peek/poke to their actual locations vs. using their actual names...
Ya never know...
|
We could still compile a HEX file with PBP 2.47 to see what happen?
Unfortunately i don't have those on hand... out of stock and there's no plan around them soon. Even if it was the case....
http://www.microchip.com/stellent/id...ct1=PIC18F8720
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Members who have read this thread : 0You do not have permission to view the list of names.
Posting Permissions
Bookmarks