This blog post will demonstrate how to cross compile QT4 applications for the Raspberry Pi (RPi). The approach taken in this entry is a little different from that taken by other tutorials such as this or this. The complete cross compilation of the QT4 or QT5 libraries will NOT be covered. Instead, the QT4 libraries available in the Raspbian’s repos will be installed on the Raspberry Pi and the RPi’s root filesystem will then be mounted onto the PC over the network using SSHFS. The RPi’s cross compiling toolchain will then build qt apps by compiling QT4 source code on the PC and linking it to the QT4 libraries available via the SSHFS-mounted RPi filesystem.
Simple QT4 application cross-compiled on PC
Eclipse has in many ways become synonymous with open source development and can be used to develop code for all sorts of projects and in many languages. Of course there are many other open source IDEs available including NetBeans, VIM, emacs & Geany; and while they are all very good at what they do, none of them try to be the “Jack of all trades” that Eclipse is.
And sure the Eclipse IDE isn’t perfect. And some of the IDE’s I cited above can be better than Eclipse in one or more aspects. But Eclipse does almost everything really well. How does Eclipse achieve this? Simple….plug-ins. What really makes Eclipse stand out from other IDE’s is the wide variety of plug-ins available for Eclipse that enable among many other things:
- GDB integration (CDT/ GDB Hardware Debugging plug-in),
- Remote control of the target system (RSE plug-in),
- ARM microcontroller development (GNU ARM Eclipse plugin).
- I/O register view for debugging firmware for microcontrollers (Eclipse Embedded Systems register view)
The Eclipse plug-ins are like “super powers” that can add needed functionality to Eclipse. Eclipse plugins are also the reason why many commercial development suites such as those created by Atollic, Code Red, TI (Code composer) and Freescale (CodeWarrior) are based on Eclipse. These companies only have to develop Eclipse plug-ins related to their products to enable developers to develop code for their particular hardware platforms.
Figure 1. IO Expansion board attached to the RPi
When the Raspberry Pi was first released, I felt that the on-board I/O capabilities were not adequate for my needs. So I decided to build my own I/O expansion board. I decided to include:
- MCP23017 that adds two 8-pin general purpose input/output (GPIO) ports,
- PCA9685 that adds 16 12-bit pulse width modulation (PWM) channels with variable PWM Frequency (20-1000Hz), and
- MCP3008 that adds an 8-channel 200Ksps analog to digital converter (ADC).
The first two are attached to the I2C bus while the last is attached to the SPI bus. I designed the board layout using the Eagle PCB layout tool in the Fall of 2012. I even ordered some bare PCBs at the time, but I didn’t have the time /equipment to populate the board. So I put it on the back burner and conveniently forgot about it. The emergence of many other I/O expansion boards such as the awesome Gertboard and Piface further reduced my incentive to continue with this project.
Recently however I decided to revive this project…..at the very least as a PCB layout design & soldering exercise. So I dug out the PCBs & populated them with the necessary parts and did some pre-eliminary testing. So far everything seems to be functional (all power connections are fine, the “i2cdetect” also detects the device addresses of all i2c devices) but I’ve yet to run any major programs on it.
Figure 2. Populated I/O expansion board for the Raspberry Pi ver 0
One of my main objectives for this I/O expansion board was to make it as low cost as possible to manufacture…..perhaps under $15 if mass produced. The three chips chosen cost about $1-2 each in unit quantities and are sure to cost significantly less in larger quantities. Continue reading
Recently, ST Microelectronics released 32-LQFP versions of their STM32F0 microcontrollers. The great thing about 32-LQFP packages is that the spacing (pitch) between the pins is 0.8mm. This spacing is rather forgiving for surface mount soldering noobs like myself and with some experience is very straightforward to deal with.
So I decided to give soldering these parts a go, and bought a few stm32f051k8t6 microcontrollers from Digi-key. I also bought some 32LQFP to DIP adapters from DAQSTUFF. I then proceeded to solder the microcontrollers on the adapters. As I expected, it was not easy, but not impossible. After soldering the part on the board, I checked for solder joints between the pins using an eye loupe as well as a continuity tester. The soldering job is not the greatest but is not bad considering that its my first attempt at it. Once all the solder joints were eradicated, I had two STM32F0 micros soldered on tiny boards & ready for a software trial run!
Figure 1. Photo of the soldered micros on the adapter boards after inspection
I followed the steps on my newer STM32F0Discovery board tutorial series, and everything just worked! The only modification that I had to make was to change the LED pins in the main.c file from PC8 & PC9 to PB0 & PB1, as there is no GPIOC port on this low pin count package of the STM32F0 micro.
In this blog entry we will examine using a development environment based on command line tools which will include using the VIM (VImproved) text editor, the GDBTUI debugger along with the Texane’s stlink and OpenOCD GDBserver / programmer utilities. It is assumed that the reader has completed Part 1 of the tutorial.
So why use these tools when you have sophisticated tools such as Eclipse ? Command line tools run faster, are usually less buggy than their GUI counterparts and require significantly less memory and processing power. They also allow for a high degree of automation. They can turn your old PC into a development power house! Continue reading