Added an init string for SiRF receivers that will bring them back out of the binary mode configuration that AP_GPS_Auto sets them to.
Picked up the GPS logging format from the AP_GPS_Auto test.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1469 f9c3cf11-9bcb-44bc-f272-b75c42450872
Major new features:
- No RAM buffer for the NMEA message being parsed; saves 120 bytes of RAM.
- More robust parser, a little less likely to be confused by bad messages.
- Added configuration strings for SiRF, ublox and MediaTek GPS in NMEA mode to select just the messages of interest.
Note that the issue that TinyGPS has with co-ordinates with "different" numbers of decimal digits is addressed in this code.
Size is comparable to the old parser.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1468 f9c3cf11-9bcb-44bc-f272-b75c42450872
Otherwise, we can end up settling on NMEA as a mode just after switching a SiRF GPS to binary mode.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1467 f9c3cf11-9bcb-44bc-f272-b75c42450872
This is a partial workaround for not being able to use PSTR at global scope, e.g. in an argument to a constructor; it makes the intent of the otherwise somewhat bulky declaration of the string more obvious.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1464 f9c3cf11-9bcb-44bc-f272-b75c42450872
Add support for re-opening a port without changing the baudrate or buffer sizes. By passing zero for the parameters that aren't to be changed, code can reconfigure a port without needing to know how it was originally configured.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1462 f9c3cf11-9bcb-44bc-f272-b75c42450872
Increase the no-data timeout to slightly more than a second, so that GPS' with a 1Hz update rate don't cause problems.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1461 f9c3cf11-9bcb-44bc-f272-b75c42450872
Add a variant of AP_Float that stores the value as Q5.10 (16-bit fixed-point) to save EEPROM space.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1446 f9c3cf11-9bcb-44bc-f272-b75c42450872
AP_Vars with either a name or an address are 'interesting' (the latter so we can save_all).
Add the concept of address offsets to scopes. Now we have a container that we can put AP_Vars into that can be moved around in the EEPROM. This will make it easier for things like the PID library which need to support multiple instances getting their parameters from different parts of the ROM.
Improve documentation.
Suck it up and admit that we aren't going to do "identity"-based addressing for the EEPROM and just call the property "address".
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1417 f9c3cf11-9bcb-44bc-f272-b75c42450872
- Add a default ctor/dtor pair. The dtor ensures that all dtors are virtual, and guarantees that there is something in the dtor vtable slot for classes that don't implement their own.
- serialize must not alter the class, mark it const
- Improve documentation
- Fix handle validation to prevent trying to read 2 bytes beyond the end of memory
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1416 f9c3cf11-9bcb-44bc-f272-b75c42450872
The overriding principle here is to keep the use of AP_Vars as simple as possible, whilst letting the implementation do useful things behind the scenes. To that end, we define AP_Float, AP_Int8, AP_Int16 and AP_Int32. These are strongly typed, so that there is no ambiguity about what a variable "really" is.
The classes behave like the variables they are storing; you can use an AP_Float in most places you would use a regular float; you can add to it, multiply by it, etc. If it has been given an address in EEPROM you can load and save it.
Variables can be given names, and if they are named then they can be looked up. This allows e.g. a GCS or a test tool to find and traffic in variables that it may not explicitly know about.
AP_Var does not attempt to solve the problem of EEPROM address space management.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1399 f9c3cf11-9bcb-44bc-f272-b75c42450872
Most other consumers of the accel/gyro values should be asking us for them anyway. At that point, what they are getting are the values we sampled here.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1376 f9c3cf11-9bcb-44bc-f272-b75c42450872
DrZiplok@gmail.com
DrZiplok
rmackay9@yahoo.com
james.goppert
jasonshort