Re: Developing/compiling software

On Wed, 16 Sep 2009 10:53:35 +0200, "Lodewicus Maas"
<(E-Mail Removed)> 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

I hope you aren't finding the many English answers complex enough to
make further discussion hard for you. I see you haven't added
anything yet, which concerns me. You mention Atmel and Asem51v1.3, so
I'm assuming this is the AT89 series from Atmel?

Some questions that are important to know, before discussing things:
(1) Hobby or professional application? (Not clear, but I'm leaning
towards believing this is for professional use.)
(2) Assembly or c? (You mention asem51v1.3, but also mentioned
'compiler software', so it's not clear to me. It's possible
when you talk about 'Keil software' you may only care about
the debugger/JTAG capability, too. Can you clarify this?)
(3) Project size/complexity?
(4) Unique requirements?

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.

You might be able to test this a little by seeing how they treat you
with pre-sale questions -- but test things in several ways. Including
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. 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.

Do the same for any supplier you consider. In the end, whatever your
choice, you will spend a fair amount of your time learning to properly
use the tools. Even if you have good hand-holding from the supplier,
excellent documentation, or an energetic and healthy users' group, you
will still have to put in a lot of your own time. It's always good to
know what to expect and plan for. So, the effort won't be entirely
wasted, even if the results don't materially change your final
decision.

I haven't used Keil for 20 years. So my early experiences will be of
almost no use -- they have changed hands probably more than once since
then and, besides, the entire environment around them has also
changed. But I think it would help others respond to you better if
you could say a little more about your situation.

Jon

In message <(E-Mail Removed)>, Jon Kirwan
<(E-Mail Removed)> writes
>On Wed, 16 Sep 2009 10:53:35 +0200, "Lodewicus Maas"
><(E-Mail Removed)> 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 <(E-Mail Removed)>
wrote:

>In message <(E-Mail Removed)>, Jon Kirwan
><(E-Mail Removed)> writes
>>On Wed, 16 Sep 2009 10:53:35 +0200, "Lodewicus Maas"
>><(E-Mail Removed)> 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

In message <(E-Mail Removed)>, Jon Kirwan
<(E-Mail Removed)> writes
>On Sat, 19 Sep 2009 09:43:22 +0100, Chris H <(E-Mail Removed)>
>>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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Sun, 20 Sep 2009 20:19:13 +0200, "Lodewicus Maas"
<(E-Mail Removed)> 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 <(E-Mail Removed)>
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 message <(E-Mail Removed)>, Jon Kirwan
<(E-Mail Removed)> writes
>On Sun, 20 Sep 2009 16:18:42 +0100, Chris H <(E-Mail Removed)>
>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.

It was a recommendation from people who know you.

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

In message <(E-Mail Removed)>, Jon Kirwan
<(E-Mail Removed)> writes
>On Sun, 20 Sep 2009 20:19:13 +0200, "Lodewicus Maas"
><(E-Mail Removed)> 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.

There are demo version of the Keil and IAR. Though I would suggest Keil
in this case as a first stop. It is the one area where they really
specialise.

>And besides that, there is SDCC which you could also do
>some trial compilations with.

Not worth the effort. Start with Keil

> 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. T

Again not worth the effort. This is a lot of work for a system that will
not even come close to Keil

>here 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.

The Atmel stuff will be set up to compile with the Keil extensions. You
will have to port for the SDCC.

BTW there are some very cheap dev kits with the 4K version of the Keil.
However....

The code size limit is not the killer here. It is the DATA space. As
Keil does aggressive data overlaying in the DATA space you can get it to
compiler programs that the SDCC can't get to fit in the space.

I have seen cases where 119 bytes of DATA was compiled into 23 bytes of
DATA space. So in that case the SDCC would run out of space and the 2K
eval Keil will compile and run the app.

That is without the optimisation of the code the Keil can do compared to
the SDCC.

Then there is the fact the Keil is VERY heavily tested compared to the
SDCC and WILL do what it says.

The you have the fact that most companies, like Atmel, write their code
to be Keil compliant (not SDCC compliant)

As Jon pointed out changing development teams can have an effect.
Whereas the Keil has had a single team all the way though SDCC has AFAIK
changed complete development teams several times.


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

On Mon, 21 Sep 2009 10:34:49 +0100, Chris H <(E-Mail Removed)>
wrote:

>In message <(E-Mail Removed)>, Jon Kirwan
><(E-Mail Removed)> writes
>>On Sun, 20 Sep 2009 20:19:13 +0200, "Lodewicus Maas"
>><(E-Mail Removed)> 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.
>
>There are demo version of the Keil and IAR. Though I would suggest Keil
>in this case as a first stop. It is the one area where they really
>specialise.
>
>>And besides that, there is SDCC which you could also do
>>some trial compilations with.
>
>Not worth the effort. Start with Keil
><snip>
>Again not worth the effort. This is a lot of work for a system that will
>not even come close to Keil

I think it took me a half hour to follow the instructions.

>>here 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.
>
>The Atmel stuff will be set up to compile with the Keil extensions. You
>will have to port for the SDCC.

True. But it's been minor issues so far, in comparing them. Some of
the differences are talked about in the SiLabs appnote.

>BTW there are some very cheap dev kits with the 4K version of the Keil.
>However....
>
>The code size limit is not the killer here. It is the DATA space. As
>Keil does aggressive data overlaying in the DATA space you can get it to
>compiler programs that the SDCC can't get to fit in the space.
>
>I have seen cases where 119 bytes of DATA was compiled into 23 bytes of
>DATA space. So in that case the SDCC would run out of space and the 2K
>eval Keil will compile and run the app.
>
>That is without the optimisation of the code the Keil can do compared to
>the SDCC.
>
>Then there is the fact the Keil is VERY heavily tested compared to the
>SDCC and WILL do what it says.
>
>The you have the fact that most companies, like Atmel, write their code
>to be Keil compliant (not SDCC compliant)
>
>As Jon pointed out changing development teams can have an effect.
>Whereas the Keil has had a single team all the way though SDCC has AFAIK
>changed complete development teams several times.

The OP has yet to say what this is all about and money may yet be an
issue. Hard to say.

SDCC is probably not the direction to head if you are expecting the
kind of sole-source support phone numbers and email you get when you
lay down some cash. No doubt.

Jon

On Mon, 21 Sep 2009 10:24:59 +0100, Chris H <(E-Mail Removed)>
wrote:

>On Sun, 20 Sep 2009 19:24:32 GMT, Jon Kirwan <(E-Mail Removed)> wrote:
>
>>On Sun, 20 Sep 2009 16:18:42 +0100, Chris H <(E-Mail Removed)>
>>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.
>
>It was a recommendation from people who know you.

Obviously, not as well as you imagine. In any case, this whole thrust
of yours is little other than an attempt at being personal. Which is
exactly how you started with your responses here, again. Rather than
dealing with a direct question, the answer to which may help others if
you'd cared to.

Oh, well.

Jon