Brandon:

I forgot about Mappy!  I'm sorry.

Also, I almost got Bob Allen to put a RoboBricks2 connector
on the latest Trinity Fire fighting board, but he forgot.

-Wayne

--- In RoboBricks2@yahoogroups.com, Brandon Blodget <brandon.blodget@...> wrote:
>
> I'd like to add that my Firefighter, Mappy, uses Robobrick2 modules :-)
> -Brandon
>
> On Mon, Oct 19, 2009 at 10:10 AM, waynegramlich <Wayne@...> wrote:
> >
> > Dave:
> >
> > As near as I can tell, the only people that use RoboBricks2
> > on a regular basis are myself and Bill Benson. We get
> > together on a weekly basis, so we tend to communicate
> > with one another verbally. To the best of my knowledge,
> > the only other person who built an actual robot that worked
> > with RoboBricks2 is Mike Thompson (his balancing robot.)
> > I do not think Mike is doing anything with RoboBricks2
> > these days. If I am wrong, please correct me. Anyhow,
> > that kind of explains the low level of traffic on this
> > group.
> >
> > Bill and I continue to work on robots using RoboBricks2.
> > We are actually trying to put a Table Top challenge
> > robot for October that uses a new laser sensor that
> > we have been working on. I have Bot-50 robot that is
> > going to be tasked for solving MicroMouse mazes.
> > Lastly, I have working on larger domestic robot that
> > currently has one (lame) arm, but will eventually have
> > two less lame arms. The domestic robot is forcing me
> > to learn all sorts of stuff about mechanical engineering,
> > CAD, CAM, Tormach CNC machines, etc. Hopefully, over
> > the next few months we can show a few robots successfully
> > using RoboBricks. It has been a long slog.

[snippage]

Dave:

As near as I can tell, the only people that use RoboBricks2
on a regular basis are myself and Bill Benson.  We get
together on a weekly basis, so we tend to communicate
with one another verbally.  To the best of my knowledge,
the only other person who built an actual robot that worked
with RoboBricks2 is Mike Thompson (his balancing robot.)
I do not think Mike is doing anything with RoboBricks2
these days.  If I am wrong, please correct me.  Anyhow,
that kind of explains the low level of traffic on this
group.

Bill and I continue to work on robots using RoboBricks2.
We are actually trying to put a Table Top challenge
robot for October that uses a new laser sensor that
we have been working on.  I have Bot-50 robot that is
going to be tasked for solving MicroMouse mazes.
Lastly, I have working on larger domestic robot that
currently has one (lame) arm, but will eventually have
two less lame arms.  The domestic robot is forcing me
to learn all sorts of stuff about mechanical engineering,
CAD, CAM, Tormach CNC machines, etc.  Hopefully, over
the next few months we can show a few robots successfully
using RoboBricks.  It has been a long slog.

-Wayne

--- In RoboBricks2@yahoogroups.com, Dave Curtis <dave@...> wrote:
>
> Bill Benson wrote:
> >
> >
> > Well Dave, this got to me so I suppose the forum still exists.  It has been
> > pretty dormant for some time however.
>
> Yup.  I was just going through my .procmailrc today and wondered if it
> was still worth having a filter rule.  That's the only reason I
> remembered its existence.
>
> -dave
>
> >
> > Bill
> >
> > Dave Curtis wrote:
> >
> >>
> >>
> >> Is this list still alive?
> >> -dave
> >>
>

Bill Benson wrote:
>
>
> Well Dave, this got to me so I suppose the forum still exists.  It has been
> pretty dormant for some time however.

Yup.  I was just going through my .procmailrc today and wondered if it
was still worth having a filter rule.  That's the only reason I
remembered its existence.

-dave

>
> Bill
>
> Dave Curtis wrote:
>
>>
>>
>> Is this list still alive?
>> -dave
>>

 

Is this list still alive?
-dave

Dave:

The group is still alive.

I'm lousy at marketing, so it has been idle for quite a while.

-Wayne

--- In RoboBricks2@yahoogroups.com, Dave Curtis <dave@...> wrote:
>
> Is this list still alive?
> -dave
>

Is this list still alive?
-dave

Dave:

I forgot to order a USBKey with my last DigiKey order, so
do not rush to document on my account.

Please hit me up for the $10 at the next HBRC meeting.
I'll pay in cash rather than check.

-Wayne

--- In RoboBricks2@yahoogroups.com, Dave Curtis <dave@...> wrote:
>
> Hi,
>     The board is 4 in^2, so that is a straight $10 at
> BatchPCB prices.  Don't worry about mailing a check --
> I'll catch up with you at the HBRC meeting.  I still have
> to complete some basic assembly notes for you anyway.

Hi,
     The board is 4 in^2, so that is a straight $10 at BatchPCB prices.
Don't worry about mailing a check -- I'll catch up with you at the HBRC
meeting.  I still have to complete some basic assembly notes for you anyway.

-dave

Wayne C. Gramlich wrote:
>
>
> Dave:
>
> I'm not going to make it to the Maker Faire, since my son
> wants to study for his three AP exams next week.
>
> When I look at all of the stuff I am trying to do, it
> is clear that working on the AT90USBKEY carrier board
> is not going to happen either this month or next for me.
>
> Please send me your address and the amount you are going
> to charge me for the board, and I'll mail you a check.
>
> If somebody is really anxious to get USB to RoboBricks2
> bus stuff going, I will gladly donate my rev. A board to
> the cause.
>
> -Wayne
>
> --- In RoboBricks2@yahoogroups.com
> <mailto:RoboBricks2%40yahoogroups.com>, Dave Curtis <dave@...> wrote:
>  >
>  > The AT90USBKEY carrier board arrived yesterday. I haven't
>  > had a chance to do anything but open the envelope. I'll put
>  > together a package of schematic and check plots and try to
>  > scribble down a few notes -- if I can manage to get to it
>  > today, maybe we can meet up at Maker Faire.
>  > Otherwise early next week.
> [snippage]
>
>

Dave:

I'm not going to make it to the Maker Faire, since my son
wants to study for his three AP exams next week.

When I look at all of the stuff I am trying to do, it
is clear that working on the AT90USBKEY carrier board
is not going to happen either this month or next for me.

Please send me your address and the amount you are going
to charge me for the board, and I'll mail you a check.

If somebody is really anxious to get USB to RoboBricks2
bus stuff going, I will gladly donate my rev. A board to
the cause.

-Wayne

--- In RoboBricks2@yahoogroups.com, Dave Curtis <dave@...> wrote:
>
> The AT90USBKEY carrier board arrived yesterday.  I haven't
> had a chance to do anything but open the envelope.  I'll put
> together a package of schematic and check plots and try to
> scribble down a few notes -- if I can manage to get to it
> today, maybe we can meet up at Maker Faire.
> Otherwise early next week.
[snippage]

The AT90USBKEY carrier board arrived yesterday.  I haven't had a chance
to do anything but open the envelope.  I'll put together a package of
schematic and check plots and try to scribble down a few notes -- if I
can manage to get to it today, maybe we can meet up at Maker Faire.
Otherwise early next week.

-dave

Dave Curtis wrote:
>
>
>
> Wayne C. Gramlich wrote:
>  >
>  >
>  > Dave:
>  >
>  > Could you sign me up for a Rev. A board?
> Yes, will do.
>

--- In RoboBricks2@yahoogroups.com, "Wayne C. Gramlich" <Wayne@...> wrote:
>
[snip]
>
> Some encoders have an index pulse that triggers once for
> each revolution.  This is used to "home" the encoder to
> a specific angle.  Most of the encoders we purchase tend
> to skip the index pulse since we do not need it.  So just
> hook up the wires you have and ignore the 5th wire.

This was my guess.  It is good to get confirmation.

> The firmware I burned into the chips about a year ago
> is pretty primitive.  The latest firmware performs a
> full dead reckoning algorithm.  I'll burn a chip up
> for you and we can swap at the next HBRC meeting.

Great.  I'll bring my bot and shaft2 module to the next meeting.

thanks,

-Brandon

--- In RoboBricks2@yahoogroups.com, Brandon Blodget <bbhome@...> wrote:
>
> Hi Wayne and all,
>
> I have a Shaft2 Rev D module I am looking to use.  The
> connector to the encoder has  five pins (Ground, Index,
> A Channel, +5 Volts, B Channel).
> My encoders (US Digital E4-200-079-HT) only have 4 pins.
> They are missing the "Index" signal.  What is the "Index"
> signal and do I need it to use the Shaft2 module?

Some encoders have an index pulse that triggers once for
each revolution.  This is used to "home" the encoder to
a specific angle.  Most of the encoders we purchase tend
to skip the index pulse since we do not need it.  So just
hook up the wires you have and ignore the 5th wire.

The firmware I burned into the chips about a year ago
is pretty primitive.  The latest firmware performs a
full dead reckoning algorithm.  I'll burn a chip up
for you and we can swap at the next HBRC meeting.

-Wayne

Hi Wayne and all,

I have a Shaft2 Rev D module I am looking to use.  The connector to the
encoder has  five pins (Ground, Index, A Channel, +5 Volts, B Channel).
My encoders (US Digital E4-200-079-HT) only have 4 pins.  They are
missing the "Index" signal.  What is the "Index" signal and do I need it
to use the Shaft2 module?

thanks,

-Brandon

Well, I've cleared the BatchPCB DRC-bot and ordered, so now we wait. ~3
weeks seems the norm.

-dave

Dave Curtis wrote:
>
>
>
> Wayne C. Gramlich wrote:
>  >
>  >
>  > Dave:
>  >
>  > Could you sign me up for a Rev. A board?
> Yes, will do.
>

Wayne C. Gramlich wrote:

  > 9) For the Atmel, serial programming is done using MISI,
  > MISO, and SCK, pins 17, 18, and 19.

For *this* Atmel.  For *most* Atmel. Not *all* Atmel.  That's a common
pitfall -- a few use other pins.

> I'm still scratching my head on J2. I think there is
> a circuit error. On the Atmel, MISO is an output which

Well, no.  MISO -- Master IN Slave OUT is an output if the Atmel is a
slave (SS# pin configured as an input and asserted low) or is an input
if the Atmel is a master.  Or if SPI is not used, it follows the data
direction register and can be general I/O.  A note about SS# -- if you
are using SPI in master mode only, *always* configure SS# as an output.
   If you configure it as an input, and SPI is used, then as soon as SS#
goes low, the Atmel goes into SPI slave mode.

>
> Oh, well, now I know there will be a Rev. E of Controller28.

Situation normal.

-dave

Hi Wayne,

Very interesting!  I don't know if I would have gone to all that
trouble, but it's a useful solution.  I've often wanted a 'bot board
that could support either chip.  My only solution was to put two 40 pin
sockets on the board.  It became easier to simply lay out two boards,
one for each chip.

Alan  KM6VV

Wayne C. Gramlich wrote:

>Alan:
>
>Please read the schematic for the Controller28 Rev D:
>
><http://gramlich.net/projects/rb2/controller28/rev_d/controller28.png>
>
>The labels on the left are for the ATmega168 the ones on
>the right are for the PIC16F876A.
>
>  1) The OSC1 and OSC2 pins (9&10)are the same for both chips,
>     thus, the resonator needs no special consideration.
>
>  2) For the Atmel Ground is on pins 8, and 22.  For the
>     PIC, ground is on 8 and 19.  Pin 8 is the same.
>     For the PIC, pin 22 is RB1, which is an I/O pin
>     that can be safely grounded.  Pin 19, is grounded
>     by jumpering J1 for the PIC.  For the Atmel, J1 is
>     left unjumpered so that PB5 can be used for SCK
>     needed for serial programming.
>
>  3) For the Atmel, VCC is on pins 7 and 20.  For the PIC,
>     VCC is on pin 20.  Pin 20 in in common.  For the PIC,
>     pin 7 is RA5, an I/O pin that can be safely tied to +5V.
>
>  4) For the Atmel, RXD is pin 2 and the PIC, RXD is pin 18.
>     In general, pins 2 and 18 can be safely connected together
>     and connected to RXD on the MCP2551.  I'll talk about J2
>     later.  On the Atmel, pin 18 is PB4, and I/O pin and on
>     the PIC, pin2 is RA0, another I/O pin.
>
>  5) For the Atmel, TXD is pin 3 and the PIC, TXD is pin 17.
>     Again, pins 3 and 17 can be safely tied together.
>     For the Atmel, pin 17 is PB3 and I/O pin.  and for the PIC,
>     pin 3 is RA1, another I/O pin.
>
>  6) For both the PIC and Atmel, pin 1 is reset.
>
>  7) The PIC needs pins 25, 27, and 28 for the ICD2 download
>     and debug capability.  N2 is unused for the Atmel.
>
>  8) For the Atmel, debugwire is done over Reset pin 1.
>
>  9) For the Atmel, serial programming is done using MISI,
>     MISO, and SCK, pins 17, 18, and 19.  J1 is left open
>     to connect pin 19 (SCK) to N6.  J2 is jumpered to
>     connected PB4 (pin 18) to N6.
>
>I'm still scratching my head on J2.  I think there is
>a circuit error.  On the Atmel, MISO is an output which
>would conflict with RXD on the MCP2551 which is also an
>output.  I think J2 was supposed to be placed directly
>on the line to MCP2551 (pin 4).
>
>Oh, well, now I know there will be a Rev. E of Controller28.
>
>-Wayne
>
>--- In RoboBricks2@yahoogroups.com, Alan KM6VV <KM6VV@...> wrote:
>
>
>>Hi Wayne,
>>
>>How is it that the controller-28 board supports BOTH
>>PIC and ATmega168?   I didn't think they were any
>>where close in pinout.
>>
>>

Alan:

Please read the schematic for the Controller28 Rev D:

<http://gramlich.net/projects/rb2/controller28/rev_d/controller28.png>

The labels on the left are for the ATmega168 the ones on
the right are for the PIC16F876A.

   1) The OSC1 and OSC2 pins (9&10)are the same for both chips,
      thus, the resonator needs no special consideration.

   2) For the Atmel Ground is on pins 8, and 22.  For the
      PIC, ground is on 8 and 19.  Pin 8 is the same.
      For the PIC, pin 22 is RB1, which is an I/O pin
      that can be safely grounded.  Pin 19, is grounded
      by jumpering J1 for the PIC.  For the Atmel, J1 is
      left unjumpered so that PB5 can be used for SCK
      needed for serial programming.

   3) For the Atmel, VCC is on pins 7 and 20.  For the PIC,
      VCC is on pin 20.  Pin 20 in in common.  For the PIC,
      pin 7 is RA5, an I/O pin that can be safely tied to +5V.

   4) For the Atmel, RXD is pin 2 and the PIC, RXD is pin 18.
      In general, pins 2 and 18 can be safely connected together
      and connected to RXD on the MCP2551.  I'll talk about J2
      later.  On the Atmel, pin 18 is PB4, and I/O pin and on
      the PIC, pin2 is RA0, another I/O pin.

   5) For the Atmel, TXD is pin 3 and the PIC, TXD is pin 17.
      Again, pins 3 and 17 can be safely tied together.
      For the Atmel, pin 17 is PB3 and I/O pin.  and for the PIC,
      pin 3 is RA1, another I/O pin.

   6) For both the PIC and Atmel, pin 1 is reset.

   7) The PIC needs pins 25, 27, and 28 for the ICD2 download
      and debug capability.  N2 is unused for the Atmel.

   8) For the Atmel, debugwire is done over Reset pin 1.

   9) For the Atmel, serial programming is done using MISI,
      MISO, and SCK, pins 17, 18, and 19.  J1 is left open
      to connect pin 19 (SCK) to N6.  J2 is jumpered to
      connected PB4 (pin 18) to N6.

I'm still scratching my head on J2.  I think there is
a circuit error.  On the Atmel, MISO is an output which
would conflict with RXD on the MCP2551 which is also an
output.  I think J2 was supposed to be placed directly
on the line to MCP2551 (pin 4).

Oh, well, now I know there will be a Rev. E of Controller28.

-Wayne

--- In RoboBricks2@yahoogroups.com, Alan KM6VV <KM6VV@...> wrote:
>
> Hi Wayne,
>
> How is it that the controller-28 board supports BOTH
> PIC and ATmega168?   I didn't think they were any
> where close in pinout.

Wayne C. Gramlich wrote:
>
>
> Dave:
>
> Could you sign me up for a Rev. A board?
Yes, will do.

>
> Just to be clear here. To be a RoboBrick2 you have to
> adhere to the CAN bus electrical standard and talk RoboBricks2
> protocol -- nothing else. The connector and mechanical stuff
> is actually extra.
I'm just trying to set clear expectations.

> I view the standard as three levels:
>
> 1) CAN electrical + RoboBricks2 protocol (required)
>
> 2) 2x5 Connector (optional, but strongly recommended)
>
> 3) 1.25" x 2.50" form factor with Lego hole spacing
> (strictly optional)

Yes, I'm doing a similar layering.

Working bottom up:
1) CAN electrical and CAN framing provided by a CAN controller.
2) Connector: 2x5 matching RoboBricks2 is one options, other connectors
possible.  Although I typically design around a right-angle 2x5 so that
I can do a mother-board/daughter-board arrangement easily.  But it isn't
hard to design a board that works with either a r/a or straight connector.
3) 48mm x 48mm or 48mm x 96mm basic form factors, which get bent
frequently.  But the location of 5 screw holes, the HBRC bus connector,
the U/I board edge, and application interface board edge are well defined.

So basically, for a lot of what I'm doing if there is a spare serial
port laying around, by leaving off the CAN controller and jumpering to
the UART the board can talk either protocol.

-dave

Hi Wayne,

How is it that the controller-28 board supports BOTH PIC and ATmega168?
I didn't think they were any where close in pinout.

Alan  KM6VV

Wayne C. Gramlich wrote:

>The Controller-28 supports both PIC16, PIC18, and the
>Atmel AVR ATmega168.  I think the ATmega168 is the better
>way to go.  You will need either the AVR-Dragon (~$50)
>or the AVR-ICE Mk.2 (~$200).  There is a nasty issue with
>the '168.  In order to debug it using the DebugWire protocol
>(available from either the AVR-Dragon or the AVR-ICE), you
>need to get the DWEN fuse turned on.  This can be done using
>either product, but it can not be done over the DebugWire
>cable.  With the AVR-Dragon, I use parallel programming
>mode to set the DWEN fuse.  After DWEN is set, everything
>else can be done over the DebugWire cable.
>
>The new Controller40 uses an ATmega324p which uses the
>JTAG cable instead of DebugWire.  I am still finding and
>fixing bugs in the Controller40 Rev. A board, so it is
>not ready for "prime time" yet.
>
>-Wayne
>
>

Dave:

Sounds like a reasonable design to me.

-Wayne

--- In RoboBricks2@yahoogroups.com, Dave Curtis <dave@...> wrote:

> Summary: CAN4Bots with 3.3V processor requires fully
> populated board, all other assembly options omit/jumper
> various parts. Actual hacking of the USBKEY to change
> voltage is only required if you desire 5.0V logic
> levels at the breakouts.

Dave:

Could you sign me up for a Rev. A board?  My goal is to
be sure that there are 2 or 3 of these things lying around
in the RoboBricks2 community.  Getting USB connectivity
will be a huge win.

--- In RoboBricks2@yahoogroups.com, Dave Curtis <dave@...> wrote:
>
> I'm at the checkplot/gerber review stage on a USBKEY breakout
> board as outlined below. My plan is to wrap up 3 or 4 other
> boards in the next 2 or 3 days and do an order through batchpcb.
> Does anyone want to be a guinea pig?  The board is 48mm x 52mm,
> or just under 4 in^2.  BatchPCB charges $2.50/square inch, so
> each board will run about $10.  This is a rev A board, so don't
> expect perfection.  I think it's right, but I always do :)
>
> Anyway, if anyone else wants to help check out the board,
> I'll include it into my order.
>
> Features are as outline below, plus:
> * Port A broken out in its entirety, and is unused on the USBKEY,
>    so that is a complete, undedicated, whole port.
> * SPI and UART broken out and available.
> * A few other scattered I/O are broken out opportunistically,
>    these are pins that are parts of ports needed for SPI, UART,
>    and the CAN controller and are not otherwise encumbered
>    by USBKEY peripherals.
> * The board is designed to my mechanical standards, not
>    RoboBrick2. So the board outline isn't RB2, and screw holes
>    are different. The mounting holes do line up on 8mm centers,
>    though, so they match Lego spacing.

Just to be clear here.  To be a RoboBrick2 you have to
adhere to the CAN bus electrical standard and talk RoboBricks2
protocol -- nothing else.  The connector and mechanical stuff
is actually extra.  I view the standard as three levels:

  1) CAN electrical + RoboBricks2 protocol (required)

  2) 2x5 Connector (optional, but strongly recommended)

  3) 1.25" x 2.50" form factor with Lego hole spacing
     (strictly optional)

> * Note that I pretty much blew off doing anything with the
>    analog inputs.
> * All through-hole components.

Yeah for thru-hole!

-Wayne

--- In RoboBricks2@yahoogroups.com, "wbowers9000" <wbowers9000@...> wrote:
>
> If I want to learn how to program the atmel chips what development
> board / chip package should I order? Ease of use being a greater
> priority over cost. My intention is to get up to speed on whatever chip
> (s) will be used in the robobricks.

I will continue to use the PIC16F688 for many of the RoboBrick2
modules that I design.  The '688is a PIC in a 14-pin DIP socket
that has no AVR counterpart from ATMEL.  This microcontroller
choice should have no impact on you, since it will be a while
before you start designing RoboBricks2 boards.

> The design of the atmel chips looks
> to be slightly better and cleaner than the pics. Normally I'd figure
> this out on my own, but I'm knee deep in getting my bot to work with
> what I've already got on hand. Which happen to be pics. I really liked
> what atmel had to say about the Zig-bee interface. :)

The Controller-28 supports both PIC16, PIC18, and the
Atmel AVR ATmega168.  I think the ATmega168 is the better
way to go.  You will need either the AVR-Dragon (~$50)
or the AVR-ICE Mk.2 (~$200).  There is a nasty issue with
the '168.  In order to debug it using the DebugWire protocol
(available from either the AVR-Dragon or the AVR-ICE), you
need to get the DWEN fuse turned on.  This can be done using
either product, but it can not be done over the DebugWire
cable.  With the AVR-Dragon, I use parallel programming
mode to set the DWEN fuse.  After DWEN is set, everything
else can be done over the DebugWire cable.

The new Controller40 uses an ATmega324p which uses the
JTAG cable instead of DebugWire.  I am still finding and
fixing bugs in the Controller40 Rev. A board, so it is
not ready for "prime time" yet.

-Wayne

Well, the "clean architecture" is to me less important than what having
a clean architecture yields: C code that is easy to port from one AVR to
another with a simple recompile, and good support from the gcc tool chain.

So as to which AVR to start playing with, "any" is a reasonable answer.
   The ATMega324p has a good mix of features, I've been designing it into
a lot of my (non-RoboBricks) boards, and the 324p is designed into at
least some RoboBricks boards.  It comes in a 40 pin DIP as well as
surface mount, so it's easy to experiment with.

As to programmers, there are lots of choices.  If you want to do ICE
debugging, then your main choices are the JTAG ICE MK II, which handles
all Atmel parts, is ready to roll out of the box, and is the more
expensive solution.  The other choice is the Dragon, which will only
debug up to 32K, and is bare-bones -- you'll have to solder on some
connectors and so forth, but is much cheaper.  For programming only, the
AVRISP MK II is a good solution, and cheap.

There's a little bit of stuff on the Wiki about getting started with
AVR's -- I started a write-up, but it's full of holes still.

-dave

wbowers9000 wrote:
>
>
> If I want to learn how to program the atmel chips what development
> board / chip package should I order? Ease of use being a greater
> priority over cost. My intention is to get up to speed on whatever chip
> (s) will be used in the robobricks. The design of the atmel chips looks
> to be slightly better and cleaner than the pics. Normally I'd figure
> this out on my own, but I'm knee deep in getting my bot to work with
> what I've already got on hand. Which happen to be pics. I really liked
> what atmel had to say about the Zig-bee interface. :)
>
>

If I want to learn how to program the atmel chips what development
board / chip package should I order? Ease of use being a greater
priority over cost. My intention is to get up to speed on whatever chip
(s) will be used in the robobricks. The design of the atmel chips looks
to be slightly better and cleaner than the pics. Normally I'd figure
this out on my own, but I'm knee deep in getting my bot to work with
what I've already got on hand. Which happen to be pics. I really liked
what atmel had to say about the Zig-bee interface. :)

I'm at the checkplot/gerber review stage on a USBKEY breakout board as
outlined below. My plan is to wrap up 3 or 4 other boards in the next 2
or 3 days and do an order through batchpcb.  Does anyone want to be a
guinea pig?  The board is 48mm x 52mm, or just under 4 in^2.  BatchPCB
charges $2.50/square inch, so each board will run about $10.  This is a
rev A board, so don't expect perfection.  I think it's right, but I
always do :)

Anyway, if anyone else wants to help check out the board, I'll include
it into my order.

Features are as outline below, plus:
* Port A broken out in its entirety, and is unused on the USBKEY,
    so that is a complete, undedicated, whole port.
* SPI and UART broken out and available.
* A few other scattered I/O are broken out opportunistically,
    these are pins that are parts of ports needed for SPI, UART,
    and the CAN controller and are not otherwise encumbered
    by USBKEY peripherals.
* The board is designed to my mechanical standards, not
    RoboBrick2. So the board outline isn't RB2, and screw holes
    are different. The mounting holes do line up on 8mm centers,
    though, so they match Lego spacing.
* Note that I pretty much blew off doing anything with the
    analog inputs.
* All through-hole components.

-dave


Dave Curtis wrote:
>
>
> Having slept on it, here is what I think makes the most sense:
>
> Four assembly options, the matrix being:
> Processor 3.3V v. 5.0V.
> CAN4Bots v. RoboBricks2.
>
> Processor 3.3V is an unmodified USBKEY
> Processor 5.0V is the standard R20/R21 jumper swap as defined by Atmel.
>
> CAN4Bots includes an MCP2515 CAN controller chip.
> RoboBricks2 omits the MCP2515 CAN controller.
>
> The MCP2551 XCVR always runs off of HBRC bus 5V.
>
> The USBKEY always runs off of switched, unregulated logic battery at
> 7.5V(?) nominal or greater, supplied via the USBKEY's built-in two pin
> connector. (The regulator Atmel uses requires 1.5V headroom. There is
> also a diode in series, I haven't checked what the forward voltage drop is.)
>
> USBKEY regulated Vcc (either 3.3V or 5.0V depending on R20/R21 swap)
> supplies I/O breakout and the MCP2515 CAN controller.
>
> A pull-up and Schottky diode circuit does level translation at the
> MCP2551 RXD output. This can be omitted when the processor is set for 5V.
>
> Summary: CAN4Bots with 3.3V processor requires fully populated board,
> all other assembly options omit/jumper various parts. Actual hacking of
> the USBKEY to change voltage is only required if you desire 5.0V logic
> levels at the breakouts.
>
> -dave
>

Having slept on it, here is what I think makes the most sense:

Four assembly options, the matrix being:
Processor 3.3V v. 5.0V.
CAN4Bots v. RoboBricks2.

Processor 3.3V is an unmodified USBKEY
Processor 5.0V is the standard R20/R21 jumper swap as defined by Atmel.

CAN4Bots includes an MCP2515 CAN controller chip.
RoboBricks2 omits the MCP2515 CAN controller.

The MCP2551 XCVR always runs off of HBRC bus 5V.

The USBKEY always runs off of switched, unregulated logic battery at
7.5V(?) nominal or greater, supplied via the USBKEY's built-in two pin
connector. (The regulator Atmel uses requires 1.5V headroom. There is
also a diode in series, I haven't checked what the forward voltage drop is.)

USBKEY regulated Vcc (either 3.3V or 5.0V depending on R20/R21 swap)
supplies I/O breakout and the MCP2515 CAN controller.

A pull-up and Schottky diode circuit does level translation at the
MCP2551 RXD output. This can be omitted when the processor is set for 5V.

Summary: CAN4Bots with 3.3V processor requires fully populated board,
all other assembly options omit/jumper various parts. Actual hacking of
the USBKEY to change voltage is only required if you desire 5.0V logic
levels at the breakouts.

-dave

Dave Curtis wrote:
>
>
>
> Wayne C. Gramlich wrote:
>
>  >
>  > I would design the board so that it takes external battery
>  > at 6V+ and provides 5V for the RoboBricks2 bus. That way
>  > no surgery on the USBKEY is required.
>
> My only quibble with that is that because of the diode and the fact that
> the LM340 is *not* an LDO regulator, if you drop below 7.0-7.1 input you
> are likely to drop out of regulation on the USBKEY. But, s/6V/7.5V/ and
> that is certainly an option.
>
>  >
>  > I would just want to drive an MCP2551 which will run
>  > just fine with 3.3V inputs. It will need 5V for power,
>  > but that is available. If the AT90USBxxxx has
>  > 5V tolerant inputs, nothing special is required.
>
> Data sheet says "Absolute Maximum Vih: Vcc+0.5V" -- so some level
> translator is needed.
>
>  >
>  > > I suppose the USB KEY could have it's own battery supply
>  > > referenced to the common HBRC logic ground -- I just hate
>  > > the requirement of a second set of logic supply batteries.
>  >
>  > There should be one set of batteries, and it should power
>  > the USBKEY *and* the HBRC bus. Just add an LM2490 and a
>  > couple of filter capacitors.
>
> OK, so I've been assuming power off the bus, not powering the bus. But
> powering the bus is certainly an option. Or another option is requiring
> switched unregulated logic battery at 7.5V or greater, powering only the
> USBKEY board. And it could certainly be designed so that you have the
> option of either.
>
> In either case, while this yields a zero-hack solution, you still have
> 3.3V I/O from the processor. The MCP2515 CAN ctlr will run at 3.3V, but
> Vih max is Vdd+1.0. The MCP2551 data sheet I am looking at has a
> clearly erroneous number for Voh min, and I couldn't find a Voh max.
>
> I'm going to sleep on it.
>
> -dave
>
>

--- In RoboBricks2@yahoogroups.com, "wbowers9000" <wbowers9000@...> wrote:
>
> With the new robobrick under development using the atmel chip I
> started looking at the specsheet for the AT90USB1287 and comparing it
> to the PIC16F877 (the first pic specsheet I came across this
> morning). I must be missing something. The capabilities of the chips
> seem very similar at first glance. Excluding the cost of the tools,
> considering just the chips themselves, what is the advantage of the
> atmel chip? Granted, I am looking at the spec sheets with 2 kids
> running around and making a LOT of noise.
>
> Tell me if I have this right:
> atmel
> -----
> 16 Mips
> 128 K program
> 8 K data
>
> pic
> ---
> 5 Mips
> 112 K program
> .368 K data
>
> I'm continuing to read the AT90USB1287 spec sheet. What points of
> interest should I look for that I may have missed?

In general, for roboticists, the choice between Atmel vs.
PIC is made on issues unrelated to the chip architecture.
For me, the cost of a programmer + C compiler + debugger
+ platform + chip package needs to be factored in.

For PIC, compiler = $99, programmer + debugger = ICD2 =
$160, platform = windows only, package = DIP or Surface

For AVR, compiler = free, programmer + debugger = AVR-Dragon =
$52, platform = windows/MacOS/Linux, package = DIP or Surface.
The AVR-Dragon does not work for all chips, tho'

For me, Atmel is ahead right now.

--------------------------------------------------

Having said all of that, my overall goal is to move
software development off of these 8-bit microcontrollers
and onto higher performance 32-bit microcontrollers.
Hence, the push to use the WRTSL54GS router, and figuring
out how to interface RoboBricks to USB and/or Ethernet.
A 32-bit microcontroller running Linux is going to be
a lot easier to program than any 8-bit microcontroller.
Thus, the choice of AVR vs PIC is a decision that I
as a RoboBrick board developer care about, but the users
should not care as much.  The Controller-28 accepts
either PIC or AVR parts.

-Wayne

With the new robobrick under development using the atmel chip I
started looking at the specsheet for the AT90USB1287 and comparing it
to the PIC16F877 (the first pic specsheet I came across this
morning). I must be missing something. The capabilities of the chips
seem very similar at first glance. Excluding the cost of the tools,
considering just the chips themselves, what is the advantage of the
atmel chip? Granted, I am looking at the spec sheets with 2 kids
running around and making a LOT of noise.

Tell me if I have this right:
atmel
-----
16 Mips
128 K program
8 K data

pic
---
5 Mips
112 K program
.368 K data

I'm continuing to read the AT90USB1287 spec sheet. What points of
interest should I look for that I may have missed?

Wayne C. Gramlich wrote:
> The question is whether
> the AT90USBxxxx is 5V tolerant.

Nope.

> If not, some sort
> of voltage divider is needed.
>