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.
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).
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.
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... :-)
@ mmormota.. I am succesfully using remzibi OSD with r141 ..ALso download latest firmware for remzibi osd which supports 19200 bauds..If you do not have one.let me know I will send you. NOte:- I have not used later versions other then R141 from the trunk. but I have done dozens of flights of R141 with Remzibi..
YOU also need to activate GPGGA and GPRMC on UBLOX to use Remzibi on spare uart port of UDB.
I have a question about verifying the PWM in dsPIC30F4011 that you writed in UAV "DevBoard servoOut.c" function that called init_pwm(),
PTPER = 25000 ; // 25 millisecond period at 16 Mz clock, prescaler= 4
PTCONbits.PTCKPS = 1; // prescaler = 4
But by the information that I had saw in dsPIC Family data sheets like DS70046E it most doesn't work at 16 MHz clock and prescaler=4 (PTCONbits.PTCKPS = 1) and PTPER = 25000
Because by an example that Microchip had written in section 15.3.7 (Equation 15-1) (I supposed that when you don't verify the PTCONbits.PTMOD=0b00 but it should be Free Running Count Mode PWM and by the 25 milisecond period we have a PWM-Frequence Fpwm=40 Hz) "servoOut.c init_pwm()" most use a prescaler= 16 that could achieve PTPER = 25000 and 25 milisecond period time by 16 MHz clock, not a prescaler= 4. http://ww1.microchip.com/downloads/en/DeviceDoc/70046E.pdf
Please help me to understand it and finding my mistake.
The input clock to PTMR is FOSC/4. That means that when the clock is running at 16 MHz, the clock input signal to the PWM module is only 4 MHz, so everything comes out ok. There is a built-in divide by 4, which when combined with the selectable prescaler of 4, gives you an effective prescaler of 16, just like you said.
This is a confusing point...in some places the dsPIC documentation refers to the crystal frequency (FOSC), and in some places it refers to the crystal frequency divided by 4 (FCY=FOSC/4).
So, be careful to look at any equation involving a clock to see if it is FCY, or FOSC. Usually it will be FCY, not FOSC.
How this arises it that the control for the CPU execution uses 4 phases derived from the raw crystal oscillator, to control the 4 phases of the execution cycle. So, there is a place in the dsPIC where the raw signal (FOSC) is divided by 4 to produce the CPU control, as well as the drive for most of the timers.
When the oscillator is running at 16 MHz, all of the timers are running at 4 MHz, and the CPU is executing 4,000,000 instructions per second.