Yep, - Thought about designing one with all through holes, but I don’t have that much of a problem soldering some of the SMT devices like 0805 resistors… So I went that way… Also if later if a group of them are made they can automate most of it…
Kurt
Nice looking board Kurte
I have now assembled one of them 
I found the MUX chip a real pain in the… to solder in. I probably fried it. I would be really surprised if it completely still works, but will test it out.
I have however so far verified that I can use the AVRISP to burn a bootloader and I can download programs using the AVRISP. I used the default program Blink and my LED blinks.
Other things I would change if I do a Ver 002 include: moving the jumper JRST as to make it easier to plug in AVRISP. Note: The plug is currently such that the ribbon cable points in toward the Atmega chip… Not sure if that is good or bad…
Also would probably make sure there are not vias or the like under the Crystal. I used tape under it to insulate it from the metal case. Could also simple order a crystal insulator.
Will continue to do some more testing for I build 2nd one.
Kurt
Ahoy! There be parts on the board!
Looks pretty good.
Often, crystal circuits are to be in a “guard band”, I don’t know if that applies here. This is a ground trace that surrounds the xtal and its caps. Or at least a “keep out” area.
Alan KM6VV
Ah, that MUX didn’t look easy to solder by hand.
Always exciting when powering a new board for the first time, let us know if everything works. 
Yep, not a lot of fun to solder those suckers… I have done an update of the board on how I should have done it, or if I decide to do a V2…
That is with a different version of the same part which just barely fits… Also move stuff around the Crystal…
So far most of the digital pins work. I need to make up my own version of the Arbotix type directory which does not dedicate Serial1 to do AX12 type stuff… Sound works, Can down load programs using the Bootloader… Next to see what works of the Analog Mux
Update: Some of the Mux may work at least I am getting some non zero, non 1023 values, but it looks like the input going to A7 is failing all 0’s coming from analogRead… Will investigate more, but I may delay for some other projects…
Kurt
I have done a little more playing around with the first of these boards I assembled. I am pretty sure I screwed up pin 3 of the MUX and it ain’t coming back .
I will do some more testing of this board. Probably can not use it yet as my DIY remote replacement, trying to decide if I will attempt board 2 or fabricate version .002 which gives me a fighting chance. If I do, I am trying to decide on a few other changes on if I should do or not.
Things like: Remove JTAG connector. It is nice to have to debug stuff, but all of the IO pins minus reset are right next to there, so would not be hard to setup a wiring harness.
Also having some second thoughts about having the Automatic reset over XBee option I put in. May work in certain cases, like if my XBEE is always in Serial replacement mode and paired with the PC one. There are probably not going to be my normal configuration. I am wondering if instead I should have a pushbutton connected up to the reset line of the XBee, such that I can reset it and maybe have it’s default configuration set that way, that when after reset the actual program running on it is free to change it to whatever configuration that is appropriate for it, like convert to Packet Mode… Optionally could tie the reset to an IO pin of the Processor, but not sure if we want to lose another pin. Or I wonder if it can all be tied to the same reset line as the processor. Not sure if this would work yet as processor +5v, XBee +3.3, but I think both do Pull low to reset…
Still want to do a little more testing before I make 002 as I should try to fix as many issues as I can on the first one, so I wont need 003.
Thoughts
Kurt
I have no useful input here, but wanted to offer you my support. I’m not sure what purpose the xbee reset serves.
Thanks Jim,
Welcome back! Hope you had a nice, fun, relaxing week off!
My thoughts are, I allow you to use the XBee on either USART0 and USART1. If you use it on USART0 and the XBee is set to be in Transparent mode, and is set for the baud rate 38400, then you can in theory download your updated program from the PC to your board. However the way that I use the XBees, is that the majority of the time I put the XBee into Packet mode. It gives a lot of nice flexibility. Things like: the hardware takes care of check-summing your data, you know when something starts and stops, and you can easily send and/or receive from multiple other XBees. That is the way my DIY stuff works.
So one approach is to have the XBee configured with the defaults I mentioned above(38400, DL set to My on Xbee on your PC). When you are ready to program you hold down on the reset until the program is ready to download and release. The bootloader will try to download the new program (either over the XBee or whatever else is connected (FTDI cable)… If the bootloader does not detect a program attempt, it will run your normal program that is free to configure the XBee however it needs it. Note: I can actually probably do this with a remote switch without any changes to the board as I have all of the XBee pins run to a .1" pin header. Alternative is simply turn the power off and turn it on when it is ready to program. However if you are using the power by USB jumper that approach is problematic.
An alternative to this, is I could probably do this in the software. For example the DIY remote code could have a page you step to, when you press the OK button, sets the xbee back to the defaults and spins until it is reset, or maybe cancelled. But this may be harder to program in, if I use this board for example to run my T-Hex. Although I am thinking of adding 1 button to the board to maybe help here.
Again glad your back
Kurt
Thanks Kurt! One week is not long enough. 
I’d prolly just add the button and be done with it.
Decided to have another batch fabricated… Did some more editing of the board. Things I change include:
If anyone is interested in looking I again uploaded the package with all of the design files, a somewhat up to date BOM (need to remove the parts I removed)…
Kurt
DIY_002.zip (445 KB)
The boards arrived today and I assembled one of them.
The good news, soldering in the Mux on this one was far easier than the first one… But I think I may have over sized the capacitor next to the speaker. When I plug in the usb, I hear my computer complain like it device went away… But the led on the board still was lit. I was able to plug in the AVRISP MK2 and download the bootloader to it and was able to download a test program, which so far I have verified the speaker works and the I2C EEPROM works…
Another minor issue with the Arduino 1.0 stuff was I labeled the Analog pins also with their digital numbers, that matched Sanguino boards(A0-31, A1-30… A7-24), which was screwy. The Arbotix people decided to break from this and renumbered them where A0-24, A1-25… A7-31. I personally think it was the right decision, as before if you did something like:
for (i=A0; i<=A7; i++) {…}
This loop would never execute…
Will continue to test and hopefully move it to my Arduino DIY remote control. Again assuming it works OK, will assemble 1 or 2 more and then maybe try ordering a small group of them from Seeed Studio, where you can get 10 for $10.
Kurt
Good job Kurt!
Alan KM6VV
I’m assuming that you have to handle the mux in the arduino sketch? As in there no way to make it native…
Yes, I deal with the MUX in the sketch, but it is not that big of a deal. Here is my simple AnalogPin test…
[code]void AnalogPinTest() {
int i;
Serial.println("");
for (iPin=0; iPin < 6; iPin++) {
pinMode(iPin, INPUT);
Serial.print(“Analog Pin “);
Serial.print(iPin, DEC);
Serial.print(”:”);
Serial.println(analogRead(iPin), DEC);
}
// Now lets test our extended Analog pins. - Configure the two digital pins as output and the two analog pins as input
pinMode(22, OUTPUT);
pinMode(23, OUTPUT);
pinMode(A6, INPUT);
pinMode(A7, INPUT);
for (iPin = 0; iPin < 4; iPin++) {
digitalWrite(22, iPin & 0x1);
digitalWrite(23, (iPin >> 1) & 0x1);
delay(100); // give some time to settle…
// Read the two values…
Serial.print(“X”);
Serial.print(iPin2, DEC);
Serial.print(":");
Serial.println(analogRead(6), DEC);
Serial.print(“X”);
Serial.print(iPin2+1, DEC);
Serial.print(":");
Serial.println(analogRead(7), DEC);
}
}[/code]If it became difficult, could easily provide wrapper function: that checked if < 6 use analogRead, >=6 set the appropriate digital values and then read from appropriate place. Also if others wanted to build this board and did not need more than 8 Analog pins, they could easily solder bridge two sets of pins going to the Mux and I think A6 would go to X0 pin and A7 would go to X5 or to the Voltage divider… If I order some from Seeed may put marks on Silkscreen to indicate this.
Kurt
In case anyone is interested, I thought I would post up an updates excel spreadsheet with the parts list, that I used yesterday to assemble the board.
You will need some form of AVRISP. I mainly use the AVRISP Mk2: digikey.com/product-search/e … 0?k=avrisp
You can probably use other ISPs like: trossenrobotics.com/p/USB-AV … mer.aspx….
Also to talk to the serial port you will need a FTDI break out: trossenrobotics.com/store/p/ … le-5V.aspx (Both of these are from Sparkfun)
Kurt
DIY Remote BOM.xlsx (13.9 KB)
Today I started to look to put the board I assembled yesterday into my Arduino Mega based remote control (viewtopic.php?f=21&t=7422&start=124). Right now I am trying to decide on IO pin mapping. Will probably start it’s own thread, or could continue on with the other thread as well…
What I am currently looking at doing is to experiment with leaving the XBEE on USART0 (which is also used by the FTDI breakout board). It will be interesting to see how reliable downloading new programs over XBEE works… Things like,need to reset XBEE to not be in packet mode, then reset processor… May be simpler to leave it off until the compile completes and then turn it on… Will experiment. This has the downside that you can be harder to debug as you can not output data to serial port… Will work on some solutions for this, plus some can be output using other things like the LCD.
Will use the 2nd USART to talk to the OLED
Analog pins A0-A5 will use for the Original 6 analogs (2 per each joystick and 2 sliders)
My Extended Analogs X0-X2 will use for new ones (rotation on joysticks, plus middle slider)
X3-X5 are Free
X7 - Voltage monitor.
Digital Pin: 0-7 will be used for keypad.
8,9,10,11 - Are the IO pins used by USART0 and 1
12-15 - Command buttons - If we get tight can reduce this down to one pin (add a row or Column to keypad), like I did with BAP version.
16-17 - Buttons on top of joysticks
18-20 - Are free - (May experiment with using a button to do a reset for download), but could this in keypad pages…
21 - Sound
(22-23 and A6-A7) - Are used in the MUX…
If we desire to try a parallel LCD We can easily reclaim some IO pins. The switches and buttons can be added to the keypad logic. Also can use X5-X5 and potentially X6 (Solder in pin for it) can be used for buttons as well, but would probably need external PU added. May be able to rig it using the underlying PU of A6/A7 when testing for these button… May experiment.
That is all for now… Thoughts?
Kurt
I’ve managed to control my parellel 4x20 vfd using a 74595 shift register. This means that we can control a full featured parallel display with just three pins as long as it has a 4bit mode.
I guess the question with adding a Shift register such as this, is do you end up needing another board to hold this and if so, do you still have a cost savings versus using one of the other displays with Serial or I2C connections…
Since the 74595 shift register is an 8 bit shift and you mentioned 4 bit mode, you probably put some of the other control lines on this as well? I know that a long time ago, when I built the Seattle Robotics Society workshop robot, I assembled a daughter board that controlled a Parallel LCD as well as a few other devices had 2 74595 for output and 2 74589 registers for input and they were connected to the SPI lines. I remember these chips were chained to each other so you can build whatever size output you desire.
Right now, I have the board mounted to the DIY case and am updating the code and still connecting all of the wires. There were some other issues with my earlier code that I am changing as well, like I was using DigitalWriteFast library which does not have support for the 644P, so changing back to normal digitalRead and DigitalWrite.
Kurt
The way I hooked it up I used four data pins, and then the RS, RW and EN pins were also connected. This allowed Reads and Writes to the display in 4-bit mode. I did not use the eighth bit to control the display.
