Open GoogleCodeExporter opened 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
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
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
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
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
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
Will implement this and combine with next version of Configurator
Original comment by CaranchoEngineering@gmail.com
on 14 Feb 2011 at 8:17
Original issue reported on code.google.com by
al...@arcor.de
on 10 Jan 2011 at 3:33