Better still, use 65536.  See reply #1

 

You've already posted a bitshift method that works, so why not use it?

It doesn't work.
It may do something, but it isn't correct.
It may help to see the problem if you write 32767 out in hex.

Dividing by 32767 'works good'?
That's where your problem is; your definition of 'good' is flawed.

No, Ian, I'm not, I'm just saying that the experience an AVR-based Forth offers may not be  the one you're craving.

Try to stick with C - it may yet just 'click'.

It iis easily the most scaleable language I've programmed in, from single device AVRs to mixed architecture CAT scanners with multiple CPUs and DSPs.

It means it works, but probably not in the original spirit of Forth, i.e its interactivity.

Early Forth machines were probably a little more symmetrical, or were even RAM-heavy, meaning applications could developed, the dictionary extended, and eventually commited to ROM.
Long names could easily mean that a RAM-based dictionary could be very rapidly exhausted.

I'd forgotten that Forth doesn't have type checking. Really not good.

Well, there's the RPN and the fact that it doesn't work terrifically well in a RAM-limited Harvard architecture.

I've likened learning to program to learning French - some people take a few classes, get as far as singing 'Sur le pont d'Avignon' and then pick up 'A la recherche du temps perdu' and wonder why they trip up on the first paragraph.
Actually, programming makes things worse by providing libraries, which are a bit like phrase-books, where you can use the language without understanding the principles - great for ordering a beer and croque monsieur, but useless for translating the Gettysburg Address (BT,DT).

Take the time to learn the basics; at least C doesn't have gender and irregular verbs!

You forgot IBM's attempt - PL/1, or  'when Algol metCOBOL'

Ian,
C was designed as a high-level assembler to aid porting, meant to be close to the machine.
It was never intended for the casual programmer - it would be like handing a loaded gun with the safety off to a toddler.
If there were a sensible cheap alternative, I'm sure it would have been offered for the Arduino.
I've programmed enough different architectures in more than enough assembly languages to know that I'm onto a good thing, and I don't want to go back.

If you want a readable book on C, skip K&R and look at Kelley and Pohl's A Book on C.
Don't ever read Stroupstrup (well, not the first edition anyway)

[edit]FWIW, English is a pretty crappily designed language, and if it weren't for the Yanks adopting it, I'm pretty sure we'd all be speaking French (who, after all, invented everything) or Mandarin. FORTH is good only for those who speak reverse Polish. Or double Dutch. Â

A define is simply a macro; you can apply casts if you like.
, though I don't see how it helps you achieve what you want.
A full implementation of sprintf is a bit OTT for the Arduino.

Somewhere there is an implementation of the more C++ like iostream, I'll see if I can find a link (on a train ATM)

You need to post the code for us to help.
Looks like you're almost there.

Well, yes there's that, and the 'r' wear due to 'can I reset myArduino by performing a call to the reset vector?'

This has got to be prime candidate for a sticky thread, hasn't it?
Pretty please.

Code:

rudderangleValue = map(rudderangleValue, -180, 1800, 0, 179);    

Is there a zero missing off that -180?

Can I ask why you're using SoftwareServo?