Quote:
|
This is definately NOT a good engineering principle.
|
While that may be true, the programming part is quite a bit more forgiving - unlike forces on the robot and such, the program (if written well) will do the exact same thing every time - you don't have hostile robots crashing into your code. Generally, if it works in testing, it will work anywhere - and if it doesn't, well it's much more likely to be a bug than your code than your choice of variables. According to the IFI website, you have 1800 bytes of variable space. That's 225 double-precision (8 bytes, right?) variables. Granted, there is a bit of overhead associated with the default code - it has its own state variables and such - but even (just a wild guess) if it used 100 of those (which I'm pretty sure it comes nowhere near) that still leaves you with another 125 for your own use - quite enough for most people.
Quote:
|
The point is that if you know that something will cause a problem in the future, design your system in such a way that you never get yourself into that situation.
|
That's like saying that we know at some point we're going to lose a pushing match - so we'd better gear down all our motors 600:1 so that we can win it! At some point, you're losing more by doing that than if you do eventually run into that limit. I'm not saying that your point isn't reasonable - just that in this case convenience for the programmer may be more important.
Quote:
|
Wanna bet. If you get enough code running in your loop you can easilly get the RC to miss packets. Trust me, we've been there.
|
Actually, I've never seen this happen, even though we were running a few PID loops (yes, with floating-point numbers
) along with a few interrupts firing quite often to count motor revolutions. That's interesting that that would happen - I would have thought that as long as you hit the main loop at least every 26.2 ms you would be ok. Doesn't the master processor buffer the incoming radio data? If you do in fact need to hit that more often, than I may be completely and totally off.
Quote:
|
Also floats take up more program space, which is definately a valueable commodity.
|
We have (again according to IFI) 32k of program space. Again some of that is taken up by the default code and libraries and such, but even if you're left with only a few K of space, you're not likely to save enough to do anything significant with a few extra bytes here and there.
Of course, everything I've said goes right out the window as soon as you start using arrays and structs and such. In that case, you may be much better off using chars or bitpacking
I probably don't know enough about how IFI has this all set up to be totally right, but it seems to me that replacing variables which do in fact hold floating point values with integers just because it saves you a few bytes of space is worth it.