Developing/compiling software

In message , Meindert Sprang writes

And the Imagecraft AVR compiler will work with the 8051?

READ THE QUESTION

BTW there is no better 8051 compiler than Keil

AFAIK there is no gcc for 8051

In message , FreeRTOS info writes

There is no comparison between the SDCC and Keil

It's kind of an odd architecture (by current standards). Well suited for assembler coding. The bit-addressable registers (including I/O ports) avoid the need to, e.g., do a read-re/set-write sequence to twiddle a single flag. The external memory interface isn't all that common on uCs and can be used to address memory-mapped I/O peripherals (external synchro-digital converters, for example).

So, there's nothing intrinsically "wrong" with it, and it can be a very good fit for some projects. Just need to match the problem domain with the appropriate solution set.

Keil IAR and Tasking are professional tools Of the three the Keil is the best for 8051.

About 80$% of the professional market is Keil. The rest use IAR or Tasking with only a few using anything else

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

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

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

Not sure I agree with all that, but the Keil compiler seems pretty good and the ide is easy to live with. It's just so expensive. I guess not too bad if you can amortize the cost over several projects. Otoh, have been able to complete 2 small controllers with the Silabs kits well within the 4 K size limit, though neither were particularly complex. Also have an older Keil C, 5.1 iirc, that was bought for another project some years ago, but am told that there is no upgrade path and must pay the full price, yet again. Visions of bohica etc. It's a completely unlocked version as well, something we (the client in fact) paid extra for at the time.

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

Regards,

Chris

In message , Jon Kirwan writes

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.

In message , Jon Kirwan writes

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

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.

Get the eval version of the compiler.

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.

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

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.

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.

Now that's just you being sour and grumpy.

That, too.

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.

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.

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

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

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

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

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.

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.

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.

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.

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

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.

In message , Jon Kirwan writes

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

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

You made the point. I just clarified your FUD

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?

I know

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

I know who to have a s a referee.

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.

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

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 , Jon Kirwan writes

It was a recommendation from people who know you.