Page 2 of 3

Re: DragonPro

Posted: Wed 11 Mar 11 2009 2:51 am
by Daniel Wee
Need to correct the Voltage1 display. Apparently we're reading the voltage through a protection diode (that I didn't originally include in the schematics).

Daniel

Re: DragonPro

Posted: Wed 11 Mar 11 2009 9:22 am
by Daniel Wee
We current have a 256-byte serial buffer running in circular mode. At 115200 baud, each character takes 10/115200s or 86.8us. This means that the buffer will fill up in 22.2ms. Given that a full NMEA frame of RMC, GGA and GSV messages take about 1104-bytes (95.8ms to send) or so, we have more than enough data to cause an buffer overflow. Furthermore, our primary loop latency is constrained by the draw_osd render time, which at it's worst case is around 92ms so we can fill that buffer up four times over before getting a chance to process it. This means that we probably need to drastically increase the buffer size or reduce latency.

*update - we have now confirmed this buffer overflow condition.

Daniel

Re: DragonPro

Posted: Wed 11 Mar 11 2009 11:16 am
by Daniel Wee
Okay, buffer size is now up to 1024-bytes in order to accommodate for future 10Hz GPS data streams. Buffer no longer overflows. SPI Rendering issues have been largely resolved - no more lockups. There is the very rare data corruption and it is uncertain what the cause of this is. We also fixed some of the draw routines and will have to start working on making the render_element functions smarter - ie. render changes only. Then we will have to do up the draw routines properly as well as write the code for the missing elements (alt-change arrow and warnings). Then the capture codes and menu follows after that.

*update - smart render works and is cutting down a lot of data traffic so this is a good thing. We were looking at between 700 to 1400-bytes per screen. Now we're looking at an average of about 200 to 300-bytes depending on amount of change. Compass end indicator arrows are acting weird - needs investigating.

Daniel

Re: DragonPro

Posted: Wed 11 Mar 11 2009 5:37 pm
by Daniel Wee
Okay, I think the drawing primitives are now all done. I do need to think about how and when to set the warning conditions - ie. low voltage warnings, range warnings, and so on. Under ideal conditions the screen draw can be as low as 13.6ms or a 73.5Hz rate. This is without the rendering of the artificial horizon. Overall we are seeing a huge performance improvement with this scheme. In the absolute worst case scenario, this will only be as bad as the old scheme (92ms). This is a very unlikely scenario, however, in actual operation - possibly impossible even. At a 10Hz GPS data rate, we are looking at between 13.6% to 50% slot occupation typically. This leaves us 50ms to complete all other navigational processing.

Daniel

Re: DragonPro

Posted: Thu 12 Mar 12 2009 1:14 am
by Daniel Wee
You learn something new and quirky every day! As it turns out, you can't have a bclr and bset to the same PORTx back to back. But you can if you use the corresponding LATx latch. So, this doesn't work:-

bclr PORTD, #3
bset PORTD, #4

but this works:-

bclr LATD, #3
bset LATD, #4

Must be something to do with the way the address is clocked inside the MCU but it took a long time to find out the reason because everything else looked correct.

In any case - PPM stream capture is written and should work, but not tested. PWM output works on at least 4-channels which is what we have defined so far. Not sure if we will need more outputs but these will do for now.

Daniel

Re: DragonPro

Posted: Fri 13 Mar 13 2009 12:18 am
by Daniel Wee
Okay, the warnings code is done but not fully tested. I have also optimized the ADC1Interrupt routine in assembly and came up with some super fast and compact code which is probably 2 or 3 times faster than the original. Likewise, I re-wrote a few minor functions in assembly to speed things up. I must say that the Microchip C30 compiler is generating some pretty decent code though, which is a good thing and more than I can say for the MikroeElektronika one.

I also corrected for the protection diode - which, amazingly, only incurs a 0.0159V voltage drop. I don't know what that part is but it's pretty darn amazing. Need to determine the part number for this.

On the display side, I would say pretty much everything has been completed in terms of duplicating the DragonOSD display. I need to write an alternative compass display and see how that works out. After that, I need to write the passthrough code and devise a system for assigning channels to functions.

All in all, a lot of quirks sorted out. Decade Engineering confirms that the SPI problem is theirs and not due to my code. Not a serious issue at this point.

Daniel

Re: DragonPro

Posted: Fri 13 Mar 13 2009 3:05 am
by Daniel Wee
Okay, another weird thing - the branch LT instruction is WEIRD! Works once then stops working. Mental note here to use the NC instead of LT condition in the future. That took a long time to solve but at least now we know it is working perfectly, which is always a good thing.

The warnings have also been tested and now works fine. Next up - new compass draw routine.

Daniel

Re: DragonPro

Posted: Fri 13 Mar 13 2009 5:09 pm
by Daniel Wee
Minor update: Got an e-mail from Neil at Decade Engineering that there is indeed a known bug in the SPI hardware at high speeds such as what I was using, except that they found it at a higher speed but I managed to reproduce it at a lower speed. This isn't a significant problem as we are still sending data far in excess of the data processing speed. Good to know and not a deal breaker.

Also got hold of the latest BOB-4 firmware file from Mike, the 4.2.17 with all the bug fixes, improvements, and new features. We were at stepping 10 before this. Upgrade went without a hitch using the Conscriptor software. I am thinking perhaps to make some custom font characters to prettify the display. We will see about this in due time.

Daniel

Re: DragonPro

Posted: Sat 14 Mar 14 2009 1:58 pm
by Daniel Wee
The Microchip ICD3 got in today. I paid USD256.49 for it inclusive of shipping (and probably got one of the first few in the world - it was just launched on the 10th March). The thing basically looks like the ICD2 (hockey puck look) - wish they had made it square instead of round but then again, it's just a piece of equipment so who really cares what it looks like. Got it in, removed the IC from the test board and made it into a adapter for my current connectors. The drivers installed automatically since I had MPLAB already installed. And I gave it a shot - wow! This thing is fast. In fact it programmed so fast I thought it didn't program. I would say it programs about 5-10 times faster than the older ICD2. This is great and should save me considerable code development time (no need to keep waiting for chips to be programmed hundreds of times). The other neat thing about this ICD3 is that you can actually power the target from the programmer - a very useful feature. Now, most importantly, I hope this ICD3 doesn't hang occasionally like the ICD2 does.

Meanwhile, I've installed some custom fonts in the BOB-4 just to see what an alternative compass recticle would look like. Not bad so far, but I need to write more code for it and possibly do a few more custom glyphs.

Daniel

*note to self - spending moratorium this month. Already spent too much on equipment, PCB and components.

Re: DragonPro

Posted: Sat 14 Mar 14 2009 10:22 pm
by Daniel Wee
Phew! Finally got that alternative compass renderer done. It does look rather nice although a little short - a bit like the EagleTree compass. Clear but short. It should render faster though, consisting of fewer characters albeit slightly larger ones.

Next up - the passthrough and channel mapping stuff. Hmm... I probably should do up the menu so I can play with this once I get it working.

*update - converted more ISR's to assembly so things should run even faster. Also added a moving average filter to voltage readings to take out the jitter.

Daniel