Thursday, November 7, 2013

Design Learnings

Back in August, I was invited to share a selection of my personal electronics "design learnings" to a class of Monash University 3rd-year electrical engineering students. The class itself is centered around a design challenge where students would spend the entire semester planning, designing, prototyping and testing a robot to perform a specific task, which would then have to compete against other team's robots at the end of the semester (video from 2012). The presentation focused on a number of simple things which are often overlooked during the design process, but in a competition such as this, could ultimately give your design an edge in terms of reliability and performance. Topics covered were:
  1. Conserving Power
    1. Regulator choice
    2. ADC input circuit
    3. MCU operating conditions
  2. Circuit Protection
    1. Input supply protection
    2. Undefined MCU pin states
    3. MCU input pin protection
  3. Firmware
    1. Watchdog timer
    2. Real-time operating system (RTOS)
  4. PCB Design
    1. Level translation
    2. Filtering
Download Presentation [1.71 MB]
Download Presentation (Updated 2014) [2.32 MB]

Sunday, November 3, 2013

VT6656 WLAN driver on Ubuntu 12.04

For reasons unclear, Ubuntu Precise and Quantal (3.2/3.5) releases do not contain the VT6656 WLAN driver (deliberately). Nevertheless, the driver can still be manually built and installed.

The following procedure has been tested with Linux kernel 3.5.0-42 and 3.5.0-43:

1. Install build tools:
$ sudo apt-get install build-essential linux-headers-`uname -r`

2. Get driver source code (specific commit tested in this procedure):
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git
$ cd wireless-next
$ git checkout master-2013-10-18
NOTE: If the target machine does not have network connectivity, perform the above step on a machine which does and the copy the files to the machine manually.

3. Modify Makefile (wireless-next/drivers/staging/vt6656/Makefile):
A) Comment out (with a #): obj-$(CONFIG_VT6656) += vt6656_stage.o
B) Add: obj-m = vt6656_stage.o

4. Build driver:
$ cd drivers/staging/vt6656
$ make -C /lib/modules/`uname -r`/build M=`pwd` modules

5. Make a new directory for the driver in the kernel modules directory:
$ sudo mkdir -p /lib/modules/`uname -r`/kernel/drivers/staging/vt6656

6. Copy the new driver to the kernel modules directory:
$ sudo cp vt6656_stage.ko /lib/modules/`uname -r`/kernel/drivers/staging/vt6656/

7.  'do' a depmod:
$ sudo depmod -a

8. Reboot.

Reference(s):

Sunday, April 15, 2012

PandaBoard ES: Getting Started with Ubuntu 12.04 LTS Desktop

The following is a basic starter guide in getting Ubuntu 12.04 LTS Desktop running on the recently released PandaBoard ES:

1. Download the Ubuntu 12.04 LTS pre-installed desktop image for OMAP4 here (direct download link: ubuntu-12.04-preinstalled-desktop-armhf+omap4.img.gz).

2. The downloaded file from Step 1 will be a GZIP archive containing a RAW file - use ImageWriter for Windows to write this RAW image file to an SD card [I used a Sandisk Extreme Class 10 16GB 30MB/s SDHC].

Note: It also good practise to check the MD5 hash of the downloaded GZIP archive before doing this. This can be done by loading the archive in ImageWriter and ticking the MD5 check-box. The program will then calculate and display the hash (takes a few minutes). Compare this value with value contained in the "MD5SUMS" file on the download page in Step 1.

3. Setup the PandaBoard ES hardware:
  • Insert the SD card prepared in Step 2.
  • Use the HDMI connector adjacent to the USB/Ethernet sockets to connect the PandaBoard to a suitable display. I used a Dell U2412M UltraSharp 24” monitor with a DVI-HDMI adapter.
  • Connect a USB keyboard and mouse. I connected these via a powered USB hub.
  • Finally, connect a 5V DC power supply to the board (ensure that it is centre-pin positive). I used a 3A rated supply.

4. The PandaBoard should now begin booting from the SD card after the power supply is connected (Note: Both STATUS and STATUS2 LEDs should become momentarily lit after power is connected).

If the SD card was prepared correctly, Ubuntu will first resize the image to fill the SD card and then reboot and start oem-config to prompt for localization and user info.

5. After Ubuntu has successfully booted, you may be prompted to install the PowerVR SGX propreitary graphics driver for OMAP 4. From my initial tests however, I found that this driver did not render the desktop widgets correctly. After installation of this driver, I also discovered that I couldn't bring up an instance of Terminal with the Control-Alt-T shortcut. So for the time being, I recommend using the stock graphics driver supplied with Ubuntu 12.04 LTS.

6. Finally, connect to the internet either via the on-board WiFi or Ethernet and update your Ubuntu installation by typing the following in Terminal (use Control-Alt-T to open an instance of Terminal):
$ sudo apt-get install
$ sudo apt-get upgrade
All in all, the installation procedure was extremely straight-forward with no major issues. Time-to-boot from plugging in the power supply to fully loading the Ubuntu desktop was approximately 45 seconds. One strange thing I found however is that Ubuntu (with the stock graphics drivers) does not always boot in the higher resolution of 1680x1050 - it may also sometimes boot in 1024x768. Also, choosing Restart again in Ubuntu to reboot the device does not always work - the power supply must be physically removed and re-inserted to re-boot the PandaBoard if this occurs.

UPDATE (13th May 2012):

There currently exists a yet-to-be-fixed bug in the 12.04 OMAP4 release which causes the PandaBoard to eventually freeze after certain amount of time (usually an hour or so). The following is a workaround which fixes the issue:
$ update-rc.d ondemand disable
$ apt-get -y install cpufrequtils
$ echo 'ENABLE="true" GOVERNOR="performance" MAX_SPEED="0" MIN_SPEED="0"' > /etc/default/cpufrequtils
$ cpufreq-set -r -g performance
UPDATE #2 (14th August 2012): The above mentioned bug has been patched into the mainline kernel (tested and OK with 3.2.0-1416-omap4). Run sudo apt-get upgrade after a clean install as described above.

Saturday, February 4, 2012

qt-opencv-multithreaded: v1.21 Released

A custom ROI set with canny edge detection on.

After around 6 months since I last updated my qt-opencv-multithreaded project, I've finally released what I consider, more-or-less, a "final" version of the application. A few features have been added such as the ability to choose the priorities of the capture and processing threads at run-time, as well as the option to drop frames if the image/frame buffer is full (this is useful when lag is undesirable - i.e. not every frame is processed). The interface has also been neatened and the code has been simplified as well (a lot of redundant code has been removed), making the application much more easier to modify than before (see full list of features here).

From the beginning it was my intention to keep the application simple in the hope that it would be used as the base for a range of interesting projects. I now feel that it has enough basic features to be an excellent "base application" for any computer vision application using OpenCV and Qt. As a result, any updates in the future will only address bugs in the program (please do contact me if you happen to find any!).

This "base application" was used (and is currently still being used) as the base for software written as a part of my university undergraduate thesis project (see video here). In short, the software features two extra threads with the GUI highly modified to suit the project application and over the last year or so, has proven to be highly stable.

As before, please go to the project page at Google Code to download the application and for more details (including installation and usage instructions). Any feedback/suggestions/questions would be greatly appreciated. I'd also like to thank everyone who has downloaded and tried the application so far!

Camera connect dialog showing new options to select thread priority and drop frames.

 

AVR XMEGA uC/OS-II Port (UPDATE):

I've also added v2.92.01 [currently the latest (last?) version of uC/OS-II] port files to the AVR XMEGA uC/OS-II Ports project page. Enjoy!

Links:

Saturday, April 9, 2011

uC/OS-II on the AVR XMEGA

Although the files have been quietly available to download from my site for a couple of weeks now [here], I'd just like to give a little bit more exposure to using uC/OS-II as a real-time operating system on the AVR XMEGA series of microcontrollers.

A port of uC/OS-II for the XMEGA was released quite some time ago by Micrium, however, this port was designed specifically to run on the STK600 - a relatively expensive development board produced by Atmel. It was therefore my goal to modify this original port and create a more universal port which could be used on both Atmel's low cost XMEGA evaluation boards (AVR XMEGA-A1 Xplain & the newer Xplained) as well any custom XMEGA-based board (after some simple modifications).

As a result, I have made available to download two full AVR Studio 4 projects [see link at bottom of page]:
  • uC/OS-II v2.91 for the AVR XMEGA-A1 Xplain
  • uC/OS-II v2.91 for the AVR XMEGA-A1 Xplained

Terminal application connected to the AVR XMEGA-A1 Xplain running uC/OS-II v2.92.01

On an unrelated note, my qt-opencv-multithreaded project hosted over at Google Code has reached over 130 total downloads in two months - I never expected it to be this popular! For all those interested in creating OpenCV-based computer vision applications, please do check it out - as always, I appreciate any feedback and suggestions. Stay tuned for the next version of the application where I hope to incorporate the option of using OpenGL to display the frames and also utilize the new OpenCV C++ interface.

Links:

Wednesday, March 2, 2011

HOW TO: Peter Fleury's I2C Driver and the AVR XMEGA

Even though the AVR XMEGA microcontroller features multiple hardware Two-Wire Interfaces (i.e. I2C interfaces), there may be times when it is simply not possible to use them because the pins to these interfaces are already in use (as I have experienced). Fortunately, the I2C interface can be emulated in software using regular I/O pins by "bit-banging".

This post will explain how to modify Peter Fleury's I2c Master Interface library to work with the XMEGA. Modifications are necessary due to the fact that unlike other AVRs, XMEGA I/O port registers have addresses outside the I/O space and thus must be mapped to "virtual ports" (which have registers in the I/O space) for this library to function.

1. Download the I2C Master Interface library from Peter Fleury's website (here) or here and unzip.

2. The only file which needs to modified is i2cmaster.S:

Original (Lines 41-56):

;***** Adapt these SCA and SCL port and pin definition to your target !!
;
#define SDA4                     // SDA Port D, Pin 4
#define SCL5                     // SCL Port D, Pin 5
#define SDA_PORT PORTD           // SDA Port D
#define SCL_PORT PORTD           // SCL Port D

;******

;-- map the IO register back into the IO address space
#define SDA_DDR        (_SFR_IO_ADDR(SDA_PORT) - 1)
#define SCL_DDR        (_SFR_IO_ADDR(SCL_PORT) - 1)
#define SDA_OUT         _SFR_IO_ADDR(SDA_PORT)
#define SCL_OUT         _SFR_IO_ADDR(SCL_PORT)
#define SDA_IN         (_SFR_IO_ADDR(SDA_PORT) - 2)
#define SCL_IN         (_SFR_IO_ADDR(SCL_PORT) - 2)

 

With Modifications (Lines 41-56):

;***** Adapt these SCA and SCL port and pin definition to your target !!
;
#define SDA            0
#define SCL            1
#define SDA_PORT       VPORT0_OUT
#define SCL_PORT       VPORT0_OUT     

;******

;-- map the IO register back into the IO address space
#define SDA_DDR        (_SFR_IO_ADDR(SDA_PORT) - 1)
#define SCL_DDR        (_SFR_IO_ADDR(SCL_PORT) - 1)
#define SDA_OUT         _SFR_IO_ADDR(SDA_PORT)
#define SCL_OUT         _SFR_IO_ADDR(SCL_PORT)
#define SDA_IN         (_SFR_IO_ADDR(SDA_PORT) + 1)
#define SCL_IN         (_SFR_IO_ADDR(SCL_PORT) + 1)

3. The next step is to map the appropriate port (the one containing the pins which you will use as the I2C interface) to the virtual port as defined in the modified code above (Virtual Port 0 has been chosen).

For example, the following will make PORTA PIN0 SDA and PORTA PIN1 SCL:
PORTCFG.VPCTRLA = PORTCFG_VP0MAP_PORTA_gc;
(This line of configuration code must be placed in your C source file and should be executed before initializing and using the I2C interface).

Of course, the port and pin mappings can be changed to suit your particular needs.

Note: It is possible to have SDA and SCL on different ports by using two virtual ports. Also note that register VPCTRLA configures Virtual Port 0 and 1 whereas VPCTRLB configures Virtual Port 2 and 3.

4. Next we must modify the i2c_delay_T2 assembly function (also in i2cmaster.S) to give the appropriate delay:

 

Original (Lines 66-83):

;*************************************************************************
; delay half period
; For I2C in normal mode (100kHz), use T/2 > 5us
; For I2C in fast mode (400kHz),   use T/2 > 1.3us
;*************************************************************************
        .stabs    "",100,0,0,i2c_delay_T2
        .stabs    "i2cmaster.S",100,0,0,i2c_delay_T2
        .func i2c_delay_T2    ; delay 5.0 microsec with 4 Mhz crystal
    i2c_delay_T2:    ; 4 cycles
rjmp 1f              ; 2   "
1: rjmp 2f           ; 2   "
2: rjmp 3f           ; 2   "
3: rjmp 4f           ; 2   "
4: rjmp 5f           ; 2   "
5: rjmp 6f           ; 2   "
6: nop               ; 1   "
    ret              ; 3   "
        .endfunc     ; total 20 cyles = 5.0 microsec with 4 Mhz crystal

With Modifications (Lines 66-85):

The following modification assumes a 2MHz clock and that the I2C interface is operating in Normal Mode. Use R17 (thanks Joerg!).

Note: Use the AVR Delay Loop Generator program to generate appropriate ASM delay functions for other combinations of clock frequency and I2C modes.

;*************************************************************************
; delay half period
; For I2C in normal mode (100kHz), use T/2 > 5us
; For I2C in fast mode (400kHz),   use T/2 > 1.3us
;*************************************************************************
        .stabs    "",100,0,0,i2c_delay_T2
        .stabs    "i2cmaster.S",100,0,0,i2c_delay_T2
        .func i2c_delay_T2    ; delay 5.0 microsec with 2 Mhz crystal
    i2c_delay_T2:             ; 4 cycles
; =============================
;    delay loop generator
;     3 cycles:
; -----------------------------
; delaying 3 cycles:
          ldi  R17, 01
WGLOOP0:  dec  R17
          brne WGLOOP0
; =============================
    ret              ; 3 cycles
        .endfunc     ; total 10 cyles = 5.0 microsec with 2 Mhz clock

5. Finally, follow the documentation provided by Peter Fleury (here or in the archive downloaded in Step 1) to correctly initialize and use the I2C interface.

 

Update (5th March 2011): 

This library doesn't seem to work correctly when using the XMEGA internal 32MHz clock (even after modifying the delay routine appropriately). I'll post another update when this issue has been resolved.

 

Update (13th March 2011):

After modifying the delay routine (i2c_delay_T2) to reduce the I2C clock down to 20kHz (or 10kHz), I was able to successfully communicate with my slave device with the XMEGA clock set at 32MHz. Admittedly though however, the slave device (Texas Instruments bq20z65-R1) I used to to test this driver actually uses the SMBus protocol and it therefore must be noted that the SMBus and the I2C bus are usually compatible with each other - with complete compatibility only ensured at clock speeds below 100kHz.

 

Links:

Thursday, February 24, 2011

qt-opencv-multithreaded: v1.12 Released

A custom ROI set with canny edge detection on.

This multithreaded Qt-based OpenCV application was first released mid-January this year on Google Code (here) and since then a few minor changes (mostly coding style and GUI-related) to the original application have been made.

This program was originally written to serve as basic "framework" application for my undergraduate project which required the tracking of multiple moving objects (using OpenCV). The initial implementation of the tracking program simply used a large "while" loop which first captured a frame from the camera and then performed image processing on it - a sequential process. It soon became apparent that as the image processing became quite intensive, not only did the responsiveness of the Qt-based GUI suffer, but the frame processing rate also decreased drastically (resulting in "dropped" frames).

As a result of this, I decided to re-write the entire tracking program from scratch using separate threads for the capturing of frames from the camera and the image processing. This was a logical decision considering the increasing popularity (and low cost!) of multi-core processors in both laptops and desktops nowadays.

I have intentionally kept this program quite simple so it can be easily modified to suit the needs of any Qt GUI-based computer vision project using OpenCV. Several in-built (and user-settable) OpenCV image processing functions have also been included so that multithreading performance can be assessed (see full list of features here).

In short, this application takes advantage of multithreading to allow frames to be captured from the camera while at the same time performing image processing. In other words, once a frame has been captured from the camera, the application does not have to wait until image processing is performed on that frame before it starts capturing a new frame - instead a new frame is captured, added to a FIFO queue and is processed a short time later.

Please go to the project page at Google Code to download and for more details (including installation and usage instructions). Any feedback/suggestions/questions concerning this "framework" application would be greatly appreciated. I hope it serves as a basis for many interesting computer vision projects in the future!


Processing Settings dialog used to customize the in-built OpenCV functions.

Links: