Compile Error

Dear Erik,
Yes you are right, I'm using the evaluation board. I'm quite a novice and I'm just beginning to learn the tricks. If I may ask, what do you mean by scaling?
I have successfully used the below strategy to avoid floating point numbers. e.g representing 1.09 as 109/100.
I however need the result to be in floating point as the figure is supposed to be used to control a servo motor so I'll be using figures like 1.02, 1.14 e.t.c. Is there a way of solving this problem?

I however need the result to be in floating point as the figure is supposed to be used to control a servo motor
how (e.g RS232), and in which format (e.g. ASCII) do you send it to the servo motor control?

Erik

If I may ask, what do you mean by scaling?
I have successfully used the below strategy to avoid floating point numbers. e.g representing 1.09 as 109/100.
that IS "scaling"

Erik

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.

"I have successfully used the below strategy to avoid floating point numbers. e.g representing 1.09 as 109/100."

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

Contrary to what you may have heard there is absolutely no reason not to use floating point provided:

1) You have sufficient code space.
2) Your timing requirements do not prohibit it.

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.

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!