DEBUG on 18F4620

[sinoteq]

Hi,
Does anyone know why Debug does not compile without warnings on 18F4620? I am using PBP 2.46 with MPLAB 7.10 I have located the problem to the P18F4620.INC in MPLAB To make the program compile without warnings I must edit the file to remove the DEBUG Label used in the INC file

For the moment this solves the problem but the question is why have they done like this?

Mike
This is what the edited part of the P18F4620 file looks like
;=============================================
;
; Register Definitions
;
;===============================================

;----- Register Files -----------------------------------------
PORTA EQU H'0F80'
LOTS OF MORE DEFINES
OSCCON EQU H'0FD3'
;DEBUG EQU H'0FD4'
T0CON EQU H'0FD5'

[SteveB]

If you do a seach for "DEBUG" in the pdf Datasheet for the 18F4620, you will see that the word is used as a reseverd word. It points to the configuration bit for the In-Cuircut Dubugger (Hardware). Not the same a PBP DEBUG, which is a simple serial command (PBP Software). Your solution should work neatly. Unless, of course, you decide in the future to use the ICD feature of the chip.

Steve

[SteveB]

Mike,

Why use DEBUG instead of HSER? HSER uses the PIC hardware serial port, not the "bit-banged" software serial of PBP. The HSER ends up being much more effiecent, both in code space and execution time.

Steve

[sinoteq]

You know how it is, things tend to grow bigger and I am using the Windows method of programming ( if the code gets too big or too slow change the hardware) For the moment the USART pins are assigned to other I/O functions, maybe in the future if I have to change the PCB layout I might swap the pins to enable HSER functions. DEBUG gives the smallest code for the moment given the hardware used.

I thought reserved words in PBP were reserved words and not words MPLAB also wanted to use. What will we loose next time?

Mike

[mister_e]

That's kinda interesting and i agree that some things could be changed to allow all feature, but usually it's a good practice to use internal PIC ressource instead than a software solution to, at least, save code space. For a such device (64K) i'm pretty sure there's a few thing that could be changed prior to say that DEBUG is the solution.

Sometimes i'm afraid what people do with PIC. Pretty sure than most of their own feature aren't used.
Why using PULSIN while you can use internal Counter?
Why using SERIN/DEBUGIN while you can use HSERIN?
Why using I2CREAD while your PIC have internal MSSP?
Why using PAUSE/US while your PIC have spare timer(s)?
Why using Sound while your PIC have spare CCP and allow your frequency range?
What is the real need of 20MHZ crystal while 4MHZ would be enough?
And so on...

Once done, you'll be amased how many project could be ported from a 8K device to a 4K (or less) memory device.

OK i heard some... sorry to say that.

[sinoteq]

Maybe we should talk to Microchip and ask them to make a PIC with NO internal hardware except A/D converter. Then they could spend all money on codespace

When selecting a PIC, functions, performance and price has to be matched. This DEBUG project became a bit big for a 16F877A and I only pay 2.5 USD more for the 18F4620 so why not?? As for using DEBUG in the new PIC, the idea was to reuse the old program without changing too much. Functions in PBP, as I see it, are here for the user to use, if you want small and fast write ASM.

The only change I had to do was some ADC settings and change in the MPLAB file, I am happy, my product is happy and the only thing to remember is to change the MPLAB file everytime I upgrade. This is also true for all the changes you have to do if you want the CONFIG settings to be included in you program but that is an other story. Maybe we really should talk to Microchip about some things.

mike