Searching \ for '[PIC] F871 compilers?' 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: 'F871 compilers?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] F871 compilers?'
2000\06\12@094610 by Hardware Engineering

picon face
I've been developing in assembly for many years now, never really *needed* to
use a higher language (basic/C) for my projects.  Now I have a new one, and
think that maybe its time.

OK..so I've looked at the demo versions of the C stuff, but they all are for
lower end PIC's.  What compilers (basic or C) handle the F871 device, and do
they interface with the MPLAB simulator?

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

2000\06\12@095228 by Andrew Kunz

flavicon
face
>OK..so I've looked at the demo versions of the C stuff, but they all are for
>lower end PIC's.  What compilers (basic or C) handle the F871 device, and do
>they interface with the MPLAB simulator?

HiTech PICC is very good, and I understand integrates well into MPLAB.  (I don't
use MPLAB, but PICC integrates well into Mathias which I _do_ use).

I understand Bytecraft is very good and integrates well, but I don't use either
of them.

Andy

2000\06\12@141316 by pandersn

flavicon
face
I'd second that in looking for the F873 device too.

Phil.

On Monday, June 12, 2000 8:45 AM, Hardware Engineering [SMTP:spam_OUTpic-ineerTakeThisOuTspamUSA.NET] wrote:
{Quote hidden}

2000\06\12@142510 by Ralph & Helene

picon face
I have successfully developed a number of programs using the PIC16F877 with
the Pic Basic Pro Compiler from Micro Engineering Labs (melabs.com).

Ralph Krongold
Los Angeles, CA
{Original Message removed}

2000\06\13@015613 by Dr. Imre Bartfai

flavicon
face
Hi,
visit http://www.bknd.com
Regards,
Imre

On Mon, 12 Jun 2000, Andrew Kunz wrote:

{Quote hidden}

2000\06\13@141716 by fernteix

flavicon
face
Hi,

I had the same problem. I use assembler for easy projects ( I/O and timer0)
and to avoid spend my life rediscovering whells I decide for the Basic: PBP
of http://www.melabs.com
But people that want to do things with the small PICs (8 pin ones) the way
seems to be C to get compact code: so I will start with the CCS
http://www.ccsinfo.com because it has a very good library already done for all the
hardware functions. With this I dare to work with short time with all the
hardware the PIC has.
I plan to use both according to the needs. The PBP for quick work with more
memory is available.
I discovered also that I can«t avoid to study the hardware. For that Benson
books are perfect.
Regards

Fernando

{Original Message removed}

2000\06\14@053237 by Marc

flavicon
face
> HiTech PICC is very good, and I understand integrates well into MPLAB.  (I don't
> use MPLAB, but PICC integrates well into Mathias which I _do_ use).

I have downloaded the (free) PicLite for 16F84.  I'm not really satisfied with the
output code size.  A lot of space is wasted.  Maybe the non-Lite version is better.

On the other hand, it really integrates well and it's very easy to get something
done with it fast.  Big plus on that side of the coin!

2000\06\14@090934 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Marc [SMTP:.....marcKILLspamspam@spam@AARGH.FRANKEN.DE]
> Sent: Wednesday, June 14, 2000 1:03 AM
> To:   PICLISTspamKILLspamMITVMA.MIT.EDU
> Subject:      Re: [PIC] F871 compilers?
>
> > HiTech PICC is very good, and I understand integrates well into MPLAB.
> (I don't
> > use MPLAB, but PICC integrates well into Mathias which I _do_ use).
>
> I have downloaded the (free) PicLite for 16F84.  I'm not really satisfied
> with the
> output code size.  A lot of space is wasted.  Maybe the non-Lite version
> is better.
>
> On the other hand, it really integrates well and it's very easy to get
> something
> done with it fast.  Big plus on that side of the coin!
>
>
I'm surprised.  I have made many small 16F84 toys using HiTech (full
version) and I always thought the code was pretty good.  In fact I would
have found it pretty hard to improve with my somewhat dodgy assembly skills,
the only bad point was some unnecessary bank swithcing in some of the
earlier versions of the complier.

You are invoking the compiler with the switches for maximum optimisation
aren't you?  ( -O -Zg9 off the top of my head, and assuming the lite version
implements this)

Mike

2000\06\14@091355 by Andrew Kunz

flavicon
face
From what I understand of one of Clyde's earlier postings, the PICLITE is an
older version and doesn't do the same level of optimizations as when you buy the
real product.

Crippleware.

Andy










Michael Rigby-Jones <.....mrjonesKILLspamspam.....NORTELNETWORKS.COM> on 06/14/2000 06:32:09 AM

Please respond to pic microcontroller discussion list <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>








To:      PICLISTspamspam_OUTMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: [PIC] F871 compilers?








> {Original Message removed}

2000\06\15@103049 by Marc

flavicon
face
> I'm surprised.  I have made many small 16F84 toys using HiTech (full
> version) and I always thought the code was pretty good.  In fact I would
> have found it pretty hard to improve with my somewhat dodgy assembly skills,
> the only bad point was some unnecessary bank swithcing in some of the
> earlier versions of the complier.
>
> You are invoking the compiler with the switches for maximum optimisation
> aren't you?  ( -O -Zg9 off the top of my head, and assuming the lite version
> implements this)

I have added it to MPLAB and it offers me two checkboxes, "Local optimization"
and "Global optimization".  I have both on, that's all I could find about optimizing.

The missed optimization chances are simple stuff like this for example:

   42                           152: if (RB0) data |= mask;

   43  0250  1283                      bcf     3,5
   44  0251  1C06                      btfss   6,0
   45  0252  2A55                      goto    l8
   46  0253  0827                      movf    ?a_comReceive+1,w
   47  0254  04A6                      iorwf   ?a_comReceive
   48  0255                     l8

Could be:

       bcf     3,5
       movf    ?a_comReceive+1,w
       btfsc   6,0
       iorwf   ?a_comReceive


Or, the handling 32bit variables was really bad!  I collected 4 8bit bytes
and built a 32bit ulong from them. The compiler did not recognize that

       ulong data;

       data <<= 8;

can be done by moving the bytes. Instead it used half a page full of setup
code for a subfunction call, and then called a bitwise shift!!   Building
a long from 4 bytes by this method (which I routinely use with IAR-C on the
AVR) costs about 300 words of code space, 1/3 of the chip!!!

I ended up to define a union with access to the long via individual bytes,
and insert them directly now (with the little/big endianess portability
caveat).

2000\06\15@111414 by Michael Rigby-Jones

flavicon
face
{Quote hidden}

This compiles to the same on the full version.  Maybe Clyde could implement
this as a future optimisation?

{Quote hidden}

This must be where the Lite version differs.  Compiling with full
optimisation on the latest full version gives:

    21  03F0  0812                     movf    _data+2,w
   22  03F1  0093                      movwf   _data+3
   23  03F2  0811                      movf    _data+1,w
   24  03F3  0092                      movwf   _data+2
   25  03F4  0810                      movf    _data,w
   26  03F5  0091                      movwf   _data+1
   27  03F6  0190                      clrf    _data

which is pretty much what you would expect.

As for building a long from four chars, I used a very usefull header file I
was directed to on http://www.keyghost.com/ which defines macros for doing
exactly this sort of thing.  Moving four chars into a long in the same bank
compiles to 8 instructions. With the macros expanded it looks something like
this:

(unsigned char)(*(((unsigned char *)&var)+0))=mybyte1;
(unsigned char)(*(((unsigned char *)&var)+1))=mybyte2;
(unsigned char)(*(((unsigned char *)&var)+2))=mybyte3;
(unsigned char)(*(((unsigned char *)&var)+3))=mybyte4;

and compiles to this:

   23  07F5  0820                      movf    _mybyte1,w
   24  07F6  00A4                      movwf   _var
   26  07F7  0821                      movf    _mybyte2,w
   27  07F8  00A5                      movwf   _var+1
   29  07F9  0822                      movf    _mybyte3,w
   30  07FA  00A6                      movwf   _var+2
   32  07FB  0823                      movf    _mybyte4,w
   33  07FC  00A7                      movwf   _var+3

All the above were compiled for a 16F84.

Regards

Mike Rigby-Jones

2000\06\15@165020 by Clyde Smith-Stubbs

flavicon
face
On Wed, Jun 14, 2000 at 09:11:34AM -0400, Andrew Kunz wrote:
> >From what I understand of one of Clyde's earlier postings, the PICLITE is an
> older version and doesn't do the same level of optimizations as when you buy the
> real product.

Not true, it reflects a recent version, but will not be updated as
often as the full version.

Clyde

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: RemoveMEclydeTakeThisOuTspamhtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger spamBeGoneclydespamBeGonespamhtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

2000\06\15@165910 by Clyde Smith-Stubbs

flavicon
face
Regarding the suboptimal code mentioned earlier (I've deleted that
message):

1) The sequence

       if(RB0) a |= b;

could indeed be improved by one word. Thanks for that. It will be done.

2) Regarding shifting of longs, I couldn't find a problem. The compiler
generates
   32                           ;x.c: 10: c <<= 8;
   33  03EC  0811                      movf    ?a_main+4,w
   34  03ED  0092                      movwf   ?a_main+5
   35  03EE  0810                      movf    ?a_main+3,w
   36  03EF  0091                      movwf   ?a_main+4
   37  03F0  080F                      movf    ?a_main+2,w
   38  03F1  0090                      movwf   ?a_main+3
   39  03F2  018F                      clrf    ?a_main+2

which looks pretty good to me.

Cheers, Clyde

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: TakeThisOuTclydeEraseMEspamspam_OUThtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger RemoveMEclydespamTakeThisOuThtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

2000\06\15@212919 by Don B. Roadman

flavicon
face
On 16 Jun 2000, at 6:48, Clyde Smith-Stubbs wrote:

> On Wed, Jun 14, 2000 at 09:11:34AM -0400, Andrew Kunz wrote:
> > >From what I understand of one of Clyde's earlier postings, the
> > >PICLITE is an
> > older version and doesn't do the same level of optimizations as when
> > you buy the real product.
>
> Not true, it reflects a recent version, but will not be updated as
> often as the full version.
>
> Clyde
>
> --
> Clyde Smith-Stubbs               |            HI-TECH Software
> Email: clydeEraseMEspam.....htsoft.com          |          Phone            Fax
> WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
> PGP:   finger EraseMEclydespamhtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355
> 8334
> ----------------------------------------------------------------------
> ----- HI-TECH C: compiling the real world.
>
I'm curious about all the bank switching that goes on in the
compiled code. I wrote a program for 16F84 and looked at the
code. The only time I ever needed to go to bank one was in the
very beginning of the program to set the I/O ports. After that, I didnt
use any registers in bank 1. But, I noticed in the code that there
were places where the rp0 bit was being  cleared, as if the compiler
didnt keep track of the bank it was in. Did I miss a setting or
something? I used mplab and had both optimization boxes
checked, but I'm wondering if maybe mplab doesnt properly send
the optimizations to the compiler?

2000\06\16@055507 by Marc

flavicon
face
> HiTech PICC is very good, and I understand integrates well into MPLAB.  (I don't
> use MPLAB, but PICC integrates well into Mathias which I _do_ use).

I have downloaded the (free) PicLite for 16F84.  I'm not really satisfied with the
output code size.  A lot of space is wasted.  Maybe the non-Lite version is better.

On the other hand, it really integrates well and it's very easy to get something
done with it fast.  Big plus on that side of the coin!

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