I’m using Netbeans as my IDE to build embedded linux application. Here’s the small guide to setup your Netbeans for cross compiler IDE.

Setup The Toolchain

I’m using CodeSourcery GCC toolchain for my TS-7260 ARM9 board. Download their lite toolchain package, and install it somewhere in your system. For me, I installed it into $HOME/CodeSourcery. It doesn’t matter where you put it, as long you can remember its place.

Setup The Netbeans

I’m using the new Netbeans 6.5. Download and install it (anywhere you like). Then run it. Open Tools->Options->C/C++.

On your left pane, there’s Tool Collection pane. Click add..Fill the Base Directory field with the directory where you put the CodeSourcery (until bin/ directory). Fill the Tool Collection Name with the name of the toolchain (I named it CodeSourcery_ARM_Toolchain, but you can choose anything that you like).

After that, fill up the C/C+/GDB compiler path (eg. take a look at the 1st picture).

Ok that’s it. Now your Netbeans can be used as IDE for CodeSourcery’s cross compiler.

Testing Your Setup

Create new C/C++ project: File ->New Project->C/C++->C/C++ Application. Let’s name our test project as ts_hello, and leave everything (except for the name) as default. Once the project is created, modify its properties: Right click the project name on Project View->Properties.

Goto Build->Tool Collection, and select the cross toolchain.

Then, goto the C Compiler->Additional options. This is where you inform the compiler what kind of target architecture that you want. For TS-72xx, add “-march=armv4t -static“. For TS-78xx, add “-march=armv5t -static“.

That’s it. The project is now configured for ARM920T target.

Now, for the infamous hello world program, add new C files on the project, and type:

#include
#include

/*
 * Hello world for TS-7260 with Netbeans 6.5
 */
int main(int argc, char** argv) {
  printf(“Hello Worldn”);
  return (EXIT_SUCCESS);
}

Remember this carefully, you are cross-compiling. You cannot run the binary on your host (ie. on your PC). What you can do is build the binary, put it inside the ARM’s root filesystem, and run it from your board. So, goto Run->Clean and Build Main Project to compile the program.

If everything is okay, copy the ts_hello executable file into your root fs (I’m using NFS, so I just need to copy it locally). Like this:

# sudo cp dist/Debug/CodeSourcery_ARM_Toolchain-Linux-x86/ts_hello /nfs/tmp/mnt/root/

Then boot your board, and run your hello world with:

# ./root/ts_hello

To optimize the AVR’s power consumption, you will need to modify its power mode according to the peripheral that you need at that time.

This is the part of the TinyOS ATMega128 driver that you can use directly (without TinyOS). It will select the best power mode for the MCU, based on the peripheral(s) that is active.

uint8_t getPowerState() {
// Note: we go to sleep even if timer 1, 2, or 3’s overflow interrupt
// is enabled – this allows using these timers as TinyOS “Alarm”s
// while still having power management.

// Are external timers running?
if (TIMSK & ~(1 << OCIE0 | 1 << TOIE0 | 1 << TOIE1 | 1 << TOIE2) ||
ETIMSK & ~(1 << TOIE3)) {
return SLEEP_MODE_IDLE;
}
// SPI (Radio stack on mica/micaZ
else if (bit_is_set(SPCR, SPE)) {
return SLEEP_MODE_IDLE;
}
// A UART is active
else if ((UCSR0B | UCSR1B) & (1 << TXCIE | 1 << RXCIE)) { // UART
return SLEEP_MODE_IDLE;
}
// I2C (Two-wire) is active
else if (bit_is_set(TWCR, TWEN)){
return SLEEP_MODE_IDLE;
}
// ADC is enabled
else if (bit_is_set(ADCSR, ADEN)) {
return SLEEP_MODE_ADC;
}
else {
return SLEEP_MODE_PWR_DOWN;
}
}

How to use it ? Simple, just call the function to select the correct power mode, before going to sleep. Like this:

while(1)
{
// do homework before going to nap

// Take a nap
set_sleep_mode(getPowerState());
sleep_mode();
}

Therefore, you can turn on/off your peripheral while optimizing the power mode selection on the fly. Nice invention from TinyOS’ contributor.

Anyway, the function is not covering the whole AVR’s peripheral (and its sleeping mode), but I guess you got the catch.

What’s the thing that I don’t like from NesC ? Well, it doesn’t have any of IDE. I heard that Eclipse has plugin for NesC/TinyOS, but I’m too lazy to download and install whole 210MB of Eclipse, just to have NesC’s IDE.

My solution was to use simple editor, such as jEdit, then add some plugin to execute Makefile and highlight the NesC/TinyOS syntax.

Here’s the how to

Syntax Highlighting

1. Download the archived files from here
2. Find the jEdit local settings directory. In linux, it will be $HOME/.jedit
3. Check whether $HOME/.jedit/catalog fle is empty or not.
4. If it is empty, untar the file in $HOME/.jedit/modes directory
5. If it is not empty, copy the nc.xml into $HOME/.jedit/modes directory. Thus, add this line in the $HOME/.jedit/modes/catalog file: <MODE NAME=”nesc” FILE=”nc.xml” FILE_NAME_GLOB=”*.nc” />
6. Restart jEdit

Additional notes:

• Some NesC files that have been opened before this mode is added will not be highlighted. Delete the recent.xml and history file in $HOME/.jedit
• You can have this syntax highlight as global (affected all the jEdit users in the system), by replacing the path of $HOME/.jedit to <your_jEdit_installation_directory>
• This howto is tested using jEdit 4.3pre15, and Java 1.6.0

Makefile Execution

> Coming up very soon

I’m having trouble debugging the AVR-to-GSM modem serial communication.

Fortunately, my colleague has made me a circuit to view the communication. Unfortunately, it takes two serial ports just to debug the serial communication while my laptop doesn’t have any serial ports (I use USB-serial converter). So, I was thinking to buy another USB-serial converter, before I was struck by this idea.

Here’s the simplest circuit to debug the RS232 serial communication between two devices:

RS232 Sniffer/Monitoring Schematic (taken using gEDA-gschem)

Believe it or not, although the signal that’s received by the sniffer is not 100% perfect, this circuit works !!

For diode, I use 1N4004 power diode (since that was the only thing that was inside my pocket). But if you want to make it better, I suggest to use Schottky diodes (since they have low forward voltage and fast recovery).

Anyway, there are other things that you should know too before using this circuit. First, you cannot use this circuit to debug full duplex communication (data is sent while other data is received at the same time). Second, the baud rate is limited by the choice of your diode (that’s why you need fast recovery diodes).

Additional Info

There’s other version of this circuit. Like this:

You can refer to the original site for the details of this circuit.

I’m using Linux, and tools like Window’s Hyperterminal to debug your serial port is rare, difficult to use, unpractical, and I have to live with it =) So, after moving here and there, I finally choose my favorite serial debugger in Linux: GNU Screen.

Here’s some tips to use it for your debugging:

• Opening serial port (with the correct baud rate)
  

bash> screen /dev/ttyUSB0 57600

/dev/ttyUSB0 is the serial port, while 57600 sets its baud rate into 57600bps.

• Enable the CTS/RTS handshake

bash> screen /dev/ttyUSB0 57600,ctsrts

• Close the screen after you finish the debugging session

Ctrl + A + k

• View your serial port status (CTS/RTS/DTS/PE/RI..etc)

Ctrl + A + i

I’m designing battery powered embedded systems. Here’s some lessons that I got in my daily work.

• 1000mAH battery should last 10 hours under 100mA continous load, right ?

Whoops…Read carefully on the battery datasheet —if you are serious about your work, you should have serious battery supplier vendor which supports you with real datasheet and/or battery sample =).

1000mAH claim is based on how much continous current draw that your system take. Most of the batteries will die sooner, if you load them more than the datasheet requirement. I’m taking Energizer E91 battery as example.

Under 25mA continous load, the battery has 2750 mAH capasity. Under 100mA continous load, the battery has only around 2000mAH.

This is the characteristic of battery’s chemical reaction. Battery’s cathode has limited ability to absorb ion from the anode. Therefore, under heavy load, there’ll be a layer of ion covers the battery’s cathode. The heavier the load is, the thicker the layer will be. This layer will prevent other ion from anode to reach cathode. Hence, reduce the total capasity of the battery under continous load.

So, to predict how long your system will run, you will need to average your current draw, and match it with the battery’s datasheet.

• Slew rate and battery

Like I said, the battery has limited capability to absorb ion from the anode (or battery has limited current that can be delivered in a time). To load battery with higher current, you need to increase the load gradually and slowly. If, you push high load suddenly, the cathode may be broken. This is the explanation why rechargeable battery that was shorted (and has not exploded or burned yet) cannot recover its full capasitance.

The same principle also applies to the slew rate. High speed systems usually have higher slew rate. Therefore, it’s able to draw current higher than the battery’s cathode can supply in a time. This may damage the battery. If the battery is rechargeable, this will reduce its charging life.

My suggestion is use capasitors to reduce the current spikes in your system. My experience with this is using the oscilloscope with the resistor in series with the battery. Then, adjust the capasitors (by soldering/desoldering them on board) until the spike slope is reduced. It’s not easy, but designing the best products have never been easy anyway.

• Can we extract more power with boost regulator ?

This is the thing that I bet you’re thinking when designing battery powered system. If the battery is low, can we use boost regulator ?

Be careful with the boost regulator. Boost regulator has great efficiency (90%-98%) only if the difference between input-output voltage is low (refer to the boost regulator datasheet). If the difference between input and output is too high, the efficiency is greatly reduced (from 60%-80%..Refer to the datasheet). It means that if the battery is low, more power is needed to boost the voltage than doing the job.

The solution for this is to design the system with minimum operational voltage. The next step is to design the boost regulator to shutdown the system (stop regulating) if the minimum operational voltage reached. This is important, since most of batteries will have zero voltage right after their capasity is finish (its voltage will not gradually down again).

In the diagram, the boost regulator should stop working before 0.9V reached.

In battery application, after the system is off for some time, the battery voltage will rise again. This may trigger the system to active. However, since there’s no capasity left, the battery will drop dead soon. So, it’s like bouncing ball..the system is on, then off, then on, then off again..This may create trash data logged into the system.

To prevent this kind of problem, add delay in the boost regulator. So, the system will on, only if the battery is stabile for some time.