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 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?
"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++...
Lou; It still applies, "read the small print". The Keil tools are fully functional but offset the 4K and restricted to 4K of linked code. There are free 8051 tools for 'C' and 'Pascal' for the "standard" 8051 but I'm sure that you chose the Silabs device for some non-standard features. Without questioning your programming abilities and your 8051 experience, I challange you to write some simple programs for the Silabs device using some of the non-standard featues. Write in both 'C' and assembly. Use some of the examples such as 'Blinky', etc. I'll bet the stripped Keil tools will make better ASSEMBLY code for these devices than you can write until you get up the learning curve on the SiLabs "deviates" as Erik calls them. As you have probably discovered by now, the Silabs IDE and tools have a fully functional, no restrictions assembler for their devices. One other thing, I recommend that you download the eval versions from this website. The tools that come on the eval CD are several versions old. The eval versions will have the same 4K restrictions. No,I do not work for Keil. Al Bradfrod Bradford
I can't even spell my own name but I have an excuse. I'm typing with a broken hand. Bradford
Fully functional? Part of my "what crap" expression was also because I read somewhere in the last two days that Keil was limited to 2K/4K and the floating point, including trig functions, dont work.
So actually, it appeared that I had "crap". Bunch of misinformation or misunderstanding, I guess.
So far my little C program has consumed 3K of the 4K limitation so I am VERY dissappointed with the efficiencies I see so far.
With regards to Blinky, come on, it's just initializing a port, setting a loop for a timer, and toggling a bit. But then again I dont know what you mean by "stripped Keil tools" but I cant imagine they can do better. Yeh, I know, there are probably some registers that need to be set (ie clk registers) but that cant be much. Yea, and you're right, there's a learning curve with assembly and, for me, C.
BTW, I chose SiLab because it was cheap enough, had 12 bit A/D (2 channel), a UART, some I/O, and the plus was -40 to +125 deg operation, and small footprint. Built-in clk, too. Dont know if all that is standard or special but if someone can recommend something else I'll listen.
Thanks for pointing out the unlimited assembler. No, I hadn't discovered it but since I am sure I will exceed the 4K limit by tomorrow, I'll need it. Not even doing floating point or trig yet.
Have you modified the compilers optimization settings yet? As default, the compiler produces completely un-optimized (i.e. large and slow) code that's easy to debug.
The Keil evaluation limitations are here: http://www.keil.com/demo/limits.asp
Both the 2K limit and the lack of floating-point are clearly stated.
Your "little" C program doesn't use printf, does it?
printf is a very powerful and, therefore, very large function - it can easily eat up most of the demo code limit!
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.
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]
You may well find that a small program that occupies 3k written in 'C' would occupy 300 bytes an assembly. That doesn't mean that a 600 byte assembly program would occupy 6k in 'C'. If you don't understand why, ask and I'll explain.
Unless you are pushing your 8051 derivative to the limit in terms of code size or speed than 'C' is almost certainly a good choice. I would suggest you persist with it but you will have to accept that you will have to buy the real version of the toolchain.
The code size limit you are approaching is designed, for obvious reasons, to prevent you from doing any serious work with it.
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)
Erik
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.