[gentoo-embedded] OT: HiTech-C question

[gentoo-embedded] OT: HiTech-C question

[David Relson]

Greetings,

I'm using HiTech-C for the first time.  Given a program that references
undefined functions, the linker complains (and rightfully so!)  Given a
program with _no_ undefined functions, the linker gets stuck in  Though
I've been programming in C for many years, I'm new to HiTech-C. My
efforts to build a program are failing, likely because I've overlooked
a simple detail.

I running 64-bit gentoo on an AMD Phenom.

Here's my test program:

#include <htc.h>

void main(void)
{
  unsigned char var;
  unsigned char *addr;
  addr = (unsigned char *)0x20;
}

I use the following command to build

    /opt/hitech/picc/9.80/bin/picc -N32 --chip=16C926 -Oprog prog.c

The compiler prints the following:

    Licensed for evaluation purposes only.
    This licence will expire on Tue, 28 Dec 2010.
    HI-TECH C Compiler for PIC10/12/16 MCUs (PRO Mode)  V9.80
    Copyright (C) 2010 Microchip Technology Inc.

Then it runs forever, keeping a processor 100% busy cpu.

Output of 'ps' shows the following:

... 0:00 /opt/hitech/picc/9.80/bin/picc -N32 --chip=16C926 -Oprog E 0

... 32:48 cgpic --edf=/opt/hitech/picc/9.80/dat/en_msgs.txt -Og9s -w9
-PM

Additionally, I've loaded MPLAB IDE and HiTech-C 9.80 using wine and
get the same result with that combo.

Any suggestions as to what's wrong?

Thank you.

David

Re: [gentoo-embedded] OT: HiTech-C question

[Peter Stuge]

Hi David,

David Relson wrote:
> I'm using HiTech-C for the first time.

Sorry, I think there's a misunderstanding.

gentoo-embedded is about running Gentoo Linux in embedded systems,
not about developing embedded systems using Gentoo as a host.


> I use the following command to build
> 
>     /opt/hitech/picc/9.80/bin/picc -N32 --chip=16C926 -Oprog prog.c

Allow me to suggest that you ditch the closed source tools quickly,
before they have a chance to create more trouble for you.

For PIC16 you could give sdcc a spin instead. Then I suggest looking
up the gnupic mailing list.


> Any suggestions as to what's wrong?

Insert rant about how closed source crap software is slightly more
crap than open source crap software here.


//Peter

Re: [gentoo-embedded] OT: HiTech-C question

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 246 bytes --]

i think Peter is right.  i dont know what HiTech-C is or where to find it, but 
if it's a completely closed source product, you should seek assistance from 
them.  or from some website that caters to it.  neither of which this list is.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-embedded] OT: HiTech-C question

[wireless]

Previously you wrote:
> Greetings,
> 
> I'm using HiTech-C for the first time. 

I agree with both previous responses.

If you insist on closed sources, look here:
http://www.microchipc.com/
==> Pic C Sample Code and PIC FAQ


However, as one who has worked with traditional
development environments for uP, here's my wisdom.

Ditch Hi-tech C immediately. It is garbage and you'll
waist tons of time on things you should not. If you want
to use a commercial compiler, then you have to decide.

Want a really good compiler for Microchip stuff?

==> IAR, as they are THE GOLD STANDARD. www.iar.com

Sure you pay, but, in the long run, you'll be
thankful. Compilers for small micros are only as good
as the folks that develop and support them. IAR
is the best. Nobody else is even close. I know, as I use
to be part of a team, that used everything you can image.


Now, if you're a hack, and CHEAP, which is a compliment,
then get real and start learning how to use the open source
compilers.

I'll dig out a few links of my PIC open source references
and post it, if you like.



hth,
James

Re: [gentoo-embedded] OT: HiTech-C question

[Arkadi Shishlov]

Isn't the arrival of really cheap ARM-s, like M0, puts PIC and AVR and the like
in legacy category you won't ever look again? Assuming you can match the
hardware side: UARTs, counters, voltage, etc. the power consumption of today
ARM-s made on modern process is really good and programming experience is so
much better - not to deal with PIC brain-damaging architecture is so relieving.

People say, PIC-s are very robust and can handle a lot with theirs bare pin-s,
but still, does it really matter most of the times?

My experience with Hitech is that it generates significantly smaller code. Not
sure about PICC bugs (I used Windows version), but SDCC created broken program
(infinite loop) from the same code. Anyway, my experience with PIC was episodic
and the bug was fixed very fast by SDCC team.

Re: [gentoo-embedded] OT: HiTech-C question

[wireless]

Previously you wrote:
> Isn't the arrival of really cheap ARM-s, like M0, puts PIC and AVR and the like
> in legacy category you won't ever look again? Assuming you can match the
> hardware side: UARTs, counters, voltage, etc. the power consumption of today
> ARM-s made on modern process is really good and programming experience is so
> much better - not to deal with PIC brain-damaging architecture is so relieving.

Wow, this is fantastic! Really?

OK, maybe you spec for me an Arm chip?

I need at least 16 channels of 12 bit analog IO
at least 12 channels of DIO,
temperature sensor support
voltage sensors
(2) counters
(4) timers
(2) pwm
USART (2) + (1) SPI
packaging (flexible)

OK, we're talking nano watts of power consumption
(in sleep mode)!

Oh and  under $10 per unit on qty 100 or more!

Entire board build out should be less that $50
(qty 100) with lots of isolation and separated
power supplies to surge protect inputs. Secret,
get as much integrated into the micro to keep
board costs (other components) down. Ignore cost of PCB,
although a good embedded designer can include it,
for under $50.

Sure, spec me a 32 bit ARM, bro......
I'll buy 2 and you can burn me a eGentoo
CD?

curious,
James

Re: [gentoo-embedded] OT: HiTech-C question

[Peter Stuge]

wireless wrote:
> OK, maybe you spec for me an Arm chip?
> 
> I need at least 16 channels of 12 bit analog IO

That means external ADC, maybe two.


> at least 12 channels of DIO,

No problem of course.


> temperature sensor support
> voltage sensors

That's "just" two more analog inputs.


> (2) counters
> (4) timers
> (2) pwm

Too many timing peripherals. You'll need to split this up onto
multiple parts as well I think.


> USART (2) + (1) SPI
> packaging (flexible)
> 
> OK, we're talking nano watts of power consumption (in sleep mode)!

It's not a realistic spec for any microcontroller. Please try again,
with more care. You can get most of what you want in a single package
but not all of it. Unless of course you make your own.. Take an Actel
M1A3P250 with an ARM Cortex-M1 hardcore, then you could easily fit
all those peripherals in one package.


> Oh and  under $10 per unit on qty 100 or more!

M1A3P250 starts at $11.99 at Future Electronics. (MOQ=180, was 90 before)
But maybe you'll be able to put something else on the board into the
FPGA to balance that extra cost.

The closest you'll get for an NXP Cortex-M0 ARM part would be
something like LPC1113. (But there are other vendors too!)

http://ics.nxp.com/products/lpc1000/lpc1100/lpc11xx/

2 16 timers (counter and/or timer)
2 32 timers -"-
9 pwm
1 uart
1 spi

Packaging is QFN-33 or LQFP-48 for the slightly larger parts.

The QFN costs $1.46 for 100+ at Future.

See the family here:
http://ics.nxp.com/products/lpc1000/mcus/parametric/?sub=06


> Sure, spec me a 32 bit ARM, bro......
> I'll buy 2 and you can burn me a eGentoo CD?

As you see, part cost is no problem for ARM, but you'll need more
than one component for your project however you do it.


//Peter

Re: [gentoo-embedded] OT: HiTech-C question

[wireless]

Previously you wrote:

> It's not a realistic spec for any microcontroller. Please try again,
> with more care. You can get most of what you want in a single package
> but not all of it. Unless of course you make your own.. Take an Actel
> M1A3P250 with an ARM Cortex-M1 hardcore, then you could easily fit
> all those peripherals in one package.

Oh sure it is, but not in the 32 bit world.

> M1A3P250 starts at $11.99 at Future Electronics. (MOQ=180, was 90 before)
> But maybe you'll be able to put something else on the board into the
> FPGA to balance that extra cost.

yes, 32 bit and dsp processors have come way down on price.
But, when  you look at building a complete embedded system,
those high end processors eat you alive on external
component count  and manufacturing costs.  That board I just
spec'd cost less that $30 to manufacture, with a PIC and
every thing else that I did not require, like molex
connectors  and such.


> As you see, part cost is no problem for ARM, but you'll need more
> than one component for your project however you do it.

PRECISELY!; a 32 bit part can never compete with a micro if
specs are tight and cost/power requirements are astringent,
which most are. Certainly anything that is manufacutured in
lots of 10 or more, every penny counts and cost reduction
rules the decision process, never what some employee or
consult "likes". They (32+) only compete when you actually
need all those mips and mops, which is rare for the vast
majority of uP based products.

Don't believe me, just do a little research into the
numbers, not the (dollar) values, of those little 8/16 bit
parts. Fairchild and such won't even talk to you about
anything less than 1M in qty per quarter. For large
companies, those (8/16)uP are sub $1, for qty 10k or
more....... Some companies sell uP for pennies, just
to get the supply contract for the passives and such
on really large deals.

8/16 STILL rules the world and dominates the economics of
embedded. Granted 32 bit cores that run linux are very cool
and preferred by most embedded folks, but, that's a very
small number of design wins with big quantity (cell phones
for example), compared to their mature brethren (8/16).
There are millions of design wins each year, STILL, for 8/16
bit micros....

and yes, I like ARM very much, particularly in areas of
low power design, relative to intel or amd.


James

Re: [gentoo-embedded] OT: HiTech-C question

[Peter Stuge]

wireless wrote:
> > It's not a realistic spec for any microcontroller. Please try again,
> > with more care. You can get most of what you want in a single package
> > but not all of it. Unless of course you make your own.. Take an Actel
> > M1A3P250 with an ARM Cortex-M1 hardcore, then you could easily fit
> > all those peripherals in one package.
> 
> Oh sure it is, but not in the 32 bit world.

You can get one, but will end up with a much larger chip, in order to
find one which has all the things you needed, and it'll also have a
ton of other stuff that you don't need.

To a degree I think this goes for all processor makers, but granted,
Microchip really have very many parts with only small peripheral
differences. :)


> > M1A3P250 starts at $11.99 at Future Electronics. (MOQ=180, was 90 before)
> > But maybe you'll be able to put something else on the board into the
> > FPGA to balance that extra cost.
> 
> yes, 32 bit and dsp processors have come way down on price.

The M1A3P250 is not a processor, it's a processor and FPGA combined.


> But, when  you look at building a complete embedded system,
> those high end processors eat you alive on external
> component count  and manufacturing costs.

The point that this thread tries to make is that all 32-bit
processors are not "high end" as you might be used to.

In particular the Cortex-M products are quite fuss free. A handful of
caps is really all you need. That goes for the M1-enabled FPGA too.


> That board I just spec'd cost less that $30 to manufacture, with a
> PIC and every thing else that I did not require, like molex
> connectors  and such.

I think the cost would not be significantly higher if using something
more powerful than a PIC, and the other point this thread tries to
make is that the development work would be significantly easier,
netting a total reduced cost.


> > As you see, part cost is no problem for ARM, but you'll need more
> > than one component for your project however you do it.
> 
> PRECISELY!; a 32 bit part can never compete with a micro if
> specs are tight and cost/power requirements are astringent,
> which most are. Certainly anything that is manufacutured in
> lots of 10 or more, every penny counts and cost reduction
> rules the decision process, never what some employee or
> consult "likes". They (32+) only compete when you actually
> need all those mips and mops, which is rare for the vast
> majority of uP based products.

I think you would benefit from re-evaluating this position, quickly.

And of course it is simply folly to save on production cost in a
small (1k, 10k) run if there is a noticeable tradeoff to be made with
software/firmware development effort.

For lots of 10, 100, 1000 and even 10000, pennies in production are
irrelevant, they translate to just a few hours worth of development
time.

I haven't looked closely at the power numbers for M0, so for power,
physical size and mass production I agree that it remains very
important to choose parts very carefully.

But ARM cores have quite significant benefits in development, and
especially with Cortex-M0 they are eating up big parts of what used
to be an 8- or 16-bit only market.


> Don't believe me, just do a little research into the numbers,

This is my point too.


> Fairchild and such won't even talk to you about
> anything less than 1M in qty per quarter.

That's certainly not my experience from (in particular) Fairchild.


> For large companies, those (8/16)uP are sub $1, for qty 10k or
> more....... Some companies sell uP for pennies, just
> to get the supply contract for the passives and such
> on really large deals.

Of course it may be significant to save $1 (vs. the $1.46 ARM in
100qty, assuming you can get down to $0.46 for something else) for a
10k run, but certainly not for a 100qty run. It buys just one hour of
development time.


> 8/16 STILL rules the world and dominates the economics of embedded.

The state today is mostly uninteresting IMO, I find what happens
tomorrow all the more interesting. ARM is quickly taking a big part
of the market.


> Granted 32 bit cores that run linux are very cool and preferred by
> most embedded folks, but, that's a very small number of design wins
> with big quantity (cell phones for example), compared to their
> mature brethren (8/16).

That's comparing apples and oranges. I think you should really take
a look at the smallest ARM cores.


> and yes, I like ARM very much, particularly in areas of
> low power design, relative to intel or amd.

While more on-topic for gentoo-embedded that is only the Cortex-A
parts, which is on the opposite end of ARM's line card. Look into
the Cortex-Ms.


//Peter

Re: [gentoo-embedded] OT: HiTech-C question

[Arkadi Shishlov]

On 11/15/10 20:13, wireless wrote:
> PRECISELY!; a 32 bit part can never compete with a micro if
> specs are tight and cost/power requirements are astringent,

About power, I think PIC/AVR/MSP can't play that card anymore.

180 µA/MHz while running applications from Flash memory and a Shutoff mode with
only 20 nA.

http://www.energymicro.com/technology

Re: [gentoo-embedded] OT: HiTech-C question

[Peter Stuge]

Arkadi Shishlov wrote:
> Isn't the arrival of really cheap ARM-s, like M0, puts PIC and AVR
> and the like in legacy category you won't ever look again?

Yes and no. For the very smallest jobs, I think the cheapest PIC
still will beat an ARM by a bit. The PICs are also much smaller,
physically.

But I tend to agree. Used PIC since 90s, since starting with ARM
don't really think that I will look back.

> not to deal with PIC brain-damaging architecture is so relieving.

Hahaha! :) I kindof like it. The skip instructions are funny.


> People say, PIC-s are very robust and can handle a lot with theirs
> bare pin-s, but still, does it really matter most of the times?

Also a good point, the pins can sure take a beating.


David Relson wrote:
> At least one of HiTech's C compilers is gcc based.  Their 32-bit
> compiler documentation is a revised version of the gcc documentation.
> If recollection serves I think I saw a copy of the GPL, though I
> can't locate it right now.

Yes, they started out using their own fork of GCC for PIC32 (as
opposed to contributing support back into GCC) and since GCC is GPL
they are forced to publish their sources, which they also have done.
There was some community effort to clean it up and get it into GCC
proper, I don't know the status of that.

The C library is another story however. The C library that Microchip
released for their PIC32 to the public at no cost artificially limits
how large the application code can be. If you need larger you have to
buy the full version. They can do this because the C library is
separate from the compiler.


> James, I'd appreciate your posting your PIC open source references.

Here are some to get you started:

http://gputils.sf.net/ # assembler and linker
http://sdcc.sf.net/    # C compiler
http://gpsim.sf.net/   # simulator
http://www.linuxhacker.org/cgi-bin/ezmlm-cgi/1  # mailing list
http://pikdev.free.fr/ # a GUI IDE

The list is rather low volume, but has been around since 99. I would
suggest to post there any and all questions, and I believe you will
get good answers.


//Peter

Re: [gentoo-embedded] OT: HiTech-C question

[David Relson]

G'morning everybody,

Thank you all for your responses.  They are appreciated.

As a few details you don't know...

I posted to this list because, as a gentoo user and open source
developer, I knew it was a good place for information even when the
subject is somewhat off-topic and I did tag the subject as "OT".

At least one of HiTech's C compilers is gcc based.  Their 32-bit
compiler documentation is a revised version of the gcc documentation.
If recollection serves I think I saw a copy of the GPL, though I can't
locate it right now.

Checking on IAR's website, they support some PIC processors, but not
the PIC16 processor currently involved.

James, I'd appreciate your posting your PIC open source references.

Again, thank you all for sharing your knowledge and expertise.

Regards,

David

 On Mon, 15 Nov 2010 06:22:20 -0500 wireless wrote:

> Previously you wrote:
> > Greetings,
> > 
> > I'm using HiTech-C for the first time. 
> 
> I agree with both previous responses.
> 
> If you insist on closed sources, look here:
> http://www.microchipc.com/
> ==> Pic C Sample Code and PIC FAQ
> 
> 
> However, as one who has worked with traditional
> development environments for uP, here's my wisdom.
> 
> Ditch Hi-tech C immediately. It is garbage and you'll
> waist tons of time on things you should not. If you want
> to use a commercial compiler, then you have to decide.
> 
> Want a really good compiler for Microchip stuff?
> 
> ==> IAR, as they are THE GOLD STANDARD. www.iar.com
> 
> Sure you pay, but, in the long run, you'll be
> thankful. Compilers for small micros are only as good
> as the folks that develop and support them. IAR
> is the best. Nobody else is even close. I know, as I use
> to be part of a team, that used everything you can image.
> 
> 
> Now, if you're a hack, and CHEAP, which is a compliment,
> then get real and start learning how to use the open source
> compilers.
> 
> I'll dig out a few links of my PIC open source references
> and post it, if you like.
> 
> 
> 
> hth,
> James

Re: [gentoo-embedded] OT: HiTech-C question

[wireless]

Previously you wrote:

> Checking on IAR's website, they support some PIC processors, but not
> the PIC16 processor currently involved.

Deal with a salesman via email on IAR offerings. Often they
have versions not found published. IAR has an outstanding
(few) compiler developers. Best in the micro world, imho.
Ask who they'd use for your specific part/problem, if they
do not offer a suitable version for your specific (part) chip.


> James, I'd appreciate your posting your PIC open source references.

These are old and unfiltered from a long time:
from bookmarks file:

5382. http://www.embedded.com/190302110
5383. http://www.state-machine.com/
5384. http://www.circuitcellar.com/library/toc.asp
5385. http://www.ethernut.de/en/index.html
5386. http://www.sics.se/~adam/uip/index.php/Main_Page
5387. http://www.sics.se/~adam/uip/download.html
5388. http://www.edtp.com/
5389. http://liquorice.sourceforge.net/
5390. http://www-ccs.cs.umass.edu/~shri/iPicTech.html
5391. http://savannah.nongnu.org/projects/lwip/

5393.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011993
5394. http://forum.microchip.com/tm.asp?m=54189
5395. http://www.sics.se/~adam/uip/
5398. http://picnic.sourceforge.net/
5399. http://picnic.sourceforge.net/v2/wiki/
5400. http://pikdev.free.fr/
5401. http://piklab.sourceforge.net/
5402. http://hyvatti.iki.fi/~jaakko/pic/picprog.html
5403. http://home.pacbell.net/theposts/picmicro/
5404. http://picfloat.sourceforge.net/
5405.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010029&part=DM163004
5406.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1469&filter1=function
5407. http://www.beyondlogic.org/
5408. http://www.gnupic.org/
5409. http://huizen.dds.nl/~gnupic/
5410. http://groups.google.com/group/pickit-devel/
5411. http://mdubuc.freeshell.org/Jolt/
5412. http://www.oopic.com/
5413. http://www.yty.net/pic/
5414. http://www.piclist.com/techref/microchip/tcpip.htm
5415. http://www.piclist.com/techref/microchip/routines.htm
5416. http://pikdev.free.fr/
5417. http://piklab.sourceforge.net/
5418. http://www.chebucto.ns.ca/~rakerman/port-table.html#IANA
5419. http://www.piclist.com/techref/piclist/index.htm
5424. http://www.mypic32.com/web/guest/contestants


> Again, thank you all for sharing your knowledge and expertise.

Drop me some email off-line, as I'd be interested in
collaboration on PICs via wine/gentoo workstation
development. I'm BUSY right now, but in a few weeks, I'll be
finishing an old PIC(18F8720) project from 4 years ago
(customer has funding YIPEE!!!!!!!!!!!!)


James