Blog Moved!


Just a quick post to tell y’all that I eventually moved my blog to another hosting and domain.

So here is my new blog, more contents, more updates:


| Leave a comment

Stripping Down my old Laptop

A rather hot subject in embedded development are set top box tv’s. Instead of buying a new android product, I decided to reuse my old laptop, featuring a nice coure duo by Intel. Back in 2006, I was impressed at how autonomous it was (up to 3 hours!) and how well it managed multithreading.

Now, it is stripped down to a bare motherboard and a Screen:

The first thing I did, after I removed the keyboard, was cleaning it up. I used domestic cleansing alcohool, as we would do to remove the solder flux in production. To give you an insight on how much it was needed, the keyboard has been unusable for a year before the tear down due to a drink spill. I also used to eat breakfast in front of it in my student’s room, with the occasional bread dropping in the coffee…

The next thing I did was installing Linux on it, to make it boot fast, and browse the internet. What a set top box is meant to do.

The next step will be to oil-cool it. I am now looking for a case large enough to use, I will keep it posted here.

Posted in Hardware | Tagged , , | Leave a comment

Microchip MPLAB X IDE

There are a lot of things that allow for fast and cheap prototyping using Microchip’s PICs: Extended software stack, relatively cheap full compiler licence and a sufficient limited version are the main assets of the Microchip PIC development environment. One thing that was trailing behind is the IDE.

The philosophy behind the MPLAB IDE though is a good one: in one tool, you could have a code editor, makefile generator and a real JTAG debugger / programmer. One major drawback though is that the editor was not based on an industry standard editor. So they decided to change this and ported the same feeling to a NetBeans base. ( This was supposed to add the missing functionnalities (code completion / multi project handling)

But  they started by releasing a VERY Beta version, for the least ( named 4.0 ). In this version, I had code completion all right, but bad memory use feedback, poor reading capabilities over JTAG and a lot of things that were necessary with the V8 were buggy.

The good news now is that they fixed all of this, and I consider the MPlab X Beta 6 good enough to start working on large projects with it. You can find it here: . On what I have tested so far, it never failed:

  • Importing an existing V8 Project
  • Using Linker files
  • Managing Code size
  • defining Macros for the project

So all in all, it seems to be working, and it is an IDE on a very modern base, close to Eclipse, that realy communicates directly with the chip. And that is important, I can only regret the loss of productivity when a manufacturer forces you to have an IDE to manage projects and compile, an external code editor for a better auto completion and finally a flash JTAG programmer / debugger, all of which come at a cost.

If you agree or disagree, or have any remark related to the MPLAB IDE you want to share, don’t hesitate!

Posted in Embedded && / || Software | Tagged , , , , , | Leave a comment

Getting an HID Host Project Running with VC++

I used to find it almost impossible to integrate the WinDDK HID API in a program easily. Even though the SDK path has some sort of integration, when it comes to building drivers, it seems that Microsoft would prefer if you set up an entire project using only the DDK components. So when you are just interested in a simple API budled into the DDK, handling other Windows API’s becomes Mind-Blowing. Here is a list of the workarounds I came accross, depending on various version mixes of the Visual Studio / WinDDK versions.

First of all, you have to know that in order to implement the setupapi for an HDI device for instance, you only need to successfully compile and link two “visible” files that will link and include all the other files

#include <setupapi.h>  #include <hidsdi.h>

Ok , now, it is not that simple. It is striked out because these are C headers. Moreover, they need Windows.h to be understood! So here are the correct inclusions:

#include <Windows.h>
extern "C"
#include <setupapi.h>
#include <hidsdi.h>

Try to compile this with the added include path being only the one to the relevant operating system (eg: Winddk/inc/win7/i386). It shouldn’t work, since we didn’t take cae of the libraries. But it can still fail before the linker step. If you are seeing errors like “undefined” “Syntax error before”, this means that your Windows.h is not compatible with the DDK. This case we will see afterwards.

So now, you have a project that does not link. But whoo, it does find and understand all the headers it needs. You need two libraries now to make it work: setupapi.lib, and hid.lib. Rather than adding the generic libraries path, I’d rather add the two existing libraries in the project (right-click in the project explorer, add existing item).

In case the link still fails, there is a nice #pragma declaration I came accross :
#pragma comment(lib, “hid.lib“)
This should force the linker to use your library. Of course, Visual Studio still needs to know where hid.lib is, so either copy it to your project, or add the location in the libraries search path.

Now, back to the first step, in case the compiler failed to understand the headers, you have two choices: Move to a newer version of Visual Studio, or an older version of the stack (I would understand why tou wouldn’t want that); OR, you can only use the WinDDK libraries and headers to compile and link. In this case, remove all of the inherited headers and libraries, and add all the relevant links of the winDDK directory. I have tried but only to find out that building only with what is included in the winDDK makes it very difficult, or impossible, to use a form created with Visual studio and the stdafx stuff. This solution is far from satisfactory most of the time, but you should know it is possible if you don’t plan on using external components.

I hope this post explained or got you a solution for setting up this type of project. Please give me a feedback wether it was useful or not! In case you wonder, this is the type of errors you can get:

error LNK2019: unresolved external symbol _HidD_GetHidGuid@4 referenced in function "public: __thiscall UsbDevice::UsbDevice(void)" (??0UsbDevice@@QAE@XZ)
setupapi.h(60): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
setupapi.h(60): error C2143: syntax error : missing ';' before '*'

One more note, the setupapi is also available in the sdk, not just the ddk. I guess this might trigger other issues…

Posted in Embedded && / || Software | Tagged , , , | Leave a comment

Project Macros for Visual C++

Just a very quick post before I forget.
I like the default settings of naming the output as the project name and so on in VC++.
But sometimes, when you get a project you didn’t set up, you loose the settings, and forget about the names of those usefull variables.

Here are some of them:
$(SolutionDir) : Directory that was set up
$(Configuration) : Debug or Release, most of the time
$(ProjectName) : Name of the project
$(IntDir) Intermediate directory.
$(MSBuildProjectName) Name of the output built.

Posted in Embedded && / || Software | Tagged , , , , | Leave a comment

Starting with PIC C programming.

OK, so you got a PIC to program. Their versatility make them the core block of many applications, so it is not a huge surprise. And some people around you probably have a great experience with it ( like: “When I coded mine, I actually got so much CPU left I added cool animations for my LCD display” ). Well, if you know C enough, you will actually be able to do this too, and those pointers are here to help. They won’t teach you how to handle interrupts or right really incremental code, but htey will show you the way through the datasheet to the code. Note that this example is based on the PIC 24 G series, but if the names change, the process is the same.

1) Think Registers.

Probably the most important thing you need to achieve. When using a PIC, the data does not come from a cool API, which hands you a class full of data that you can access with one billion different getters. Nope, here all you have are registers. 8 bits, 16 bits registers. So when the marketting of a PIC says ” now with 4 SPI connections” what you get are 4 different registers, one per module, and maybe some generic extras. The switch between API coding and register coding does not come right away. One rue is the same though, RTFM!

2) Get the information right, and quick.

Now, you know that all there is to do, is access the registers. When, and how? you are going to ask. The answer is quite simple, data registers come along with polling bits, in status registers. The big picture looks easy enough. But often, people get stuck on this step, actually coding the register accesses. There is only one way of finding out the regiser names declared in C, and this is looking in the automatically included files by the IDE. The quick and easy way to do this is to locate headers in MPLAB, and add the one that has your PIC name in it, and after that ctrl + shift + f is your friend (global find). in this header file, if you look for a tristate register just look for ‘TRIS’. These are the first ones to get used to, as they describe the 1n/0ut properties of the PIN. If you look carefully enough into the file, you should see structures declared too. Most of the time, these are used to access a particular bit of a register. So you can even just look for the function abbreviated in the header file. For the SPI 2 module for instance, you will find SPI2CON register, SPI2STAT etc… Once you know how they are called, they don’t lie to you, and you can start coding in C ( more or less ANSI depending on your level 😛 ).

3) Get to YOUR data.

A generic way of receiving data on a PIC is:

  1. Configure the configuration registers
    This step most probably needs to be done once! Here, no miracles, you need to read the manual carefully, to choose a clock source and such things. For more readability and understanding, I can only advise you to use the structures given by the header file! To configure the SPI 2 module, there are multiple registers. The first one is SPI2CON1, and SPI2CON2. Notices that the names are the same as in the reference manual? This happens a lot!
  2. Start the measurement / communication.
    Depending on your configuration you might need this step. Don’t forget it! For instance, for the ADC, setting the start bit is wise 😉 (remember, this is C, setting is doing = 1; !)
  3. Send or Wait.
    Depending on the fact that you are the master of the module or the slave, this step is not the same. If you are active, chances are you can just fill in the proper register and the rest is done automatically. If you need to wait, just poll the proper bit until the operation is done. For instance, to send on the SPI 2, All you have to do is set the SPI2BUF register, but to wait on the ADC, you need to poll the DONE bit.
  4. Retrieve the data.
    Well, just do something that looks like myVar = SPI2BUF for instance, or myVar = ADC1BUF for instance. Note at this step that reading a register might trigger an action from the module (prepare to receive the next frame or such) so read the manual carefully.
  5. Start again until the end!

3) How to Implement

You can now implement the functions. For instance, SPI communications can look something like this:

// This piece of code sends 0x2A on the SPI 2 ( if previously configured) and receives whatever there is to receive during the transfer ( this is how SPI work, one given away, one received).
int spi2Read, spi2Data = 0x2A;

SPI2BUF = spi2Data;    // Setting the buffer, remember how sometimes accessing a register do strange things, here it starts the transfer, if you are in master mode!

// While not ready, do Nothing and block the MCU
while(SPI2STATbits.SPIRBF == 0);
// Read the received value
spi2Read = SPI2BUF;
// Extra step, in case you received two frames, always clearing the error bit is not safe, but at least you are ready for the next frame…
SPI2STATbits.SPIROV = 0;                // Clears Overflow status. Note how the bits in the end denotes a structure to access the bits of the status registers individually.

And bang! you have the transfered value to your SPI module in spi2Read, and sent out the 0x2A value!

Of course, this code is flawed, even though it can be used as such, you can only notice how it blocks the CPU, and coding all of your PIC like this will achieve only poor performances. It is just to show you that you can pretty much just translate the datasheet in C, keeping almost the same register names, and it works!

Well, not so difficult if you have a bit of knowledge in C. To get you started on a higher level too, the first things you need to type into your code are the oscillator set up ( _CONFIG in PIC 24’s, a bunch of #pragma in other pics) and declare your main. For the oscillator configurations, the first thing to look at is example code from Microchip, since it is different in almost every type of PIC! For the main, just do:

int main(void){
// Initialize Stuff
// do stuff, for instance the SPI functions

The message here is DON’T PANIC, of course. The path to success on a PIC is knowing what you want, and looking for it in the manual, then in the header files 😉 . The rest is just C. Of course, this does not tell you how to handle a full chunk of code, nor interrupts, but experience will!

PIC 24 SPI reference manual:

PIC 24 ADC reference Manual:

Posted in Embedded && / || Software | Tagged , , | Leave a comment

Debugging Complete!

One thing you figure is never optimized enough is debugging.
The first thing I consider, is a misuse of the API / stack that I am using. Back to RTFM.
In this case, this step led to the fact that I was really proud of my code structure and that I made really good use of the third party stack.
Then, I checked if it was a problem inside the stack. I have been using the TCP/IP stack of Microchip, and a lot of issues tend to come out, but I was concerned by none of them.
So I started thinking: addressing. In C, a lot os simple mistakes can be made, dealing with offsets and strings, taking or not into account the trailing NULL character…. But strangely, I could never reproduce exactly the same errors twice. Or at least as far as I could see.
So I created a patterned web page, in which I inserted characters to pinpoint what events happened where in the page sending process (I was implementing an embedded website). And this is when I realized that no event seemed correlated to an error.
So I made a short list of when it is working and when it not working. Since generated data was sent consistently whereas stored data wasn’t, the answer was obviously in the flash storing the website. But why? Where? When?
So I took my flash driver and easily incriminated a particular read function, the most used one in the process. Since the errors seemed to be totally random, I suspected the interrupts to be a part of this. So I disabled the interrupts for the function execution. And Tadahh! Eventually, everything worked, and my cool website interface is really cool now!
Of course, I didn’t stop here, and went deeper into the function, until I found what could be the root cause. So in depth, that it implied three instructions. And indeed, I was setting my hardware module just before I read the data. An interrupt here and the data read would have been completely random.
In fact, in the end, I was not surprised. In real time management, your pointer won’t follow your discarded data! That makes complete.sense. But I was really happy, because based on a really top level problem ( a website not displayed properly) I found the root cause of the problem. This means that engineers behind won’t be asking themselves “Why did he disable interrupts?” but they will have the choice between an interrupt-safe implementation or the fastest implementation.

Posted in Embedded && / || Software | Tagged , , , | Leave a comment