search

aakkkkii / aeroquad

Automatically exported from code.google.com/p/aeroquad
0 stars 0 forks source link

#define logic for forthcoming 2.1.3 Beta #75

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
General comments really, but it struck me today that we might want to do this.

a) the autodescend feature only works with the Altitude hold feature?  I'm not 
sure if this is true or not, but if so, these 2 defines probably need some 
define logic around them such that you can't define autodescent without 
altitude hold?

b) on the UNO/Due platform, either Mag *or* Alt can be defined, but not both, 
do we need to add #ifdef,#undef logic to support that?

c) do we allow a scenario where someone puts a 1.8 shield on a Mega processor 
board (it will fit just fine I believe.  They might do this to save weight as 
the Mega/2.0 combo is *very* heavy (heaviest of all the combinations).  If we 
allow it, today, you couldn't do it I don't think... well, maybe you could by 
defining the 1.8 but building with the Mega board selected in the IDE?  If this 
is a possibility, perhaps it should be *defined* or documented?

Alan

Original issue reported on code.google.com by akadam...@gmail.com on 7 Jan 2011 at 11:19

GoogleCodeExporter commented 8 years ago 
Alan, I vote to make the autodescend feature standard... we shouldn't disable 
it, it works very well.  At this point, I think the user needs to know they 
either/or can be selected... I plan to make user configs setup through the 
Configurator in the future (ie. build a Config.h on the fly), so let's leave 
this as they are for the time being.  I did this combo for the Mega/v1.7 
Shields.  To me it just made a lot of permutations in the code... I want to 
just match the v1.8 with the Uno and v2.0 for the Mega.  We have a new mini 
board on the way if folks want to go lighter.  THANKS!

Original comment by CaranchoEngineering@gmail.com on 9 Jan 2011 at 7:44