Now a variable belonging to a group can safely be constructed before the group it belongs to, and the group can be destroyed before its member variables. This greatly simplifies the AP_Var constructor(s).
Remove the lookup-by-index and lookup-by-key interfaces to AP_Var and replace them with first/next interfaces for all variables, and for variables belonging to a specific group. Document their usage. Add an accessor for the key associated with a variable so that search-by-key can be performed by a consumer. Throw away the lookup cache implementation, as it's not required anymore.
Re-layout the EEPROM variable header and tweak the EEPROM space allocator so that it's more resistant to interruptions during variable save.
Fix the global constants so that they work.
Add an interface for erasing all variables in EEPROM (only writes one byte).
Fix unit tests so that they work with the changed interfaces. Also tweak the unit test framework so that it doesn't inline all its code. This is a WIP - many more tests need to be written still.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1531 f9c3cf11-9bcb-44bc-f272-b75c42450872
Rather than implementing empty default constructors, make sure that AP_Var and friends have useful default constructors instead. This works around AP_Meta_class::meta_cast requiring a default constructor without having empty ctors scattered around.
Add accessors to AP_Var so that the global variable list can be traversed and the group/variable relationship comprehended by outsiders.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1523 f9c3cf11-9bcb-44bc-f272-b75c42450872
The format is a simple TLV format; a tag identifying the variable, a length for the variable, and then the actual data. This format could ultimately be extended to include waypoint/commands as well.
This allows us to load and save groups of variables to EEPROM without having to have a static EEPROM map.
Still needs unit tests and (probably) bugfixing.
git-svn-id: https://arducopter.googlecode.com/svn/trunk@1522 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
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
DrZiplok@gmail.com
DrZiplok
james.goppert