Searching \ for '[PIC] Configuration Bits with Hi-Tech Compiler' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Configuration Bits with Hi-Tech Compiler'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Configuration Bits with Hi-Tech Compiler'
2009\02\08@205540 by Joseph Bento

face
flavicon
face
It can get frustrating trying to track down information when one is
learning.  I'm perusing through the "Hi-Tech C 10/12/16" manual as well as
the datasheet for the 16F690.  I'm trying a couple projects in C on the "Low
Pin Count" Microchip board.

I'm trying to understand an example that flashes a couple LEDs on the board.
I can follow the C source pretty well, I can edit the code and recompile to
control different LEDs and so on.  It's the configuration bit setting that
I'm trying to understand.

My program uses the following config setting:

__CONFIG (INTIO & WDTDIS & MCLRDIS & UNPROTECT);
//Internal Clock, Watchdog off, MCLR off, Code Unprotect

Since it is commented, I can see what is happening.  It's the terminology
itself that I haven't found a reference for.  I was playing around with the
MCLR setting by temporarily deleting it from the code, and controlling MCLR
via the buttons in MPLAB.  (I wanted to prove to myself that if MCLR is
disabled as above, the buttons have no effect - they don't.)  

If I were writing this program from scratch, how would I know, and where
would I find 'DIS' for 'MCLRDIS' ?  I searched on the web, and I see that If
wanted MCLR enabled, the command is 'MCLREN'. No mention that I can see in
the manual.

Since it's apparently related to the compiler, I don't expect to see the
reference in the datasheet, but the compiler manual itself seems devoid of
explanation.

Am I missing something in understanding where to find answers?

Joe


2009\02\08@211656 by David Meiklejohn

face
flavicon
face
Joe Bento wrote:
>
> It can get frustrating trying to track down information when one is
> learning.

This is true - which is one reason I started writing tutorials - but even
when someone like me tries to write a guide, it doesn't always help,
because there is simply a lot of information to take in.

For C programming using HI-TECH C on a 16F690, I can refer you to my
midrange C tutorials (http://www.gooligum.com.au/tut_midrange_C.html),
where the answer to your question is to be found in lesson 1.

But you might say that it's buried...

> If I were writing this program from scratch, how would I know, and where
> would I find 'DIS' for 'MCLRDIS' ?  I searched on the web, and I see that
> If
> wanted MCLR enabled, the command is 'MCLREN'. No mention that I can see in
> the manual.
>
> Since it's apparently related to the compiler, I don't expect to see the
> reference in the datasheet, but the compiler manual itself seems devoid of
> explanation.

You are right that this isn't covered in the manual, because it's
processor dependent.  It's in the include files.  Here's the relevant
section from my tutorial (saves me writing the same thing again...) - see
the last line:

--------
The symbols relevant to specific processors are defined in include files.
But instead of including a specific file, as we would do in assembler, it
is normal to include a single “catch-all” file: “htc.h”.  This file
identifies the processor being used, and then calls other include files as
appropriate.  So our next line, which should be at the start of every
HI-TECH C program, is:
#include <htc.h>

To set the processor configuration, a macro called ‘__CONFIG(x)’ is used,
in a very similar way to the __CONFIG directive in MPASM:

// Config: ext reset, no code protect, no brownout detect, no watchdog,
//         power-up timer enabled, 4MHz int clock
__CONFIG(MCLREN & UNPROTECT & BORDIS & WDTDIS & PWRTEN & INTIO);

Note that the configuration symbols used are different to those defined in
the MPASM include files.  For example, ‘MCLREN’ instead of ‘_MCLRE_ON’,
and ‘INTIO’ instead of ‘_INTRC_OSC_NOCLKOUT’.  To see which symbols to use
for a given MCU, you need to look in the appropriate include file.  For
example, in this case (for the 12F629), these symbols are defined in the
“pic126x.h” file, found in the “include” directory within the compiler
install directory.
--------

For the 16F690, you need to find the appropriate header file, and that
means hunting in the include directory, within the HI-TECH C installation.

The config symbols are defined there.


2009\02\08@211915 by Bob Blick

face
flavicon
face
Hi Joe,

Look in the compiler's "include" directory and find the .h file for the
chip group you are compiling. Near the end of the file are the
configuration fuses.

Beware, some chips have some of their config settings at a second
address and require a second config line in your code, like this:

__CONFIG (FOOBAR & FOOBAS)
__CONFIG (FOOBAT)

It's not always obvious in the include file which ones need to be on the
second line - consult the chip's data sheet for the addresses of the
configuration words to see which is which.

This may be fixed in the latest version of the HiTech compiler but I use
an ancient version that doesn't even have the 16F690 so that's why I am
being general in my explanation.

Cheerful regards,

Bob


Joseph Bento wrote:
{Quote hidden}

2009\02\08@220519 by solarwind

picon face
On Sun, Feb 8, 2009 at 9:18 PM, Bob Blick <spam_OUTbobblickTakeThisOuTspamftml.net> wrote:
{Quote hidden}

Bob, you may wish to "upgrade" your compiler... ;)

--
solarwind

2009\02\08@222113 by Joseph Bento

face
flavicon
face
Bob and David,  

Thank you both very much!  It took a few moments to locate the proper file.
The 16f690 datasheet covers several devices, and the proper Hi-Tech file was
the 16F685.  As you both stated, everything I need to know for the
configuration word is in this file.

Now I'm curious as to how this pic16F685.h file is called by
'#include<pic.h>' Does the compiler choose from the device selection during
project setup?

Joe




{Original Message removed}

2009\02\08@223242 by Bob Blick

face
flavicon
face
Joseph Bento wrote:
> Bob and David,  
>
> Thank you both very much!  It took a few moments to locate the proper file.
> The 16f690 datasheet covers several devices, and the proper Hi-Tech file was
> the 16F685.  As you both stated, everything I need to know for the
> configuration word is in this file.
>
> Now I'm curious as to how this pic16F685.h file is called by
> '#include<pic.h>' Does the compiler choose from the device selection during
> project setup?

If you use MPLAB or the HiTech IDE you choose the chip and the number
gets passed to the compiler. If, like me, you use a makefile or compile
from the command line, you pass the part number implicitly, as in
"picc -16F690 filename"

Cheers,
Bob

2009\02\08@224258 by Bob Blick

face
flavicon
face
solarwind wrote:
> On Sun, Feb 8, 2009 at 9:18 PM, Bob Blick <.....bobblickKILLspamspam@spam@ftml.net> wrote:
>> This may be fixed in the latest version of the HiTech compiler but I use
>> an ancient version that doesn't even have the 16F690 so that's why I am
>> being general in my explanation.
>
>
> Bob, you may wish to "upgrade" your compiler... ;)

Not since HiTech "upgraded" their activation so it treats their paying
customers like criminals.

So far I have been able to create include files for new chips as I have
needed them. At some point if that no longer works properly I will buy a
compiler from a different vendor or choose a different architecture. But
HiTech won't get any more of my money if I have any other alternative.

Sorry to get on my high horse but they piss me off.

Best regards,

Bob

2009\02\08@230022 by Joseph Bento

face
flavicon
face


> -----Original Message-----
> From: piclist-bouncesspamKILLspammit.edu [.....piclist-bouncesKILLspamspam.....mit.edu] On Behalf
> Of Bob Blick
> Sent: Sunday, February 08, 2009 8:32 PM
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] Configuration Bits with Hi-Tech Compiler
>
> If you use MPLAB or the HiTech IDE you choose the chip and the number
> gets passed to the compiler. If, like me, you use a makefile or compile
> from the command line, you pass the part number implicitly, as in
> "picc -16F690 filename"

OK, that makes sense.  I've tried some limited development from my Mac's
terminal using PK2CMD, GPUTILS, and JAL.  All require inputting the chip
directly as part of the command.

Thanks!

Joe


2009\02\09@001126 by William \Chops\ Westfield

face picon face

On Feb 8, 2009, at 7:42 PM, Bob Blick wrote:

> So far I have been able to create include files for new chips as I  
> have
> needed them. At some point if that no longer works properly I will  
> buy a
> compiler from a different vendor or choose a different architecture.

One wonders where you would be, morally and legally, downloading the  
picc-lite version (which includes the newer include file), and copying  
the newer include files into your own compiler tree.  After all, the  
include files don't really contain intellectual property of hi-tech to  
start with...

BillW

2009\02\09@002935 by Bob Blick

face
flavicon
face
William "Chops" Westfield wrote:

> One wonders where you would be, morally and legally, downloading the  
> picc-lite version (which includes the newer include file), and copying  
> the newer include files into your own compiler tree.  After all, the  
> include files don't really contain intellectual property of hi-tech to  
> start with...

It really wouldn't bother me at all. But what I do is just duplicate the
include file for a similar chip and make whatever changes I need for
defining memory, new registers and config locations, and save it with
the new name. Then add the name of the new file to the master list of
chips. That should continue to work as long as I don't try it for one of
the new "enhanced midrange" chips.

BTW the version I use is more efficient than the old picc-lite, and both
are incredibly more efficient than the new free "lite" version.

Cheerful regards,

Bob

2009\02\09@090834 by Gerhard Fiedler

picon face
William "Chops" Westfield wrote:

> On Feb 8, 2009, at 7:42 PM, Bob Blick wrote:
>
>> So far I have been able to create include files for new chips as I
>> have needed them. At some point if that no longer works properly I
>> will buy a compiler from a different vendor or choose a different
>> architecture.
>
> One wonders where you would be, morally and legally, downloading the
> picc-lite version (which includes the newer include file), and
> copying the newer include files into your own compiler tree.  After
> all, the include files don't really contain intellectual property of
> hi-tech to start with...

The problem is not really the include files. They are simple enough to
be created (and legally, a created one can't really be distinguished
from a file copied and adapted from the lite version).

The problem may be certain errata work-arounds that they build into
their code generation, depending on type.

Whether they don't contain IP, I'm not sure but I think they do. They
are a codification of selected contents from Microchip datasheet into
HiTech compiler configurations, and as such probably considered
non-trivial and copyrighted.

Gerhard

2009\02\09@121944 by Bob Blick

face
flavicon
face
On Mon, 9 Feb 2009 12:08:06 -0200, "Gerhard Fiedler"
<EraseMElistsspam_OUTspamTakeThisOuTconnectionbrazil.com> said:

> The problem may be certain errata work-arounds that they build into
> their code generation, depending on type.

Then that would be in the compiler itself, not the include file, which
are basically lists of "names and addresses". It's not like the CCS
compiler which has lots of useful functions like I2C etc. As far as
errata work-arounds, they absolutely don't do those, since those have to
do with onboard peripherals and HiTech has no libraries for them other
than EEPROM. I remember people making include files to allow compiling
for the SX processor, that seemed to work fine.

What I do to make the compiler work for me had better be OK - I paid
gobs of money for it over the years, through purchase and yearly
maintenance. I'm voting with my $$ and if they want me back they can
stop abusing their customers.

Cheers,

Bob


--
http://www.fastmail.fm - Choose from over 50 domains or use your own

2009\02\09@133632 by William \Chops\ Westfield

face picon face

On Feb 9, 2009, at 9:19 AM, Bob Blick wrote:

> What I do to make the compiler work for me had better be OK

I didn't mean that I though you might be on shaky ground writing
your own include files (or subtly modifying the include files you
already gave to match new chips.)  I was suggesting you might have
it easier downloading the "lite" version and copying new cpu include
files from THAT distribution instead of making your own...

BillW

2009\02\09@172032 by David Meiklejohn

face
flavicon
face
Bob Blick wrote:
>
> What I do to make the compiler work for me had better be OK - I paid
> gobs of money for it over the years, through purchase and yearly
> maintenance. I'm voting with my $$ and if they want me back they can
> stop abusing their customers.

Ok, I'll bite.  I've seen various complaints about HI-TECH's policy, and I
gather that it has something to do with maintenance renews, but I'm hazy
on what is actually so objectionable.

So - what do you consider to be "abusing their customers"?  Forewarned is
forearmed etc.


David Meiklejohn
http://www.gooligum.com.au

2009\02\09@180138 by Bob Blick

face
flavicon
face
On Tue, 10 Feb 2009 09:20:00 +1100 (EST), "David Meiklejohn"
<davidspamspam_OUTgooligum.com.au> said:
> Bob Blick wrote:
> >
> > What I do to make the compiler work for me had better be OK - I paid
> > gobs of money for it over the years, through purchase and yearly
> > maintenance. I'm voting with my $$ and if they want me back they can
> > stop abusing their customers.
>
> Ok, I'll bite.  I've seen various complaints about HI-TECH's policy, and
> I
> gather that it has something to do with maintenance renews, but I'm hazy
> on what is actually so objectionable.
>
> So - what do you consider to be "abusing their customers"?  Forewarned is
> forearmed etc.

It's not the money, it's the internet activation I object to. In the
past you'd get a series of activation numbers, but now you have to
connect to Hi-Tech via the internet to authorize your computer. That is
a line I won't cross(again). Death by a thousand cuts, etc. I am not
going to participate in their flawed software protection scheme.

I actually did use the new one for a while, but when I had to travel and
tried to put the compiler on my laptop, failed, and would need to wait
until Monday for email activation, I reverted to the earlier version and
made it work for the 16F884. I pay money to save time, not for them to
waste my time.

If they don't trust me, a paying customer, I can't trust them. Good
compiler, bad management decision.

And of course this is just my personal choice, I'm sure I'm in the
minority. Maybe they had a big problem with single user licenses being
used multiple times and this fixed it.

BTW, the old version generated the same size code.

Best regards,

Bob

--
http://www.fastmail.fm - Access all of your messages and folders
                         wherever you are

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...