Skip to main content


Showing posts from September, 2009

Google Search Defaults To Wrong Country TLD in Opera

Opera 10.0 on OS X remembers the non-default country specific google TLD the first time Google redirects it to such a TLD. Having recently visited Australia, my Google search from the toolbar was stuck on; clearing cookies and private data didn't help with that.

The culprit is the following line in ~/Library/Preferences/Opera Preferences:

$ cd ~/Library/Preferences/Opera\ Preferences/
$ grep -r 'TLD Default' *
operaprefs.ini:Keyboard Configuration={Resources}defaults/standard_keyboard.ini
operaprefs.ini:Mouse Configuration={Resources}defaults/standard_mouse.ini
operaprefs.ini:Show Default Browser Dialog=0
operaprefs.ini:Google TLD

All it takes to restore the default google TLD (the US one, in my case) is to quit Opera and remove the highlighted line in operaprefs.ini. Due to this browser's cross-platform nature, it's likely that same approach will work on Windows and Linux. Hopefully it will save some traveller a bit of head …

Pascal-Style Local Functions in C (for Z8 Encore!)

When I was a kid, I used Turbo Pascal. It had one feature that I sorely miss in every embedded C compiler: local functions. Local, as in local to a block. Those become a necessity to maintain decent code performance and avoid the penalty of passing duplicate data via parameters. They also help maintain readable, decently factorized code.

A local function, were C to have it, would look like this:

void fun1(void) {
 int a;
 void fun2(void) {
   a = 0;

I hope you see that fun2() is local to the main block of fun1(), and that the variable a is in scope within fun2().

A somewhat less clean, but equally well performing way of accomplishing this would be:

extern int a; void fun2(void) {   a = 0; } void fun1(void) { ...   fun2(); }
Now the question remains: where do we actually define the variable a, which is supposed to be local to fun1?

It becomes easy if your compiler supports static frames. Static frames are, as their name implies, allocated statically by the linker, and are overlaid according to …

Asterisk 1.4 Update Woes

I admin a CentOS 5 server with Asterisk 1.4 on it, hooked up to an XO T1 link. The repo I use for this is atrpms, which has been pretty much problem-free.

After a most recent upgrade, asterisk would fail to load the dahdi channel driver, with the following in /var/log/asterisk/messages:
WARNING[pid] loader.c: Error loading module '': /usr/lib/asterisk/modules/ undefined symbol: ast_smdi_interface_unref The solution, as hinted by Chris Maciejewski, is to load the module. For whatever reason, my /etc/asterisk/modules.conf had the following line:
noload => Changing it to "load => ..." fixed the problem.

Zilog's Encore!: Changes for Change's Sake, and When Simple Won't Do

I have been using Zilog's Z8 Encore! chips since the first marketed silicon release of Z8F4801, Rev AA. The chip is a nice 8-bit MCU. As nice and useful as it is, its history can't but highlight concerning lack of vision and direction in Zilog's marketing and development efforts.

Let's start with a rather simple thing: the tool used to interface with the chip's one-wire DBG pin. It's nothing more than an autobauding half-duplex asynchronous port, in CMOS voltage levels. Such simplicity was reflected in Zilog's first debug "tool" sold with the early Z8F6401 development kits. It was a small board (approx 1 sq in), with a TTL-to-RS232 converter chip (MAX232, IIRC), a diode standing in for an open-drain driver, the DBG line pull-up, and some decoupling and charge pump capacitors, and two connectors -- one for the 6-pin target header, another for the serial cable.

Soon thereafter it became obvious that RS232 serial ports are being phased out from newly…