The new embedded system website is ready. It can be accessed using the same web address, as always. I changed the content management system to Joomla, but, all the oldest articles have been ported, and the new ones have been added.Follow bellow some quick links about the latest subjects.

• Embedded system main page
  Home page link. For more information.
• CC2430 project page.
  This is a quick link to the CC2430 development board page. You will find there all information and links to related projects.
  
• Quick link to the parallel interface
  This is a quick link to the parallel interface used to program and debug the CC2430.
• Quick link to the 2430prg
  This is a quick link to the programming and debuging software for linux.

As promised at the previous POST I made some tries with the linux application and now it can program the entire device in less than a minute. Even the 128Kb ones. The problem isn’t at PPDEV, but inside my code. I made the correction and now is possible to use it with the PPDEV or with direct access to the port.

I still working at the embedded system website and soon I will publish there the updated schematics.

I’m writing this post to present the latest results, after all, there were many months of work without any post.

The boards have been successfully concluded and work pretty well. 

The interface board has changed a little, i take out some decoupling capacitors witch are impairing the signals. The layout keeps almost the same.

The CC2430 board layout has not changed, i just change the value of the first LED resistor, so, i can use it with 5V power supply.

See bellow a picture of them at work.

Answering to many requests i started developing a linux application to program the device. It´s easy to develop, faster to test, so, i will first conclude it, and them, port the code to the windows drivers.

This application can already identify the device and program the code inside it. Unfortunately, there is a huge performance issue. It takes at least 8h to upload 32Kb of code. I am using the ppdev kernel driver to communicate with the parallel port.

I believe that if i change this to do a direct port access instead of using ppdev will improve the performance. I will make some tries during this week.

You can access the source code of the linux app at my subversion repository:
http://svn.otavio.eng.br/svn/cc2430/linux/2430prg/trunk/

user: anon
password: anon

This code will change a lot on the next weeks.

The schematics will be updated during the week at my new embedded system website. The website address will be the same. I will make a new post as soon as i finish it.

I finished the CC2430 parallel interface board. Below you can see a picture…

The tests will begin as soon as the main board is ready.

I uploaded the driver source code to the subversion repository at a temporary place. It will be moved to the embedded system repository as soon as it is more functional.

At this momement i have developed only a stub with the driver’s basic functions. I need now to finish the hardware to develop the driver’s specific functions.

To have access to the source code:

http://svn.otavio.eng.br/svn/global/trunk/drivers/CC2430Cable/CC2430CableDrv/

user: anon
password: anon

You can use the browser to see the source code, or use the subversion client to download it.

To put the parallel interface at work under Windows we will need to develop a device driver. This driver will allow the connection between the parallel port and the programming/debugging software.

Microsoft urges developers to use the new WDF framework when developing new drivers. There are slight differences between the WDF and the DDK used before. One good think when using WDF is that the framework already implements a lot of common features needed by drivers. So, you can write drivers with less code lines than before.

That is my first time writing drivers using WDF and i found some challenges:

Signed Drivers (Obligatory on Vista 64)

All Windows Vista 64 drivers must be signed by a certificate emitted by a trusted company. Until now only Micro$oft and Verisign are trusted by Windows Vista 64. You cannot add a certificate as trusted at the windows certificate manager. So, you need to sign your driver with an Authenticode certificate from one of this companies or your driver won’t load!

If you want to develop and test the driver, you will need to make some adjustments on windows boot options to start it in “Test Mode”. A small “Test Mode” brand will appear on each corner of the display.

When running in test mode you will be able to install a signed driver using a self-signed certificate which can be generated using the WDF tools. You will add this certificate as trusted at windows certificate manager and your driver will be loaded.

But, even in Test Mode, Windows Vista 64 will only load signed drivers.

Debugging

Another interesting point when testing your driver in Windows Vista is the kernel debugger. The debugger is disabled by default and you need to enable it changing some boot parameters before connecting the debugger application (WinDbg, etc..) on it.

Debugging Messages

Even after enabling the kernel debugger you will not receive the messages sent by your driver using the KdPrint function. For receiving this messages you will need to setup the registry. You need to make some mask adjustments to tell Windows what messages are enabled.

These are my first challenges which are now solved. Now, is just finish the driver.

As information, this driver will be a FDO (Function Driver Object) which will works over the parallel port system driver.

I got corage to produce the parallel interface board to the SE-CC2430 development board. Follow below some pictures of it.

Take a look at the hair wire that accidentally fell at the board at the moment of photo shoot.

After some time researching a third option has appeared.

Have you ever heard something like these: “think out of the box”?

Well, during the SECC2430 development board design i intended to use the CC2430 with 128Kb of memory, which, unfortunately, cannot be exported to Brazil. But, this component can be purchased in three flavors: 32Kb, 64Kb and 128Kb.

Neither the first (32Kb), nor the last (128Kb) could be exported to Brazil, but Mouser has the export license to the 64Kb version (839-CC2430-F64). At least there are no warnings about exporting it at their web site.

This can be a solution for the SECC2430 development board and should be enough memory for many zigbee applications.

How is to be expected, soon or later the problems would arrive.

So, there we go to the first challenge. Buying the CC2430.

Neither mouser or digikey or Arrow or any other supplier are selling the CC2430 outside US. Apparently, they don’t have the license for exporting this component. I talked with some of them and they can’t forecast when this will happen.

To help a little, TI isn’t sending samples to Brazil, according to their website there is a problem with some new Brazilian law for which their system is not prepared. I sent an e-mail asking but i didn’t get answer…

Now, there are only two options to buy this component. First, go to US and bring them by myself, or, send it to some US address and ask someone to send it to Brazil.

At last, The good thing is this… still remaining two options!

The SE-CC2430 development board had arrived. You can see below the first picture of it.

Now, i’m waiting for the components to arrive and then, start the most interesting part. Solder each one of them in their places. Doing this by hand will be a big trouble!