Replies to This Discussion

ModeratorPermalink Reply by Morli on January 13, 2010 at 4:07am

I have the same question like Mathew but with MPLAB Compatible ICD2 with USB and RS232 from SF , how to go about programming and debuging for dummies using this ? Thanks

• ▶ Reply

Permalink Reply by Michal on January 13, 2010 at 2:35pm

Hello Mmormota :)
I am interested in integration with Remzibi OSD too. But I noticed such phrase in options.h:

// Serial Output Format (Can be SERIAL_NONE, SERIAL_DEBUG, SERIAL_ARDUSTATION, SERIAL_UDB, or SERIAL_OSD_REMZIBI)
// This determines the format of the output sent out the spare serial port.
// Note that SERIAL_OSD_REMZIBI only works with GPS_UBX.

Would anybody confirm that it would not be possible with GPS_STD (EM406)?
Regards
Michal

• ▶ Reply

Permalink Reply by Adam Barrow on January 13, 2010 at 3:41pm

Michal,
I had developed the current SERIAL_OSD_REMZIBI implementation, and for now it only works with a UBlox GPS. The reason is that the UDB simply 'passes through' the NMEA sentences for the Remzibi OSD (while it uses the binary messages). As far as I know, there isn't any way to have the EM406 GPS module output both the binary and NMEA messages, which is why it isn't currently supported.

Hope this helps,
Adam Barrow

• ▶ Reply

Permalink Reply by mmormota on January 13, 2010 at 6:11pm

Thank you, now I understand why the ublox required - my first thought was: why not the exact opposite? :-)

Do you have a plan to add an output buffer and extra messages?

• ▶ Reply

Permalink Reply by Adam Barrow on January 13, 2010 at 6:29pm

I'm currently working on code that adds an output buffer (for all telemetry, not just the Remzibi) and then I plan to add the ability to add extra messages (the target being the custom messages supported by Remzibi). If you are interested, please consider joining the Google group, where this and several other work-in-progress modifications are discussed.

• ▶ Reply

Permalink Reply by mmormota on January 13, 2010 at 6:55pm

Thank you, I'll do that.

I am FPVer and a happy user of the remzibi OSD and Ardupilot, but I like the built-in IMU and the much stronger uC of the devboard. (hope the next hw will be flat, these vertical pcbs are painful)
I even more like the code, very clear and readable.

The custom message is rather useful function, good to know what exactly happens especially when the plane doesn't do what it should... :-)

• ▶ Reply

Permalink Reply by SUNEEL KAPUR on August 12, 2010 at 12:40am

Hello Michel
I am interested in using REMZIBI OSD WITH U BLOX GPS AND UDB. May i request for a detailed wiring digram for connections and other guidance on the use of REMZIBI OSD WITH U BLOX GPS with UDB
Regards
Suneel

• ▶ Reply

Permalink Reply by mmormota on January 13, 2010 at 3:43pm

Debugging using mplab and a debug tool, either pickit 2,3 or icd2 is basically the same.
Connect the hardware.
Start mplab, load the project.
Select the debug tool (pickit or icd2).
Select debug mode instead of release mode.
Build the project.
In the view menu select watch, a watch window appears. Select the registers and/or variables you are interested in.
Add a breakpoint after the point your favorite variable got it's interesting value.
Run the program. It stops at the breakpoint, and shows you the values of the variables in the watch window. Push run, it stops again on a breakpőoint and you get the new values in the watch window.
(this is only one possibility, there are many other ways to debug of course)

Worth to take a look what is going on during the above process.

In the debug mode the linker adds a monitor program to your code. It's just in the flash and doing nothing until it starts on a special event, for example the program counter hits a breakpoint.

If you set a breakpoint, and the Program Counter hits it's address, the user program stops and the PC jumps to the monitor program code. It acts like an interrupt, saves values etc, then starts communication to the PC. It transfers the required variables values, registers, memory contents, whatever you selected for examination, for example the items selected in the watch window.
Then it waits for the user, for example for a click on the run button. During wait, the user program is not running. After the click the monitor program restores the registers it had to use and the PC jumps to the code line at the breakpoint and the user program runs again.

• ▶ Reply

Permalink Reply by William Premerlani on January 13, 2010 at 4:46pm

@mmormota,

Thanks, that is a great summary for how to use the MPLAB as a debugger. Its very useful.

Another way that users are debugging the recently released MatrixPilot firmware is with the spare serial port. There is a stream of messages that come out of the serial port. They are intended mainly for telemetry, but you can use them for debugging as well. Prior to compiling the firmware, you select an option for the type of telemetry. Currently, the options are DEBUG, UDB, and ARDUPILOT. The DEBUG option gives you basic location and atttitude information. UDB gives you several of the internal variables, and ARDUPILOT gives you messages that can be fed to an ArduPilot ground station. The source code that generates the messages is included in firmware, so you can modify the messages to include any variables you want to see.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Matthew M on January 13, 2010 at 5:20pm

Awesome! I'll have to add a connector but I should be able to use pickit2's UART tool for this. I'll try picking out the variables with the MPLAB debugger also. Thanks for the info! :D

• ▶ Reply

Permalink Reply by William Premerlani on January 13, 2010 at 5:41pm

Hi Matthew,

Here is more information on using the serial port for debugging.

Bill

• ▶ Reply

Permalink Reply by Adam Barrow on January 13, 2010 at 5:45pm

Matthew,
I have used the PicKit2 (with it's software UART feature) to read the UDB's telemetry output on the PC while testing on the bench. It doesn't help you when the plane is flying (you need some kind of wireless link for that) but it is helpful to understand what is going on.

In my case I put male headers onto the UDB (which I can then connect either the PicKit2, my USB FTDI cable, or the XBee wireless transceiver). Since the pinout between the board and the PicKit2 don't match, you'll need to either make a special cable or use jumper cables (as I did).

Hope this helps,
Adam

• ▶ Reply

• ‹ Previous
• 1
• …
• 41
• 42
• 43
• 44
• 45
• …
• 58
• Next ›
• Page