All controller functions functional! Now I need some remote projects!

This slideshow requires JavaScript.

So I have gotten to a point at which everything for the controller works. SD card, Xbee, BT serial, Shift LCD, PS2, and NunChuck. Pretty awesome. But if all of that code is enabled at once, I would have less than 1k bytes to write actual code to interface with things. In the code I have debugging via serial, debugging via LCD (for the controllers). I do like having debugging for LCD, but there is a problem: the PS2 library takes up 5k bytes. So when I actually build the controller, I don’t think I’ll include a PS2 connector, at least initially.

Breakdown of Sizes
with SD enabled
Everything Enabled: 29024 Bytes
Only LCD debug: 27252 Bytes
Only NUN LCD debug, PS2 disabled: 22550
Only PS2 LCD debug, NUN disabled: 25900
Only PS2 & Nun, no debug: 24690
Only PS2, no debug: 24484
No ps2 or Nun: 20972
With SD disabled
Nun and PS2 disabled:13488
BT disabled + SD + NUN PS2
Xbee: 11910
Everything Disabled:
11886 bytes

I think the optimal configuration would be to use the Nunchuck with LCD debugging information, with SD, XBEE and BT, coming at a total of 22550 bytes, giving me about 7.5k to write my code for all of my interfaced devices.

This has led me to the idea, that my interfaced devices should be giving the controller, the menus it should show. I’m thinking of an initial packet that is exchanged between the two, which has a good amount of strings, that are then saved into flash on the controller, and once data starts arriving, those ‘labels’ of the data will make the data make sense. Another idea is to use the SD card to carry firmware for remote projects, and remotely flash them using the controller on the go, so I can update code for my cars without having to take my laptop down there.

Well here it is:

Continue reading


New Project Added: FastDigitalWrite for Arduino 1.0

… “But hasn’t this been done before?”  YES!  And I didn’t do it. I didn’t do it this time either 😛

I was reading Bill Porter‘s article about how many cycles it takes to do a digitalWrite as fast as you can in Arduino.  He compared it to the speeds attained by writing directly to the port, and he found that a digitalWrite operation takes 56 clock cycles to perform, whereas a direct port write takes 2 clock cycles.  He referred to a library that rewrote digitalWrite in terms of a macro (something I was thinking of doing, but I’m glad I didn’t, cause John Rain? with the assistance of Paul Stoffregen and Bill Westfield worked out the details of doing it).

The problem with that library, is that the last update was in 2010, and after trying, it didn’t work with Arduino 1.0.  The original file was provided as a library for arduino, but it included a ‘bonus’ section that had the macroized digitalWrite, digitalRead, and pinMode.  I’ve updated just those files for Arduino 1.0, and I have it hosted here. I have a few readme’s in there, the .txt readme is one I created, which tells you where to put the files.  But I have arranged it so that after you extract it, you can copy the lib and hardware folders to your arduino installation, and copy and replace your existing files.  The trick to their modifications is only using the original digitalWrite routine if the pin number or level specified changes.  For me, most of my digitalWrite and reads are static, same pin number, everytime.

As always, this comes with no warranties.  When comparing the Blink sketch, the size went from 1026 bytes to 674.  For my controller sketch, it went from 16708 to 16642 bytes.  I hope everyone enjoys this, and feel free to ask me any questions.


Finally got XBee, BT Serial, and menu system working… oh and Nunchucks too!

This slideshow requires JavaScript.

Last night I discovered that the software serial library can’t really keep up with what I was trying to do (configuring one module, then configuring the other). I’m sure it was something wrong with my code, but eh. Another thing I discovered was how the Arduino uses 1k resistors to buffer the FTDI connector from anything that may be connected via the serial pins. Using 1k resistors on non-dominant pins, can let you manually choose a dominant port, such as the FTDI. Why would you need to do this? Well if you have the XBee on the Hardware serial, as well as your FTDI connector, you may have some problems downloading (I did).

So I moved the XBee to Hardware serial, with 1k resistors for both TX and RX, which means that I need to disconnect the FTDI connector if I want to use the XBee, which is pretty reasonable (much better than disconnecting the xbee). Once I got that working, I had a menu system that fully let me issue configuration commands, from within it. I do need to do some tweaking on it, but it is good enough to start working on other things. Things like a NunChuck.

I spent quite a few hours tonight bashing my head trying to get this to work. I referenced this diagram, which appears correct. I didn’t realize that it was backwards until I noticed this very helpful post. The diagram shown originally, was for the socket that the NunChuck plugs into, which isn’t what I was connecting to. So once I got that working, I was able to run this sketch, which shows the address of all i2c things on the bus. It was able to detect my MotionPlus and NunChuck knockoffs with ease 🙂 I’d like to also mention that I’m using 2.2K pullups on the CLK and DATA lines for the i2c bus.

So now that I have the NunChuck working, I’m going to make a little menu for it perhaps, or play with it even more, to understand how it works better. I should be receiving parts in the next few days, so the actual controller may be built.  I do realize that this will be a first version of it, but I intend to make it awesome!


Nunchuck Library, from here.

i2C scanner code

Continue reading

Best menu system in existence

Just like a drug addict, I say ‘This will be my last menu I create from scratch’, and yet, a week or so passes and I create another. And another. Well it’s a good thing that I have this addiction, because each menu system turns out to be better than the last.

It just so happens that this menu system that I’ve created, is the best currently, and that can ever be. Yep, it’s true.

I’ve just attached them via pastebin, since the syntax highlighting is so nice, I’ve created an account and will put my code there on a temporary basis. If there is a bigger project, then it can go into its own sourceforge project account. Ultimately, it is your responsibility to save this, since I cannot guarantee that wordpress or pastebin will always be around. If you like it, take it 🙂 The compiled size is 3516 bytes, which is pretty decent in my view(and that is including the ShiftRegLCD LCD functions).

Next up, adding things to it. I think I’ll go ahead and add all of the BT and XBee configuration code, then I’ll start playing with the NunChucks! Can’t wait to start playing with solar panels…

This is the main code, which includes the entire menu system:
Here is a simple file that has three simple functions to handle multiple buttons on a ADC channel:

Raw paste of code is below (not pretty :P)
Continue reading

Information: You don’t own it unless you take it

While looking for solutions to my robotics projects, many times I come across ‘dead’ websites, people who link to really great and informative websites, that are no longer there. I think that is the principle argument against owning your own domain, and hosting your own blog, because if you stop paying (willingly or unwillingly), all of your blog vanishes.

So if you find something that you really like, you should take it. That means using tools such as FlashGot for Firefox to download videos, saving the entire website using tools like QuadSucker, or archiving a particular post using PDFcreator. This is great for things such as a product page from a particular embedded thingy you bought. Because for many websites, once they stop selling that item, poof, it is gone.

This is a good strategy for programs you use too. DaemonTools once upon a time had a Lite version for free that didn’t show ads for MountSpace (and luckily I kept a older version that doesn’t), but their newest version does. Every time you have DT open, you see a nice big banner that advertises MountSpace… Nope, uninstall. Sure, it is their right to do that, and it is their right to stop offering a free version. But it is our right to backup things that we use, and things that are interesting to us, because if we don’t, experience has taught us that one day, it may be gone.

There once was a youtube channel, photoinduction, that had a great deal of videos of taking things apart and performing neat experiments.  He was once featured on HackADay for showing his whole house backup. You could have once watched the video, if he didn’t delete his youtube account. When I went to look at his video since I might be making my own UPS soon, it was gone. If you find a good tutorial on how to do something, take it. If you find a great video that you might want to look at again someday, take it. Because if you don’t, that information may disappear forever…

XBee and BTM-182 configured via Arduino

I finally got my Ardunio to successfully configure both the XBee and this BTM-182 bluetooth serial module. Why would you want to do that? Well the XBee has six 10-bit resolution Analog to Digital Converter channels, and about 8 digital IO channels (all ADC channels double as DIO channels, so in total about 8 to play with). Another reason is if you want to only talk to one remote xbee module rather than them all, you could change it on the fly. For the bluetooth module, you can perform scanning of available BT things, and connect to them, all using the ‘Command’ mode.

This is another lesson for KISS I think, since when I first started to tackle this problem, I made these fancy functions to handle it. Well that didn’t work at first, but after some massaging, I got it working. Then I tried to get software serial working, but that didn’t work out. (I thought I configured it correctly, turns out I needed to declare inputs/outputs for the SW serial port)

Ultimately I decided to try the simplest while loop to handle the response, which worked out really well. I found out how to get the SW serial working by looking at this example which had SW serial running (the default examples in Arduino 1.0 IDE didn’t setup the input/output). I’ve attached the code below, it’s not pretty, but sharing is caring 😛

What you see in the picture are two NunChucks that I intend to get setup and running, and once they are running, I can send the joystick response anywhere 😛 Once I get some parts in for the controller, I’ll go ahead and build it up. Then something to interface with (plant waterer). Fun times!!!

Continue reading

Finding Parts is a Skill…

Let’s say you want to buy some 10 pin connectors to connect your boards together, it should be pretty easy to buy them, right? Sure! Just go to Sparkfun and spend $1.50 for a 40 pin female header and another $1.50 for a 40 pin male header. Wow, that’s expensive.

The trick to navigating Digikey or Mouser, is being able to select the right terms that get you to what you actually want, and sometimes that is trial and error. Let’s look at Mouser. Looking at the link itself, I had to go to Interconnects -> Rectangular Connectors -> Headers wire housings, then selecting male.  From there, I could then look for the actual specifications for the part I want (cheap, 2.54 mm pitch, 1 row).

Many times I get a little frustrated trying to navigate the menus, but it is usually always worth it, in $, to do so. In this case, I found the best prices at, $0.33 for each (since I’m buying 100, the price is $0.15). They had the best prices for the female connectors as well. But they lacked quite a few parts, so I will still have to order at Mouser, but I think I’ll save money by ordering from both places, rather than getting it all from Mouser.

Learning how to navigate vendors like Digikey, Mouser, Newark, and ebay can help you save lots of money versus buying parts at specialty places like Sparkfun or Pololu. In this case, I can buy 5 headers from DipMicro versus 1 from SparkFun. Wowza!

As a sidenote, I’m buying a non-latching shift register to see if I can reduce the pins needed to drive an LCD to two, using the Shift LCD library! I’m thinking of picking up a PS2 connector, as well as a NunChuck adapter, to make things nicer, even though they will probably cost more than an entire MCU + Wireless + Case combo…

Becoming Refamiliar with the BTM-182 Bluetooth Serial Module

This slideshow requires JavaScript.

I was excited to start building the Controller today… but I noticed that I didn’t have enough female headers, so I decided to breadboard the controller for now. I wired up my BTM-182 Bluetooth Serial module that I purchased almost a year ago (I bought 8 of them, they were kind of expensive ($15 each)). It was a time in which price didn’t matter as much, and I saw them as a pretty good deal ($15 vs %60 BlueSmirf’s).

So I was working on which commands to send the modem, to configure it. If it is in slave mode, You can enter command mode (+++), and tell it to go into discovery mode (ATH1). Then you can use your computer to detect it, and connect to it.

For master mode, it is a little more complicated. I haven’t ironed it out yet, but it is some combination of entering command mode (+++), Setting it in master mode (ATR0), finding other BT things (ATF?) and choosing to connect to a specific BT thing (ATF#, where # is the number of the BT thing that ATF? returns).

I’m not sure what I’ll use for the BT module, but I can see that with it, I can connect to my computer or other wireless things (iPod, Android) hopefully. Perhaps I should do a test to see how far away I can connect to it, and communicate with it…

Since I’m a good engineer, last night I was searching for other AVR controllers, or Arduino Controllers, yet I didn’t find any actual controllers like the one I will design (or the one I already have designed). So I will be sure to take pictures, for science! Still waiting on the Nunchucks…

Shift Register + LCD is Shifting! (or LCDing)

I got a shift register library working(which I got from here), and it works with 3 pins. From 6 pins to 3 pins, that is quite the reduction. There is also a 2 wire option, which I have yet to successfully test (I need a 1N4148 diode).

The reason I’m starting to play with this shift LCD library, is that I’m going to start building a controller. What!?!? You haven’t finished (or started) the wireless testing?!?! Yes. I’m losing motivation to work on it, because it will require a lot of work in order to complete it. And lets say I do finish it with all three modules, I’ll have to choose the winner, and use that module for my projects. But with how modular my boards are, I’ll be able to quickly swap wireless modules if I determine one is better than another.

I may choose to continue it later, but right now, I’m going to take a break from it, and actually ‘DO’ things. Do things like making the controller, making a engine monitoring arduino for my cars, make a Arduino for my Slash RC car. I feel that these ‘doing’ things gives me more motivation than the ‘Wireless Testing’ experiment. Ultimately, the controller I’m making will have XBee, and it will have a bluetooth serial module, and it will have those, because I have too many of those modules to not use them. I’m leaning towards the nRF12L01+ module to be the chosen wireless module, since it is cheaper than the RFM12B, but I have yet to receive it in the mail, so after I test it, I’ll make my decision.

What keeps me excited to do robotics projects is my motivation, and I noticed today that my motivation has been lagging lately. This change has already given me a boost of motivation, so coming up, Controller 2.0! It will have a PS2 connector, and eventually a NunChuck connector. Xbee pro wireless and bluetooth serial. I’m going to go and work on it now, see ya!

Virtual Build Environments and Integrating RFM12B into WirelessTesting

The past two days I’ve been playing around with creating a virtualized build environment, where all of the tools are contained within a virtualized OS. In my case, I was using an instance of WinXP virtualized. While I was able to install all of my tools (Notepad++, Arduino, Python, LScreamer), the actual downloading of the program to the Arduino would take almost double the time, which I believe was due to how VirtualBox handles USB attachments. It was a good experiment, and it may be something I play around with in the future, but right now, it seems better to use a non virtualized OS.

Currently I’m working on adding the RFM12B to my current Wireless Testing project. If you remember from last time, I was verifying that I could write to the SD cards every 100ms. I left the experiment running for a few hours, and it seems there were mixed results. In one case, after a certain time, every write took longer than 100ms to perform (the files were 3MB in size). In the other case it continued on just fine.

So for my Wireless Testing, I should take into consideration that an SD write may take a few seconds to perform, which means that I should hold onto the data that I want to write, and plan the tests to have break points at which saved data can be recorded. I’m still coming up with the exact test methodology, but I should be posting it in a few days. From the methodology, I’ll be able to code the actual test. I should also keep in mind that each wireless module works differently (RFM12B library has checksum’s integrated, XBee’s don’t). A small step in the right direction, is still a step in the right direction!