Friday, March 13, 2015

XMEGA 32E5: One-shot pulse using the XCL module

As the XCL (short for XMEGA Custom Logic) module found in the new XMEGA E series is a completely new peripheral not found in any previous Atmel chips, documentation and example code is fairly scarce. After taking the plunge and attempting to implement a one-shot pulse as described in AT01084 (Section 4.8.4), I found that the latest Atmel Software Framework (v3.22.0) has forgotten this particular XCL timer/counter operating mode! Perhaps it just isn't as popular as the other modes? But it's incredibly useful if you need a simple way to send a pulse to turn on an external device such as a PC (without using software delays or interrupts in your code).

Anyway, to be more specific on the omission: ASF is missing the One-Shot PWM mode enumeration in the xcl_tc_mode_t enum type (bug report).

Here are the modes listed in AT01084 (Section 4.8):

Not a big deal - we just need to manually specify the MODE mask (0x03) when calling the xcl_tc_mode() ASF function. After that, it's smooth sailing!

In the below example, we will output a logic-low pulse with a fixed duration (after a certain optional delay) on Port D Pin 2.

A few notes before we get into it:
  • With a 2 MHz peripheral clock:
    • 16-bit XCL timer/counter allows a pulse length of up to ~33.5 seconds.
    • 8-bit XCL timer/counter allows a pulse length of up to ~131 milliseconds.
  • Pulses can be output on either PD2 and/or PD3:
    • 16-bit XCL timer/counter: the pulse can be outputted on PD2 only.
    • 8-bit XCL timer/counter: in this case, as we have two separate timers, two independent pulses with different timing characteristics can be outputted on PD2 and PD3.

 

Example:

 

1. Initialize the XCL module and configure to output a one-shot pulse:
xcl_enable(XCL_SYNCHRONOUS);
xcl_port(PD);
xcl_tc_type(TC16);
xcl_tc_mode(0x03);  // MODE[1:0] = 2b'11 : One-shot PWM mode
xcl_tc_source_clock(DIV1024); // Starts timer

2. Set OC0 (PD2) as an output pin and also set inverted so we get a low pulse:
PORTD.DIR = 0x04;
PORTD.PIN2CTRL = PORT_INVEN_bm | PORT_OPC_TOTEM_gc | PORT_ISC_BOTHEDGES_gc;

3. Function to generate the one-shot pulse:
void pulse(uint16_t wait_ms, uint16_t pulse_len_ms)
{ 
    uint16_t _wait_ms = wait_ms / ((1024.0 / F_CPU) * 1000);
    uint16_t _pulse_len_ms = pulse_len_ms / ((1024.0 / F_CPU) * 1000);
   
    // Stop any currently in progress pulses
    xcl_disable_oc0();
    // Start at CNT
    xcl_tc16_set_count(_wait_ms + _pulse_len_ms);
    // Pulse begins at CMP and ends at BOT
    xcl_tc16_set_compare(_pulse_len_ms);
    // Start timer
    xcl_enable_oc0();
    xcl_tc_restart(RESTART_TIMER0);
}

4. Now we simply call the above function with our desired parameters:
pulse(500, 1000); // Delay 500 ms then output 1000 ms pulse on OC0

5. Voila! No interrupts or software delays needed! Easy!
 

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: