Getting Configs straight

[Dave]

vacpress, I do all of my flashing of processors with MPLAB. There is an extensive configuration menu available for all of there different processors. I never set the configuration registers from within the source code. That is one thing that confuses many people. I mearly set the configuration just before I flash the device. I suppose that is one of the perks of using MPLAB for programming as well as compiling. I hear of so many people having problems with there 2nd and 3rd party budget flash programmers it makes me laugh. If they only sent a little money on something to flash processors with that will grow with the product line and they will have for a very long time. I have an PICKIT2 and an ICD2 that I use for debugging and have never looked back yet. As far as the configuration bits go you can import your hex file into MPLAB set the configuration bits to your liking and the export it with all configuration bits set ready for flashing with your 2nd or 3rd party programmer.

Dave Purola,
N8NTA

[Bruce]

See this post http://www.picbasic.co.uk/forum/showthread.php?t=543

Melanie did a good job explaining this, but If you still have questions let us
know.

[vacpress]

bruce,

no kidding, melanie did do a good job is spelling it out! however, reading through the thread i still have a question.

is there an 'order of operations' for where config bits are pulled from? where does the compiler look for these specifically? i am having trouble tracking down a complete list of files that get compiled at any given time by PBP... it goes to fast for me to read them..

also, if i 'Import' a .hex file i compiled out of microcode studio into MPLAB, does it set the config flags? in other words, say i load a .hex i downloaded precompiled, and wanting to know what is going on, import it into mplab - are the settings in the configuration bit window current for the imported .hex or just defaults?

i have tried some experimenting, and cannot exactly tell. its a real bugger working with 3 different programs instead of say 1...

ok. ive edited this post cuz noone read it yet... i have learned that you apparently CAN put fuses in a seperate include... mister e recomends 'configfuse.cfg'

[Bruce]

PBP has a device specific header file for each PIC it supports. This gets
included automatically each time you compile. In these header files are
generic "default" config fuse settings.

These are embedded in the .hex file. When you import a .hex file into
MPLAB these default config fuse settings are used, and should show up
in the config screen when viewed in MPLAB. You can either accept them,
or change them from within MPLAB.

I always include config fuse settings in my source. Changing them with your
programmers software, or from within MPLAB, can lead to confusion down
the road.

I.E. If you can't tell by looking at the source what they were set to when
you last programmed the target -- how will you know/remember the next
time what you manually set them to?

It's much easier to just drop them directly into your source code (or use the
generic defaults) than trying to remember what they were "manually" set to
previously.

[vacpress]

yeah. after once again and more carefully reading through the PBP manual, i have finally found the information about 'what all' files go into a typical pic basic compile... and i even now know what a .mac file is, finally!

i also answered another of my own questions... which was 'can i bury the configs in a seperate include?'

the answer seems to be 'yes'. although i am not certain to what extent, as it came out of some old forum post which suggests putting your config fuses in a configfuses.cfg...i do not know if this is a special or arbitrary file name... i will probably get around to trying this soon and may even remember to report back...

i am imagining .cfg files with names like... 18f45504musb.cfg which would setup a 4550 at 4mhz with the usb regulator turned on... possibly make a few as i really do work with just a few different chip types...

anyone tried anything like this?

it sure would be cool if microcode studio had an API so I could begin automating some of this stuff...

cheerio, robert