Hi everyone.
I'm back from my brief excursion. Actually, I was working on a project for the disti that I'm contracting for. Once the PCBs were done, they needed a demo to show to their supplier and customers. At first, I thought it would be easy since I'm using an AVR MCU. I would just use the libraries provided by Atmel to implement the communications and then write a simple driver for the chips that they wanted to demo. Unfortunately, that kind of thinking backfired on me which was why I had to go into hermit mode for the last two weeks.

What happened was that the demo needed to interface to a PC, and not just a desktop PC, but laptops too. The problem is that laptops don't have serial ports anymore, and I didn't want to force people doing the demo to hang one of those USB/Serial converter dongles off of their laptops. Its much better to use the USB directly since you get both a power source and a fast communications link to the PC.

My mistake was thinking that I could take the vanilla Atmel USB device stack, port it to my platform, and have it work. When I did that, I would get intermittent crashes. I had thought that the problem was with my port, but the same type of behavior happened on the Atmel USB eval platform. For a demo, its undesirable, but probably 90% of the time, the demo reference code ends up going into the customer's design. If the code crashes a lot, then that's an easy way to lose a customer so I didn't want to risk it.

This gave me an opportunity to do something that I've been wanting to do for a long time...to write an open source USB stack. This stack, of course, is just a USB device stack, as opposed to a host stack which is much more complicated. However there seems to be a real dearth of good, open-source USB device stacks available. The ones that I've seen are mostly manufacturer stacks, with a couple of open source stacks that are heavily based on the manufacturer source code. What I was looking for was a USB stack that could be portable to different processors and USB device controllers, similar to what I'm trying to do with Zigbee. So basically, I decided to flex my USB muscles a bit. Of course I have a slight advantage with USB over Zigbee because I used to design USB chips (I was one of the designers for the USB IP being used in the Microchip PICs) and wrote a USB host stack before. Hence, there wasn't much of a learning curve for me in terms of protocol for USB as opposed to Zigbee.  

So for the past two weeks, I was writing a USB device stack from scratch. Although it's a pain, there are numerous benefits to taking this approach. The first is that it can be supported locally which means that I can add, modify, or fix the code instead of asking for help from an engineer in another country. This cuts down on the response time and the time that it takes to fix or change the code. The best way to keep a customer happy is to fix their problems fast :)

There are other benefits as well, such as the ability to open source the code (instead of using the yucky manufacturer license agreement which locks the code to the chip), and the chance to write funny comments that only I understand. 

When I was at my old company (actually two companies ago), it would have taken months to design it because of all the management approvals and meetings that were necessary, filling out statements of work, dealing with project managers to draw up the project timelines, and all the so-called USB experts that would endlessly debate the architectural tradeoffs. So now that I'm free from those shackles, I can say that it takes about two weeks of real ass-busting to get a device stack up and running, although it might still require a couple of tweaks ;)

Anyways, the outcome is that the USB stack is working, and the USB communications class driver with the Virtual COM port is up and running. I'll also be open sourcing it as soon as I clean up the code and write up the documentation.

Well, that's about it. Hopefully others will find the stack useful. At least now, its possible to get rid of that pesky FTDI chip (if you're lucky enough to have a USB interface on your micro). The release should be coming soon...and of course a Contiki port as well :)

Now...need to get back on track with Zigbee...

Ahhhh...nice to be back in Tokyo again. My trip to the US was a bit over-dramatic for my taste, but luckily it turned out to have a happy ending. Now that I'm back in my comfort zone, I can get back to work on a bunch of pressing issues. A lot of people have been asking about the next release of the FreakZ stack. I'm going to be working on it this month to try and implement the home automation profile using the Atmel Raven kits. Of course it won't have security, but it should be functional...I hope. I'm looking at the March time frame for the next release of the code with the hardware support.

Now gotta get me some sleep. I'm so jetlagged...zzz...