herolic / aeroquad

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

Add some debug printouts to the setup() function #77

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Two simple debug printouts at the begin and end of setup() like
Serial.begin(BAUD);
Serial.print("setup ");
...
Serial.println("done");
would help to debug typical startup problems of new boards.

Original issue reported on code.google.com by al...@arcor.de on 10 Jan 2011 at 3:33

GoogleCodeExporter commented 9 years ago
Good idea.  I actually want to see if I can create some sort of status register 
that let's us know what is enabled/disabled/initialized.  So the idea is after 
the quad finished initialzing something like a 16 bit unsigned integer can have 
dedicated bits assigned to let the user know a sensor is available or now.  
Thinking this through, if the setup() part gets hung up, we may not see this 
integer updated.  Let me put my thinking cap on how this could be setup... we 
might just go with debug println() statements.  Ultimately, I want the 
Configurator to have green/red lights to show the user what sensors are setup 
up.  Thanks!

Original comment by CaranchoEngineering@gmail.com on 18 Jan 2011 at 9:11

GoogleCodeExporter commented 9 years ago
The main problem is the setup function hangs if some I2C sensors lock up, and 
you do not know where it hangs. Especially this happens when setting up new 
hardware, so new users get lost and we have no way to help them efficiently. A 
clear text message on the serial helps to see that the CPU is acting at all and 
which sensors is detected.
In my code each device reports that it is up.

Original comment by al...@arcor.de on 18 Jan 2011 at 11:25

GoogleCodeExporter commented 9 years ago
The problem is that the Configurator is expecting reponses and debug statements 
like that might interfere.  It's not a problem, I can either handle it, or only 
have those messages appear when #define DEBUG is set.  I'll just do the latter 
to keep things simple for now.

Original comment by CaranchoEngineering@gmail.com on 19 Jan 2011 at 8:29

GoogleCodeExporter commented 9 years ago
This problem can be solved by using virtual I/O channels. A very simple way to 
do so is a line based protocol, having a channel number at the start of line 
and a line end at the end. As the communication to the configurator is already 
line based, this is easily done. You could assign channel 1 for the 
configurator reply data, add a Serial.print("#1,"); 
at the begin of sendSerialTelemetry() and a
default: 
  Serial.println();
to the switch statement, just in case the command letter is unknown for proper 
line end.
Now all data send has the channel 1 prefix. In the configurator you simply 
filter out the lines starting with "#1," to know they contain the replies you 
are waiting for.
Data for other channels could be supplied on a TCP/IP port or be shown on the 
serial monitor page.

Original comment by al...@arcor.de on 19 Jan 2011 at 5:33

GoogleCodeExporter commented 9 years ago
I have another thought.  What if I just put serial output for each action that 
happens in setup().  So after the gyro is initialized, then I output 
Gyro:Initialized, etc.  The new Configurator I'm building has a table which 
will display this.  So an example output will be like:

Flight Software Version: 2.2
Flight Mode: X
Heading Hold: Enabled
Altitude Hold: Enabled
Gyro: Initialized
Acceleromter: Intialized

This way we can have a readable set of debug messages from the Serial Monitor 
or the Configurator.  Just because I want to get the existing code out, the 
v2.1 release won't have this in, but will definitely be part of v2.2 (I've made 
sure the Label for this issue reflects this).  Thanks!

Original comment by CaranchoEngineering@gmail.com on 20 Jan 2011 at 9:06

GoogleCodeExporter commented 9 years ago
Outputs just in setup is what I initially suggested. Best is having one message 
at the begin and the end of the sensor initialize functions, so you see what 
hangs, but any message is better that no message.

Original comment by al...@arcor.de on 20 Jan 2011 at 11:19

GoogleCodeExporter commented 9 years ago
Will implement this and combine with next version of Configurator

Original comment by CaranchoEngineering@gmail.com on 14 Feb 2011 at 8:17