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!
In this instance, dismissing C++ out of academic principal I would say is narrow minded.
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 do not need to define narrow minded - Just use your favourite search engine.
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.
Ok, Mr Henry Ford wanted to make money but part of the dream was to give transport to the masses.
You do know about the dodge lawsuit, right? He was forced to continue to seek profit rather than divert it into more production to "help the masses." His dream was overrode by profit demands of being a corporation.
"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 ?
void main(void) { printf("Hello world!"); }
This is a "C" Compiler not a "C++" Compiler. And no they are not the same thing.
Interesting fact: When clicking on 8051 and looking at language standards, Embedded C++ is not mentioned. Only C.
When clicking on LPCxxx and looking at language standards, both C and Embedded C++ is mentioned.
Forget me for being stupid, but might a vendor who already have C and C++ support (even for 8-bit processors such as the Atmel AVR series) have considered the '51 chips not suited for C++ development?
Now, that would be shocking...
At the start I didn't realise about the precise differences in product capabilities.
But (contrary to some posters belief) I've learnt some things.
I now know that not only is C++ available it can also be practical.
What I find most bizarre is the attitude of some posters of this thread who assume to know what my precise requirements and desires are.
They then start bickering on about how limited Embedded C++ is etc etc etc.
Remember people, C is even more limited!
It is (and should always be) a case of using the tools that are most appropriate for the situation.
To those who have been helpful, I thank you.
To those who have been otherwise (and I would think you know who you are), stay in your box.
Did you try it out yourself, or did you conclude it from the advertisements of the compiler makers ?
If you had asked the question
"I want to program an 8051 and I want to do so in no other programming language than C++, please tell me which compiler to use.", this thread would have been about three or four postings long.
But you seem to prefer to keep everyone in the dark and guessing.
You also seem to like pseudonymous posters with a disposition to trolling more than people who actually post under their real name.
I believe you actually came here for fun instead of advice. Some people like ... heated discussions. Was it fun so far ?
"Did you try it out yourself, or did you conclude it from the advertisements of the compiler makers ?"
I have now downloaded, installed and successfully compiled a couple of simple C++ programs.
FYI, at the start of the thread I was (as I admitted) not aware of the nuances. I could not have been as precise as you think I should have been. But I have had a busy 24 hours and I think learnt a lot.
Heated discussions. Hmmm. I think an individual text area for a message is not long enough to describe my thoughts concerning some of the responses I have had on this thread.
Fun is definitely not a word I would use in this context!
FYI, at the start of the thread I was (as I admitted) not aware of the nuances.
Where did you admit to not knowing about the "nuances" between C and C++? As I read it, you expressed quite a lot of explicit irritation that you didn't got the "correct" answer.
Users with meaningful questions and reasonably polite behaviour do almost always get meaningful responses, and mostly in a polite way. The only irritating answers I use to see is a bit high percentage of bold-faced Please read the manual, which I think is too hard an initial answer and better reserved for repeat offenders. But people do get reasonable answers. If they expand their queries with more followup information, the answers are expanded to be more precise.
If a poster breaks his back to rub everyone backwards and complaining about stupid answers - because the answer wasn't the expected - then threads do go down the drain. You really entered this thread narrowminded and with a huge amount of attitude. Are you surprised at the outcome?
I was merely trying to point out the fact that 'experience' does not necessarily equal knowledge. You just happened to be the one who posted a particularly good example.
I'm curious - did you just pick a number out of thin air to try and make a point, or did you actually believe that printf() was at least 10k of code?
"Where did you admit to not knowing about the "nuances" between C and C++?"
He did finally admit it - Posted 20-Jun-2007 01:28: "At the start I didn't realise about the precise differences in product capabilities."
But that was after 2 days and several dozen posts of vehemently refusing to hear it!
Even now, he still doesn't seem to have grasped that the difference lies in the fact that C and C++ are different languages - it's not just a matter of "precise differences in product capabilities"!!
The interesting thing with printf - and you can see examples of it if you search this forum - is that the Keil tools are good at analyzing how you use it.
printf() can require linking of more or less code. In this case, you didn't actually perform any "formatting", so you got a minimalistic overhead.
The concept isn't new. Old MSDOS developers probably remember TurboC that constantly failed to print floating point numbers unless at least one floating point math function where referenced in the source. The MSDOS linkers didn't have enough information to know what formatting parameters that was used by printf.
You think so?
Integer formatting:
#include <stdio.h> void main(void) { int d=1; printf("Hello world %d\n",d); while(1); } 000003H 00035EH 00035CH BYTE UNIT CODE ?PR?PRINTF?PRINTF
No formatting:
#include <stdio.h> void main(void) { float f=1.0; printf("Hello world\n"); while(1); } 00051BH 000989H 00046FH BYTE UNIT CODE ?PR?PRINTF?PRINTF
Floating point formatting:
#include <stdio.h> void main(void) { float f=1.0; printf("Hello world %f\n",f); while(1); } 00051BH 000989H 00046FH BYTE UNIT CODE ?PR?PRINTF?PRINTF
Doesn't seem to be much analysis going on there.
"Doesn't seem to be much analysis going on there."
There is obviously sufficient analysis going on to allow it to omit a load of stuff if the program uses no floating point.
Presumably, if the program contains floating point and uses printf, the compiler cannot safely assume that there aren't any dynamically-created floating-point formats - so it just has to include them, just in case...
"There is obviously sufficient analysis going on to allow it to omit a load of stuff if the program uses no floating point."
From previous experience of Microsoft compiler technologies, I would say that it is not so much analyzing that the stuff can be omitted but rather that they should not be included.
Specifically - When floating point is required in a module, it makes reference(s) to any external functions that are required for the compiler chosen task.
At link time these external references would normally pull in the libraries that satisfy the external references.
So - It is not normally the formatting string of the printf that is interpreted by the compiler to determine whether the libraries that are included, but rather the fact that a floating point access is somewhere in the project.
Just curious, but how is C more limited than C++?
That's like saying that assembly is more limited than C. Or, that the Russian language is more limited than German.
Jon
Yes. But that doesn't require, or imply, any analysis of the printf() calls themselves.
Presumably, if the program contains floating point and uses printf, the compiler cannot safely assume that there aren't any dynamically-created floating-point formats - so it just has to include them, just in case.
Indeed.
The fact that you still call the difference between two separate programming languages a "nuance" is rather strong evidence that you're still just as unaware.
"Just curious, but how is C more limited than C++?"
C++ is (basically) a superset of C
Embedded C++ is (basically) a subset of C++
And Embedded C++ is (basically) a subset of C++
So, expressed in terms of facilities:
C < Embedded C++ < C++
I said it is more limited purely because it is considered to be lower level, less abstract etc
So it could be extended to the expression:
Assembler < C < Embedded C++ < C++
The extrapolation to "Russian is more limited than German" is clearly wrong.
But everyone knows that Esperanto is superior to all others ;)
View all questions in Keil forum