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: http://pastebin.com/JudSCJNN

Continue reading

Advertisements

Wire wrapping is one tool that should always be in your toolbox

This slideshow requires JavaScript.

I see so many people reaching for the soldering iron to make simple cables, when one of the simplest, and strongest, ways of joining two metal posts, is by wire wrapping.  Wire wrapping is a technique of wrapping the bare conductor of a wire around a metal post and has been in use for over 50 years.  It is used extensively in avionics and the space industry for its superior ability to handle vibrations and stresses.  A simple wire wrapping tool can be picked up at a local Radio Shack, as well as a spool of wire wrapping wire (cheapest place for both that I have found).  Here is an interesting PDF on the history of it, and why you should consider learning more about this easy way of making solderless connections.

That in itself deserves a post, but I’ve discovered what I’ll be working on for the next few weeks: Ultimate Wireless Showdown!  I’ll be putting 6 wireless modules through a gauntlet of tests to try to determine which has the best bang for the buck, when it comes to wireless transmission of data using an Arduino/ATMEGA328.  I’ll be testing the XBee Pro Series 1 60mW, XBee Series 1 1mW, RFM12B, Bluetooth Serial, nRF24L01+, and RF2400P modules.

I have outlined the test setup here, so read up on it if your interested, or on any of the other projects I have in the works.  By actually comparing these modules in real world situations, I’ll be able to see which module I should base my future robotic projects on.  So tomorrow I’ll start to get the two boards assembled, sporting a lovely 3.3V LCD and microSD card, with a few buttons for fun.  Which is why I felt it was necessary to improve my serial cables, as shown in the pictures 🙂  Future, here I come!