We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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!"; }
The ceibo might do it if I spend a few thousand bucks, but I cannot test it out on my complex one line program because it uses the Keil C compiler -
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.
There's no need to use sarcastic bold letter. Any program that uses a string formatting function _is_ large and complex for a simple 8-bit microcontroller as the 8051.
This raises the question if Keil C cannot do it, why does Ceibo come bundled with it?
Because one way of compiling C++ programs is to use C as an intermediate step.
So a C++ compiler might translate a C++ program into a C program, and then a C compiler can be used to translate this C program to assembly. I would guess that this is the way Ceibo does it - this way they don't need to make their own C compiler (and they'll have a hard time trying to beat Keil or any of the other existing solutions).
Anyway, I need to know of alternatives and not just get you can,t do it style comments.
If you had actually bothered to fully read the comments, you would have noticed several alternatives already. But I'll give you the list.
1. (this is not an alternative, but a prerequisite) Learn to extract useful information from human-readable text instead of being rude to the people who are, in fact, trying to help you. Use this skill to inform yourself about the particularities of the 8051 architecture (by reading the appropriate datasheets and the hardware documentation) and why C++ might not be a good language choice for this type of device. 2. Switch to a programming language that is more appropriate for a small device such as a 8051-type microcontroller. Plain C would be one such language. Your simple program would stay "simple", i.e. one line. (By the way, since you're trying to print text - where should the microcontroller output this text ? I did not see any intialization of an output device, for example a serial port)
Can the SDCC compiler do it? It,s based on GNU tools I think so can I use the GNU C++ with that?
I wouldn't think so. To make C usable on a 8051-type device, quite a few extensions need to be added to the C compiler. GNU C++ will not know these extensions. You may feel free to modify the GNU C++ compiler to your needs, however. It is free software, after all.
Here's a couple of alternatives:
#1 - Go ahead with your plan to modify SDCC and the GCC compiler chain to produce 8051 C++ code.
#2 - Consider a way of working around the 4K limit of the demo compiler. Maybe split your program into 2 or more blocks each being small enough to produce an executable less than 4K. Not sure how you'd split your one line program up though.
But, be warned, I (and probably most) would consider neither to be practical.
Alternative: Can't you switch to C? Do you really need C++?
-- J
Ok guys,
Looks like I'm not getting through to you here!
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.
hopeless issue
if (s)he does not understand the difference between C and C++ what will the next question be?
Of course, is a major fault of the '51 that is is good at what it is designed for and not for what the OP wants. YES, fault of the '51, not 'fault to the toolmakers', trying to make the '51 execute C++ bloatware is even more ridiculous than supporting function pointers/malloc etc. At least they (except ceibo) stopped there.
The ceibo product is NOT a C++ compiler, it is a C++ to C converter.
Erik
Well, you've discounted the hints and opinions of several experienced developers. I think the issue of who isn't getting through to whom is acutally reversed.
Well, it's not like you completely left us guessing at what the requirements were, right ?
Well, why didn't you say so ?
If your contract doesn't explicitly state that C++ must be used, then you are free to use a much, much more appropriate language for the microcontroller in question, such as C.
And after you have made this decision, you can proceed to the real time-consuming parts of your task. Like reading the datasheets of the keypad and the display and write the appropriate code so your '51 can actually communicate with these devices (no, your compiler won't do that for you. It knows exactly nothing about the peripherals attached to your MCU. May, if you're really lucky, you can find libraries, but I wouldn't count on it).
"Looks like I'm not getting through to you here!"
On the contrary - it's the return path to you that isn't working.
You seem totally unable to understand that C and C++ are different programming languages.
"You make these comments without knowledge or appreciation of the requirement."
nobody can know your requirement if you haven't stated it!
"My contract requires me to produce code for an 8052 controller board that has a keypad and a display."
I see no requirement there to use C++
Where is the requirement that the programming language used must be C++ ??
"I need serious options please."
Why do you not consider writing in 'C' to be a serious option?
However, if you do have a bona-fide commercial requirement for an 8051 C++ compiler, you should speak directly to the people at Keil and/or Ceibo and see if you can negotiate terms on a suitable evaluation...
Also, Hitex used to offer short-term licences for the full Keil toolchain (still C-only, remember) - I don't know if they still do; you can ask them: http://www.hitex.co.uk/
How many projects of this type have you done?
Quite a number of people on this forum have made quite a number of similar projects - each.
Are you really sure that it is you who isn't going through to us, and not the reverse.
As I already said in an earlier post. You are the kind of person who repeats a question until someone gives an answer you like. If the answer is wrong, is not important. When you hear the answer you like, you will go ahead.
Right now you are standing at the edge of a deep gorge. People are suggesting that you should step away from the edge, but since you like the beautiful red morning sky on the other side of the gorge, you are waiting until someone suggests that walking into the sunrise is a good idea.
Are you using your real name for these posts? Are you working on getting a wikipedia or Oxford English Dictionary entry with your name on it?
Maybe you want "define: stupidity" on google should give a link to this thread?
Hard words? Well, it is better if we use some very explicit words now, before you have started your doom project. Right now, it is only a question of lost face. A couple of weeks or months from now, it will be a question of quite a lot of lost money and significant customer badwill.
"Where is the requirement that the programming language used must be C++ ??"
I'm a C++ programmer. I write programs in C++. If I am to write a program, then the optimum path will be in C++.
"I'm a C++ programmer. I write programs in C++."
What sprang to mind when I read this was:
I think C++, therefore I am C++.
I'm a C++ programmer.
In that case, you should also know C, since it is a subset of C++.
And even if you don't know C - if you really are a programmer, you should be able to learn it in a few days. Otherwise, you're just someone who writes code.
If I am to write a program, then the optimum path will be in C++.
... and if you have a big enough hammer, every problem will look like a nail, right ?
A programmer should know that there is such a thing as "the right tool for the job", and be able to select the right tool and learn to use it.
Would you do web development in C++ (instead of php or perl) ? Would you program a DSP in C++ (even though the compiler doesn't know 60% of the instruction set and will therefore produce abysmally slow code) ? Would you program huge numeric simulations in C++ (instead of Fortran) ? Would you program an operating system in C++ (instead of a mix of C and assembly) ? Would you program a portable web application in C++ (instead of Java) ? Would you program a customizable game UI in C++ (instead of LUA) ?
C++ is not the right tool for the job "Write a program for an 8051".
I have produced at least 7 digits of C++ code lines, so I like to think of myself as a C++ programmer.
I would not try a C++ program on a '51, because I know enough of C++ and the '51 architecture to know that it would not be advantageous to me - or to a customer.
Exactly how much embedded programming have you done? Do you really have enough experience that you can afford to ignore unanimous comments pointing in a different direction?
Are you willing to post your customers contact information here - so we can get in contact with them when they need a new supplier of the product? Right now, you are not heading in a direction what will lead to a working product.
Being a consultant means that you have to spend a significant time listening. First listening to the customer requirements. Then listening if there are existing solutions that can result in short development times and a well working product. Then listening to the feedback of the end users, so that you can suggest how to improve the product.
Were you as "goood" at listening to the customer requirements as you are at listening to the suggestions you receive here?
"I'm a C++ programmer. I write programs in C++. If I am to write a program, then the optimum path will be in C++."
Ah - so it's not a requirement that the code be C++, then? That is just your preferred implementation
Although using the language that you know (C++) could well be the quickest route to get the code written, it may well not be the "optimum path" for the overall project:
eg, if you write C++ code (especially if you write it as you write for a PC), you can easily end up with grossly inflated memory requirements - which will increase the cost of each unit shipped. If you're only going to ship a few units, this probably won't matter; but, if you're going to ship millions, it would probably be better for the overall project to spend the extra development time writing lean-and-mean code (probably in C rather than C++; possibly even in assembler) and save on the cost of each and every unit shipped.
On the other hand, if the target hardware is already defined, you are going to have to work within its available parameters - which may or may not be sufficient for an application written in C++...
Ok,
The general view from this forum is that C++ an the 8052 don't mix.
Well, why do Ceibo have a product to do what you have been saying is not suitable?
I assume that they do have customers for such a product otherwise they would be out of business - Right?
So either they are wrong or you are wrong.
I think it is the product to try. It's just that I think the cost is too much. Maybe I won,t be able to afford such a big turkey this year ;)
Because there is a demeand from 'customers' that do not know better
Based on your posts I am confident that you have no idea of the '51 architecture (VERY fastidious statement: real programmers do not care about such details) so, to you, the '51 is "just another processor that you do not need to know".
This has nothing to do with C++, but with "real programmers". I was asked to help on implementing code banking (allowing a '51 program to be more than 64 k) by a company that had hired "real programmers" who, of course, started out with a 'great' OS and multitasked even the simplest operations. I had a look and redid the whole shebang to working code that fit in 8k.
there is no universal language, there is no universal processor some companies make money from those that believe it is so. And eveidently that will happen again. Have fun till you see your mistake.
You are the type of guy who decides that if something exists, it must be good and should be used.
You would want Vista in your mobile phone, just because Vista is the latest and greatest from M$.
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.
You can emulate DirectX in software - without any 3D hardware. Such functions exist. Does that mean that it is a good idea to try a firt-person-shooter game without a 3D graphics card? Do you really think it will work well with 0.1 frames/second?
A company may have invested a lot of time into a number of thousand lines of very complex C++ code that they just desperately has to convert to the '51 environment. In that case, it might be an idea to make a one-time conversion from C++ to C and then manually clean up the code to normal C, block by block. I say may - but only if the C++ front-end generates C code that is possible to maintain on it's own.
Why do I get the feeling that you are carefully avoiding the qustion about any existing knowledge of embedded development?