Single Board Computer
Serial Thread Priority
After adding the dials for representing sensors in a more graphical way, random serial I/O problems occured resulting in incorrect figures being obtained.
The solution was to increase the priority of the serial I/O thread to higher than the rest. By default it inherits the same priority from the calling thread but this isn’t enough.
I started my thead with the QThread::TimeCriticalPriority enumerated type. This seems to have solved the problem. If I discover any more problems, i will attempt setting the whole processor priority higher using the Linux nice command.
The QT Thread priority types are:
| QThread::IdlePriority | 0 | scheduled only when no other threads are running. |
| QThread::LowestPriority | 1 | scheduled less often than LowPriority. |
| QThread::LowPriority | 2 | scheduled less often than NormalPriority. |
| QThread::NormalPriority | 3 | the default priority of the operating system. |
| QThread::HighPriority | 4 | scheduled more often than NormalPriority. |
| QThread::HighestPriority | 5 | scheduled more often than HighPriority. |
| QThread::TimeCriticalPriority | 6 | scheduled as often as possible. |
| QThread::InheritPriority | 7 | use the same priority as the creating thread. This is the default. |
Checking Memory and CPU Consumption on TS7390
Today I decided to place my new updated code on the ARM device and measure CPU and memory consumption.
I used the top command to investigate the consumptions. Running the program with continuous querying 3 sensors and updating them on the GUI resulted in 10% CPU consumption and 19.3% memory consumption. The processor on this device is a 200Mhz ARM and the memory is only 64MB ram so only 12.35MB of RAM is used but most of this is the actual QT framework. Normally however, there is only about 19MB RAM free out of the 64 before actually loading the program but a lot of this is cache ram that can be removed by executing: echo 1 > /proc/sys/vm/drop_caches. This provides about 40% RAM free so this is a big improvement. I decided to remove the whole kernel feature out and do no monitoring, just load the GUI components and leave them blank. CPU consumption is almost 0% and RAM usage is still as high as 14% (8.96MB). So the kernel part of my system with all few hundred DTCs codes loaded in memory only consumes about 3MB of RAM. This is good news. However I still don’t know how adding more GUI components will affect it yet. I have to be careful with my memory consumption.
First GUI Prototype using ElmScan 5 & QT/E 4
GUI Prototype
So today I finally decided to create a GUI application that would display the revs. The photo above is taken of the TS7390 connected to the ElmScan 5 USB and my car’s DLC. Even though it is USB, it actually creates a virtual com port so my code didn’t need to be changed from past code. The chip that does this virtual com port emulation is the FT232RL from FTDI. This is supported in Linux kernels > 2.6.9 which mine satisfies. More information from: http://www.ftdichip.com/Drivers/VCP.htm
The code took me about and hour or two, but I did have the QT serial stuff already done so that would have taken quite a bit more. This is only a prototype and cannot be used in any way in the final product. I am only doing proof of concept that I can in fact read from serial while updating a GUI.
Constraints
I noticed that if I reduced the refresh rate to 1/4 of a second, things got funny, it was missing bytes etc so the revs were all over the place. It seem to be perfect at about 300ms but that means refresh rate is only ~3Hz. This is actually quite noticeable when you rev up high quickly in neutral but on the road I’m guessing as you rev gradually in normal driving circumstances that it won’t look so bad.
However, the product is not a problem with my program to the ELM327, the serial part is fine. It is a limitation of the OBD side and my car is using KWP2000/ISO 14230 so I will have to figure out more timing details on this protocol. Other protocols such as CAN should be OK speed wise but I will have to investigate more into that.
Tested Console Program to Read Revs on TS7390
Reading RPM Successfully!
In MG with Automon
It worked!
First of all I had to cross compile QExtSerialPort for ARM Linux. To do this I downloaded the tarball, unzipped it to my home directory. I set my PATH variable to point to qmake in QTEmbedded-4.4.3-arm. Then I ran qmake and make and it successfully compiled for ARM. In the build folder there is a libqextserialport.so.1.0.0 and libqextserialport.so.1 and few more. I copied all up to /usr/local/lib on my Device.
Next I ftp’d my project from windows to vmware, the one I discussed previously. I had to modify the .pro project to the new location of qextserialport libraries (in my home directory) and I had to add an extra line: libs += /home/donal/qextserialport/build -lqextserialport. I also had to modify the main.c file to point to /dev/ttyAM1 which is COM1 on the board. Then I navigated to my test folder and done a qmake followed by make and resulted in a automon binary. Doing file automon , I confirmed that it was an ARM binary. I ftp’d this up to my device.
I set the whole lot up in my car as you can see in the pictures above. Connecting the ELM327 to COM1. I ran the automon program off the device redirecting the output to the screen by doing
$ cd /home/eclipse
$ ./automon > /dev/tty0
And out comes the revs in the car perfect. It only does a snapshot every 1/2 second but it is enough for me now. Now I have done all my proof of concepts. Just to build the project now in QT!
QT Embedded 4.4.3 and TS-7390 Color Depth Issues
The colour display on the TS-7390′s screen wasn’t very good. It seemed no red or green could be displayed.
I copied the compiled version of QT3 on ftp.embeddedarm.com and this seemed to display colours ok?
So what was up. I discovered that QT4 was detecting my board as 15 bit colour depth but QT3 didn’t support it. So it assumed it would use 16bits (RGB 565 (5 bits for red, 6 green and 5 for blue).
I contacted technologic and they confirmed that my board was actually 16bits (RGB 565) but the least significant bit of green was ignored. A handy way of supporting RGB555 and RGB565. But this extra padding bit was in the middle where as QT4 expects it as the MSB or LSB of the 16bits.
This is the layout of the TS-7390: RRRRRGGGGGXBBBBB where X is the ignored bit by the TS7390.
Looking into the sources I discovered /src/gui/embedded/qscreenlinuxfb_qws.cpp. In it there is a setPixFormat function. Here I tried forcing it to QImage::Format_RGB16.
void QLinuxFbScreen::setPixelFormat(struct fb_var_screeninfo info)
{
QScreen::setPixelFormat(QImage::Format_RGB16);
}
Re compiling and deploying it, it made no difference. So then i decided to do a whole series of qDebugs in qscreenlinuxfb_qws.cpp and qscreen_qws.cpp. The result was interesting. It still claimed to be using 15 bits when infact 16.
After a lot of investigation I discovered it was detecting the green length as 5 when infact should be 6 so i forced it to 6.
In qscreenlinuxfb_qws.cpp line 309 (before the grayscale = vinfo…..) enter this line:
vinfo.green.length = 6;
re compiled and everything working fine. Note I think the modification of the setPixFormat is still required.
And that was it, perfect colour. I hope it helps someone else that has the same problem.
Deploying QT Embedded 4.4.3 on the board
From a few blogs ago I successfully compiled QT/E 4.4.3. It installed in my virtual machine at /usr/local/Trolltech/QtEmbedded-4.4.3-arm/.
On the board use the following commands:
$ mkdir -p /usr/local/Trolltech
$ chown -R eclipse:eclipse /usr/local/Trolltech
In Xbuntu:
$ cd /usr/local/Trolltech
$ scp -r QtEmbedded-4.4.3-arm/ eclipse@192.168.0.50:/usr/local/Trolltech
“libstdc++.so.5″ is required on the board. I obtained this from the precompiled binaries of QT3 on ftp.embeddedarm.com. Place this file in /usr/local/lib
On the board:
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/linux-arm/lib/:/usr/local/lib:/usr/local/Trolltech/QtEmbedded-4.4.3-arm/lib/
$ export QWS_MOUSE_PROTO = Tslib
It is best to put these in /root/.bashrc so they get automatically entered for each user session.
Since QT/E writes to frame buffer it will mess the output of IceWM. I done a sudo apt-get remove icewm and removed x11 similarly. You can do it temporary by doing a ps -A and checking the process id of IceWM and doing a kill <psnumber>
To run the program, it requires a server program but if it is the server itself you use the -qws option. For example:
$ cd /usr/local/Trolltech/QtEmbedded-4.4.3-arm/examples/widgets/analogclock
$ ./analogclock -qws
Now the problem with the output is the colours are all messed up. It seems no green and red can be displayed. This took days and days to sort and this is all explain in my next blog.
Installing TSLib and Calibrating it
From previous blogs, I successfully cross-compiled TSLib. It installed it in /usr/local/linux-arm. So on my board I created a similar path. Since I am doing a secure copy up, I need to give /usr/local/linux-arm a new owner (eclipse).
$ mkdir /usr/local/linux-arm
$ chown -R eclipse:eclipse /usr/local/linux-arm
In VMWare:
$ cd /usr/local
$ scp -r linux-arm/ eclipse@192.168.0.50:/usr/local/
Now TSLib requires environment variables set up. Edit /root/.bashrc and add these lines:
export TSLIB_TSEVENTTYPE=H3600
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/event0
export TSLIB_CALIBFILE=/etc/pointercal
export TSLIB_CONFFILE=/usr/local/linux-arm/etc/ts.conf
export TSLIB_PLUGINDIR=/usr/local/linux-arm/lib/ts
Do a switch user to load these
$ su
Now open /usr/local/linux-arm/etc/ts.conf file and delete all lines and add this:
module_raw input
module pthres pmin=1
module variance delta=30
module dejitter delta=100
module linear
(Make sure that there are no empty lines above or below)
Now to calibrate the device navgiate to the bin directory and run the program. It will display on screen points to tip. Once it is calibrated it will create a file /etc/pointercal. Don’t touch this file. If it fails to create it, ensure neccessary permissions on /etc to allow it. DO NOT CREATE a blank file before hand or you will get a segmentation fault.
$ cd /usr/local/linux-arm/bin
$ ./ts_calibrate
And that is all to installing and configuring TSLib.
Cross Compiled QT Embedded – Step by Step
Well after a few hard days of figuring out stuff I finally got a compiled version of QT Embedded for ARM. I haven’t loaded it onto the device yet as I need to mess about with partitioning the SD card to get a bigger partition. I bought a new SD card today to back up the current one which I’ll be doing later on. 29.99 Euro – what a rip off!
Anyways so the past few days were crazy, frustrating but I finally got there. I set up my whole environment in a virtual environment using VMWare. I installed Xubuntu giving 512MB ram to it, 12Gig hard drive (however I did run into space issues further down but I deleted stuff that was not necessary to make room).
So first of all I had to install a tool chain. I tried building my own one using binutils and gcc+glibc/newlib sources but it was impossible to even get to the stage of having a bootstrap gcc “c” compiler. There isn’t too much information on building a compiler with modern sources, now most people just download binary cross compilers such as the ones on codesourcery: https://support.codesourcery.com/GNUToolchain/release324. I downloaded this and successfully built a helloworld program but moving it onto my board and executing it resulted in an “Illegal Instruction” message which obviously meant the cross compiler is compiling for a slightly different processor architecture even it be ARM. This could be to do with Debian Etch compiled for OABI instead of EABI. As far as I know most modern compilers are using EABI (Embedded Application Binary Interface). This means specifies a different file format to that of Old ABI (OABI). The EP9302 processor supports both modes but it is possible the version of Debian has being compiled as OABI meaning EABI instructions be incompatible and that’s the reason I get an Illegal Instruction message. I did run the file command on the binary file and it reported correctly, being an ARM executable so it definitely cross compiled for ARM.
Anyways I moved onto the Windows cross compiler with Eclipse that came on the SD card and I could successfully compile but same problems, Illegal Instruction. There was however a hello example called helloworld-aobi so I attempted to compile this but ran into problems. It uses Cygwin to execute gcc in a linux environment but paths got mixed up and I didn’t want to spend anymore time on it since I will be compiling QT Embedded on Linux in VMWare.
The SD card came with a pre-compiled toolchain, crosstool-linux-gcc-3.3.4-glibc-2.3.2-0.28rc39.tar.bz2. So i moved this into Xubunto and tar xvjf <the bz2 filename> and moved the contents into /usr/local/opt/crosstool/arm-linux. The bin directory in this are the actual tools we require so this needs to be added to the PATH environment variable. Instead of entering it everytime I edited my bash init file .bashrc with VI (vi ~/.bashrc) and entered the line export PATH=$PATH:/usr/local/opt/crosstool/arm-linux/bin in the top of the file. Note you better off doing same for root’s one so type su and enter root password. Then edit /root/.bashrc and enter the line here too. Reason for this is I found when you run sudo you in root mode and the environment variables don’t reflect so compiler’s may not be locatable.
So I created simple hello world C and C++ programs in my home directory and compiled using arm-linux-gcc for C and arm-linux-g++ for the C++ file. arm-linux-gcc helloworld.c -o helloworldc.out and arm-linux-g++ helloworld.cpp -o helloworldcpp.out. Compilmation was successful so I moved my two binaries to the home directory of Linux on my device. This can be done by exiting “fastboot” mode using consoleo (using the JTAG board connected to the pins and hyperterminal 115200/N81. Type exit at the linux prompt and the device will boot from the SD card. Now we can ftp from VMware to 192.168.0.50 with user pass eclipse/eclipse. So I placed the files in the home directory (root on FTP). Using telnet to 192.168.0.50 I navigated to /home/eclipse and chmodded the two files to 755 to be able to execute. (chmod 755 <filename>). The owners of this file are now eclipse but telnet logs in as root (with no password) so there should be no problems. Executing the programs ($ ./helloworldc.out) I got my printf of hello world so everything is ok. Now for QT Embedded.
Setting up QT Embedded was a Pain. First of all I need to install QT in order to compile the virtual frame buffer device used to display the QT/Embedded programs on my host x86 (not target). I then compiled QT/E for my host. These steps were ok but it got a bit tricky when I needed to cross compile.
Here are the steps I took anyways, hope they work for someone out there as well. Some steps may be unnecessary such as tmake but do it in case – I came across somewhere about it so installed it just in case. I’m not pretending to be an expert here or anything but these steps may help anyways. If you have any problems, drop me an email or comment and I’ll try give a hand. It is quite a lonely procedure and finding documentation is tough so if problems encountered you must be able to troubleshoot them yourself.
(These stsps are done on Xubuntu in my virtual machine. Note the building steps can take many hours to complete. My username here is donal, obviously replace this with your own)
$cd ~
$ mkdir -p project/downloads/qt_embedded
$ mkdir -p project/sysapps/host
$ mkdir project/sysapps/device
$ cd ~/project/downloads/qt_embedded/
$ wget ftp://ftp.trolltech.com/qt/source/qt-embedded-linux-opensource-src-4.4.3.tar.gz
$ wget ftp://ftp.trolltech.com/qt/source/qt-x11-opensource-src-4.4.3.tar.gz
$ cd ~/project/sysapps/host
$ tar -xzvf ~/project/downloads/qt_embedded/qt-embedded-linux-opensource-src-4.4.3.tar.gz
$ tar -xzvf ~/project/downloads/qt_embedded/qt-x11-opensource-src-4.4.3.tar.gz
$ export QT4DIR=~/project/sysapps/host/qt_embedded/qt-x11-opensource-src-4.4.3/
$ export QTEDIR=~/project/sysapps/host/qt_embedded/qt-embedded/host/qt-embedded-linux-opensource-src-4.4.3
// Few requirements
$ sudo apt-get install libx11-dev libxmu-dev libpng12-dev
$ sudo apt-get install libxtst-dev
$ sudo apt-get install build-essential
$ cd $QT4DIR
$ export QTDIR=$QT4DIR
$ export PATH=$QTDIR/bin:$PATH
$ export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
$ echo yes | ./configure -prefix /usr/local/qt4
$ make
$ sudo make install
$ mkdir $QTEDIR/bin
$ cp bin/uic $QTEDIR/bin/
$ export TMAKEPATH=$TMAKEDIR/lib/linux-g++
$ export QMAKESPEC=$QTDIR/mkspecs/linux-g++
$ export PATH=$PATH:/usr/local/qt4/bin
$ cd ~/project/sysapps/qt_embedded/host/qt-x11-opensource-src-4.4.3/tools/qvfb
$ qmake
$ make
$ sudo cp ../../bin/qvfb /usr/local/qt4/bin
=========
close terminal to clear envs created earlier
open new one
==========
$ export QTEDIR=/home/donal/project/sysapps/qt_embedded/host/qt-embedded-linux-opensource-src-4.4.3
$ cd $QTEDIR
$ export QTDIR=$QTEDIR
$ export PATH=$PATH:$QTDIR/bin
$ export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
$ echo yes | ./configure -prefix /usr/local/qte4 -qvfb
$ make
$ sudo make install
//test framebuffer:
$ /usr/local/qt4/bin/qvfb
===========
create new console/terminal window
===========
$ cd ~project/sysapps/qt_embedded/host/qt-embedded-linux-opensource-src-4.4.3/examples/draganddrop/draggibleicons
$ ./draggableicons -qws //QTE needs sever, -qws means this application is the server
===================Cross compiling QT/E==================
===========
new terminal
===========
Step1: for tslib and autoconf support download and install in own computer
$ cd ~/project/downloads
$ wget http://ftp.gva.es/mirror/debian2/pool/main/t/tslib/tslib_1.0.orig.tar.gz [site was down so alternative location]
$ wget ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.63.tar.gz
$ cd ~/project/sysapps/
$ mkdir tslib
$ mkdir autoconf
$ cd autoconf
$ tar xzvf ~/project/downloads/autoconf-2.63.tar.gz
$ cd autoconf-2.63
$ ./configure
$ make && sudo make install
$ cd ../../tslib/
$ tar xzvf ~/project/downloads/tslib-1.0.tar.bz2
$ cd tslib-1.0
$ sudo apt-get install automake //seems to be needed
$ sudo apt-get install libtool //seems to be needed
$ sudo ./autogen.sh
$ ./configure CC=arm-linux-gcc CXX=arm-linux-g++ PLUGIN_DIR=/usr/local/linux-arm/plugins -prefix=/usr/local/linux-arm -host=arm-linux
======
I got an error during the make procedure about malloc and to resolve problem i found by editing config.h was the solution
======
$ edit config.h and comment out #define malloc rpl_malloc
$ make
$ sudo make install
==================
Ensure that cross compiler is locatable
try:
$ arm-linux-g++
if says no input files you sorted, else “export PATH=/path/to/cross/compiler:$PATH”
==================
================================
Use Qmake to create target specification
================================
Note at this stage I was running out of space (df command said. I found that the host folder was about 6 gigs (du -s -h host) so I deleted all contents in this (rm -r ~/project/sysapps/host)
EDIT: Note!!!! – The TS7390 is a 16bit colour device but techically it is 15 bits. It ignores the least significant bit of the green bits. Its arrangement is: RRRRRGGGGGXBBBBBB so infact its RGB 565 but QT Embedded detects it as a 15 bit device since it gets 5 bits back for the length of the green colour. You will get dodgy colour here. Please look at one of my latest blogs on the hack on how to fix the colour before compiling.
$ cd ~/project/sysapps/qt_embedded/device
$ tar -xzvf ~/project/downloads/qt_embedded/qt-embedded-linux-opensource-src-4.4.3.tar.gz
$ cd qt-embedded-linux-opensource-src-4.4.3
$ export QTDIR=$PWD
$ export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
$ echo yes | ./configure -embedded arm -xplatform qws/linux-arm-g++ -no-qvfb -depths all -qt-mouse-tslib -qt-kbd-usb -I/usr/local/arm/tslib/include -L/usr/local/arm/tslib/lib
$ make
$ sudo make install //Installs in /usr/local/Trolltech/QT-Embedded-4.4.3-arm/
I havn’t tested this but doing a file command on some binaries in the demo example folders it said ARM type so that’s good at least. However doing file in the bin folder for qmake I got Intel 386 binary which definitely won’t work on the board but as far as I know these are not required anyways as only using libraries. Now to get this onto the board. The whole size of the folder is only 78MB so nice and compact. I bought a SD card to back up the other so now I will go messing about getting this on.
First real look at my SBC
My 7390 SBC Front View
Rear View
So today I decided to take out my single board computer that I purchased for my project. It is the TS-TPC-7390. More details can be seen here.
Starting the device required me to wire in the transformer that came separate, but apparently it is important to get the polarity correct as there is no safety circuit on the board!? – Amn’t convinced with such an expensive device not having such features but I amn’t willing to find out either!
The device boots up to a Linux GUI in around 1.5 seconds as they claim with a nice start up tune and Technologic Systems logo. The desktop environment is IceWM, which is light weight. Obviously a big one like KDE would not work in such a device with the limited storage and memory capacity.
I was hoping the response from the touch screen would be a bit better as it requires quite bit of pressure on it to get an interaction. I tapped on the start button of IceWM and navigated around to have a look at what was available on the device. Nothing really that fancy, firefox was about the most compicated thing there and that didn’t even load! – It is actually Iceweasal – another version of firefox without all the proprietary logos etc so its free to ship. In the System Utilities folder, there was a Virtual Keyboard which is quite useful for input but really slow to use. Unfortunetly don’t have a USB keyboard with me so decided I had to figure another way of interacting with this device!
On the documentation it says that the device is preconfigured with IP address of 192.168.0.50, so I set my computer in the same subject range and attempted to telnet into it. It worked no bother and no root password either! Doing a uname -r, it is clear that it is Debian linux that is running on the device, Debian Etch to be percise. An issue of free command confirmed that 64MB ram was actually on this device with about 15MB free, but most of this is taken up by the WM which I won’t have in my project.
An 2GB SD card comes with the SBC (plugged into its slot) which contains images of Linux and a whole ready made cross complimation setup using Eclipse. This card can be hot swapped unlike CF so I took it out and stuck it into my card reader to have a look to see what was on it. It was not readable by 2 of my card readers both on different PCs so I thought something up so. At first I thought it must be because a none native Windows FS but this didn’t make since since Eclipse on it was one for Windows. I stuck it into my SBC again to see if I could read it from Linux. Doing a ls on /dev I could see sdcarddata, sdcarddata1 – sdcarddata4. This suggested to me that there was 4 partitions on the device and looking at the documentation I confirmed this. The first was a 1.5Gig that contains all the files I am looking for so I created a mount folder /mnt/donal/ and mounted the SD card using the command mount /dev/sdcarddata1 /mnt/donal -t vfat. This worked fine and I could view the contents.
I tried taring the whole folder but no room!. I set up a FTP server on my laptop and tried pushing items across. This worked fine for individual files but I wanted recursively to do everything but this doesn’t work with the standard ftp utility in Linux. Next option was SCP so I set up a SSH server on my computer creating an account for the SBC. I could successfully send all files to a home folder on my laptop using the command scp -r * donal@192.168.0.50:/ This transfer took almost 30 minutes but finally I got everything I wanted.
The next thing I was interested in looking at was connecting to the device using a serial connection. Looking at the inittab file, it writes the Kernel output to /dev/ttyAM0 which is the console port of this device. This is accessible by connecting a JTAG board to the SBC’s JTAG connector. I used a null modem cable then from that to my laptop and set the correct settings on hyperterminal (115200, 1S No Parity, 8Data No F/C). I got an output to hypterminal and could enter commands to the shell prompt. Least now I know my USB->Serial adapator works but there are issues with these when timing is involved due to the extra abstraction hardware layer associated with USB.
There were 2 more ports, COM1 and COM2 available on the board. I connected the Serial adapator to the pin outs on the board for COM1 and connected to the null modem. I hadn’t a clue of the baud rate etc for it so I guessed 9600 with the standard 8N1 & no F/C. So how would I test it? – There are no terminal utilities on the SBC. So what i thought of was doing a simple echo and redirecting it to /dev/ttyAM1 so I issued the command echo “Hi Donal!\r” > /dev/ttyAM1 and this worked perfectly so now I know my ports are working.
I created a file using touch hello but the file wouldn’t remain after a restart which suggested to me the NAND Flash was read only. This also lead me to believe there was no swap file and I confirmed this too. This is why firefox froze when loaded I’m guessing! – I will have to investigate if possible to mount a partition from a SD card and link a SWAP to this device. However, will 6MB/S be fast enough I don’t know! – Either way I am going to use the SD card for writing settings and logging data from Automon.
I think that was enough messing with the SBC for now, next I will have to look at how to get QT on it or even re compile a smaller debian image with QT/Extended binaries installed. I think that may be something that I’ll do later down the road though.
Tags
Archives
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Nov | ||||||
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
Blogroll
QT Programming
Single Board Computers (SBCs)
Recent Comments
- Mark Mikaelsen on QT and QExtSerialPort
- Mark Mikaelsen on QT and QExtSerialPort
- Donal on QT and QExtSerialPort
- Dmitriy on QT and QExtSerialPort
- Donal on QT and QExtSerialPort