All sorts of nitty-gritty technical things.

Use PIC Timer2 not Timer0 for accurate Interval Timing on an Embedded system

Recently I was struggling to achieve very accurately synchronised camera and light triggers for a real-time computer vision project that I was working on, my original PIC embedded system for triggering everything using a PIC micro-controller had a fairly reliable accuracy of about 250us which was sufficient for a few years, but for various reasons this needed to be reduced by a factor of 10 to about 25us. The problem was that as I reduced the timer’s overflow period it started to become quite inaccurate and erratic.

It is possible to achieve quite accurate timing on your embedded software system using a PIC, however it can take a bit of work to tune things. Most articles that introduce the use of timers on the PIC use the Timer0 module as an example, maybe because it has a ‘0’ in it?

Now, when using Timer0 to produce a repeated time interval, its High & Low overflow registers must be manually reset in the interrupt handler to setup the next time period, all while the timer is still counting away.

This it makes it difficult to know what values to put into the registers to get an accurate overflow period – you end up trying to account for the interrupt latency and counting assembly instructions in the interrupt handler to estimate times etc.

The upshot is that it’s hard to get a reliable overflow period with a desired accuracy when using Timer0.

Example, initial Timer0 setup code:

void init_timers() {
    // See http://www.enmcu.com/software/timer0calculatorandcodegeneration
    // for values.
    INTCON.GIE=1;         // global interrupt enable
    INTCON.PEIE=1;        // peripheral interrupt enable
    INTCON.TMR0IF = 0x0;  // Clear timer0 overflow interrupt flag
    INTCON.TMR0IE = 1;    // enable the timer0 by setting TRM0IE flag
    T0CON.T08BIT = 0;     // 16 Bit timer
    T0CON.T0CS = 0;       // Internal clock
    T0CON.PSA = 1;        // Set scaler to 1:4
    // Set timer counts
    TMR0H = TIMER_HIGH;
    TMR0L = TIMER_LOW;
    T0CON.TMR0ON = 1;     // Turn Timer0 on.
}
// interrupt handler for the timer overflow
void interrupt(void) {
    // Is this a Timer 0 interrupt?
    if (INTCON.TMR0IF) {
        // yes!
 
        // Reset the timer values
        // These are actually now incorrect
        // as time has elapsed since the timer
        // overflow and now!
        TMR0H = TIMER_HIGH;
        TMR0L = TIMER_LOW;
        
        // Reset interrupt flag
        INTCON.TMR0IF = 0;
        // Increase some counter
        ++counter;
    }
}

The best thing to do is to ditch Timer0 and switch to Timer2 instead. Timer2 automatically handles this kind of pattern (and it’s not much harder to use even though it’s got a ‘2’ in its name!).

When using Timer2 you don’t need to reload the overflow registers and so it is much easier to get an accurate and reliable overflow period! Have a look here if you need help in figuring how to setup Timer2 for your desired timing parameters – it’s very handy!

void init_timers() {
  
    // Have a look at the URL below for setting up Timer2
    // http://eng-serve.com/pic/pic_timer.html
    //
    // Setup Timer2 for 40KHz, period = 25us
    
    // Timer2 Registers
    // Prescaler = 1 - TMR2
    // PostScaler = 1 - PR2 = 200 
    // Freq = 40000.00 Hz 
    // Period = 0.000025 seconds
    T2CON |= 0;         // bits 6-3 Post scaler 1:1 thru 1:16
    T2CON.TMR2ON = 1;   // bit 2 turn timer2 on;
    T2CON.T2CKPS1 = 0;  // bits 1-0  Prescaler Rate Select bits
    T2CON.T2CKPS0 = 0;
    PR2 = 200 - 1;      // PR2 (Timer2 Match value), 200 - 1 (1 = magic value, KG)
    // Interrupt Registers
    INTCON = 0;           // clear the interrupt control register
    INTCON.TMR0IE = 0;    // bit5 TMR0 Overflow Interrupt Enable bit...0 = Disables the TMR0 interrupt
    PIR1.TMR2IF = 0;      // clear timer1 interrupt flag TMR1IF
    PIE1.TMR2IE = 1;      // enable Timer2 interrupts
    INTCON.TMR0IF = 0;    // bit2 clear timer 0 interrupt flag
    INTCON.GIE = 1;       // bit7 global interrupt enable
    INTCON.PEIE = 1;      // bit6 Peripheral Interrupt Enable bit...1 = Enables all unmasked peripheral interrupts
}
void interrupt(void) {
    // Is this a timer 2 interrupt?
    if (PIR1.TMR2IF == 1) {
        // Yes, all we have to do is clear the
        // flag, we don't need to reload any registers!
        // Clear interrupt flag
        PIR1.TMR2IF = 0;        
        ++counter;
    }
}

Once Timer2 is initialised in this manner, it will cycle automatically without the need to reload any values yielding a stable (and hopefully more accurate) time period.

Geotag – EXIF GPS Latitude field format with libEXIF

I have been developing some software to geotag jpeg images by adding EXIF GPS information using libEXIF. This is very handy as loads of applications like GIS systems and google maps etc can correctly geographically position your images.

As usual I started in the middle rather than starting at the beginning and got a bit confused by how GPS latitude and longitude fields are specified in EXIF, so I decided to try to describe it here with pictures (so that I can test out the google drawing app).

So, latitude (and longitude) can be expressed in different ways bit it is essentially just an angle. Common ways of expressing these angles are:

Degrees, minutes & seconds (with decimal places)
N 52 58 40.44

Degrees & minutes (with decimal places)
N 52 58.674

Degrees (with decimal places)
52.97790

The EXIF latitude field allows you to specify the angle in all of these forms, it is made up of 3 parts as follows:

1.) Degrees – Rational (8 bytes)
2.) Minutes – Rational (8 bytes)
3.) Seconds – Rational (8 bytes)

Each part is an EXIF Rational, it is hard to find a description of its format, but a an EXIF rational contains two 4-byte words and is like a fraction. The first word specifies the value’s magnitude while the second denominates the units. Consider the following values, (where ‘/’ should be read as ‘over’ or ‘divided by’):

a.) 52 = 52 / 1 (52 units)
b.) 40.44 = 4044 / 100 (4044 hundredths)
c.) 52.97790 = 52977900 / 1000000 (52977900 millionths)
d.) 0 = 0/1

the last value ( 0/1 ) is handy as it allows us to specify, say, 0 seconds if we only want to provide degrees and fractional minutes.

To set a rational we can use libEXIF’s set_rational() function like this:

//
// 40.44 = 4044 / 100 (4044 hundredths)
exif_set_rational(entry->data, EXIF_BYTE_ORDER_INTEL, { 4044, 100 });
//

or more generally, if, for example, you want to set a value to 6 decimal places:

//
float lat = 52.977900;
exif_set_rational(entry->data, FILE_BYTE_ORDER, { (unsigned)(lat * 1000000.0), 1000000 });
//

So now, given a latitude value in degrees, minutes and seconds all we have to do is create a EXIF_TAG_GPS_LATITUDE tag and add a rational for each. Imagine that we want to encode 52, 58, 44.44 then the tag data will then end up looking like this:

efix gps latitude format degrees minutes seconds

This is all very well but I don’t normally bother holding minutes and seconds in my code, instead I preferr to use a degree value to many decimal places, e.g. 52.97790, no problem, this is where our rational value 0 / 1 comes in handy – it can be represented as follows:

exif gps latitude format decimal degrees

So wrapping all of this up, here is some example code that sets a decimal degree value for latitude:

/*
 * create_tag() is from the write-exif.c sample code that is floating
 * around the interweb - with thanks to whoever created it!
 */
/* Create a brand-new tag with a data field of the given length, in the
 * given IFD. This is needed when exif_entry_initialize() isn't able to create
 * this type of tag itself, or the default data length it creates isn't the
 * correct length.
 */
static ExifEntry *create_tag(ExifData *exif, ExifIfd ifd, ExifTag tag, size_t len)
{
	void *buf;
	ExifEntry *entry;
	/* Create a memory allocator to manage this ExifEntry */
	ExifMem *mem = exif_mem_new_default();
	/* Create a new ExifEntry using our allocator */
	entry = exif_entry_new_mem (mem);
	/* Allocate memory to use for holding the tag data */
	buf = exif_mem_alloc(mem, len);
	/* Fill in the entry */
	entry->data = buf;
	entry->size = len;
	entry->tag = tag;
	entry->components = len;
	entry->format = EXIF_FORMAT_UNDEFINED;
	/* Attach the ExifEntry to an IFD */
	exif_content_add_entry (exif->ifd[ifd], entry);
	/* The ExifMem and ExifEntry are now owned elsewhere */
	exif_mem_unref(mem);
	exif_entry_unref(entry);
	return entry;
}
// Set a decimal degree value with support for 6 decimal places
//
//
  // create our latitude tag, the whole  field is 24 bytes long
  entry = create_tag(exif, EXIF_IFD_GPS, EXIF_TAG_GPS_LATITUDE, 24);
  // Set the field's format and number of components, this is very important!
  entry->format = EXIF_FORMAT_RATIONAL;
  entry->components = 3;
  // Degrees
  float lat = 52.977900;
  exif_set_rational(entry->data, EXIF_BYTE_ORDER_INTEL, { (unsigned)(lat * 1000000.0), 1000000 });
//
//
    

I will probably do another post that details how to write EXIF data into a jpeg image’s header using libEXIF and libJPEG

The google drawing app actually worked quite well!

Nice article about Thread Concurrency and Synchronisation in C++11

I came across this nice article about modern thread usage patters in C++11:

http://www.baptiste-wicht.com/2012/03/cpp11-concurrency-part1-start-threads/

It has a good summary of the synchronisation primitives available in C++11

Windows WPF – Always scroll to end of ListBox when new item added

If anybody is looking for a quick and dirty way of getting a list box to always scroll to its end then have a look here:

http://stackoverflow.com/questions/10884031/wpf-raise-an-event-when-item-is-added-in-listview

Take a look in Item #6, it worked well for me although I am aware that it may be seen somewhat as a hack – but then sometimes WPF just forces you into these situations as it can make it so damn hard to do the simplest of things!

Write jpeg with header comment – boost generic image library (gil)

I had to hack the living daylights out of something today, and although I am not proud of it, needs must where the devil drives!

I was using the boost generic image library (gil) for managing some camera images and using jpeg_write_view() for saving them as JPEGs. A requirement emerged to insert a comment into the header of the saved images, but the gil does not support this out of the box.

The gil uses libjpeg for writing its JPEGs and adding a comment in libjped is as easy as calling jpeg_write_marker(). The problem was that the gil buries libjpeg calls under a few classes so I had to copy and paste some of this in order to redefine a new writer which supports comments.

Anyway I have included the extra code inline below, it adds a new helper function called jpeg_write_view_comment()

Use this new function like this:

 int quality = 70;
 jpeg_write_view_comment("image1.jpg", view, quality, "a comment damn it!!!");

Here is the extra code which I placed in a file called jpeg_writer_comment.h

#pragma once
#include "boost/gil/extension/io/dynamic_io.hpp"
using namespace boost;
using namespace boost::gil;
using namespace boost::gil::detail;
class jpeg_writer_comment : public file_mgr {
    jpeg_compress_struct _cinfo;
    jpeg_error_mgr _jerr;
    void init() {
        _cinfo.err=jpeg_std_error(&_jerr);
        jpeg_create_compress(&_cinfo);
        jpeg_stdio_dest(&_cinfo,_fp.get());
    }
public:
    jpeg_writer_comment(FILE* file)           : file_mgr(file)           { init(); }
    jpeg_writer_comment(const char* filename) : file_mgr(filename, "wb") { init(); }
    ~jpeg_writer_comment() { jpeg_destroy_compress(&_cinfo); }
    template 
    void apply(const View& view,int quality=100, const char* comment = NULL) {
        _cinfo.image_width  = (JDIMENSION)view.width();
        _cinfo.image_height = (JDIMENSION)view.height();
        _cinfo.input_components=num_channels::value;
        _cinfo.in_color_space = jpeg_write_support_private::type,
                                                           typename color_space_type::type>::color_type;
        jpeg_set_defaults(&_cinfo);
        jpeg_set_quality(&_cinfo, quality, TRUE);
        jpeg_start_compress(&_cinfo, TRUE);
        if (comment) {
        	jpeg_write_marker(&_cinfo, JPEG_COM, (const JOCTET*)comment, strlen(comment));
        }
        std::vector::type> > > row(view.width());
        JSAMPLE* row_address=(JSAMPLE*)&row.front();
        for (int y=0;y
    void write_view(const any_image_view& runtime_view) {
        dynamic_io_fnobj op(this);
        apply_operation(runtime_view,op);
    }
};

template 
inline void jpeg_write_view_comment(const char* filename,const View& view,int quality=100, const char* comment = NULL) {
    BOOST_STATIC_ASSERT(jpeg_write_support::is_supported);
    jpeg_writer_comment m(filename);
    m.apply(view, quality, comment);
}

XIMEA xiGetImage() fails and returns 11 (XI_INVALID_ARG) on xiQ USB3 Camera

If you are having problems with xiGetImage() sometimes failing and returning an error value of XI_INVALID_ARG (11) then it may be due to the state of the XI_IMG structure that you are passing into the call (the image pointer argument).

The image object’s .size parameter must be set to sizeof(XI_IMG) and must not be 0. This is not really discussed in the XIMEA API documentation, but if it is left at 0 then the call will fail (however it doesn’t see to have to be sizeof(XI_IMG) for the call to work).

So xiGetImage() should be called like this:

XI_IMG image;
image.size = sizeof(XI_IMG); // Must initialise the .size field
auto res = xiGetImage(handle, timeout, &image);

If you don’t initialize the .size field then you may get occasional fails depending on how the image struct is declared, for example if it is declared as a local variable on the stack then an un-initialised image struct will have random-ish values, the .size field is unlikely to be zero, but it may occasionally be zero and when it is the acquisition will fail.

If however, the image struct is declared as a file static variable then it will always be initialised to 0, .size will always be 0 and the acquisition will always fail!

So remember to always initialise it and you will save yourself lots of head-scratching!

Strange behaviour of std::thread in Visual Studio 2012

Today I came across some strange behaviour with the VS2012 implementation of std::thread. The created thread’s job was to access the XIMEA camera API, one method of thread creation worked ok, and another only half worked.

With the first mode the API could grab from multiple cameras as expected, while with the other it could only grab from one camera – grabbing from the second camera would always fail. To make things stranger the mode that worked required the passing of an un-used argument to the thread function!

Here is the mode that didn’t work:

int t_func() {
	return do_stuff();
}
void start_thread() {
	std::thread t(t_func);
	t.detach();
}

And here is the mode that does work OK, notice the dummy argument that is passed but otherwise unused!

int t_func(void*) {
	return do_stuff();
}
void start_thread() {
	std::thread t(t_func, (void*)NULL);
	t.detach();
}

All very strange!

WPF Application add Console window for stdout etc.

I thought this would be quite hard to achieve, but it turned out to be easy. I wanted my WPF windows app to run with a standard console output so that I could see all tat was written to stdout via printf() etc from some C code that is linked in to the WPF app via a C++/CLI interface. To achieve this it was a matter of setting an application setting as detailed in this post:

http://blog.wpfwonderland.com/2009/03/01/adding-console-window-to-wpf-application/

In summary you just need to change the main App’s ‘Output Type’ setting to ‘Console Application’

Thanks to XAML Wonderland for the post!

Can I use std::thread from a C++/CLI project in Visual Studio 2012

This question seems to produce some confusing and contradicting answers, however the short answer to it is ‘yes, you can’.

You can use std::thread in unmanaged code in a C++/CLI project but not from managed code – but the good thing about C++/CLI is that you can mix managed and unamanaged code.

if you try to use it from managed code you will get an errors like this:

error directive: is not supported when compiling with /clr or /clr:pure.

and this:

error directive: ERROR: Concurrency Runtime is not supported when compiling /clr.

To mark a C++ file as un-managed, go to its C/C++ settings and set its ‘Common Language RunTime Support’ setting to ‘No Common Language RunTime Support’. You can also use the ‘managed’ and ‘unmanaged’ pragmas in your code to do the same, but something about mixing the two in a single file creeps me out!

Possibly the best thing to do is to keep managed code to a minimum (as it’s as ugly as sin) and just use it to interface your .NET code to your native C++ code – which can use std::thread et al. to its heart’s content!

Drupal 7 – Role can’t see unpublished posts, quick and dirty hack

If you want a particular role to see another’s unpublished posts in drupal, then the quickest (and possibility most dangerous) way of achieving this is to grant the role in question this permission:

bypass content access control

It sure aint pretty but it works, use at your own risk!