Joint USB and XBee Serial communication #227

Closed
wants to merge 3 commits into
from

Conversation

Projects
None yet
2 participants
Contributor

eelsirhc commented May 25, 2012

Hi,

This changeset adds a new option for serial communication that allows both USB and XBee to occur on the same board. If the define "MultipleSerialTelemetry" is enabled (instead of "WirelessTelemetry") the USB and XBee serial ports are both enabled with the same baud rate. During the serial reading/writing the origin of any messages is used to determine which serial port to reply on (e.g. send a command over USB, get a response of USB; send a command over XBee, get the response over XBee).

The case option 'Q' is used in SerialCom to allow the Xbee to be configured over USB, following the datasheet (page 27 of http://ftp1.digi.com/support/documentation/90000982_G.pdf)

Chris.

eelsirhc added some commits May 25, 2012

@eelsirhc eelsirhc Adds code to run the serial communication over XBEE or USB.
This changeset initializes USB and XBEE serial ports on the AeroQuad at the same time, and allows communication over either port. The board will respond on the same port
that received the command. There is a new serial option 'Q' that can be used to configure the XBEE (following page 27 of the XBEE-pro documentation for the commands) and everything is wrapped in a new define "MultipleSerialTelemetry" that is independent of the default option or the WirelessTelemetry option.
86b2db6
@eelsirhc eelsirhc Merge branch 'development' into xbee_serial_dual 4a49f71

Ok

This is way too complicated for nothing... MultipleSerialTelemetry instead of WirelessTelemetry is just confusing, Event WirelesTelemetry is a bit confusing cause users are not really aware that it require XBee, mostly now with SlowTelemetry... . If the goal is to be able to use XBEE on Serial0, then, it will be only on the 328p. Otherwise, it will be on Serial 3, then, the only option to check is if WirelessTelemetry is define on a 328p, then, the BAUD have to be change.

Apart from that, I like the XBee init function you code... So, the only thing I'm willing to keep is that function that could be called only if WirelessTelemetry is defined. Still, this will a bit make bigger the footprint already really short for UNO.

So, please, remove useless option and keep just the init function for XBee when WirelessTelemetry is defined.

In another note, Please respect current code std/indentaiton defined, no if on one line and brace are required even for one line, no useless comment, like line 138, 141, 142 in SerialComm.h, try to avoid getter and pointer. there is none for now and I'm happy with it.

Also, since it's quite evident that you are good in code, there is plenty of task in Jira... be my guest!

Owner

Kenny9999 commented May 28, 2012

Hey Christopher

Don't know if I have insult you in some way with my comment, it was not my intend for sure. Still, As the code guardian, I have to filter and make sure all is ok and that there is no inconsistency pass. Also, I'm not there to reformat all coder code to fit the AQ code style and structure. That why I ask you to make those change.

So, I still hope you're gonna do the change I ask you for pull request 227 and 228 and that you will update your commit range so that your work won't be lost. please.

Thank

Contributor

eelsirhc commented May 28, 2012

Hi Kenny,

No offense taken. I'm working through 227 & 228. These changes were remnants from our code that was based on AQ 2.4 . We upgraded recently to 3.0 (still rebuilding the hardware) so I wanted to offer these changes back to AQ before we start modifying 3.0 for our Quad.

I found a bug in the EEPROM writing for 228 (magScaleY & Z were not written correctly under normal conditions) which I've corrected and need to update the pull request. I've checked this code on an aeroquad 2.0 board that isn't flyable but I wanted to wait until our Quad is rebuilt to test the code more thoroughly on a flyer as you requested.

For 227, I'm not sure how to progress. You wanted only the 'init' function. Do you mean the configuration code that I put in SerialCom.h? If so, it's not clear how you will be able to call this function while connected over the XBee alone. As soon as you send the command to configure the XBee I think it will probably shut down the serial connection to start the configuration and then wait for the next instruction over serial which will never come. This is part of the reason why I enabled USB and XBee simultaneously.

As for the code style. Not following the AQ indentation style was an oversight that has been fixed in the latest update. I'll update the pull request range when I update the repository.

Chris.

On May 28, 2012, at 10:36 AM, Kenny9999 wrote:

Hey Christopher

Don't know if I have insult you in some way with my comment, it was not my intend for sure. Still, As the code guardian, I have to filter and make sure all is ok and that there is no inconsistency pass. Also, I'm not there to reformat all coder code to fit the AQ code style and structure. That why I ask you to make those change.

So, I still hope you're gonna do the change I ask you for pull request 227 and 228 and that you will update your commit range so that your work won't be lost. please.

Thank


Reply to this email directly or view it on GitHub:
#227 (comment)

Owner

Kenny9999 commented May 29, 2012

ah cool,

Thank to not let that like this...

Yes, for that pull request, I don't see the need to have that kind of define. Because, we already have the WirelessTelemetry option, that will redirect the serial output to the Serial3. So, If I understand your need, you want to use XBEE on Serial0 and this is already take care the block in the ino file at line 1173. Serial port will always be the same. What you did bring new is the configureXBee function. That seem to configure XBee, this is new to me and I have the feeling that will help xbee communication greatly!

The rest is just doing nothing really from what I see

Contributor

eelsirhc commented May 30, 2012

I don't think I explained the changeset clearly based on your reply.

The MultipleSerialTelemetry option enables USB and XBEE at the same time . USB is still Serial, and XBEE is still Serial3. We have two computers connected to our AeroQuad board. The first connected over USB for programming, the second computer connects over XBEE as a flight computer / logger.

I don't think you can/should configure the XBEE while connected only over the XBEE. During the configuration the XBEE will reset and you'll lose the serial connection and the ability to configure properly.

I've pushed the cleaned up code to the same branch, but I haven't removed the new option or the getters or pointers. The getter/pointers are needed to point the serial port (_ser) to the correct port before writing.

Owner

Kenny9999 commented May 31, 2012

I'm sorry but... I still don't see the point of this!

can you describe me a use case? how do you use this?

From what I recall of using XBee, on mega, you are able to speak Serial over XBee on Serial3 and if you want to upload, it will do it anyway over USB...

The only trouble was on 328p, like on the UNO, I had to disconnect the XBEE if I wanted to upload the firmware! But, in both case, I never had a possibility to use both at the same time.

So, the only advantage I see is, only for 328p, you don't need to disconnect the XBee from the shield when you want to upload the firmware... Right?

Kenny9999 closed this Jun 5, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment