Compile Error

I would recommend that you upgrade to the full version and use floating point rather than that kludge.

That is NOT a kludge it is a recognized, accepted, apprecieated, well known, much used method when programming the '51 (and a few other architectures).

Whether or use it or not has nothing to do with eval or not, but whether to run or crawl the processor. I can find several professional '51 users that will avoid floating point at all cost.

If you do not like scaling, say so, but it is NOT a kludge.

That some "purists" that have absolutely no idea what is going on in the real world consider efficient programming that may not be straight out of a C book but adapted to the '51 a no-no is their problem.

Erik

I would recommend that you upgrade to the full version and use floating point rather than that kludge.

That is NOT a kludge it is a recognized, accepted, apprecieated, well known, much used method when programming the '51 (and a few other architectures).

Whether or use it or not has nothing to do with eval or not, but whether to run or crawl the processor. I can find several professional '51 users that will avoid floating point at all cost.

If you do not like scaling, say so, but it is NOT a kludge.

That some "purists" that have absolutely no idea what is going on in the real world consider efficient programming that may not be straight out of a C book but adapted to the '51 a no-no is their problem.

Erik

addition to the above:
If you have "all the time in the world" by all means use floating point (I do) but since this is about a servo (PID?) loop, the time consumed will "kill" you

Erik

I asked: "how (e.g RS232), and in which format (e.g. ASCII) do you send it to the servo motor control?"

you replied" I'm sending pulses(PWM) to the servo using one of the ports on the microcontroller. In order to control the servo, the pulse width will vary between 1ms and 2ms with an interval of 0.02ms."

Thewn, where does the floating point requirement come in? The PWM timer or PCA (if using timer, have a look at a PCA chip) is in microseconds anyhow. Just calculate all in, say, multiples of 10 microseconds instead of using seconds or milliseconds and all reasons for considering floating point disappear.

Erik

Thanks very much. I'll try that. Also, I think stefan was refering to the evaluation board as kludge and not the idea of scaling.
i'll let you know if i have any further problems.
cheers.
ade

"I can find several professional '51 users that will avoid floating point at all cost."

Failure to use the most appropriate tools is hardly a sign of professionalism.

"That is NOT a kludge"

Quoting from my dictionary:

'Kludge: A clumsy or inelegant solution to a problem.'

I think you'd have to agree that avoiding the use of a floating point library when a floating point calculation is required is both clumsy and inelegant. I fully appreciate that there are situations where it is not feasible to use floating point, but when it is feasible it would be foolish not to.

I think you'd have to agree that avoiding the use of a floating point library when a floating point calculation is required is both clumsy and inelegant

Who the #&!! cares about "elegant". The issue is reliable, fast and maintainable.

anyhow, I can agree that "the use of a floating point library when a floating point calculation is required" makes sense, the problem is that in ever so many cases when "a floating point calculation is not required" it is still used.

Erik

"Who the #&!! cares about "elegant". The issue is reliable, fast and maintainable."

I'm not sure how you define 'elegant', but here's an example of usage from my dictionary:

'an elegant mathematical solution--simple and precise and lucid'

which when paraphrased into a computing context appears to be pretty much what you want.

"anyhow, I can agree that "the use of a floating point library when a floating point calculation is required" makes sense, the problem is that in ever so many cases when "a floating point calculation is not required" it is still used."

Obviously, although I have an unfortunate feeling that we define 'required' differently in this case.

http://www.wordreference.com/definition/elegant defines elegant this way:
"refined or imposing in manner or appearance"

Please note "appearance", not "substance".

More crappy code has been turned out in the name of "elegance" that any other reason. The worst programmer I ever employed (I "inherited" him, I hope my interviewing skill are better than that) used the word "elegent" every time he presented his crap.

I note that you do not comment on "reliable, fast and maintainable." while harping on "elegant" so, evidently, you think that "elegant" is the most important - sorry.

Erik

when a floating point calculation is required

The point is that it almost never actually is required, and it shouldn't be. Let's see where requirements in embedded projects usually come from:

1) requirements of the product, as in "the final product must be able to do this"

2) requirements for the implementor, as in "the product must be constructed using methodology foo".

An embedded systems programmer who allows his customer to impose something like floating-point maths as a type-2) requirement would be comitting corporate suicide. As a type-1) requirement, floating-point arithmetic essentially never happens except in cases where the customer has no idea what he's talking about.

The smaller the CPU, the more likely it is that floating-point is a bad idea compared to fixed-point arithmetics (which was called "scaling" elsewhere in this thread).

"I note that you do not comment on "reliable, fast and maintainable." while harping on "elegant" so, evidently, you think that "elegant" is the most important - sorry."

Flippin' heck, re-read my post. What I basically said was that 'reliable, fast enough and maintainable' are encompassed in my understanding of the word 'elegant'.

You may find this hard to believe but I was pretty much agreeing with you!

"The point is that it almost never actually is required, and it shouldn't be."

Most of the stuff I work on requires a lot of floating point. It would be extremely difficult, if not impossible, and certainly pointless, to write and maintain a fixed point implementation.

"An embedded systems programmer who allows his customer to impose something like floating-point maths as a type-2) requirement would be comitting corporate suicide."

It'll only be 'corporate suicide' if the programmer in question isn't capable of assessing the impact of the customer requirement.

"As a type-1) requirement, floating-point arithmetic essentially never happens except in cases where the customer has no idea what he's talking about."

Not in my workplace. The only requirements our customers place on our product is that it works reliably.

"The smaller the CPU, the more likely it is that floating-point is a bad idea compared to fixed-point arithmetics"

You're quite correct in the general case. What irritates me is the assumption that the general case must always be extended to every case. For instance, there are many factors involved in selecting a processor for a job - inevitably it winds up being a compromise, so the processor isn't ideally suited for all of the tasks it is expected to do. This is the part where the brain has to be switched on to discover whether those compromises are reasonable or are going to create headaches later on.

We use certain 8051 derivatives for some very good reasons. The use of floating point does not have any negative impact on anything of importance - reliability, development time, maintainability etc, in fact, it has a positive impact on all those things.

Most of the stuff I work on requires a lot of floating point.
Have you had a look at come of the SILabs, e.g. some of the f12x they have a "SFR driven" MAC. ?

Erik

You may find this hard to believe but I was pretty much agreeing with you!
Not at all, I think we agree on many things.

Erik