Instead it would introduce the “Why can’t I have Wifi” and the “Why can’t I have Bluetooth” and the “Why can’t I have RS232” problem threads.
None of them are interchangeable.
TTL / CMOS works with anything.
I think that was me. 
I would love to see stacking connectors on the ABB that has all the MCU signals brought out. This would make it insanely easy to add other interfaces such as Bluetooth, ZigBee, and lots of other stuff like specialized and/or custom sensor interfaces, external EEPROM, etc.
Right now, the only real easy way to interface some new hardware is build another board or module and run it serial or I2C. It would be much easier and nicer being able to stack a board right on top of the ABB for custom interfacing. I think this could create a whole new market area for the ABB and Atoms and custom stacking modules could be created and added easily. I think all that would be required is a single row connector on two sides of the ABB out of the way of the sensor/servo connectors.
These are all good reasons to provide stacking connectors on the new ABB. This way, you choose where you want to put things. If it isn’t reasonable for a stacked wireless module, put it where ever it would make the most sense. It could still be a stackable module, as well as a standalone module connected by a cable or wireless link. This is one feature I really love about the Pluga modules New Micros has.
8-Dale
You just agreed with what I have been trying to say all along.
Each technology whether it be RS232, Buetooth, I2C, etc… they can all exist on the same board and utilized; provided the outputs are designed to work together. Together not meaning talking to each other, but simply any one piece of technology can be used by it’s self for its intended application. The PC has USB, RS232, PS2, ETC… you pick your flavor with what you want to use.
Perhaps I miss understood some things, my apologies.
This is true, but in the case of the new Mini Atom Bot Board Design, there is a finite amount of space to put things on. There just isn’t enough board space, with the current form factor, to add Bluetooth, ZigBee, or WiFi, and such other things we might want there.
There may not even be enough room to add a USB interface. At some point, there really does need to be USB on the bot board, if for no other reason than to fix the USB adapter problems many are having when using Laptops.
8-Dale
USB I think should be the first priority and then see what kind of space is left. I’m sure you can get USB and at least some kind of interface connector like you were mentioning before.
I’ll keep my mouth shut for anything else 
Unfortunately for each interface you add, you have to utilise at least one extra pin on the processor. It is not possible to run different 3 different devices off one UART on the processor.
The more UARTs a microprocessor the bigger the footprint, the more serial handling code that needs to be running in the proceesor therefore less processor power and memory for the end user to write code.
P.C.s do it but at a massive cost. The whole botboard is smaller than a Pentium chip. The physical size of board needed to have a USB socket, a DB9 and an SMA aerial socket plus bluetooth aerial backplane would make the botboard two or three times the size it is now.
How about some kind of Lexan panel the same size as the bot board with holes predrilled for short standoffs for common modules and/or an option of no holes? This would let people stack their WiPort V2, BlueSMiRF, ZigBee, USB->RS-232 converter, etc. with the bot board or an SCC-32 without taking up any more space on the board itself. Some handy tutorials on how to interface common modules using TLL or 12V RS-232 headers, (the IDC cables needed to do this are already on the site) and basically everyone is happy. If someone really needs to cram stuff into a small package they might be out of luck, but at that point tough noogies you need to make something more custom.
Well said Tillin9
The way of the future…modules… or was that last year…
I honestly would hate to be RobutDude because everyone of the comments is valid to the person making it. We all have a vision of what we want and unless you make a board 4 foot wide there is no way to satisfy everyone…
I’ll admit I’m picky about what I buy, its why I follow these forums. SOme of the ideas are stunning…
Sorry for the hijkack…
back to the argument… scratch that… discussion
My only opinion on the ABB really would be that I’d like to see a *smaller *one. It’s already fairly small, but it’s a lot bigger than it needs to be.
Who is really powering a lot of servos or motors or whatever from it? Usually it looks pretty empty, and the Sabertooth and/or the SSC-32 is doing the heavy lifting. I say scale it back, scale it down, and leave more floor space in the bots for other stuff.
I don’t really see any point in sticking with the largish ooPIC-R form factor moving forward. I mean seriously you can get a 1GHz PC smaller than that thing! 
I admit that stacking with the SSC-32 is really nice for servo bots. Even so, if it was a lot smaller, it would fit next to the SSC-32 no problem, and it would be great to have a smaller one for rovers, that’s all I’m saying.
The ABB is already as small as it can be and is cramped for space already. It can’t get any smaller and retain the utility is has as a carrier board for 24 and 28 pin microcontrollers.
Generally, unless it is a very small project, we don’t use the ABB/Microcontroller to control servos directly. We use the SSC-32 for servos and a motor controller like the Sabertooth for motors.
How is this a reason to scale the ABB down? The ABB has all the I/O from the microcontroller direct, which is barely enough to handle the bunch of senors most of us want to put on a robot. Even with my rover, W.A.L.T.E.R. I am having to go to expansion I/O chips and I2C to get more I/O and conserve on use of the ABB’s I/O connections.
That 28 pin socket has to be there or the ABB loses its utility as a carrier board. The ABB is not about being the smallest board for a microcontroller. It’s about being a carrier for microcontrollers like the Basic Atom and Atom PRO.
What form factor would you go to for the ABB if you could?
How exactly would you make the ABB smaller while still retaining its utility as a carrier board?
8-Dale
One way to do that is front and back SMD components. Squish it all together and stick all the resistors and other crap on the back so that you can have the front of it for just the headers. I think removing the BS PS2 port can help scale it down a bit… But honestly. I am fine with the size. I think it is tiny enough.
If you aren’t happy with its size and need something small for your specific project then make your own board! batchpcb.com sells PCBs for 2.5$/sqr-inch! Thats a damn good deal. Theres many threads about custom micro board in the forums so you can read up on it if you want. SN96 made a nice board.
On the other hand, I think that the SSC-32 can be made a little smaller, or at least space efficient. That DIP is large! Going to a small SMD package would increase room on the board allowing for more servos or other goodies… or in general making the board smaller. Removing the DP9 and replacing it with a USB port would also give some extra room.
Oh, another way I thought of to make the ABB smaller is to make the speaker “external” and just connect its header to a port. The speaker is rather large and not many people use it. Most people who use speakers generally buy a larger speaker.
One rule about size… You can only make your product as small as the largest part. The largest part I see is the 3 x 19pin header section. If you wanna make the board smaller, you would need to either:
A) Remove pins
B) Use the SSC-32 style layout and split the pin location in half. This would require either:
A) Removing DB-9
or
B) removing the push buttons/LEDs.
I personally feel that the Mini-ABB should be left alone in size. If you change its size, then you would need to make adapters or make the other boards smaller so you can stack 'em.
I, however, think the board should be made more space efficient. Lynx should remove some of the stuff, or make it smaller, and then use the new space to add new feature such as an I2C EEPROM socket or I2C 8-bit I/O expander.
I don’t really have a problem with the size of the ABB. It’s pretty small. And robodude summed it up pretty nicely, so no need to repeat. I’m not saying it should be a replacement board for larger do-everything megabots.
I guess what I’d really like to see is a smaller board for smaller applications. Not everyone thinks MORE and MEGA is better. There are different schools of thought. I want to build some small bots, and I want to use Lynxmotion parts, but if I want to build anything smaller than a mini-sumo sized bot I’ll have to look elsewhere for a carrier board.
The board would need a 28 pin socket, a USB port, and a handful of IO ports to talk to a motor controller and let’s say four to six sensors. I2C would be fine. Ideally it would stack with a Sabertooth 2x5. Now that would RULE for small bots. Think about it.
I sure ain’t gonna be making one … my time is best spent on the mechanical and programming stuff.
32 servo cables, 3 power input lines, 4 A/D lines and a comms line… Please dont make it any smaller… Actually I found the layout helps to make quite a tidy cable layout.
The plug fot a USB may be a bit smaller but when you take into account the metal shields etc they can get quite large. Theres not much space saving.
I’m not sure how hard it would be, but the DB9 connector on the ssc-32 boards could be unsoldered and removed to get rid of its bulk. The ssc-32 only needs three wires (tx, rx, and ground). To make a smaller serial connector one could get a servo extension cable, cut it in the middle, and solder one end to the board where the DB9 was and the other to the wire comming from the serial port. Then just connect the servo connectors together for the connection. As for adding a USB connector, what would its purpose be? USB is designed for use up to ~16’, where serial connections can be on long runs of wires.
Some side comments back to Robot Dude’s original questions:
-
For I2C pull-up resistors, I like his idea. If that will take up extra room, I would probably simply default to 1K resistors. I am pretty sure that is what several other board manufactures have done. This includes the Bdmicro.
-
I like the idea of having connections available to do a daughter board. For the most part we might be able to do some of that now. If you design the daughter board to have a connection on the bottom that plugs into the 28 pin DIP and then have a 28 pin dip plug on top…
-
I would not get rid of the standard serial communications as there are lots of ways this can be used. However one possibility to save space would be to remove the DB9 connector and have a 4 pin connector with an external cable that has the DB9 connector on it…
Just a few thoughts.
0.10" header plugs are probably better for that application, but yeah, something like that would allow for a standardized bus, much like the “appmod” connectors on the Parallax products. (though truth be told, I’ve only ever used a total of one daughterboard with an appmod connector, and for that, I made a breakout so that it didn’t need to plug into a header socket)
5-pin, with either pin #2 or 4 missing, corresponding to a plugged hole in the mating connector, to prevent plugging it in backwards. 
This would work great and would be a good way to make room for other stuff, perhaps even a USB interface two stacking connectors.
I completely support a change like this for cables, to get connectors off the ABB!
8-Dale
I noticed on the BotBoard pdf file there are several implementations for Hexapod where the SSC-32 is used as well.
In this case, the Serial from the Botboard is implemented on a DIO pin (15 I think) as a one way Tx.
Would it be possible to implement the Rx on the adjacent DIO. This would then allow responses back from the SSC. In particular the ‘Q’ commands could then be used and the ‘V’ commands thus making the A/D inputs on the SSC available to the Botboard. Double the number of A/D available.
Taking it one step further, could any command prefixed with a SSC-32 command, i.e. #nPnnn or VA be passed transparently to the SSC so the user only has to connect to the Botboard Serial port and has access to the SSC through theBotboard. This latter bit might just be a user/programmer issue.
My current implementation of the ATOM Pro port of the Hex code does use a second line to the SCC board so that I could use the ‘Q’ command to see if the previous command had completed before issuing a new one. Appears work fine.
I have not tried using the A/D inputs yet. With the Pro you can have up to 8 of them on the ABB board.
I have thought about trying this out, but have not done so yet. I thought it would be nice to be able to press a button or the like on the ABB or PS2 controller and enter into this mode. Then I was hoping like I could use SEQ to modify sequences without having to rewire…
I think the RX is there, but is just not implemented in the cable that is provided at present. I don’t know why a true bidirectional cable isn’t being provided when it would be very useful.
You could create a bidirectional cable using a servo extension cable though, like I plan to do.
I believe this can already be done or already is done. I think the serial port to the SSC-32 is a different address than the main serial port you connect to in order to program the microcontroller on the ABB.
8-Dale