Hi Wayne,

> In message 5 you said:
>
> > I've done a few bootloaders for the ATMega as well,
> > so I should be able to do a bootloader for the ATMega88.
>
> Somebody's going to have to do one. ;-)
>
> -Wayne
>

In anticipation of getting my hands on the RoboBricks2 modules I
looked over the Controller28 module with regards to using it with the
ATmega88.  Below are some notes.

I should have realized this earlier, but the ATmega88 is the 8K
version of the ATmega168 I use in the OpenServo.  Your Controller28
board should support the ATmega8, ATmega48, ATmega88 and ATmega168
MCUs as they all share a common 28 pin pinout.  I have one or two DIP
versions of the 168 on hand that I can use with the board.

Unfortunately the leads for the in-circuit PIC programmer go to
different leads than the in-circuit ISP pins needed by the AVR.  No
surprise there.  With this in mind I think it would be useful to
contemplate a version of the Controller28 which supports the standard
AVR 2x6 ISP header on it.  For now, I can simply use my STK500 to
program the AVR chips.

With regards to a bootloader, as part of the OpenServo project I have
bootloader code specific to the ATmega8/48/88/168 MCUs.  The only
issue is that it's front end is I2C rather than UART, but it shouldn't
be terribly difficult modify the code support UART communication and
parsing of hex data.  The I2C bootloader is very simple.  The
ATmega8/48/88/168 looks to be an I2C slave Flash/EEPROM device while
the bootloader is active and pages in Flash or EEPROM on the MCU can
be programmed.  I'll look over the protocol for your PIC bootloader to
see how much work adapting my existing bootloader would be.  Perhaps
it's not much work at all.

Mike

--- In RoboBricks2@yahoogroups.com, "Dave Hylands" <dhylands@...> wrote:
>
> Hi Wayne,
>
> > Anyhow STIPPLE runs on Linux.  (It could be compiled
> > to run on Windows, but have not had the need yet.)
>
> I just turfed XP (not quite completely - I installed vmware) and
> installed OpenSUSE 10.2 on my laptop.

One of these days I need to install vmware on my laptop.
Right now I dual boot to XP or SUSE 10.0.  I spend 99.9%
of my time in SUSE.

> > The code STIPPLE generates can be run on both Linux
> > and Windows.  For example, the uCL compiler is run
> > through the STIPPLE compiler and generates both a
> > Linux image (using GCC as the backend) and a Windows
> > image (using MINGW GCC as the backend.)
>
> I've always been interested in scripting languages, and lately my
> quest has been for a decent language that I could use to run both on
> an embedded platform and on a host.

Most scripting languages seem to be headed in the
direction of a big heavy weight run time.  Tcl
is the smallest.  Pearl and Python are kind of big.

> In my ideal world, the scripting language would
> actually compile to a bytecode that was then
> interpreted by a small VM. The VM would then
> have easy hooks to allow native code to be
> integrated as well.

That is always what I kind of wanted; small and
lightweight.

> By using bytecodes, you could run the same code
> say in a simulator on the PC and then download
> it to the uP. Also, byb using bytecodes, you
> could easily add tons of code by utilizing an
> external EEPROM.

Exactly.  You could also compile the byte code to
run natively.

The plan for STIPPLE was to have two code generators
one for ANSI-C and one for a VM.  I only have the
ANSI-C one working right now.  Given how many back
ends have been generated for GCC, I'm not sure that
a VM code generator makes much sense any more.

> So, I'd be interested in getting the sources to
> STIPPLE and uCL so I can play with them.

Let me tweak my Make files to generate .zip (and
.tgz) files of the source files.  That way I can
easily generate updates.  This will take a day or
two.

-Wayne

--- In RoboBricks2@yahoogroups.com, "Dave Hylands" <dhylands@...> wrote:
>
> Hi Wayne,
>
> So, in reviewing the boot loader protocol, I have a couple of questions:
>
> 1 - I'm assuming that "Address Set" specifies a word address. It
> doesn't say it explicitly.

It sets a 16-bit address value.

For PIC16's, instructions are 14-bit quantities.  Address 0
refers to the first 14-bit instruction, address 1 to the
second 14-bit instruction, etc.

> 2 - Memory Get  references "Set Memory Address". I'm assuming it
> really meant to say "Address Set"

You are correct, and I have updated the documentation in
rev. D.

> 3 - Do you have the host side program which talks to the
> bootloader?

Actually, there are two possible host side programs --
a terminal emulator and a program that directly opens
the serial port.

> 4 - PCs only have 8-bit serial. How does the host manage
> the 9-bit to 8-bit mapping?

The mapping is performed by the WireHost board.  It
talks 8-bit RS-232 on one end and 9-bit CAN bus on
the other.  The Wirehost board can take a line of
HEX code and send it to the currently selected module
as a series of Program Memory Write commands.  Thus,
a program such as Hyperterminal (Windows) or minicom
(Linux) can grab a .hex file and just send it down.

After you read up on the Wirehost module, it should
start to make a little more sense.

-Wayne

Hi Wayne,

So, in reviewing the boot loader protocol, I have a couple of questions:

1 - I'm assuming that "Address Set" specifies a word address. It
doesn't say it explicitly.

2 - Memory Get  references "Set Memory Address". I'm assuming it
really meant to say "Address Set"

3 - Do you have the host side program which talks to the bootloader?

4 - PCs only have 8-bit serial. How does the host manage the 9-bit to
8-bit mapping?

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

Hi Wayne,

> Anyhow STIPPLE runs on Linux.  (It could be compiled
> to run on Windows, but have not had the need yet.)

I just turfed XP (not quite completely - I installed vmware) and
installed OpenSUSE 10.2 on my laptop.

> The code STIPPLE generates can be run on both Linux
> and Windows.  For example, the uCL compiler is run
> through the STIPPLE compiler and generates both a
> Linux image (using GCC as the backend) and a Windows
> image (using MINGW GCC as the backend.)

I've always been interested in scripting languages, and lately my
quest has been for a decent language that I could use to run both on
an embedded platform and on a host.

In my ideal world, the scripting language would actually compile to a
bytecode that was then interpreted by a small VM. The VM would then
have easy hooks to allow native code to be integrated as well.

By using bytecodes, you could run the same code say in a simulator on
the PC and then download it to the uP. Also, byb using bytecodes, you
could easily add tons of code by utilizing an external EEPROM.

So, I'd be interested in getting the sources to STIPPLE and uCL so I
can play with them.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

--- In RoboBricks2@yahoogroups.com, "Dave Hylands" <dhylands@...> wrote:
>
> Hi Wayne,
>
> So if I'm reading things correctly, the current bootloader is written
> in uCL and the uCL compiler is written in STIPPLE.
>
> So STIPPLE generates ANSI C.
> I'm guessing the uCL generates PIC assembler?
>
> Call me interested....

Dave:

uCL generates an assembly file (.asm), an assembly
listing file (.lst) and an Intel hex file (.hex).
In theory, the .asm file should be able to be pushed
through the Microchip MPASM assembler and generate
identical .hex files.  (The .lst files will be quite
different.)  MPASM has an idiotic restriction on
symbol name lengths of 32 characters and my internal
uCL assembler does not.  Thus, if procedure name length
plus local variable name length exceed 32, MPASM will
croak on my output.  Since MPASM only runs on Windows,
I have not tested it in quite a while; so other errors
may have crept in.

uCL started out as gross hack written in Tcl.  It kind
of grew and grew and grew until it morphed into 12,000+
lines of Tcl code.  For those of you who know Tcl, this
is approximatedly 11,000 too many lines.  Anyhow, the
performance was so bad that it was taking five minutes
to compile any code with the floating point library in
it.  So I rewrote it in another language called STIPPLE.

STIPPLE started out when I realized that C++ had become
the heir apparent to ANSI-C.  I could handle ANSI-C although
it does have a few strange quirks, but C++ was a different
story all together.  It really annoyed me that simple
3 line C++ programs  could cause people at the C++
standards committee to scratch their heads trying to
figure out what thye means.  So I deliberately set out to
write a strongly typed language that is *compiled* and
*linked* to form an *executable* image.  I made pretty
good progress on the language until I discovered I liked
doing robotics even more. ;-)

Anyhow STIPPLE runs on Linux.  (It could be compiled
to run on Windows, but have not had the need yet.)
The code STIPPLE generates can be run on both Linux
and Windows.  For example, the uCL compiler is run
through the STIPPLE compiler and generates both a
Linux image (using GCC as the backend) and a Windows
image (using MINGW GCC as the backend.)

Anyhow, if you have more questions about either,
please let me know.

-Wayne

Hi Wayne,

So if I'm reading things correctly, the current bootloader is written
in uCL and the uCL compiler is written in STIPPLE.

So STIPPLE generates ANSI C.
I'm guessing the uCL generates PIC assembler?

Call me interested....

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

If the controller28 has an ISP (in system programmer) header a
bootloader for me would not be necessary as I'll just use the AVR ISP
or STK500 to program the chip.  I could take a stab at writing a
bootloader, but it may be a bit of time before I get to it.

Mike


--- In RoboBricks2@yahoogroups.com, "Wayne C. Gramlich" <Wayne@...>
> Dave:
>
> In message 5 you said:
>
> > I've done a few bootloaders for the ATMega as well,
> > so I should be able to do a bootloader for the ATMega88.
>
> Somebody's going to have to do one. ;-)
>
> -Wayne

Hi Wayne,

OK - I'll put in my request for modules as well.

2 x Controller 28 - with no PIC processor populated
2 x DB9RJ11
1 x wirehost
1 x IO8
1 x splice
1 x terminate2

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

--- In RoboBricks2@yahoogroups.com, "Dave Hylands" <dhylands@...> wrote:
>
> Hi guys,
>
> > > I'll be creating my own AVR based equivalent of the
> > > controller 28 module.  Although if you have one
> > > already designed I wouldn't mind looking at what
> > > you already have (I didn't see it on the web site).
> >
> > The site has been updated to have controller28 Rev. D.
> > We'll have to get a boot loader from Dave Hylands tho'.
>
> I guess I'll have to get my act together and write it :)

Dave:

In message 5 you said:

> I've done a few bootloaders for the ATMega as well,
> so I should be able to do a bootloader for the ATMega88.

Somebody's going to have to do one. ;-)

-Wayne

--- In RoboBricks2@yahoogroups.com, "michael_peter_thompson"
<michael.p.thompson@...> wrote:
>
> --- In RoboBricks2@yahoogroups.com, "Wayne C. Gramlich" <Wayne@>
> >
> > Let me get over this code that has been knocking me down
> > and we can rendezvous to transfer the modules over to
> > your possession.
> >
>
>
> Terrific.  I hope you are feeling better soon.  I'll wait
> to hear from you to get the boards.  Out of curiosity,
> what's the pricing by the way :-).

In general, Olimex charges $45 for a Eurocard (3.9"x6.3")
sized PCB.  I can get 7 1.25"x2.50" RoboBricks cards on
a Eurocard.  this works out to be $45/7 = $6.43 per
RoboBrick2 card.  The LCD32 and MidiMotor2 are 2.50"x2.50".

Sometimes we order more than one Eurocard at a time.
Then we get a price break.  For the last order, we
ordered 3 panels for 21 RoboBricks 1.25"x2.50" panels.
This cost $106/21 = $5.05 each.  Since most of the
boards you will be getting came from the last patch,
I'll charge $5 a board.

Then comes parts.  Most of the boards are populated
with parts.  (Actually, all of them are ;-)  Some
parts I buy in 1's and 2's, but many of them are
purchased by the tube, etc.  I'll have to look up
the quanity 1/10/25 price, do some voodoo and try and
figure out a reasonable price.  There will be some
slop, but it will be cheaper than ordering you own
boards and parts.

> Also, a suggestion regarding your site.  For some
> reason when you make a change to a page your site
> is telling my FireFox browser to used the locally
> cached version of the page so I don't see the
> changes you make unless I explicitly tell it to
> reload the page.  I presume this may be happening
> with others as well.  Perhaps something is configured
> wrong in your web server?  Just thought I would let
> you know.

When it comes to configuring Apache2, there is much
I do not know.  I know that my Apache2 server is
running with the mod_expires module loaded, but I
do not have any Expires directives specified in
my configuration file.  It is not really obvious
to me where to stuff an expires directive in the
vast mess that is the Apache2 configuration files.
If you know more about the process, I would be happy
to tweak the Apache2 configuration file, but I am
always weary of breaking something else.

-Wayne

Hi guys,

> > I'll be creating my own AVR based equivalent of the controller 28
> > module.  Although if you have one already designed I wouldn't mind
> > looking at what you already have (I didn't see it on the web site).
>
> The site has been updated to have controller28 Rev. D.
> We'll have to get a boot loader from Dave Hylands tho'.

I guess I'll have to get my act together and write it :)

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

--- In RoboBricks2@yahoogroups.com, "Wayne C. Gramlich" <Wayne@...>
>
> Let me get over this code that has been knocking me down
> and we can rendezvous to transfer the modules over to
> your possession.
>


Terrific.  I hope you are feeling better soon.  I'll wait to hear from
you to get the boards.  Out of curiosity, what's the pricing by the
way :-).

Also, a suggestion regarding your site.  For some reason when you make
a change to a page your site is telling my FireFox browser to used the
locally cached version of the page so I don't see the changes you make
unless I explicitly tell it to reload the page.  I presume this may be
happening with others as well.  Perhaps something is configured wrong
in your web server?  Just thought I would let you know.

Mike

--- In RoboBricks2@yahoogroups.com, "michael_peter_thompson"
<michael.p.thompson@...> wrote:
>
> Hi Wayne,
>
> You said I should ask on this list first before ordering my
> own boards so here it goes.

As you see below, that is definitely the right strategy:

> I'm looking to get the following:
>
> QTY    Part
> 1      IO8 module

We have one that is built out -- Rev. C.

> 1      LCD32 module

We have one that is 50% built out.  It needs the
resonator and the the LCD panel.  Both are in my
private stock.

> 1      MidiMotor2 module

We have one that is built out -- Rev. C.

> 1      MiniMotor2 module

We have one that is built out -- Rev. C.

> 1      Shaft2 module

We have one that is built out -- Rev. D.

> 2      Terminate modules

We have two rev. A termination modules.

> 1      DB9RJ11 module

We have a rev. A version o this.

> 1      Wirehost module

We have one of this built out -- Rev. C.

You will have to supply your own DB9 Cable (male to female).

> My assumption is the following connection between the PC and Wirehost:
>
> PC Serial --> DB9RJ11 --> Phone Cord --> Wirehost Module --> RB2 Bus
>

I have a Controller28 (Rev. C) that can be upgraded to Rev. D
by adding 4 wires.  I uploaded the Rev. D design to my web
site:

   <http://gramlich.net/project/rb2/controller28/rev_d/index.html>

This has the 4 extra wires drawn in the schematic.  You will
have to purchase your own ATmega28.  When you place your order,
I'd like to piggy back an order for a couple of them myself.

> I'll be creating my own AVR based equivalent of the controller 28
> module.  Although if you have one already designed I wouldn't mind
> looking at what you already have (I didn't see it on the web site).

The site has been updated to have controller28 Rev. D.
We'll have to get a boot loader from Dave Hylands tho'.

> I'm looking forward to playing with the RoboBricks2...

Let me get over this code that has been knocking me down
and we can rendezvous to transfer the modules over to
your possession.

-Wayne

Hi Wayne,

You said I should ask on this list first before ordering my own boards
so here it goes.  I'm looking to get the following:

QTY    Part
1      IO8 module
1      LCD32 module
1      MidiMotor2 module
1      MiniMotor2 module
1      Shaft2 module
2      Terminate modules
1      DB9RJ11 module
1      Wirehost module

My assumption is the following connection between the PC and Wirehost:

PC Serial --> DB9RJ11 --> Phone Cord --> Wirehost Module --> RB2 Bus

I'll be creating my own AVR based equivalent of the controller 28
module.  Although if you have one already designed I wouldn't mind
looking at what you already have (I didn't see it on the web site).

I'm looking forward to playing with the RoboBricks2...

Mike Thompson

--- In RoboBricks2@yahoogroups.com, "michael_peter_thompson"
<michael.p.thompson@...> wrote:
>
> Hi Wayne,
>
> I wanted to complement you on an excellent presentation at the
> HBRobotics meeting last week regarding RoboBricks2.  Very
> inspiring...

Thanks.  I had a good time giving the presentation.

(I should mention, I have been getting totally hammered
with colds this cold season -- I'm currently on the 3rd
cold in 5 weeks.  I am pretty run down.)

> I had a question about the motor and encoder you were using
> on your robot.  Could you provide a link to motor and encoder
> hardware your robot is using?

I have updated the shaft2 module page to talk about
where to get the motors:

    <http://gramlich.net/projects/rb2/shaft2/rev_d/index.html>

down at the end.  In short, we got ours from Solutions Cubed.

> I looked on your website, but I didn't find anything
> on the specific robot you showed using the RoboBrick2 modules.

I am working on documenting the robot.  We need to take
some pictures (on our "to do" list) and I have actually
been trying to enter the robot into a CAD system.

> I am very interested in getting some RoboBricks2 PCBs made.
> I've never ordered PCBs from the Gerber/Excellon files
> before, but I have worked with ExpressPCB which uses
> their own custom application.  Hopefully the ordering
> process from Olimex isn't too daunting.  I'll post
> questions here if I get stuck.

First off, Gerber(RS-274X) and Excellon are the standard
for PCB manufacture.  Everybody takes them.  Basically
there is one file for each layer of the PCB:

   Front side copper
   Back side copper
   Front side solder mask
   Back side solder mask
   Front side artwork (silk screen)
   Back side artwork (silk screen)
   Excellon drill file

You typically bundle everything up into a .zip file
along with a readme.txt file that specifies which
which files contain what.  The file suffixes have
been pretty standardized.

I've always appreciated the ExpressPCB concept because
they hide some of the ickyness (technical term) of gerber
files, but in the end, it is part of the learning process.

Before ordering any boards, you should post a message
to this list saying what you want.  That way I can
dig around in my inventory and sell you stuff that
I already have.  Also, we can bundle together orders
to improve costs.  I tend to use Olimex, but it does
take 3/4 weeks for the boards to show up.  I need to
send another batch of board revisions off to Olimex.
(I'm just trying to get over all these nasty cold viruses
that have taken up residence in my body.)

> BTW, if I do get Robobricks PCBs, what is the minimal
> equipment I need to download firmware to the PICs?

You need access to a PIC programmer.  I use an independent
vendor model called the K149 from Kits R Us:

   <http://www.kitsrus.com/>

I use it becasue I can run it from Linux and I am a
total Linux bigot.  If you are a Windows sort of guy,
it would be tempting to purchase a programmer made
by Microchip, since they pretty much guarantee that
they will program all of their chips (on Windows.)
The after market programmers such as the K149 have
fallen way behind in their ability to program PIC
chips.  Since you live in the SF bay area, I won't
have any problems programming your chips for you.
So you scan skip the expense of purchasing a programmer.

> I'm an AVR guy and am befuddled by the sheer
> diversity of PIC devices and programmers available.

I currently use very few of the PIC chips in the
RoboBricks Modules.  The primary chip I use is the
PIC16F688 (a 14-pin DIP).  I also use the PIC16F628
(an 18-pin DIP) and the PIC16F767 and PIC16F876A
(a 28-pin skinny DIP.)  One of the modules used a
PIC16F88, but that chip will be switched over to
PIC16F688 by the next release.  That is it.

I was always attracted to the AVR series of chips,
but was turned off because Atmel seemed to be
unwilling to release their better chips in DIP
packages.  Microchip always keeps supporting the
DIP package.  More recently Atmel has changed its
behavior and started releasing new chips in DIP
packages, so one of these days I will start building
some modules that use AVR chips instead of PIC chips.

On an independent note, I am going to take the plunge
and learn how to do surface mount.  But I will still
hold the line and design most of my boards to use
through hole to simplify the task for beginners.

-Wayne

Hi Wayne,

I wanted to complement you on an excellent presentation at the
HBRobotics meeting last week regarding RoboBricks2.  Very inspiring...

I had a question about the motor and encoder you were using on your
robot.  Could you provide a link to motor and encoder hardware your
robot is using?  I looked on your website, but I didn't find anything
on the specific robot you showed using the RoboBrick2 modules.

I am very interested in getting some RoboBricks2 PCBs made.  I've
never ordered PCBs from the Gerber/Excellon files before, but I have
worked with ExpressPCB which uses their own custom application.
Hopefully the ordering process from Olimex isn't too daunting.  I'll
post questions here if I get stuck.

BTW, if I do get Robobricks PCBs, what is the minimal equipment I need
to download firmware to the PICs?  I'm an AVR guy and am befuddled by
the sheer diversity of PIC devices and programmers available.

Thanks,

Mike Thompson

--- In RoboBricks2@yahoogroups.com, Shannon Holland <holland@...> wrote:
>
> Yeah, I looked at your document later, then remembered from a while
> back that you were using the CAN transceiver over a uart bus. For
> what you're trying to do, I think this makes perfect sense. CAN is
> great and all, but it greatly limits the range of microcontrollers
> that can be used. It's also more complex than a simple uart based
> protocol.
>
> I had looked at LIN a few years back, it's a very simple highly
> reliable multidrop serial bus. It also looked great but has the same
> problem as CAN with few of the advantages.
>
> The great news here is that it will be extremely easy to integrate
> with existing systems. I haven't looked through all of your modules
> yet, but do you have a TTL/RS232 level serial<-> robobricks adapter?
> I need to double check, but I'm pretty sure the uarts on the atmel
> arm7's support a 9 bit protocol.

The module names are not very intuitive.

The WireHost module provides RS-232 to RoboBricks2 bus.
The connector on the WireHost module is an RJ11-4.
I had insufficient space for a DB-9 connector on the
WireHost module board.  There is another board call the
DB9RJ11 board that converts the RJ11 signals to the
correct DB9 pin-outs.  Since I use the RJ11 connectors,
it is possible to use standard coiled telephone handset
extension cords to connect to the WireHost module.  Some
extension cords are 25' long.

> Sorry, didn't mean to start the whole CAN versus UART discussion.
> Onward Robobricks!

The current minimum to get started is:

   DB9RJ11 -  RS232 to RJ11 converter
   WireHost - RS232 to RoboBricks2 bus interface
   Controller28 - 28-pin PIC controller + bus power supply
   Terminate - 100 ohm bus termination.

With the collection above, you can hook a PC up to
a RoboBricks bus via a serial port and probe the
bus via Hyperterminal (Windows) or Minicom (*nix).

After that you add in modules as needed for the robot
proper.  Most robots are differentially steered.
For servos modified for continuous rotation, use the Servo4.
For small motors use MiniMotor2.  For larger motors
(like the Solutions-Cubed motors), use the MidiMotor2.

For sensors, start with the IO8 to provide bump sensors.
Add in IRDistance2 to hook up to the popular Sharp GP2D12's.
Add in a Sonar2 to provide sonar with either a Parallax
Ping, Devantech SRF04, or MaxRobotics EZSonar1.

Lastly, Bill and I have found the ability to send
text out to an LCD display to be very useful.  The
LCD32 is our LCD display.

[snippage]

-Wayne

Yeah, I looked at your document later, then remembered from a while
back that you were using the CAN transceiver over a uart bus. For
what you're trying to do, I think this makes perfect sense. CAN is
great and all, but it greatly limits the range of microcontrollers
that can be used. It's also more complex than a simple uart based
protocol.

I had looked at LIN a few years back, it's a very simple highly
reliable multidrop serial bus. It also looked great but has the same
problem as CAN with few of the advantages.

The great news here is that it will be extremely easy to integrate
with existing systems. I haven't looked through all of your modules
yet, but do you have a TTL/RS232 level serial<-> robobricks adapter?
I need to double check, but I'm pretty sure the uarts on the atmel
arm7's support a 9 bit protocol.

Sorry, didn't mean to start the whole CAN versus UART discussion.
Onward Robobricks!

Shannon


On Mar 5, 2007, at 5:30 PM, Wayne C. Gramlich wrote:

> Shannon:
>
> I decided to start a new thread about your comment below:
>
> > I'm interested in learning more about what you've
> > done at the protocol level. I was using CAN
> > as a network for robotics, but had broken the boards
> > out at higher levels of functionality than
> > what you've done (everything was arm7 based as well).
> > I'd like to be able integrate the two protocols if
> > at all possible.
>
> The primary reason for using UARTs on top of CAN bus
> physical layer vs. full up CAN bus is primarily to
> reduce cost and complexity.
>
> Full up CAN bus requires some additional dedicated
> hardware support inside the microcontroller. This
> hardware support tends increase both microcontroller
> cost and size.
>
> For example, in the Microchip family of microcontrollers,
> the PIC16 series has no chips with CAN bus support and
> the PIC18 series has only one CAN bus chip in a 28 pin
> package. Conversely, for UARTS, the PIC16 series has
> plenty of options, in packages ranging from 14-pins
> 18-pins, 28-pins, 40-pins, etc. The PIC18 series has
> a similar range of options from 18-pins and up. Thus,
> UART's are more available in cheaper packages (for the
> PIC series.)
>
> I'm not as familiar with the Atmel AVR product series,
> but pretty much all of the AVR's (except the ATtiny series)
> have UARTs. The only Atmel AVR's with CAN bus hardware
> support come in 64-pin surface mount. (Somebody, please
> correct me if I am wrong here; I've just quickly scanned
> the Atmel parametric table.)
>
> Most the RoboBricks2 boards do need much of a microcontroller,
> just a CPU a little RAM and a UART.
>
> In addition, there is there is the complexity issue.
> A full CAN bus implementation requires some additional
> complexity in the software inside the microcontroller.
> This is in contrast to running a UART, which is typically
> a few line procedure to send a byte and another equally
> simple procedure to receive a byte.
>
> The RoboBricks2 protocol is to just send 1 or 2 bytes
> followed by optionally getting a byte in return. There
> is no overhead of block lengths, checksums, etc. Again,
> this makes that task of writing firmware for a new RoboBrick
> an easy (almost trivial) task.
>
> I do not view the RoboBricks2 bus as the ultimate bus
> for controlling a robot. Instead, I view it a reasonable
> bus for gluing a bunch of related sensors and actuators
> together on a single bus under control of a more capable
> microcontroller. For example, I have no problems with
> having a board with both a full CAN interface and a
> UART acting as a hub. The UART talks to the RoboBricks2
> modules and the CAN bus interface talks to other hub modules
> in the robot . For a biped walker, there might be a hub for
> each leg, arm, torso, hand, etc.
>
> -Wayne
>
>
>

Shannon:

I decided to start a new thread about your comment below:

> I'm interested in learning more about what you've
> done at the protocol level. I was using CAN
> as a network for robotics, but had broken the boards
> out at higher levels of functionality than
> what you've done (everything was arm7 based as well).
> I'd like to be able integrate the two protocols if
> at all possible.

The primary reason for using UARTs on top of CAN bus
physical layer vs. full up CAN bus is primarily to
reduce cost and complexity.

Full up CAN bus requires some additional dedicated
hardware support inside the microcontroller.  This
hardware support tends increase both microcontroller
cost and size.

For example, in the Microchip family of microcontrollers,
the PIC16 series has no chips with CAN bus support and
the PIC18 series has only one CAN bus chip in a 28 pin
package.  Conversely, for UARTS, the PIC16 series has
plenty of options, in packages ranging from 14-pins
18-pins, 28-pins, 40-pins, etc.  The PIC18 series has
a similar range of options from 18-pins and up.  Thus,
UART's are more available in cheaper packages (for the
PIC series.)

I'm not as familiar with the Atmel AVR product series,
but pretty much all of the AVR's (except the ATtiny series)
have UARTs.  The only Atmel AVR's with CAN bus hardware
support come in 64-pin surface mount.  (Somebody, please
correct me if I am wrong here; I've just quickly scanned
the Atmel parametric table.)

Most the RoboBricks2 boards do need much of a microcontroller,
just a CPU a little RAM and a UART.

In addition, there is there is the complexity issue.
A full CAN bus implementation requires some additional
complexity in the software inside the microcontroller.
This is in contrast to running a UART, which is typically
a few line procedure to send a byte and another equally
simple procedure to receive a byte.

The RoboBricks2 protocol is to just send 1 or 2 bytes
followed by optionally getting a byte in return.  There
is no overhead of block lengths, checksums, etc.  Again,
this makes that task of writing firmware for a new RoboBrick
an easy (almost trivial) task.

I do not view the RoboBricks2 bus as the ultimate bus
for controlling a robot.  Instead, I view it a reasonable
bus for gluing a bunch of related sensors and actuators
together on a single bus under control of a more capable
microcontroller.  For example, I have no problems with
having a board with both a full CAN interface and a
UART acting as a hub.  The UART talks to the RoboBricks2
modules and the CAN bus interface talks to other hub modules
in the robot .  For a biped walker, there might be a hub for
each leg, arm, torso, hand, etc.

-Wayne

I'm interested in building some robobricks. So the first thing I wanted
to figure out is what is the CAN Protocol. After reading the messages
to the ARM guy and finding a broken link, I think it's time to Google.
Since I'm just starting in robotics, my first order of business is to
get two microcontrollers talking to one another. My second order of
business is to get n-number of microcontrollers talking to a PC.

I think your robobricks will same me a LOT of soldering time since I
don't have to solder many wires, just parts. ;)

I'd like to piggyback on one of your board orders since I have almost
no knowledge in board manufacturing.

--- In RoboBricks2@yahoogroups.com, "totalslacker17" <holland@...> wrote:
>
> --- In RoboBricks2@yahoogroups.com, "Wayne C. Gramlich" <Wayne@> wrote:
>
> > > If so, I can implement the same protocol. If not, we should develop
> > a protocol.
> >
> > ... there is a specified protocol.
> >
> >   <http://gramlich.net/rb2/controller28/rev_c/index.html>
> >
> > has both the boot loader code and the protocol specification.
>
> Wayne,
>
> That link looks to be broken right now - is the server down?

Sorry about the typo:

   <http://gramlich.net/projects/rb2/controller28/rev_c/index.html>

> I'm interested in learning more about what you've done
> at the protocol level. I was using CAN as a network for
> robotics, but had broken the boards out at higher levels
> of functionality than what you've done (everything was
> arm7 based as well). I'd like to be able integrate the
> two protocols if at all possible.

I'll talk about this more in a message tomorrow;
I've had a long day.

-Wayne

--- In RoboBricks2@yahoogroups.com, "Wayne C. Gramlich" <Wayne@...> wrote:

> > If so, I can implement the same protocol. If not, we should develop
> a protocol.
>
> ... there is a specified protocol.
>
>   <http://gramlich.net/rb2/controller28/rev_c/index.html>
>
> has both the boot loader code and the protocol specification.

Wayne,

That link looks to be broken right now - is the server down?

I'm interested in learning more about what you've done at the protocol level. I
was using CAN
as a network for robotics, but had broken the boards out at higher levels of
functionality than
what you've done (everything was arm7 based as well). I'd like to be able
integrate the two
protocols if at all possible.

Shannon

--- In RoboBricks2@yahoogroups.com, "Dave Hylands" <dhylands@...> wrote:
> I was thinking that using an MCP2515 connected via SPI (and of course
> the 2551 transceiver) would be the way to go.

I've used the MCP2515 for a few projects with an atmel arm (their SAM7 series
before the
SAM7X with the onboard CAN controller) - I can defintely recommend it. It works
quite well
and is easy to work with.

Someday I hope to resurrect all of that...

Shannon

--- In RoboBricks2@yahoogroups.com, "Dave Hylands" <dhylands@...> wrote:
>
> Hi Wayne,
>
> > RoboBricks2 uses CAN bus physical layer and UARTs.  Since
> > UART's are trivial to use, it is easy to develop the
> > firmware for RoboBricks2 modules.
>
> Ahhh. Somehow I managed to miss that little detail. The schematics
> make a bit more sense now :)
>
> I've done a few bootloaders for the ATMega as well, so I should be
> able to do a bootloader for the ATMega88. Do you have one for the PIC
> yet?

Yes, I do and ...

> If so, I can implement the same protocol. If not, we should develop
a protocol.

... there is a specified protocol.

   <http://gramlich.net/rb2/controller28/rev_c/index.html>

has both the boot loader code and the protocol specification.

-Wayne

Hi Wayne,

> RoboBricks2 uses CAN bus physical layer and UARTs.  Since
> UART's are trivial to use, it is easy to develop the
> firmware for RoboBricks2 modules.

Ahhh. Somehow I managed to miss that little detail. The schematics
make a bit more sense now :)

I've done a few bootloaders for the ATMega as well, so I should be
able to do a bootloader for the ATMega88. Do you have one for the PIC
yet?

If so, I can implement the same protocol. If not, we should develop a protocol.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

--- In RoboBricks2@yahoogroups.com, "Dave Hylands" <dhylands@...> wrote:
>
> Hi Wayne,
>
> > Incidently, on the next revision of the Controller28,
> > (rev. D), I intend wire up to support the ATmega88, which is
> > available in a PDIP28 package.  It turns out that none of the
> > power lines are incompatible with the PIC series chips in the
> > PDIP28 package.  While the UART lines are on different pins,
> > again, there is no incompatibility.  All I have to do is make
> > sure that I can program the ATmega88.  I mention this since
> > I know that you are a *big* fan of the AVR series chips.
>
> Sounds interesting. I'd be happy to review your schematics.
>
> I took a look at Rev C. So does the 16F767 have a CAN controller
> onboard? Or are you planning on doing it in software.
>
> I was thinking that using an MCP2515 connected via SPI (and of course
> the 2551 transceiver) would be the way to go.

RoboBricks2 uses CAN bus physical layer and UARTs.  Since
UART's are trivial to use, it is easy to develop the
firmware for RoboBricks2 modules.

Basically we are using the CAN bus physical layer as
a glorified RS-485 transceiver, but we do not have to
worry about the transceiver direction pin.

> If you need any help programming the AVRs, let me know.
>
> I've programmed them using nothing more than a DB-25 connector and
> some wires. I prefer to use my AVRISP mkII (USB based programmer
> available for $34 from DigiKey.

I just need to make sure that I run the appropriate wires
to the 1x6 connector on the board.  The 1x6 connector is
officially used to provide support for the Microchip ICD2
in-circuit debugger.  But I figure it can do double duty
and provide in circuit AVR programming.

> It seems like a few well placed jumpers (or places to solder in some
> wires and/or cut traces) would make it completely usable for both.

Exactly.  And hence I intend to add the wires.  It looks
like I can avoid all jumpers.

-Wayne

Hi Wayne,

> Incidently, on the next revision of the Controller28,
> (rev. D), I intend wire up to support the ATmega88, which is
> available in a PDIP28 package.  It turns out that none of the
> power lines are incompatible with the PIC series chips in the
> PDIP28 package.  While the UART lines are on different pins,
> again, there is no incompatibility.  All I have to do is make
> sure that I can program the ATmega88.  I mention this since
> I know that you are a *big* fan of the AVR series chips.

Sounds interesting. I'd be happy to review your schematics.

I took a look at Rev C. So does the 16F767 have a CAN controller
onboard? Or are you planning on doing it in software.

I was thinking that using an MCP2515 connected via SPI (and of course
the 2551 transceiver) would be the way to go.

If you need any help programming the AVRs, let me know.

I've programmed them using nothing more than a DB-25 connector and
some wires. I prefer to use my AVRISP mkII (USB based programmer
available for $34 from DigiKey.

It seems like a few well placed jumpers (or places to solder in some
wires and/or cut traces) would make it completely usable for both.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

--- In RoboBricks2@yahoogroups.com, "Dave Hylands" <dhylands@...> wrote:
>
> Hey - there weren't any messages posted, so maybe this will be the
first one?

Yup.  You got first post.  I'm going to let a few more
people who said that they were interested sign up before
I start posting.

> I've been following the RoboBricks2 stuff from a distance, and I'm
> definitely interested.

I know you have been following.

Incidently, on the next revision of the Controller28,
(rev. D), I intend wire up to support the ATmega88, which is
available in a PDIP28 package.  It turns out that none of the
power lines are incompatible with the PIC series chips in the
PDIP28 package.  While the UART lines are on different pins,
again, there is no incompatibility.  All I have to do is make
sure that I can program the ATmega88.  I mention this since
I know that you are a *big* fan of the AVR series chips.

-Wayne

Hey - there weren't any messages posted, so maybe this will be the first one?

I've been following the RoboBricks2 stuff from a distance, and I'm
definitely interested.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/