Compiler differences between PBP 2.33 & 2.46

[nikopolis]

I have been using the PBP 2.33 compiler to program a 16f628A chip without any issues. I wanted to try something with a 16f88 and so I downloaded the pbp demo version of PBP (which I believe is version 2.46 but the program doesn't seem to list its version)... the same program that works fine compiled, programmed and ran fine with 2.33 compiles, programs but doesn't run with 2.46 demo version.

I finally had time today to reinstall the pbp demo and take everything back to basics for a simple example of my problem using the blinky LED.

I used the blink.bas sample provided in the demo version without altering the code:




' Example program from manual to blink an LED connected to PORTB.0 about once a second

LED1 VAR PORTB.0 ' Alias PORTD.0 to LED

loop: High LED1 ' Turn on LED connected to PORTB.0
Pause 500 ' Delay for .5 seconds

Low LED1 ' Turn off LED connected to PORTB.0
Pause 500 ' Delay for .5 seconds

GoTo loop ' Go back to loop and blink LED forever
End

I compiled it using pbp 2.33 using the command

pbp -p16f628 BLINK.BAS

I then programmed the pic using the PicKit 2 programmer and I had a blinky LED. Everything is good.

I then compiled the same blink.bas using the demo version which I believe is 2.46. It compiled, I programmed the PIC and nothing appears to happen (no blinky LED).

I compiled using the command:

pbpdemo -p16f628a BLINK.BAS

and also tried:

pbpdemo -p16f628 BLINK.BAS

but both seem to generate code that doesn't seem to run (no blinky LED).

I compared the .HEX files and saw there is a slight difference in the next to the last line:
From 2.33 the .HEX file that works is:



:100000002828A301A200FF30A207031CA307031C9A
:1000100023280330A100DF300F200328A101E83E90
:10002000A000A109FC30031C1828A00703181528FC
:10003000A0076400A10F152820181E28A01C222844
:1000400000002228080083130313831264000800B1
:1000500006148316061083120130A300F430022028
:1000600006108316061083120130A300F43002201C
:0600700028286300392876
:02400E00543F1D
:00000001FF

From the demo (2.46) version, the .HEX file that doesn't appear to work is:



:100000002828A301A200FF30A207031CA307031C9A
:1000100023280330A100DF300F200328A101E83E90
:10002000A000A109FC30031C1828A00703181528FC
:10003000A0076400A10F152820181E28A01C222844
:1000400000002228080083130313831264000800B1
:1000500006148316061083120130A300F430022028
:1000600006108316061083120130A300F43002201C
:0600700028286300392876
:02400E006D3F04
:00000001FF


A diff of the two shows that the last 3 bytes of the second to last line are different (543F1D vs 6D3F04).

Can anyone point me in the right direction on what might be the reason for the difference. Perhaps I am not installed correctly (uninstalled and reinstalled) or there is an option I need to set in 2.46.

Thanks in advance

Other particulars: I'm using Windows XP Pro and the PicKit 2 programmer. The pic is programmed on my own proto-board using the ICSP lines from the PicKit 2; this setup has been working fine for lots of different programs but with pbp 2.33

[Bruce]

The difference is config word settings.

The first hex file created with PBP 2.33 has internal osc, mclr off.

The one created with the demo version has XT, mclr on.

When you install the demo it includes different "default" config fuse settings
in device header files installed in the PBP demo directory.

Change the demo version default config settings by editing the device header
file, or simply change config word settings with your programmer before
programming the target.

[nikopolis]

A little digging and a little learning and I see how it works...

adding the line

@ device pic16F628A, intrc_osc, wdt_on, mclr_off, lvp_off, protect_off , pwrt_on, bod_on

to my source file fixed the problem.

Thanks so much.

I don't want to mess up the included .INC files but if I wanted to avoid having to add the above line to all my source, I assume the I could create my own .inc file and reference that in the pbp command line such as:
pbp -fMY16f628a blink.bas

Is that the common way to get defaults set for a particular setup?

[Bruce]

I normally just use the @ DEVICE directive as you have done. I wasn't sure if that would cost you a line of code with the demo version or not, but @ DEVICE is the best approach for me.

I much prefer to "see" config options in my code rather than change them with my device programmer, or edit header files.

If I do edit defaults in my header file, I'll most often comment out the default settings, include my own, and just keep/use the original file.

I'm not sure pbp -fMY16f628a blink.bas would be a valid command line option since f isn't shown in the command line options list.

It's probably easier to just use the @ DEVICE directive. At least when you're using the default PM assembler.