The thing is, it brings me back to my first C programs. It’s quite hard to come back to some unmanaged, memory limited, namespace less language. I thought the lack of objects would be the hardest part, but in fact it’s not (you can easily emulate it). The hardest part is the lack of namespace and the massive use of “#define”, I really would be happier with a some sort of limited version of C++. The MPLAB development environment is awful (compared to Visual Studio) : no reindenting, no refactoring, no smart-anything. This is WILD for me. It’s like being a citizen in the jungle.
I took back the old Doxygen to add some pretty doc.

I’m doing it step by step, 2 to 3 hours some evenings. I started by being able to use the leds, then the buttons, then the serial port (using the UARTIntC library). Recently I added MiWi protocol support. My two chips are connecting to each other and sending messages to each other just fine.

As you can guess, programming this kind of equipment is much less fun than doing some C# .Net. But it has the major advantage of running on very low-cost (less than 4€) chips.

There are some funny things with the Microchip PIC18 Compiler (MCC18).

If you take this code :
buttons.c :

1
2
3
4

#include "buttons.h"
void buttons_Task() {
    // Some stuff
}

buttons.h :

1

void buttons_Task();

It produces this error :

1

Warning [2058] call of function without prototype

The reason is that you must declare your prototypes with no arguments with a void. You have to declare it as “void buttons_Task(void);”. Well, thank you Microchip for the dumb pre-compiler error messages.

I also discovered that they are two memory (data and program memory).
In one file I had an : “extern unsigned char *var;” and in the other one : “unsigned char var[8];”. The thing is the compiler doesn’t throw you any warning but when you will copy data from this variable, you will get some other data. Because the C programs doesn’t use the same memory in the two cases. MCC18 doesn’t detect this and the debugger doesn’t help much because it chooses one variable.

But the project has been cancelled, so I won’t make this program. But still, I decided to give the format of the file for those who would have the same needs.

everything is Little Endian

1
2
3
4
5
6
7

[ 4 ] - Frame Number (starting at 0) : 00 00 00 00 is frame 1, 01 00 00 00 is frame 2
[ 4 ] - Time 
[ 1 ] - Length of the frame (remember it counts the 2 last mandatory bytes) 
[ 2 ] - Mac Frame Control
[ 0-125 ] - Frame content
[ 1 ] - RSSI
[ 1 ] - Corr + CRC

MSB of this last byte describes if the CRC is OK.

In .Net, making this program is pretty easy. You just have to read the first 9 bytes. You will then read the next X (given by the 9th byte) + 3 bytes. Converting these bytes into a readeable message is easy :

1
2
3
4
5
6
7
8
9
10

var frameHeader = new Byte[] { 
    0, 0, 0, 0, 
    0, 0, 0, 0,
    4
};
var rawFrameNumber = new Byte[4];
Array.Copy(frameHeader, 0, rawFrameNumber, 0, rawFrameNumber.Length); 
if (!BitConverter.IsLittleEndian) // .Net isn't x86 specific
    Array.Reverse(rawFrameNumber, 0, rawFrameNumber.Length);
var frameNumber = BitConverter.ToUInt32(rawFrameNumber, 0);