Quote:
Originally Posted by Alex.Norton
I haven't played with the new robot control system (last robot I worked on was 2007) so I don't know much about WPILib, however from the non hardware side of things, If your going to be rewriting the library to not be platform specific perhaps you should write the platform specific stuff in a platform independent library (only do the work once).
I realize that it adds another library that would be needed for development on any particular machine, but as example http://qt.nokia.com/products is a platform independent C++ library. There are versions for linux, and VsWorks and there are two different opensource licences that it can be used under.
just a thought,
--Alex |
Yeah, that was my thought as well. Via an O/S specific header and a glue library, you could make the WPILib fairly OS/platform agnostic. You'd probably have to watch out for the big endian/little endian thing, but that could be dealt with ala the way the network code handles it. If you define BIG_ENDIAN it does one thing, LITTLE_ENDIAN does another. However, I am concerned that we keep things to something that can be tested and verified to work for safety's sake if not for our own sanity.
Since we're limited to what the battery can supply, I'd be reluctant to jump on the Atom processor until the generation after next (Medfield?) due to power draw. The current Pineview draw is something like 2 watts compared to the ARM Cortex A8/A9 in the sub 500 milliwatt range.
Of course, using an Intel-based board makes it even easier to develop code for. But, I like the idea of using a cross-compiler because that's a lot of what embedded systems developers do in real life. It's nice to give the kids a taste of how the pros in the industry work.
Mike