Time for a Bot Board redesign, what features should we add?

Well, right now, the ABB stacks very nicely with the SSC-32, and I think also a dual H-Bridge board. I am betting that Jim wants to keep the current form factor for that reason.

8-Dale

The reason for this post was to see what changes to the Bot Boards hardware the users would like to see. I appreciate all of the feedback so far! The Bot Board with it’s 28 pin socket fits the Atom processors best. All other Stamp pin compatibles are 24 pin. I wanted to see what changes we could make to take better advantage of the hardware commands on the Atoms. For example, pin9 on the Atom 28 has a hardware PWM, so we connected it to the mini speaker on the Bot Board. To my knowledge it’s never been taken advantage of, but it’s there… However I’m finding the Atom 28 and the Atom Pro 28 don’t share the same hardware functions on the same pins. So I may need to make it favor the Pro. As far as hardware I2C, I’m told don’t worry about trying to use hardware I2C pins because it’s fine to do it in software, and can be a pain to try and do it with the chips hardware anyway.

Here is a little info on the Atoms

ATOMPRO28
P0(P50/WKP0)<->(PB0/AN0)
P1(P51/WKP1)<->(PB1/AN1)
P2(P52/WKP2)<->(PB2/AN2)
P3(P53/WKP3)<->(PB3/AN3)
P4(P54/WKP4)
P5(P55/WKP5/ADTRG)
P6(P56/SDA)
P7(P57/SCL)
P8(P80/FTCI)<->(P15/IRQ1)
P9(P81/FTIOA)<->(P74/TMRIV)
P10(P82/FTIOB)
P11(P83/FTIOC)
P12(P84/FTIOD)<->(P10/TMOW)
P13(P85)<->(P20/SCK3)
P14(P86)<->(P21/RXD)
P15(P87)<->(P22/TXD)
AX0(P11)<->(PB7/AN7)
AX1(P12)<->(PB6/AN6)
AX2(P16/IRQ2)<->(PB5/AN5)
AX3(P17/IRQ3)<->(PB4/AN4)

ATOM28
P0-P7 are PortB pins
P8-P15 are PortC pins
AX0-AX3 are PortA pins(pins AX0,1,2 and 3)

For ATOMPRO see H8-3664 hardware manual
For ATOM hardware functions see the PIC16F876 data sheet from microchip.com

Nathan Scherdin
www.BasicMicro.com
www.XLNTIdea.com

If this has to do with using the speaker to make noises, I use it for that all the time to indicate which sensor my robot is detecting with. I have a different sound combination for each sensor.

Personally, since the Basic Atom and Atom PRO are the same price anyways, I think the Basic Atom should just be phased out as a product. While it is true there is not as much software for the Atom PRO right now, that is starting to change. Favoring the Atom PRO over the Basic Atom would hopefully fuel and encourage further development for the PRO. I won’t be doing any more new development for the Basic Atom. Maybe there will be another H8 based microcontroller released at some point that would match the pinouts of the current H8 based Atom PRO. For instance, having more memory and being faster is almost always better. :slight_smile:

Is this due to problems with the H8’s I2C hardware? Shouldn’t hardware protocol management normally be better than doing it in software?

8-Dale

If the serial port pins are linked the same way they are in the SSC-32 then the BlueSmirf works amazingly easy. 1 x 2 way Header to pick up a 5V supply, the other a 3 way header (I used a dead servo lead) to pick up the TTL serial and instant BlueTooth.

I used the BlueSmirf with an external aerial but if you only want close range then they do an internal aerial version.

It also connects to my Mobile phone and my XDA (Jasjar) so instant remote control as well. (As long as you can program Windows Mobile)

:open_mouth: :confused: I’m lost… :laughing:

I have no previous training or understanding of electronic boards so I am also confused of what they are saying. All I can say is it would be nice to have some kind of wiport embedded into the bot board making it wire free. This could help cut down on cost for the purchasing of another board to piggy back onto this. Just think of a beast that would be!

The problem with embedding Wifi and all other wireless stuff is that its changing so rapidly that by the time the board was ready for production, the wireless hardware would be unobtainable.

The best that can usually be achieved is to make sure that a socket somewhere is available and that consideration is given when writing firmware code, that someone, somewhere is going to want to do it differently.

A prime example of this that we are seeing in my job, is systems that have TCP/IP V4 embedded. V6 is now available and the hardware which in some cases can’t be upgraded, is useless.

I think the idea that someone mentioned of being able to stack daughter boards would be ideal if its flexible enough. Then you just plug in whatever fits. I’m sure, going by the standard of some of the work ive seen on this forum, it wouldnt be long before a good list of modules would be available.

RS232 ports are disappearing on PCs. Please add a USB to RS232 for programming and 2 I2C DACs.

Unfortunately, with Windows you will never get away from RS232, To use USB on a P.C. it has to made into a virtual RS232 port.

As to the hardware, it always means having a massive socket with an ungainly screened cable hanging out the bottom.

To have a true USB interface built requires registration of the low level drivers with Microsoft.

RS-232 is not going anywhere. I just recently purchased Core Duo 2 boards that had 4 serial ports per board. And a USB to serial converter is $10 if you need it. There is no PC board made in the past decade that I know of which doesn’t come with either serial ports, USB, or both.

The vast majority of consumer USB devices integrate the USB to RS-232 converter. However, most microcontrollers don’t have USB capacity, and when then do for example on the PIC 18F2550 and 18F4500, its USB slave support i.e. they can be a device attached to a USB host, like a PC. USB master support is not an option on ANY micro I know of, and is just becoming an option on some higher end embedded systems.

There is no way baring a high end embedded with USB master support to run a cheap USB WiFi or bluetooth dongle on a bot. Not to mention on such a system you’ll see why those devices are so cheap, they offload nearly all the work onto the central processor. This might be fine on a PC which has cycles to spare, but on a bot, this could be over 50% of your processing load.

However, there are plently of WiFi or Bluetooth to RS-232 devices. The BlueSMiRF and the WiPort are both rather good at this. While I’d love for Lynx to carry a breakout board for the WiPort, integrating this into the bot board is too much expense for too little gain.

I would recommend more I2C expansion and the terminating resistors, since OpenServo and many other smart servos (the Biloid for example) are using I2C as their preferred method of connection and this trend is likely to continue in the future, since HMI (Hitec’s proprietary alternative is) doesn’t seem to be gathering much steam.

I also agree with linuxguy, that having the regulator laying down would help. I’ve felt like I was going to break off the regulator from my SCC-32s a number of times. Plus, laying flat you could add a cheap Al sink without taking up too much extra space. In that vein, you might want to put the speaker up by the LEDs and switches and use the resulting large flat area for the regulator. Dedicated IDC pins for the serial port(s) might be a good idea to make it easier to hook up peripherals, but the ports are already exposed on the current design, one just has look up which ones to use.

Did I mention built in Bluetooth :smiley:

I think someone mentioned bluetooth. Either way, bluetooth isn’t hard to add. Just connect the pwr/gnd pins and the Rx/Tx to their pins on the micro and you have bluetooth… Adding onboard bluetooth would bump the price up like $60. Which kills the main feature of the Bot board - It is an affordable carrier for the BA.

But it would be all inclusive :smiley:

Meh, not everyone wants bluetooth. I know I don’t yet. I am fine with a serial cable or a USB cable. However, if the Bot Board stays with serial, Lynxmotion could sell an adapter which plugs into the DB9 on the BB and has a bluetooth module on it. That would save you some time and you won’t have to solder on the board either.

Bluetooth modules are only like $60 at sparkfun so its not bad. If you buy a large lot, you get discounts :slight_smile:

DB9 cables are sooo limited. I think an adapter might work, though it would have to be for a specific type of bluetooht module. I think LM should pick a good one and build it around that.

Serial?! LIMITED? It can go fine at 115Kbps and can reach maximum speeds of almost 900Kbps!!! My project I am using 115Kbps and the data pops up right away in the terminal. You don’t understand how fast 115,000bps is. “1” is a bit. To send that to the screen it would take 8.69uS. To send a byte it would take 69.56uS. Thats .0000695652174 SECONDS. Thats beyond the speed you need for sending some data. I don’t think youl be sending MP3 files via Serial or bluetooth. Full USB is for that: 12Mbps. A $15 USB to USART bridge chip would do it for ya.

I think RS232 serial should get a prize for being one of the best methods of communication ever invented!

Either way… WiFi is better for wireless.

I meant as in range and teathered…:wink:

Simple solution: Get a longer cable :stuck_out_tongue:… Anyways, back on topic. Don’t want to spam this thread.

Would it be possible for you guys to add some I/O extensors or whatever its called? To give us more I/O ports =D What about having an ATMEL on board for that and going through the atmel via serial to get I/O data? Sort of like a small SSC-32 onboard but for general I/O stuff :slight_smile:?

Thats not exactly a solution, but no more highjacking this thread…

that would be awsome :laughing:

yes i agree there should be a feature like that