Developing/compiling software

In message <l6o7b5d4so1t4vdtf13het6k6n56okl6qk@4ax.com>, Jon Kirwan
<jonk@infinitefactors.org> writes
>On Wed, 16 Sep 2009 10:53:35 +0200, "Lodewicus Maas"
><wicus.maas@gmail.com> wrote:
>
>>I've looked at Keil uVIsion (Trial Version) as well as Asem51v1.3 (old
>>stuff).
>>
>>Any suggestions of the compiler software you're using to write/compile your
>>code and create hex files to upload to the ATMEL microcontrollers. I would
>>rather review a few other options, than to invest in the Keil software, only
>>to discover afterwards that there are maybe better tools for the job
>>
>>(Apologies for my tenses/grammar - English is my second language)
>>
>>Kind Regards
>
>If budget is not a concern; this is a large, professional application;
>and you intend on using the c language for it, then the main question
>I'd have regarding using Keil's c compiler would be the quality of
>their after-sale support for you and their product documentation.  (I
>already believe they have a good quality compiler.)  How important
>those are will depend some on your own skills, of course.

Their after sales service is as good or better than most. See comment
at end.

>some rather detailed technical questions, beforehand.  Ask for some
>names they can offer you, unaffiliated with them otherwise, whom you
>can talk with a little about their experiences.

Just go on the Keil forum. As 80% of the professional world use Keil
that is a recommendation in itself. Besides I doubt if other customers
will talk to you.

>And do some research
>on your own to get a sense.  This may be worth a little prodding and
>research at the price point they are charging.  Get a manual and look
>it over, too.

Get the eval version of the compiler.

>I haven't used Keil for 20 years.  So my early experiences will be of
>almost no use

Correct yet still you ranted about it a few months back. You were going
to show us all the results of your SDCC -Keil comparison tests.

> -- they have changed hands probably more than once since
>then and,

Wrong. Keil was bought by ARM. However that was just a change of
ownership. For the 8051 (and 166) nothing else changed. As they were
bought by ARM the changes were to the ARM tool chain.

Keil can still support all their 8051 compilers going back 20 years. As
those of you here will know, at christmas 2008 they even sorted out a
dongle problem for a version (rebadged as Franklin) that was 18 years
old...

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Sat, 19 Sep 2009 09:43:22 +0100, Chris H <chris@phaedsys.org>
wrote:

>In message <l6o7b5d4so1t4vdtf13het6k6n56okl6qk@4ax.com>, Jon Kirwan
><jonk@infinitefactors.org> writes
>>On Wed, 16 Sep 2009 10:53:35 +0200, "Lodewicus Maas"
>><wicus.maas@gmail.com> wrote:
>>
>>>I've looked at Keil uVIsion (Trial Version) as well as Asem51v1.3 (old
>>>stuff).
>>>
>>>Any suggestions of the compiler software you're using to write/compile your
>>>code and create hex files to upload to the ATMEL microcontrollers. I would
>>>rather review a few other options, than to invest in the Keil software, only
>>>to discover afterwards that there are maybe better tools for the job
>>>
>>>(Apologies for my tenses/grammar - English is my second language)
>>>
>>>Kind Regards
>>
>>If budget is not a concern; this is a large, professional application;
>>and you intend on using the c language for it, then the main question
>>I'd have regarding using Keil's c compiler would be the quality of
>>their after-sale support for you and their product documentation.  (I
>>already believe they have a good quality compiler.)  How important
>>those are will depend some on your own skills, of course.
>
>Their after sales service is as good or better than most. See comment
>at end.

The OP needs to comment.  And being "as good or better than most"
doesn't necessarily say that one shouldn't see how it applies to their
specific circumstances.  In some cases, the norm is pretty bad.  It's
worth some investigation, unless it's already known at the outset that
it doesn't matter.  Which was my point.

>>some rather detailed technical questions, beforehand.  Ask for some
>>names they can offer you, unaffiliated with them otherwise, whom you
>>can talk with a little about their experiences.
>
>Just go on the Keil forum. As 80% of the professional world use Keil
>that is a recommendation in itself.

The OP still needs to comment here.  But the Keil forum is an obvious
place to check out, I agree.  Band wagon propaganda isn't meaningful,
though.  Just because 80% of the professional world uses Microsoft
compilers for Windows development doesn't mean it's always the more
appropriate choice, either.  Nor should it be the case that
competition isn't supported.  Few markets are served as well by single
suppliers than if there are several viable ones.  Competition is good.

>Besides I doubt if other customers will talk to you.

Now that's just you being sour and grumpy.

>>And do some research
>>on your own to get a sense.  This may be worth a little prodding and
>>research at the price point they are charging.  Get a manual and look
>>it over, too.
>
>Get the eval version of the compiler.

That, too.

>>I haven't used Keil for 20 years.  So my early experiences will be of
>>almost no use
>
>Correct yet still you ranted about it a few months back. You were going
>to show us all the results of your SDCC -Keil comparison tests.

Yes, when I am ready.  Turns out, I have become more fully engaged in
work than I'd imagined and although I have plenty of raw data, it will
take some time (and thought) to pull it together for a post.

>> -- they have changed hands probably more than once since
>>then and,
>
>Wrong. Keil was bought by ARM. However that was just a change of
>ownership.

Which matters, as experience has done little but to inform me about.
It can be good or bad, but rarely indifferent.  Of course, I have no
idea about what the changes have and have not meant.  So I'll leave
this for you to rant about.  My point was to admit my ignorance.  If
you want to roll around in that mud, have at it.

>For the 8051 (and 166) nothing else changed. As they were
>bought by ARM the changes were to the ARM tool chain.

People matter.  Especially those near the top, whose attitudes and
goals impact everyone all the way down to those on the phone lines.

>Keil can still support all their 8051 compilers going back 20 years. As
>those of you here will know, at christmas 2008 they even sorted out a
>dongle problem for a version (rebadged as Franklin) that was 18 years
>old...

Oh, cripes.  A segue back into the dongle or not-to-dongle argument.
You and I will never agree on this point, either.  You are simply
wrong there, too.  Oh, well.

Someday, we should meet and have lunch.  If we still couldn't find
common ground or common worldviews, I'd at least be able to enjoy
watching you simmer over old grievances still remembered too well.

Jon

On Sat, 19 Sep 2009 09:35:50 +0100, Chris H <chris@phaedsys.org>
wrote:

>In message <jun7b51ca0mmlh513qmraeco91cr3rscon@4ax.com>, Jon Kirwan
><jonk@infinitefactors.org> writes
>>On Fri, 18 Sep 2009 18:22:14 +0100, Chris H <chris@phaedsys.org>
>>wrote:
>>
>>><snip>
>>>SDCC is not even in the frame It can not handle the Dallas
>>>memory map. There are several ways of doing it and I recall it took a
>>>lot of doing to getting working well.
>>
>>Is this the issue that SDCC mentions back in 2000 and 2001 and seems
>>to have been resolved then?  (Those issues they mention as related to
>>the Dallas DS 390?)  Or something you know to be otherwise and later?
>>
>>Jon
>
>Hi Jon,
>
>Last time we discussed SDCC and Keil you made all sorts or personal
>attacks on me and made many claims. You were going to prove you were
>right by doing a comparison test between SDCC and Keil
>
>As that was many months ago you can either show your results or
>apologise and go away.

I will prepare publishable results when I'm able to.  I've a schedule
to keep on a commercial project that arrived a month ago, right now.

No, I don't trust anything you say without checking it very carefully,
if I care about it at all.  You've earned that on your own.  But when
it also serves you well, you can offer some truly useful advice.  So
sometimes I find gems.  I just have to verify everything, that's all.

My question stands.  You said that SDCC "is not even in the frame" and
then used the solitary specific about a Dallas memory map problem to
back that broad statement up.  I went over to see what I could find
reported about such a problem and what I did uncover seemed to be
about 2000/2001 and the DS 390.  Supposedly, that's been taken care of
around that time.  But it might not be what you were talking about. So
I'm curious if this is what you were using or not.

I'm sincerely interested and believe it's possible you may have more
recent information than I've been able to find.  If so, your provision
of some researchable specifics might help others, if not me.

If you really don't have anything to add, beyond what I already
discovered, then that's fine, too.  It just undermines your prior
comment, is all.

Jon

Chris H wrote:
> In message <4ab336aa$0$26305$8404b019@news.wineasy.se>, David Brown
> <david@westcontrol.removethisbit.com> writes
>> FreeRTOS info wrote:
>>>> I agree about the ARM having lots of tools, but I thought the choice
>>>> of
>>>> practical tools for 8051 was fairly limited - either SDCC (for those
>>>> who value the benefits of free and open source tools, or for those on
>>>> a low budget) or Keil (for those with plenty of money looking for top
>>>> quality commercial tools).  Are there other alternatives?
>>>  IAR, Resonance, Tasking, to name but 3.
>>>
>> Thanks.  Keil and SDCC are the only ones I regularly read about in this
>> group.
> 
> Keil IAR and Tasking are professional tools  Of the three the Keil is
> the best for 8051.
> 
> 
>> For example in this thread, the OP asked for tools for the 8051, and
>> until now no one has mentioned anything other than Keil and SDCC. Are
>> they so dominant that few people use other tools for the 8051?
> 
> About 80$% of the professional market is Keil.  The rest use IAR or
> Tasking with only a few using anything else
> 
>> And if so, is it for technical reasons,
> 
> Mainly technical. Also the silicon companies work with Keil and IAR
> before the chip is launched... often up to two years before launch.
> 
> In this case Keil would be the best technical choice. Follwoed by IAR
> and tasking. SDCC is not even in the frame It can not handle the Dallas
> memory map. There are several ways of doing it and I recall it took a
> lot of doing to getting working well.
> 
>> economic reasons,
> 
> Economic is another reason in this particular case. The silicon
> companies work with *some* compiler companies and they have the examples
> and set up projects also their generated coded is usually a LOT more
> compact and faster. Thus less memory is needed and less power is needed
> and therefore lower costs in production that far out weigh any cost of
> the tools
> 

I don't want to go into the pros and cons of SDCC in this thread (unless 
the OP goes there) - I don't know the specifics of the tools, so it 
would end up in yet another generic argument about the advantages and 
disadvantages of expensive commercial tools against FOSS tools.  I'm 
happy not to talk about SDCC here if you are.

You say Keil has about 80% of the market.  I regularly read that "Keil 
is good, but horribly expensive" - a comment that equally applies to IAR 
in many cases.  And as far as I know, IAR works very closely with 
manufacturers (I know of several cases of both commercial and FOSS tool 
developers having trouble because manufacturers wouldn't talk to them - 
as far as the manufacturer was concerned, IAR was the only relevant tool 
vendor and since IAR made a compiler for their micro, why should they 
bother talking to any other tool vendor?).  So is there something else 
that makes Keil so dominant over IAR in the 8051 market?  How do they 
compare in price and code quality?

I know very little about Tasking - are they comparable in price and 
quality with Keil and IAR?

And why is there (apparently) no "ImageCraft" for 8051?  In the AVR and 
MSP430 market, ImageCraft is an example of a "cheap and cheerful" 
vendor.  They are much cheaper than (for example) IAR, and have much 
lower code generation quality (both IAR and gcc generally make smaller 
and faster code, and have far more features).  But the tools are easy to 
use and you get excellent support.  These sorts of tools are very 
popular among smaller developers.  Is there nothing equivalent in the 
8051 market?

In message <-tednXyshY6FainXnZ2dnUVZ8sudnZ2d@lyse.net>, David Brown
<david.brown@hesbynett.removethisbit.no> writes
>Chris H wrote:
>I don't want to go into the pros and cons of SDCC in this thread
>(unless the OP goes there) - I don't know the specifics of the tools,
>so it would end up in yet another generic argument about the advantages
>and disadvantages of expensive commercial tools against FOSS tools.
>I'm happy not to talk about SDCC here if you are.
>
>You say Keil has about 80% of the market.  I regularly read that "Keil
>is good, but horribly expensive" - a comment that equally applies to
>IAR in many cases.

Neither are expensive in reality. The initial purchase price is higher
than SDCC but total cost for a project can easily make the Keil the
least expensive choice.

> And as far as I know, IAR works very closely with manufacturers

Yes both IAR and Keil work closely with the 8051 silicon and core
makers. NOTE like ARM many 8051's are VHDL and Verilog cores as well as
in MCU chips.

>(I know of several cases of both commercial and FOSS tool developers
>having trouble because manufacturers wouldn't talk to them

This is not uncommon. It is a business arrangement.  The silicon
companies work with, usually, several of the leading compiler companies.
This is often several years before the release of the silicon.  I was
involved in this myself with one of the new parts for an 8051.

However... they want these new MCU's to be confidential until the
release (at least until the release to the lead customers) which would
not be possible with Open Source compilers.

> - as far as the manufacturer was concerned, IAR was the only relevant
>tool vendor and since IAR made a compiler for their micro, why should
>they bother talking to any other tool vendor?).

Some silicon companies work exclusively with IAR or Keil for the initial
compiler for their new part. After release other compilers are usually
able to gain information and also offer support.


> So is there something else that makes Keil so dominant over IAR in the
>8051 market?  How do they compare in price and code quality?

It is the design of the compiler. It has some features not found in any
other 8051 compiler.  Do remember that Keil specialised in the 8051 and
only the 8051 for a long time.

The code quality from a Keil compiler for 8051 can not be beaten (some
can equal it) the other point is the Keil 8051 compiler will handle all
the 600 odd variations of the 40+ different 8051 family cores.

The standard Intel 8051/52 core is AFAIK no longer used. There internal
architectures for the memory and the extensions to the SFR's mean a
standard 8051 12 cycle compiler will not work with most of the 8051
family.... or at least only with a subset of the SRF's and memory.

>I know very little about Tasking - are they comparable in price and
>quality with Keil and IAR?

I too know less about Tasking than IAR and Keil. They were bought by
Altium a while back and compilers do not seem to be their core business.
At Embedded World in Nuremberg this year the Tasking compilers were not
on the Altium stand bar a couple of flyers they managed to find under
the counter.


>And why is there (apparently) no "ImageCraft" for 8051?  In the AVR and
>MSP430 market, ImageCraft is an example of a "cheap and cheerful"
>vendor.  They are much cheaper than (for example) IAR, and have much
>lower code generation quality (both IAR and gcc generally make smaller
>and faster code, and have far more features).  But the tools are easy
>to use and you get excellent support.  These sorts of tools are very
>popular among smaller developers.  Is there nothing equivalent in the
>8051 market?

Not any more. The Keil (and IAR) compiler have the 8051 market sewn up.
The 8051 compiler has to handle many variations in the 8051 cores. There
are many memory layouts and SFR's . The 8051 market is not expanding.
The number of potential customers divided by effort to produce will
determine cost. So any 8051 compiler to compete with Keil will be
expensive to produce.

Besides you will have to convince the MCU makers to work with you as
well.

The problem is that due to the free and very cheap tools is that those
who don't care about high quality tools will use the free or *very*
cheap ones. Those who need the quality tools will get them as they are
very cost effective for their work.

That leaves the middle ground. Cost more than the cheap tools but they
not have performance that is that much better than the low end tools and
the are no where near as good as the expensive tools...

This is why the mid-range tools have disappeared in so many areas.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <06a9b51627kq9qu06t86irg1e19slo60tk@4ax.com>, Jon Kirwan
<jonk@infinitefactors.org> writes
>On Sat, 19 Sep 2009 09:43:22 +0100, Chris H <chris@phaedsys.org>
>>Besides I doubt if other customers will talk to you.
>
>Now that's just you being sour and grumpy.

No, I will talk to him but most developers are doing commercially
confidential stuff and time is money.

>>>I haven't used Keil for 20 years.  So my early experiences will be of
>>>almost no use
>>
>>Correct yet still you ranted about it a few months back. You were going
>>to show us all the results of your SDCC -Keil comparison tests.
>
>Yes, when I am ready.

:-) We did not expect you to produce any evidence.

>>> -- they have changed hands probably more than once since
>>>then and,
>>
>>Wrong. Keil was bought by ARM. However that was just a change of
>>ownership.
>
>Which matters, as experience has done little but to inform me about.
>It can be good or bad, but rarely indifferent.  Of course, I have no
>idea about what the changes have and have not meant.  So I'll leave
>this for you to rant about.  My point was to admit my ignorance.  If
>you want to roll around in that mud, have at it.

You made the point. I just clarified your FUD

>>For the 8051 (and 166) nothing else changed. As they were
>>bought by ARM the changes were to the ARM tool chain.
>
>People matter.  Especially those near the top, whose attitudes and
>goals impact everyone all the way down to those on the phone lines.

Stop digging a hole and talk about something you have some idea about.

Though we do know that SDCC has changed the whole development team more
than once... or is that why you were trying to sling mud at Keil?


>>Keil can still support all their 8051 compilers going back 20 years. As
>>those of you here will know, at christmas 2008 they even sorted out a
>>dongle problem for a version (rebadged as Franklin) that was 18 years
>>old...
>Oh, cripes.  A segue back into the dongle or not-to-dongle argument.
>You and I will never agree on this point, either.

I know

> You are simply
>wrong there, too.  Oh, well.

Except I proved your entire argument WRONG with a live case in this very
NG not 8 months ago.

>Someday, we should meet and have lunch.

I know who to have a s a referee.

>If we still couldn't find
>common ground or common worldviews, I'd at least be able to enjoy
>watching you simmer over old grievances still remembered too well.

No you I have a life.... Remember I do know other people who do know
you. I suggest you look in a mirror and mix with people a bit more.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In the country I'm living - PIC's are really hard-to-get ,and at a price. I 
started looking at Ebay and found the cheapest option available which can 
give me 32 I/O ports, and the best offers I could get was on the AT89S52, 
and this is how I ended up with the ATMEL product

I definately agree with a few posts that PIC might be easier and maybe 
cheaper, but like I said, I had to look at availability/price first, and now 
I must move on to the next step, which is compiling the code I already 
written over the past 2 months - without having any compiler or hardware. My 
programmer arrived  on Friday and as soon as I made up my mind on a 
compiler, then I can test(compile) the code which is currently only in a 
.txt file, and hope there is no compilation errors.

My AT89S52's should arrive within the next 2 weeks, and only then will I see 
if the past 3 months was a total waste of time.

Thank you for all the input
Much Appreciated
Lodewicus Maas 

On Sun, 20 Sep 2009 20:19:13 +0200, "Lodewicus Maas"
<wicus.maas@gmail.com> wrote:

>In the country I'm living - PIC's are really hard-to-get ,and at a price. I 
>started looking at Ebay and found the cheapest option available which can 
>give me 32 I/O ports, and the best offers I could get was on the AT89S52, 
>and this is how I ended up with the ATMEL product
>
>I definately agree with a few posts that PIC might be easier and maybe 
>cheaper, but like I said, I had to look at availability/price first, and now 
>I must move on to the next step, which is compiling the code I already 
>written over the past 2 months - without having any compiler or hardware. My 
>programmer arrived  on Friday and as soon as I made up my mind on a 
>compiler, then I can test(compile) the code which is currently only in a 
>.txt file, and hope there is no compilation errors.
>
>My AT89S52's should arrive within the next 2 weeks, and only then will I see 
>if the past 3 months was a total waste of time.
>
>Thank you for all the input
>Much Appreciated
>Lodewicus Maas 

Best of luck.  The AT89 is a fine chip for some uses.  I'm not sure
why you haven't tried to compile the code, though.  As Chris has
mentioned, there are demo versions of commercial c compilers that are
available.  And besides that, there is SDCC which you could also do
some trial compilations with.  I'm not sure if the Keil IDE can do
this (it may work, just fine) but Silicon Labs has an IDE as well for
their 8051 core cpus and their IDE (and SiLab's web site discusses
this in an appnote) can integrate SDCC into it, so you should be able
to run some tests that way.  There are some slight differences in
syntax for ports, if I recall, but that's also documented.  At least
you could have tested for compilation before receiving parts.

I am gathering now this may be a hobby project, though you still
haven't said.  Best of luck, either way.

Jon

On Sun, 20 Sep 2009 16:18:42 +0100, Chris H <chris@phaedsys.org>
wrote:

>>Someday, we should meet and have lunch.
>
>I know who to have a s a referee.
><snip>
>...and mix with people a bit more

Ironic, coming after suggesting you'd need a referree to meet.  Still,
I'm sure you meant this last part in a positive way so I'll just say
you shouldn't worry.  Just met with my Representative over lunch, a
few days ago, for example.  Plenty on my plate in that regard.  No pun
intended.

Jon

P.S.  I'd still think it would be helpful to others if you'd expand
even slightly on your earlier comment about SDCC.  I'm curious and I
did check to see what I could find about what few words you offered,
found something that seemed close, and if so it seems to be a bit out
of date.

In article <mQSsm.269458$156.79097@newsfe14.ams2>,
ChrisQ  <blackhole@devnull.com> wrote:

<SNIP>

>
>With regard to the ide, have been using Renasas 80C87 series on a client
>project and the "High Performance Embedded Workshop" ide looks very
>similar to the Keil
>ide, as does the ide from the Embest arm development kits. Perhaps Keil
>customise the ide for many. or is the look and feel being copied and
>becoming standardised ?...

My impression is that for better or (probably) worse, everybody
is trying to please people who are accustomized to MS Visual studio.
I can't get the hang around "project's" and "debug" directories
and such, but I know where it comes from.

>
>Regards,
>
>Chris

Groetjes Albert
--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst