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:
- Got rid of JTAG Header - All of the pins needed for JTAG are all in one place so real easy to simply patch wire one up…
- Added in 1 button - Sometimes nice to have a button to push to end or start tasks…
- Removed the XBee automatic Reset the processor optional parts. - It is not a straight foreword process to setup to use. Need to modify XBee holder on PC, need to change make changes in the Device Manager, Probably need to update the firmware of the XBees to a version that supports it, plus make several configuration changes to the XBEE… Decide that very few including myself are going to go through the hassle.
- Added in a 3 pin header for Com1, that can use a Servo extension wire to connect to SSC-32 if desired. Or other boards as well…
- Replaced on of the POLCAPS with a larger metal SMT capacitor, so can now mount a 220UF cap instead of the 10 I used…
…
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.
I hate to admit it, but I just broke down and bought a serial LCD. A little bigger (depth-wise), but easier to interface if you’re limited on pins.
Alan KM6VV
Yep, Serial LCDs can be nice when you are low on IO Pins, But parallel is nice when you have several free pins, as that data is that you control the timing of the data, so it less susceptible to being corrupted than the serial ones are, unless of course if you have a hardware serial port available…
Still testing the new board in the remote control. Having a few issues with timing of the secondary analog inputs. Will work it out soon, but been busy with other stuff…
Kurt
Probably should continue this under Remote control, but I have been slowly working on making my DIY remote control to work with this new board.
So far I now have all of the inputs working 
. This includes using the inputs from the Multiplexer… Next will to be get it to work with the XBee on USart0.
Will work on making it such that maybe I can have it be programmed from the PC over the XBee. So would need to be in serial replacement mode at power up with it’s DL pointing to the the XBEE that is connected up to the PC. After it gets past the bootloader it will then switch into packet mode and start talking to whichever robot you have selected. Also since in this mode, I no longer have a standard debug terminal, so may write a quick and dirty VB app (I think I started one earlier), that my program can send debug information to and potentially get debug commands from.
With my current DIY Remote control code for this board, I have it read all 6 standard Analog inputs per pass and only up to one set of 2 of the extended ones. I then setup the extended ones for the next 2 and return. This gives a little time for the Analog signals to stabilize from the new set of pins before I try to sample them…
In case anyone wishes to see the WIP…
Kurt
DIY_Remote_644P-120530a.zip (27.6 KB)
Quick update:
Having some issues with getting the XBEE to work in the DIY on USART0 with the OLED on USART1. For some reason, when I try it, the USART0 TX stream is corrupted, where the TX1 stream appears to also come out on TX0. If I don’t have my jumpers in place to enable the XBEE this does not happen. Have traced some of the IO lines so far everything appears to be OK…
Next will try unplugging the OLED display… If I make Rev 003 of the board, I am now wondering if I should instead of using the resistor divider approach for voltage conversions for the XBEE, instead go to a chip like the Parrallax adapter does 74LCV244A. Could use a large 20 pin version, that should hopefully fit under the XBEE, bit taller than I would want… I sort-of remembered having issues before with the Arduino Mega shield and the XBee/OLED until I used this adapter…
Any other ideas?
Kurt
A R2R ladder does seem to be the easiest way and will perhaps use less space if SMD resistors are used. One could also look at Delta Sigma but that is probably equivalent to making a mountain out of a mole hill; not to mention the extra cost. I could not find any data sheet with 74LCV244A? Perhaps I am looking in the wrong place.
Could you design one with a smt processor ?
Yes, could design with SMT… Most all of the other components are SMT. My only issues are my old eyes and hands are not very good at hand soldering those really small pins… Should probably someday try making a solder mask and either try toaster oven or frying pan approach…
Kurt