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

Timing tests have begun!

This slideshow requires JavaScript.

Yesterday’s problem, that riddled me for a few hours last night… was that I depended on an array stored in EEPROM to handle the menu system, and for the new AVR’s…. I didn’t initialize the EEPROM. I learned my lesson, I’ll always put a ‘List to do for new AVR’s’ at the top of my projects, so that when I am in that situation again, I’ll look at that list to make sure it works, the first time. Also save often. I was working on the below code, and had it almost finished, when my PC reset. Not fun (Ctrl + S)!

Luckily getting it working was one of the first things I did tonight, the other, was to setup both Wireless Testers (WT) for a timing experiment. They both have 16 MHz resonators, and I want to see how quickly they drift apart with time. So I have a test pin, A0 (PORT C pin 0), that is connected to both WT’s, and a single connected to 3.3V. Each has a 10K pulldown resistor. When I remove the wire from 3.3V, the test starts.

In the test, it gets the current time, compares it to the time the test started, and saves it to a 16GB SD card, and it does this every 100 ms. As I have found in my preliminary testing, sometimes a SD card write can take longer than a second. I have a flag that is set if the time hasn’t exceeded 100ms, at which point it waits until 100ms before taking another measurement. I am curious if as the file gets bigger, will it start to take longer to write to it? Can the arduino handle really big file sizes? I have it running right now, and I intend to leave it running all night.

With both systems working, both LCD’s and SDCards(If I don’t fry it tonight), I’ll start working on the design of the wireless testing plan. Contrary to this test, writing all of the data transferred to the SD card won’t be the objective, the objective will be to test the wireless modules. So a simple time stamp, as well as if the packet was received with the correct checksum, will be sufficient. I will create a simple python script to handle the data, so I won’t have to put it into excel to get the important statistics.

I am really looking forward to making the controller, and all of the little projects that are associated with it. Progress!!!

Here is a code Snippet:
Continue reading

SD Library is ALIVE!!!

Exciting times!!!  Now I have a fully functional Raw SD/MMC library working on the ATmega168!   This library isn’t optimized for Arduino, since I prefer making my own drivers. I have found many Arduino libraries for writing to SD/MMC cards, so there are other libraries available.

I created this library (with the help of at least 3 other libraries) so that I could log measurements and IO pins directly to a microSD card. Not only am I giving you the library (SD_Card.c, SD_Card.h), but I’m giving you all of my code so that you can see how everything is initialized.  I also have a jpg of how to wire the SD card to the ATmega168.  There is also a detailed Readme.txt that first explains the File Structure, Programming Environment, Programmer, Hyper terminal program used, then serves as a notebook, explaining some of the troubles I went through to get it to work.

Here are the stats for the things I have setup (2 timers, ADC, USART, SPI, and SD_card)

text       data        bss        dec        hex    filename
7638          0        562       8200       2008    ATmega168_slash.out

FLASH: text + data
SRAM: data + bss

So for this software, I’m using 7638 bytes of Flash and 562 bytes of SRAM.  For the ATmega168, there is 16K of flash and 1K of SRAM available, so there still is a good deal of room left.

Hope you guys enjoy this!  I’m using Mercurial for version control, and I’m finding it very easy to use and helpful for figuring out if something went wrong.