compiling/programming errors to 12f675

[iaindunn]

Hi All

I have managed to install flowcode and link it to my pickit 1 proggrammer. A simple led on off program for the 12f675 has been tested in flowcode and then compiled. The pic appears to prgram OK but the led on off does not work.
My question is in flowcode where the configuration is do I have to put in __config _CP_OFF & _CPD_OFF etc. or do it in binary eg __CONFIG 'B' 110000100
I tried this and when I tried to compile the Dos screen threw up an error.
I then tried to open the asm file directly into mplab 7 and use the configure from there but still no joy.
Any ideas

Form a total newbie!

Iain

[Steve]

Hello Iain,

This used to work, but it doesn't seem to anymore (or at least I've forgotten how to do it).

But luckily, there is a very simple workaround. In your program, put the appropriate config data into a C icon within your program - this can be anywhere in your program, but I suppose it makes more sense to put it at the beginning of your "main" routine. Here's an example that shows the appropriate syntax:

Code: Select all

asm __CONFIG _CP_OFF & _CPD_OFF & _HS_OSC

I hope this helps.

[iaindunn]

The other question is what about configuring ports as all digital i/os and turning off the AD convertor and comparator modules.
Should this also be done as an asm code block ?

I will get it eventually
Iain

[Steve]

For each chip in Flowcode there is an "FCD" file ("Flowcode Chip Definition", I think). Each one should contain the appropriate code to turn off the a/d or comparitor modules as standard. For example, the 12F675.FCD file has the following:

Initialise="ansel = 0x20;\ncmcon = 0x07;\n"

So basically, Flowcode should handle this for you and all i/o lines should work as digital i/o as standard.

[iaindunn]

Thanks ..will give it a go.
Tried out compiling in version 3 ..seems slow. (I,m talking about 2/3 minutes for on/off LED )
Is this because the c compiler has changed?

[Steve]

The C compiler has changed and it is slower than the old one - but it is a much more fully-featured compiler that allows us (and you) to do much more.

The makers of this compiler have told me they are working to get the compilation time down.

Having said that, the time you say seems extremely long. I develop a PC that is over a year old and has 512MB of ram, and I've never had a program take more than around a minute to compile.

Please send me the FCF file and the generated C file and I will see if there is any simple solution to this.

[Steve]

I've received the files and they compile very quickly (8 secs) on my PC and produce near-identical C and ASM files.

I suspect there is something hogging resources on your PC.

[iaindunn]

Avast Virus checker seems to be the main culprit in slowing the compile down.

Also tried putting the config for the 12f675 as asm code as below:
asm __CONFIG _CP_OFF & _CPD_OFF & _WDT_OFF & _MCLRE_OFF & _IntRC_OSC

But get a compile error saying unable to compile C code.
Is the syntax wrong?

[Steve]

Hi Iain,

Good news that you've got the compiler time down. I've also made some inroads into that today and the final release of Flowcode will have an additional compilation-time improvement over the current demo version (on my PC, I've cut the time from 8 secs to 4 secs for a simple program).

Onto your config problem - the "asm __CONFIG ..." suggestion will work for Flowcode v2, but this won't work in v3. You now have 2 choices:

1) Select "Chip...Configure..." and put something similar to the following into the window:

Code: Select all

0x2007, 0x3FB4

2) Select "Edit...Supplementary code" and put the following code into the "definitions" section:

Code: Select all

#pragma DATA 0x2007, _CP_OFF & _CPD_OFF & _WDT_OFF & _MCLRE_OFF & _INTRC_OSC_NOCLKOUT

Hope this helps...

[iaindunn]

Thanks steve
Tried the original suggestion as a block of code ie asm __config INTOSC etc in version 2 as well and still get the compile error
is there a way of slowing down the DOS flash? so I can read it.
I think it mentioned definitions out of date.
I'll try your second suggestion in V3 and see how I get on.
My fault for using the 12f675 I suppose..but it seems such a great little chip.
Sorry to be such a pain in the @*$e

[Steve]

You originally had "_IntRC_OSC" in the list, but I don't think this is right. Try "_INTRC_OSC_NOCLKOUT" or "_INTRC_OSC_NOCLK" instead.

As for slowing down the compile time, there is a fix:

http://www.matrixmultimedia.com/mmforum ... c.php?t=36

[iaindunn]

Thanks Steve. that works now in version 2..a case of RTFM for the 12F675

[canipus]

Thanks Steve. that works now in version 2..a case of RTFM for the 12F675

Just in case you are not aware, the 12F675 and 629 internal oscillator have a calibration byte at the end of code memory. When you program the PIC you will erase the byte unless you specifically instruct the programmer to record it or you have previously recorded the calibration value as set by Microchip, and placed it into your code prior programming.

You may or may not need calibration (depending on the timing requirements of your application), but, if you do, you MUST insure the calibration byte EXISTS in the PIC. If it doesn't your code will go into a loop and you will be left wondering why your program doesn't work when it may work on a simulator.

Microchip did not do a good job of documenting the importance of maintaining the integrity of this byte, inserted by them, at the point of manufacture.

canipus