I,ve installed the Compiler and I can,t get even the simplest code to compile properely.
Anyone know where the fix for this bug is?
Or is it a limit of the demonstration version?
void main(void) { cout << "Hello world!"; }
what is it the compileer you installled?
keil c????
if you be answer keil c then code you give is bad and not compiler
you code is c++ but compile is c
c not thinking about cout like this you be not good and give errror
Can someone answer my question in English please!
"Ok,
The general view from this forum is that C++ an the 8052 don't mix."
Filip,
Their real statement is somewhat more basic than that, but may not quite have gotten through. When you're programming for an "embedded" processor, various assumptions that are easy-to-make and almost guaranteed to be "correct" in a desktop environment cease to make any sense. Imagine this situation: Someone could have an 8052 based system that has all of the following:
1. A large LED bar sign that can scroll text 2. A small LCD display 3. A serial port
All of these bits of hardware could be considered the "console" referred to by cout. Which one is appropriate? Further, what code should be generated to control one of them when you use "cout <<"? These are the kinds of things that have to be considered in an embedded project.
I will make a prediction: If you buy the Ceibo package, it will have no idea how to compile "cout <<" unless you customize some library or at least tell it in detail what type of display and controller chip are attached to your board and where.
-Jay Daniel
"either they are wrong or you are wrong"
Of course, it's not as simple as that!
Every rule has its exceptions, and every market has a niche where the specific conditions mean that the general rules require a different interpretation.
You came here without even understanding that there is any difference between C and C++ - do you not think that there are probably plenty more issues of which you are not (yet) aware, but of which others here will have extensive experience...?
As Per says, "Why do I get the feeling that you are carefully avoiding the question about any existing knowledge of embedded development?"
"TV Shop has a huge number of products that exists, but are no good. The world is full of products that exists because it is possible to make them, not because they solve a problem people want to have solved. Not because they actually works."
Have you never heard the term, "Snake Oil"...?
en.wikipedia.org/.../Snake_oil
You guys REALLY don't get it!
I've now noticed that IAR produce a C/C++ compiler for the 8051.
So that's two products I've found that do what you people say shouldn't be done!
Someone in those companies must have seen an opportunity to fill the need for C++ on the 8051.
Maybe, just maybe, for some projects it would be a quick way of getting the job done.
I'll have a look on the IAR forum. Who knows, it may even have people on that one who have slightly less narrow minded views.
I think you don't understand what companies do.
Companies don't exist to fill needs.
Companies do exist to make money, by making products that there is a market for. It does not matter whether the product is necessary, useful or sensible. The only thing that matters is that there are people who will pay for it (or that can be talked into paying for it). In fact, there are many, many necessary, useful and sensible products that do not get made because there aren't enough people that can pay for them.
If you had read this thread, then you would have already seen a mention of the one scenario where such a compiler makes sense - when there is an existing, large code base that needs to be run on an 8051 without porting it to a more appropriate language.
Also, you could already be halfway done with your project if you had taken advice from experienced embedded developers, instead of arguing with them. Or at least you could have read the specs of your hardware. Simply using cout and expecting text to magically appear on your display makes me believe that you expect your 8051 to work like a PC. It doesn't.
Who knows, it may even have people on that one who have slightly less narrow minded views.
"I know only C++, so any problem must be solved in C++" isn't narrow-minded ?
All the other people on this thread also know C++. They know C. They know assembly. They know the hardware architecture of the 8051. They have a broad perspective and know that and why C++ is not the right tool for simple 8-bit devices.
Anyway, good luck at what you're trying to do. You'll need it.
You seem to think that C++ with virtual methods is good. The 8051 chips hates function pointers, and a virtual method is a form of a function ponter.
You seem to think that object-orientation with dynamically created objects is good. The 8051 has too little memory to work with dynamic memory. Even if you can implement it, you run a large risk of failing because of memory fragmentation. So forget new/delete.
You probably haven't realized that the '51 chips are TRUE 8-bit chips. They are not 16-bit chips with an 8-bit bus like the 8088 was on the original PC, more than 20 years ago. The register size is smaller than the short or int data types, so you don't have atomic add/sub/mul/div. How much code do you think a software div contains?
The processor doesn't have a file system, so forget about file streams.
The target doesn't have an OS, and the processor are just minimally able to host a minimal OS. So forget about threads or tasks.
There is no driver layer. Every single hardware peripherial needs bit-fiddling code to function. Code written by you. Or written and uploaded by narrow minded old fools who doesn't know that C++ has come to town.
The processor contains true boolean variables. But the variables are not actually boolean true/false, but actually on/off.
The processor requires special language extensions for tagging of variables to inform in which memory areas they should be stored.
The application has to settle for using a subset of the C runtime library. A huge number of the C library doesn't make sens. A even huger part of the C++ standard libraries makes sens - or can even be used - on a '51 platform.
You have no experience of embedded development, but instead of listening, you think everyone is narrow-minded.
You are the drunk who stands on a rooftop and claims you can fly.
The problem is that you claim that you know C++, but your posts gives very clear indications that you do not actually know so much about C++. You do not seem to know what makes C++ ticks - what it looks like under the hood. For embedded programming on this scale, you have to know the inner workings. Programming on a macro scale does not work.
So you get a C++ compiler. You then have to use the C++ compiler to write a mostly C-ish program, because most of the C++ concepts and libraries are not available. Who do you expect to fool with that?
You have still totally missed the point. The people who are on this forum have already got things done. We are not arguing based on "maybe" or "i like to" or "it would be good to". We are arguing based on existing products available all around you. Real, physical, working factory-produced products.
"Companies don't exist to fill needs."
What a cynical view of life!
Ok, Mr Henry Ford wanted to make money but part of the dream was to give transport to the masses.
Part of marketing is understanding what people want!
I want to use C++ because I know C++.
I say that in the same way that I said I want a response in English. It is because I talk English!
To do something you are familiar with is quicker than doing something totally foreign.
To think knowledge in one area of life is directly applicable to other areas of life is not faster. It's just plain dumb!
Not knowing the relationship between C and C++ questions your C++ knowledge.
To think companies focuses on customer needs instead of what makes money is naive.
Have you picked up the phone and called IAR? Do they recommend C or C++ for a '51 target? Have you asked how much of the C++ concepts and libraries you can actually use?
Have you prepared critical questions to ask them, or do you make your neck as long as possible and tells your suppliers: please put a noose around my neck - I'm gullible?
This isn't about what you know - but what you don't know. If you focus your life around what you know, you will never grow. Right now you are a man with a hammer, desperately seeing everything as a nail.
Please define narrowminded...
I said PART of marketing I said PART of the dream
Surely you would agree that it is always better to build upon what you know rather than always going for something different.
A skyscraper is built of same style blocks one upon another. If they were all different then the structure almost certainly wouldn't stand!
I do not need to define narrow minded - Just use your favourite search engine.
In this instance, dismissing C++ out of academic principal I would say is narrow minded.
Of course. I would even say that all of marketing is understanding what people will want to buy, or what they can be made want to buy. It is all about business - if people will pay for it, then is is economically sensible for a company to make.
That, of course, does not mean at all that the product has to be technically sensible. What the customer does with the product does not concern the company, as long as they get paid.
We've already discussed this: If you know C++, then you also know C (if you do not know C, please stop claiming that you know C++).
I am sorry, but the hardware you have to work with isn't going to accomodate your wishes. Humans have this capability called "learning", while your hardware can only be used as-is, or replaced completely.
The concepts of C++ are totally foreign to your 8051. That is precisely why is does not make sense to try programming it in C++.
Hello ? The other posters on this thread are experienced embedded developers. That means they have already written code for real-life projects that are being sold on the market. Their views and opinions stem from years of practical, hands-on experience with the 8051 architecture.
The person who has a purely academic point of view is you.
sir filip
you be needing project work soon?
i help you please
i say send info and i see what to do for work
if working c then you think be happy yes??
I know what it means. I'm just very curious to know what you think it means.
It is an academcial goal to use as high-level language as possible for all development. It a practical rule to not use a higher-level tool than the target can handle in a good way. You call our arguments academical???
Many of us _are_ experienced C++ developers, which is something you seems to constantly ignore.
Don't you wonder just a little bit why I claim to be an experienced C++ developer, and still says that C is a better language to use for a '51 chip?
Don't you get a feeling that there _may_ be parts of the equation that you haven't seen yet?
How long was it since you left school?
How many real projects (embedded or not) have you worked with?
Haven't you noticed that real projects tend to have a large number of mutually exclusive requests - something that didn't exist in school assignments. In real projects, you always have to compromise!
"I do not need to define narrow minded - Just use your favourite search engine"
Just tried doing a search for that on my favourite search engine and got nothing!?
Trouble is, my favourite search engine is http://www.booble.com ;)
Maybe you should have been more specific.
I noticed the following comment upthread:
As I have said before: The problem you are going to run into if you use the Ceibo + Keil combination is that the evaluation version of Keil C51 only allows a code size of 4 kB. Any complex string formatting function (this includes printf and cout) will easily need upwards of 10 kB code space.
Compiling the following program with a recent version of C51:
#include <stdio.h> void main(void) { printf("Hello world\n"); while(1); }
Gave the following map:
BASE START END USED MEMORY CLASS ========================================================== X:000000H X:000000H X:007FFFH XDATA X:000000H X:000000H X:007FFFH HDATA C:000000H C:000000H C:007FFFH 000438H CODE C:000000H C:000000H C:007FFFH CONST C:000000H C:000000H C:007FFFH ECODE B00:0000H C:000000H C:007FFFH HCONST I:000000H I:000000H I:0000FFH 000001H IDATA I:000000H I:000000H I:00007FH 00001CH DATA I:000020H.0 I:000020H.0 I:00002FH.7 000001H.1 BIT
And in particular:
000003H 00035EH 00035CH BYTE UNIT CODE ?PR?PRINTF?PRINTF
Which shows the original statement to be out by more than an order of magnitude.
Presuming the person who made this statement is reasonably familiar with C51, how are we supposed to have any confidence in the commentary on the unsuitability of C++ when it would appear that none of the contributors have actually used any of the available implementations? Should we assume that their 'experience' really is sufficient?
If I am wrong in my assumption that none of the contributors to this thread have used C++ on an 8051 please do correct me. If you can provide any actual data to support the hypothesis that C++ is a non-starter on an 8051 I would be genuinely interested.
Jack,
Finally someone responds with a positive point of view :)
Up to that time all responses have been leaning towards the "I know better than you because I've got experience" style.
What there seems to have been lacking is the desire to try something that they are unfamiliar with.
The words new, dog, tricks and old in a different order seem to be appropriate for some here.
Note that JS showed an example saying that the Keil C compiler + linker (the buggy tool you have been recommended to use) is quite good.
That should not be extrapolated into believing that the '51 is a processor well suited to C++.
There is still problems with dyanmic memory, virtual methods, templated code etc.
I did not say, nor have I assumed, that the 8051 is well suited to C++.
I am hoping (and increasingly believing) that it CAN be successfully used.
Some investigation I have done has revealed that there is even a Java VM that runs on a derivative (the Dallas 80C400).
Java is interpreted, C++ is compiled. Both have the problems that you mention.
So if (yet another) supplier provides tools for such a high level language to be used, it implies that there are requirements that can be satisfied with such tools.
"Some investigation I have done has revealed that there is even a Java VM that runs on a derivative (the Dallas 80C400)."
True.
"TINI is available online at TINI Store for $67.00 which includes 1 MByte SRAM and 512 KBytes of Flash ROM."
Tiny footprint...
At this point I can contribute some real-life experience.
I have developed a couple of applications using Java on the Dallas 80C400 - Their name for the technology is TINI.
I had previously done a lot of work (more than 15 years worth) primarily in assembler and C on 8051 and V55 cores.
TINI was my first attempt of using such a high level language on the 8051 derivative (albeit a vastly souped-up one).
The result - The projects were written in time, to cost and within the constraints laid down by the hardware.
Fortunately, they were not time critical applications and they performed their function adequately and (most importantly) within specification requirements.
Then came another project.
The management wanted me to use the same basic platform; i.e., the 80C400 with TINI. Knowing what the project entailed, I was reluctant to us TINI on this project but I had my orders and decided to go along with the decision.
It very quickly became apparent that the setup just was not man enough for the job. I decided (unknown to the management at that time) to rewrite the application in C.
The result was that the application ran some 400 time faster in various critical sections than the equivalent TINI code. Yes, I do actually mean 400 times faster!
Fortunately (for me), the management agreed that I had made the right decision.
So ... my advice is this:
Yes you CAN consider and use C, C++, JAVA or any other high level language, but please also consider whether the resultant application is going to work in a satisfactory and acceptable manner for the customer.
Ok,
It's becoming clear that I can write on the 8051 in C++.
It may be inefficient code and need more resources than code which others write. But if I can write an application quickly with the confidence brought about by using tools I know then it should be worth the wrath of some forum members.
I don't understand why there are some guys that are so negative about certain suggestions.
"I don't understand why there are some guys that are so negative about certain suggestions."
Trying to compile C++ with a C compiler:
I,ve installed the Compiler and I can,t get even the simplest code to compile properely. Anyone know where the fix for this bug is?
On receiving an answer that it is a C compiler:
On experience with embedded compilers:
Why is the demonstration version so limited? It looks very weak! Microsofts free compiler can do so much more!
On receiving a good description of the problem, a note that the M$ compiler can't build for the '51 target, and that the C51 can't build C++ and that a trivial change to the code (to make it C code) would make the example buildable:
Someone give a more positive (and helpful) response please!
After having received a number of descriptions that C and C++ are different languages:
Why have a demo version that won,t compile my simple program?
After receiving a further note that C and C++ are different languages, and that a C compiler just can't compile C++:
Anyway, I need to know of alternatives and not just get you can,t do it style comments.
On the question: Can't you switch to C? Do you really need C++?
You make these comments without knowledge or appreciation of the requirement. My contract requires me to produce code for an 8052 controller board that has a keypad and a display. I need serious options please.
This implies that the chip 8052, or the keypad or the display is a direct implication why C++ is a requirement and not an option. It also implies that the answers you have received are not serious.
After receiving a number of notes that C++ are not the best of languages for the lowest end of microcontrollers, you translate unsuitable into impossible:
The general view from this forum is that C++ an the 8052 don't mix.
From then on, it's not meaningful to follow the thread anymore.
As you can (probably not) see, you entered this thread in a very narrow-minded way. The perfect way of entering a forum and ask questions...
It's becoming clear that I can write on the 8051 in C++
It's becoming clear now ? I mentioned that there are C++ compilers (not free, neither beer nor speech) in my posting yesterday. Along with the fact that Keil C51 is not a C++ compiler, and that what you considered a "bug" was actually a lack of reading and understanding the documentation.
It took a while to get through ?
No. It's become overabundantly clear that you believe you can use C++ on an 8051. Now that was pretty evident from the beginning, but that didn't keep you from stressing this point at every opportunity.
But if I can write an application quickly
If you can do it. But there has been negligible evidence that you really understand the task you're so convinced you're capable of completing. Instead you blame every failure of your attempts at implementing your ideas on others --- the tools, their makers, the people in this forum. Something and somebody must obviously be faulty, incompetent and/or "academic", as long as you can deny it might be your fault. In my country this attitude is usually summarized by an old adage: If the farmer can't swim, his swim trunks are at fault.
with the confidence brought about by using tools I know
... except that you rather evidently don't know the tools relevant to the job at hand.
then it should be worth the wrath of some forum members.
You're mistaken if you think what's being directed at you qualifies as wrath. It's more like commiseration, for now.
Indeed, you don't understand. But you're wrong about what it is you don't understand. You utterly fail to grasp the idea that people telling you that your suggestions are bad might be doing so not because they're "negative", but because their experience taught them.
While pretending to ask a question, you really came here with a prejudice expecting people to provide arguments supporting it. But then something happened that you hadn't contemplated before: people gave you answers that disagreed with your pre-set opinion. Well, guess what, that's one of the consequences of asking a question: you lose the right not to have to listen to answers you don't like.
Wisdom comes not from asking questions, but from actually listening to answers.
The problem you are going to run into if you use the Ceibo + Keil and you reply
void main(void) { printf("Hello world\n"); while(1); }
where does the Ceibo C++ come in, in the above mr smokied sardine
Erik
void main(void) { printf("Hello world\n");
while(1); }
Oh dear, here we go again.
I quoted two sentences as follows:
You snipped this down to half a sentence:
The problem you are going to run into if you use the Ceibo + Keil
Thereby removing all the content I was actually replying to.
You then quoted part of my response, this time snipping out all the text that gave meaning to the code snippet.
Go back and read my post again. If you still do not understand it let me know and I will explain it to you in whatever level of detail is necessary.
I do not give a hoot about your post, the subject of this thread is NOT that printf works in C, which we all know, but C++ on the '51.
Erik,
I think in this case you really have missed Jack's point. He was showing the m51 file to indicate the using printf() in Keil didn't increase the code by 10kB, but rather by 1kBish which was an order-of-magnitude less "badness" than the original statement. It had nothing to do with C++, but was just continuing illustration of what he sees as bad in the responses on this forum -- namely that sometimes the estimates people provide from experience can be exaggerated and overly-emphatic.
Also, just as a point of reference for your future usage: The name he's chosen (Jack Sprat) doesn't have anything to do with sardines. It's from an old nursery-rhyme (though I don't know it's origin) that begins like this: "Jack Sprat could eat no fat. His wife could eat no lean."
Also, just as a point of reference for your future usage: The name he's chosen (Jack Sprat) doesn't have anything to do with sardines.
I know that, but sardines are canned :)
"[Jack Sprat] was showing the m51 file to indicate the using printf() in Keil didn't increase the code by 10kB, but rather by 1kBish"
But did it show that?
It showed that the size of ?PR?PRINTF?PRINTF is 1K-ish, but it doesn't consider what other stuff may also get pulled-in as a result of having printf that wouldn't other wise have been included.
I haven't had the time for a detailed look at the map file, but the summary line from building a simple "Hello, world" example as shown indicates that the total CODE space usage is on the order of 2K...
It probably also varies with the Memory Model chosen...
So: still not 10K, but it certainly does show that a simple printf can easily use up virtually the whole CODE size limitation of the Evaluation version...!
View all questions in Keil forum