The Arduino Command Line Interface, aka CmdArduino, is a simple shell that can be run on an Arduino. It's nothing fancy and its main purpose is to allow users to easily call their functions on a running Arduino via a simple serial terminal. It also allows users to pass in arguments from the command line into the functions they wrote so they can easily toggle pins, set blinking speed, set pwm duty cycles, or whatever else might need command line user input. Using it is fairly simple and just requires unzipping the files into the "Arduino/libraries" sub-directory in the Arduino program folder. The following is a tutorial that goes into more detail about how to implement CmdArduino in a sketch and easily add user functions to the command table. 

Hi all.

Sorry about the delay in releasing the ATXMega boards. There's some good news and bad news.

The bad news is that there won't be SPI DMA support. I was validating the SPI DMA feature and found that DMA transfers for an SPI master can't be made directly to an SPI port. They can only be made to a UART configured as an SPI master. This would have required swapping two pins, but still wouldn't have been much of a problem. The real issue is that when I configured a UART as an SPI master and sent data through it, I ran into what looks like a hardware bug that leaves some SPI transfers incomplete. Here's a shot of a 2-byte transfer:

Hence, I've made the decision that I won't be supporting the DMA to SPI feature. I apologize since I believe there were some people that were looking forward to that feature. For people looking for DMA'd wireless transactions, I'd recommend the EconoTAG from Redwire. Its based on the Freescale MC13224 and supports DMA to the radio FIFOs. It's also designed and supported by Mariano Alvira who is a frequent contributor to open source and the Contiki project. 

The good news is that the memory to memory DMA feature is working so that people doing a lot of block copying can now offload that from the MCU.

Anyways, that was the last thing standing in my way to release the ATXMega boards. The boards are now in the shop and I've also put together a set that consists of an MCU board, radio, antenna, and standoffs.

Thanks for the patience and sorry about not supporting that feature. Here are the links to the products:

ATXMega MCU Board Link

ATXMega MCU + Radio Set Link

Just a quick note that Chibi v0.85 is released. The main purpose for this release is to add support for the Atmel ATXMega MCU family. There are other minor changes that were also added. The EEPROM driver was moved to the MCU specific directories since the ATXMega has different EEPROM access method than the standard AVR series. The standard AVR chips have EEPROM libraries that are supported by avrlibc which is not the case for the ATXMega. Along with that, there were some minor cosmetic changes to the demo file to simplify things. It started feeling like it was getting cluttered.

To switch between the different MCUs, just open up the Makefile and set the MCU variable to the processor of your choice. To select the radio, do the same for the RADIO variable. 

Here's the change list:

• Added ATXMega support for 2.4 GHz and 900 MHz radios
• Fixed compilation issue on Linux where case sensitivity caused problem with makefile
• Changed usec_delay function in ATXMega radio drivers to be based on stated MCU frequency F_CPU. There may still be some issues since the clock frequency is changeable on the fly, however old drivers assumed 8 MHz clock
• Added support for command line via UART rather than USB for ATXMega boards since they use FTDI USB serial bridge to UART
• Moved chb_eeprom.c/h to MCU specific directories since they are MCU specific
• Removed "dump" command for register dump
• Removed "pwr" command to set power. This is just demo so default should be okay. API call is still in driver so this can be implemented as needed by the user. Just didnt want to make things too complicated.

You can pick up the source code from the project page.

Link to Chibi Project Page

Hi all.

Wow! Things have been unbelievably busy recently. Along with the part-time consulting, things have been heating up at the Tokyo Hackerspace recently.

I started a group with another member called "Wireless Wednesdays" that meets two Wednesdays a month. In it, we discuss and try out different things going on with wireless. The first meeting, we actually flashed an 802.11 router with DD-WRT and then demonstrated how to boost the transmission power, partition the networks between public and private, go into repeater mode, and do other fun things with the firmware. We also have a two group projects going on in a rural area outside of Tokyo. One of them is to instrument rice paddies with wireless sensors to help out the elderly farmers so they don't have to climb up the hillside terraces every day to check on the crops. The other project is to help take a census on wild monkeys and boars that keep feeding on the farmer's crops. If we can get a good estimation of the animal count, we can help them plant lower quality side crops outside of the main farm area so that the animals won't need to forage from the farmer's main crops. Not sure if that second one will be successful, but it sounds fun and we might be able to save some animal lives as well as help out the farmers. 

I'm also hoping to set up a test bed managed by the group to test out some of the WSN work going on inside the IETF. There's been a lot of exciting things recently with the release of RPL (the 6LoWPAN Routing Protocol) by ROLL and an upcoming CoAP plugfest by CoRE (6LoWPAN application layer protocol).

I also taught my microcontroller class again at the hackerspace and updated a lot of my lessons. I've been meaning to post the lessons for a few months now, but have been so busy with new designs and other work that it kept on falling through the cracks. However I've been giving out the lesson notes to a few people and have gotten good reviews on them so I think they're ready to be published. Those should be going up soon, once I get a little bit of breathing space. 

I've been working hard to get the ATXMega boards out the door. The first batch are fully assembled and tested and I actually finished writing the documentation last weekend. However I realized that just throwing the ATXMega's out into the wild may not be the best thing to do since they're quite different from the AVR ATMega chips. The number of new features are really amazing, and just as amazing is the amount of documentation you have to go through to figure out what you're doing. Because of that, I decided to postpone the release a bit and put together a software package that shows how to do some fundamental things on the new chips.

As an example of why the test code was needed, you can just take a look at the GPIO configuration. In the ATXMega, you can now configure each pin to be internally pulled down, pulled-up, wired-or, wired-and, or as a buskeeper. Each IO can also be configured as an interrupt and the interrupt can have three different priority levels. There's also slew rate control to increase the rise/fall times of the IO. There are now individual set, clear, and toggle registers for the direction and port registers which get rid of the need for read/modify/writes. And you can batch disparate GPIO pins from different ports together into a "virtual port" which can be accessed just like a normal GPIO port. Damn! The flexibility is great, but the options can make your head spin!

Anyways, so I put together a very simple test code package that hopefully can help make kicking the tires on the ATXMega a little bit easier. It's nothing comprehensive, mind you, but it should show how to get the basics going on the chip. You can find a tutorial I wrote on it here:

Link

I also finished a Chibi port to the ATXMega and should be uploading that soon. 

And finally, the boards will be released after I post the Chibi code and check over the documentation. Stay tuned...

*Whew!*

The ATXMega is an upgraded version of the popular AVR microcontroller from Atmel. It still contains the basic AVR core but has a huge amount of enhancements to both the core and the peripherals. Basically, you can think of it like an AVR on steroids…a whole lot of steroids. Switching from the ATMega to the ATXMega series is a bit overwhelming because there are so many new features and improvements. Consequently, there is also a lot of new documentation which shows how to use the new features and the old ones. Because of the potential register shock to people that try out the ATXMega, I decided to put together a library of the Atmel drivers and some example functions. And of course, all the functions are ported and tested. Some of the examples may seem trivial, but they’re not designed for evaluation purposes. Their real purpose is to serve as a reference on how to access and use the peripherals, now that the register set is different.

I’ve been spending the past week bringing up the ATXMega boards that I put together and porting Chibi over to them for testing the radio modules. While doing so, it also got me thinking about how I chose the parts and what the landscape for wireless sensor nodes is starting to look like.

The original idea of wireless sensor nodes was that they would be like dust. They’d be inconspicuous, ubiquitous, and you could essentially just sprinkle a couple all over the place to monitor some area that you’d like to keep tabs on. It was expected that wireless sensor nodes would be small, lean on memory resources, and extremely low power. Fast forward about seven years and we see that there are some real deployments going out with wireless sensor networks and the usage scenarios are much different than what was first envisioned.

It feels like wireless sensor nodes are going down two different paths. On the one hand, you still have extremely resource constrained nodes that are being used for specific applications. These would be like environmental monitoring or proprietary applications where the network and use cases are extremely well defined.

On the other hand, large scale deployments like the US smart grid (as well as the conversion over to smart meters in other countries) are showing that widespread adoption will put a limit on the minimum amount of resources required for a wireless node. One of the biggest resource consumers of a large scale deployment of wireless nodes is protocol standardization. 

One of the interesting things I've been seeing is that Macs are starting to become very common in the tech industry. Strangely enough, there is almost a majority of Mac users in Tokyo hackerspace which is heavily dominated by techies. I also see a lot of Macs in other hackerspaces and at events like the Make meeting in Japan. So it seems kind of strange that there is still very little support for embedded development on the Macs. In fact, I'd have to say that a lot of the info on how to set up embedded development environments on that OS is coming from the open source software and hardware communities. This is probably because they're widely used for Arduino development.

So I finally gave in and went out and bought a used Mac at a local second-hand computer equipment store. It was kind of sweet because it had an 2 GHz Intel Core2Duo CPU and quite a nice screen. It set me back about $400 which was really good considering how well Mac notebooks retain their value. The reason for the low price was that it had a US keyboard which is not very desirable in Japan, except for foreigners like me. 

After having used the Mac a bit, I can say that I understand why people like it. Apple obviously paid a lot of attention to usability and aesthetics. The GUI blows away the Windows XP GUI (I haven't tried Vista or Windows 7) and you can drop down to the command line and go straight into Unix. It's like the best of both worlds!

Anyways, enough gushing. The main reason I got the Mac was to figure out how to develop on the boards I'm making using that OS. It's becoming too important to ignore. Along the way, I can hopefully help others figure out how to set up their Mac environments for development on other boards and platforms. My first attempt at using a Mac for development was very basic. I wanted to access the bootloaders on the AVR USB microcontrollers to perform the fundamental operation of downloading code. It actually is very similar to Linux, however you need to do a couple of extra steps to get dfu-programmer to run on that OS. Once the setup is out of the way, downloading code is extremely easy.

And so, with no further ado, here's how to download code on AVR USB microcontrollers using a Mac. It's at the bottom of the original tutorial. Hope it's useful...

Tutorial Link