All components including the XBee wireless data source are working in rudimentary form. Now all the junk nailed to cheap piece of plywood needs to be shrunken into a cockpit instrument of some sort, and we need to get to work on the probe.
Friday, April 28, 2017
All display components working together
All components including the XBee wireless data source are working in rudimentary form. Now all the junk nailed to cheap piece of plywood needs to be shrunken into a cockpit instrument of some sort, and we need to get to work on the probe.
Sunday, April 23, 2017
Embedded system progress
Airball embedded system code is moving right along.
* Here I've improved the concurrency so that we have a separate input handler (equivalent to an interrupt handler) that puts inputs on a queue, and a separate display thread. This mostly fixes the problem of flakey response to the encoder knob. The rest of the flakiness I suspect will be solved once I've added a proper RC (resistive-capacitive) debounce circuit to the analog inputs.
* The display code timing is fairly primitive right now -- I just sleep for 10ms between each recompute/repaint. This puts me at about 50% CPU load on the Raspberry Pi 2 that I'm using, and a frame rate fast enough that the steps are not perceptible. I need to do more instrumentation and measurement, and use a proper timed display clock, but for now this is very promising.
* The next step is to connect this up to an XBee wireless link so I can get data wirelessly. Once that's done, I'll have a benchtop prototype of pretty much all the moving parts.
* The following steps are to resume work on the airdata probe, and to start looking at high brightness displays and embedded computers. As to the latter, some SODIMM form factor ARM compute-on-module units are looking promising:
http://www.compulab.com/…/cl-som-imx7-freescale-i-mx-7-sys…/
* Here I've improved the concurrency so that we have a separate input handler (equivalent to an interrupt handler) that puts inputs on a queue, and a separate display thread. This mostly fixes the problem of flakey response to the encoder knob. The rest of the flakiness I suspect will be solved once I've added a proper RC (resistive-capacitive) debounce circuit to the analog inputs.
* The display code timing is fairly primitive right now -- I just sleep for 10ms between each recompute/repaint. This puts me at about 50% CPU load on the Raspberry Pi 2 that I'm using, and a frame rate fast enough that the steps are not perceptible. I need to do more instrumentation and measurement, and use a proper timed display clock, but for now this is very promising.
* The next step is to connect this up to an XBee wireless link so I can get data wirelessly. Once that's done, I'll have a benchtop prototype of pretty much all the moving parts.
* The following steps are to resume work on the airdata probe, and to start looking at high brightness displays and embedded computers. As to the latter, some SODIMM form factor ARM compute-on-module units are looking promising:
http://www.compulab.com/…/cl-som-imx7-freescale-i-mx-7-sys…/
Sunday, April 16, 2017
Display on Raspberry Pi
Got display working on a Raspberry Pi with support for the adjustment knob. The adjustment character layout is still in need of work. This is on an 800x480 display; the intended display will be the same number of pixels (272x480) as the area painted here, but 4.3" diagonal, and very bright. Need to add serial connection via XBee and a prototype of sorts of the display device will be more or less ready. Then maybe back to working on the airdata probe!
Sunday, April 9, 2017
Saturday, April 8, 2017
Subscribe to:
Posts
(
Atom
)