I was hoping to find on-line manuals that I could print and read on the john. So far no luck. But what I really need is how to declare variables in C.
For example, I have a sample code that has the statement:
unsigned char
and
unsigned long
What do these mean and do they limit the declaration to integers. What do i declare if I want a floating point?
Also, someone told me I cant do floating point with a Keil Compiler because of licensing issues (I got my copy from Silicon Labs and have just registered it). I will eventually need to do trig functions. What do i have to get (buy) to complete my project?
You don't need an on-line manual, you need actual literature on the basics of C programming. The C51 compiler manual is not a substitute for a book about C, nor is it intended to be one.
K&R (i.e. "The C programming language" by B. W. Kernighan and D. M. Ritchie) has already been suggested, and I strongly second that recommendation. After all, it's _the_ book about C written by the guys who invented C in the first place.
I will eventually need to do trig functions.
Using trigonometric functions does not require use of floating point arithmetics. In fact, part of the skillset of an embedded developer is coming up with solutions that fit the capabilities of the target hardware - and the '51 is very much unsuited for floating point math (even though the C51 compiler will not try to keep the programmer from shooting himself in the foot there).
There are other solutions, like using lookup tables and interpolation.
The embedded developer should also have the skill to assess whether the use of a professionally written, optimised and debugged floating point math library such as that supplied with the C51 compiler would either positively or negatively impact his project.
Reinventing an already nicely developed wheel if not absolutely necessary would, frankly, be plain stupid.
I've been doing micro-controllers for 30+ years in assembly language. Sure, my experience is probably limited compared to you guys but give me a break. I admitted ignorance about C and ask for guidance and I create an argument?
That wasn't really an argument, more a lively discussion. The advice you got (get a copy of K&R and H&S) was spot on - it won't take long to get familiar with the basics of 'C' with K&R, H&S will answer any remaining questions you have.
I'd like to think I have the brains to figure out advantages vs disadvantages. Seems to me C was invented to get the job done fast and not efficient. My plans are, if needed, to optimize the code after the feasibility study.
I'd have said "C was invented to get the job done faster than assembly language and as efficiently as possible for a high level language".
Furthermore, from what I can tell, there must be better solutions than that offered by Keil, anyhow.
I'm not going to offer an opinion, but my impression from what I read is that Keil is probably the tool of choice if you wish to program the 8051 using 'C'.
I just bought the development package thru Silicon Labs and Keil doesn't want to support it and I am having difficulty ascertaining what I must spend to lift it's 4K limits.
From the sound of things you really bought a development board from Silicon Labs and it came with the trial version of the toolchain, or possibly a slightly enhanced trial version. You can't really expect to get a few thousand dollars worth of software for a hundred bucks.
Sharpening knives...
I'd like to think of it as Keil's loss. I'm going somewhere else if there is an option. I am sure there is an option. Like assembly language, lookup tables, and not Keil. Who needs to be part of the C community after this?
Anybody know of other development systems IO can consider to use with the Silicon Labs EVAL Kit? I've heard of http://www.avocetsystems.com.
Seems to me C was invented to get the job done fast and not efficient.
C was designed to be as close to the silicon as you can get without using assembly, actually. Hence, programs in C _can_ be very efficient.
Did you contact your local distributor of Keil products? He should be more than happy to provide you with a quote.
Well, how 'bout that. A fan.
Thanks for your comments. I'll have to put those in my scrapbook.
I'm at Renco Encoders now doing other strange stuff. Working on a real neat encoder solution. So simple I am surprised no one has thought of it. Well, maybe they have, I just cant uncover it.
Maybe I'll have one last hurrah before exiting ;)
In another forum there was a "which '51 compiler is bast" thread and several SDCC users stated "Keil is best" an IAR user stated "I think Keil is better". NONE stated that another product was better than Keil '51.
Erik
I'd like to think of it as Keil's loss. I'm going somewhere else if there is an option.
Hmmm. For someone with 30 years of experience in the field you seem to have an awfully light trigger. Running away like a startled deer, just because you witnessed a bit of banter among other users of the tool, and even "liking" that? Get real, mon.
I've been doing micro-controllers for 30+ years in assembly language. Sure, my experience is probably limited compared to you guys but give me a break.
On what basis should we have done that? Read your own OP again, slowly. What in there would make you guess that the author is anything other than a complete newbie on his first microcontroller project ever?
Calling that conclusion premature would be doing it an unjustified favour.
I am having difficulty ascertaining what I must spend to lift it's 4K limits. What crap.
crap? crap? I believe this is a feature of most commercial tool chains. what did you expect exactly? the source code along with the eval. binaries? and another thing: I also have expressed criticism here in the past regarding the tool chain and some of its extentions (FlashFS...) but you would not see me here calling it names like "crap". you give us a break - now often have you used the product to make sure a statement?
I meant: "such a statement?"
Sorry.
"crap" was referring the whole situation and not to the Keil product.
Perhaps my frustration should be directed towards Silicon Labs as they are the ones that sold me a development kit with a crippled Keil product.
Last embedded project I did, the manufacturer supplied the evaluation board and the development system (equivalent to Keil) all included for $79. Came with everything I needed to finish the project and we are in production. That is what I expected FROM SILICON LABS (emphasis - not shouting). I was wrong to blame Keil.
What I did not expect was the fight that insued herein because of my initial stupid questions, that, BTW, were promptly answered by the first poster.
I am sorry if I offended anybody. I am sure my comments could have been misinterpretted. I do favor assembly language over higher level languages and my comments about "waste" and "inefficiencies" are my opinion only and based on my beliefs. This was going to be my first C based project.
In my experience (only 25 years, I'm afraid), it is standard practice that the tools supplied with "dev kits" are just "evaluation" versions.
And free "evaluation" versions are always "crippled" in some way or another.
(in fact, I think the SiLabs kit gives you a slightly less limited version than the "standard" free evaluation?)
The exception is the single-source proprietary architectures like PIC and AVR - where the chip maker knows that the tools are useless with any chips other than their own. Therefore the tools can simply be considered as part of the marketing budget!
And free "evaluation" versions are always "crippled" in some way or another.<p>
"Ain't no such thing as a free lunch."
;)
And so we live in two different worlds. I have learned much. Thanks.
Good point. I said nothing about free. It cost me 79 buck-a-roos. ;)
and my comments about "waste" and "inefficiencies" are my opinion only and based on my beliefs. This was going to be my first C based project.
I think everybody moving from asm to C had such beliefs initially. After a while you learn that C is the way to go where nominal "waste and inefficiencies" do not matter and the percentage where (you think) it matters (and you write an assembly module) will be constantly shrinking, but - in my opinion, never go to zero.
"I think everybody moving from asm to C had such beliefs initially"
and it is interesting to see the same beliefs emerging in people moving from C to C++...
If it weren't for the fact that I suspect you have a rather rigid idea of what 'nominal' means I'd have congratulated you for taking a balanced view...
Yes. The conversation usually goes like this:
Have you used C++ on the 8051?
No! It's for PCs. Too slow. Too much overhead.
Have you actually tried it?
[silence]
Don't ignore the fact that the availability of C++ compilers is not so good for the 8051 chip - changing from a good C compiler to a bad C++ compiler can offset any tests.
But one thing with C++ is that virtual methods do not map well on the 8051.
Having established that certain standard features of 'C' don't map well onto the 8051, it should come as no surprise that certain of the additional, standard features of C++ also don't map well onto the 8051.
But, since the former didn't disqualify 'C' from being a valid tool for the 8051, I very much doubt that the latter necessarily disqualifies C++ as a valid tool for the 8051...
But it does very much depend upon the availability of a decent compiler...
If it weren't for the fact that I suspect you have a rather rigid idea of what 'nominal' means I'd have congratulated you for taking a balanced view... I'd say that the paragraph following 'nominal' says it all.
Yes, since i am in the "big volume league" I am not in favor of spending $1 more per unit of hardware to avoid a module or two being in assembler.
Of course, if you are in favor of the comfort of the coder (programmers need no 'comfort') then your attitude would be different and that fact that $1 (often many times over) can break or make a sale would be no concern of yours.
The most I have ever saved by writing an assembler module is $0.83 but that sold 860.000 units (you do the math)
Indeed.
I think the Ceibo offering translates C++ into C then compiles it with Keil, so perhaps all that is required is a decent translator, which may well be a rather easier thing to write than an optimising compiler. I don't know how much less 'efficient' the resulting object code is.
I think that the biggest problem here is that a user of a new tool (using C or C++) must spend time looking at the code, or at least have a very good knowledge how the language works internally together with a trust in the compiler vendors abilities.
It is so easy to look at a source code line that looks trivial, and assume that a trivial C or C++ source line must translate into similarly trivial assembler. But if the processor don't have any suitable instructions or addressing modes, major performance losses may be the result of the code.
Since C++ has operator overloading, virtual methods, ... it increases the probability that the compiler must work with pointers (cheap for most processors, but not a traditional 8051) and the amount of assembler code for a single C++ line may significantly increase.
In the end, the problem isn't with the tool but with the user. But sometimes it is better to warn people to not select a too sharp tool unless they are sharp enough to know how to use the tool.
Another thing is of course that most (all?) C++ compilers for 8051 only has a subset of C++. A fully compliant C++ RTL would require huge amounts of code and data, but the user would not really gain any advantages since a 8051 chip is not used for problems where all features are meaningful.
I'd say that the paragraph following 'nominal' says it all.
I read, and quoted, the one and only paragraph in your post.
"The most I have ever saved by writing an assembler module is $0.83 but that sold 860.000 units (you do the math)"
To compute the real net saving, we'd have to know the cost of writing the assembler; ie, the cost of the extra time that it took you to manually optimise it into assembler.
(I don't doubt that there was a real net saving)
Lou, I have had to get used to what has passed above. When you speak to people, phone or face to face, they suddenly become members of the human race. The days of PLM51 have sadly passed: now there was an elegant and efficient little compiler, but then it was designed by the guys who made the uCs (85, 51, 80, 88, 86/7, 186/7, 286/7, 386/7..... and you could port between them).
If the C bots could get rid of "unsigned character", when they mean "byte", allow base 2 in the source, and get rid of most of the darned braces I would be happy to meet 1/2 way. As it is C is the only show in town and all things to all men. I have had to learn to accept the compromises.
BTW does anyone know if there is a token I can use to create a NOOP instruction in C51 source code?
Some of what you said went over my head (ie PLM51).
Just an update. I have pretty much completed the project in assembly with maybe 1000 bytes of code (about 1/4 that required by C in my estimation) and it does it's conversion in 100us. This includes 32bit divide and is before I have implemented any optimizing - the code is *** code though that I strung together with my limited knowledge of the limited instruction set of the 8051. That's just my opinion, mind you. Evidently, there are many instructions not available on the 8051 that I found with other MCUs. Oh well.
I aint a pro but when I got a hold of a pdf version of the keil assembly manual via the black market (keil does not know one exists) I felt right at home.
I love assy. But, to be fair, doing the feasibility analysis (first attempt) in C was easy and worthwhile.
If you have 1000 bytes of ASM and 4000 bytes with C Either you are a master ASM programmer, or a Poor Embedded C programmer. That or are using a poor compiler.
Do not take it Personal. Coding for an a limited memory Embedded System is not the same as for the desk top. Embedded C programs get large because statements that produce a large amount of code look the same as those that do not. Like using int as a loop counter (less than 255). You would not use a 16 bit signed value in ASM, but many pepper their C code with it. Printing with printf() that is over a 1K right there. Large Memory model? Click And on and on.
Yes, it is a shame that Keil has stopped doing the '51 manuals as PDF documents.
:-(
http://www.keil.com/support/man/docs/c51/c51__nop_.htm
View all questions in Keil forum