Thank you for the quick replies!
towlerg:
Yes, the code compiles fine. A bit of backstory: I was given code to fix, and it came in two files- one was a text file with PBP code, and the other was a PBP file that was mostly macro functions written in assembly. The code was previously compiled with PBP 2.60A, and I was given the version of MPASM that it was originally compiled with.
When I compile the code with PBP 2.60A and the same MPASM version now in MicroCode Studio, the hex file that is produced just writes white squares to the LCD of the hardware I'm working with, even though *nothing* has changed in the code.
I should have clarified what I meant when I asked about variables: I was wondering if PBP 2.60A relies on certain environment variables in windows, or if compiling it on a windows XP machine would yield different results than compiling it on a windows 8 machine. I would hope not, but I am running out of other possibilities. Browsing other threads, I have heard of people resorting to reinstalling their OS's to get things working, especially after mistakenly installing an incorrect version of software.
I'll need to compare the hex files next... and I'll also look for the fuses. I haven't seen any in the code so far, but I'll need to look through it again with that in mind.
Scampy: I'm glad you mentioned that - a timing issue and the currently-unknown states of the fuses leaves the possibility that my code configures the oscillator one way, but the programmer (meLabs programmer beta) might be overwriting the oscillator config.
Is there any way to read the config/fuse settings from the hex file/from a programmer connected to a functional piece of hardware?
Bookmarks