[beagleboard] Experience with TinCan Tools Trainer board

GoogleGroups
1

Hi Folks,

In advance - sorry for the long post. But I hope it would be helpful
for those who will try to do the same. Also, please take in
account that this was my first real experience with OE and
Angstrom, so I might be doing something just wrong. So
please bear with me :slight_smile: .

I spent last week trying to bring up Trainer board from Tincan
Tools connected to BB C3 and would like to summarize my
experience. There are also some unresolved issues remain
so I would be glad to get some hints.

My goal was to use I2C level translation functionality to control
motors and to make sure that i can use Arduino software with AVR
micro-controller (to collect some sensor data).

To communicate with AVR, avrdude was necessary, which is not
available in OE, but it is a story on it's own :slight_smile: . I compiled it myself
and can share the experience (and .bb recipies) if someone is
interested.

So I basically tried three configurations.

1. Using demo images offered here [1]

It works very well. Boots fast, all required GPIO pins are
available under /sys/class/gpio. However, avrdude was unable to
talk to AVR so I assumed that there is no Arduino boot loader and
it needs to be flushed. All my attempts to do it from
BeagleBoard (BB) was unsuccessful. So I flashed AVR with Dragon
programmer. After that avrdude on BB was able to talk to AVR as
expected and LED blinking program works fine.

Conclusions:

- AVR need to be flashed using external programmer to be Arduino
  software compatible.

- Provided images [1] work good but very minimalistic and are
  only useful to test that hardware works. That is why I decide
  to build own kernel and image.

2. Angstrom from stable brunch.

Does not work well, i.e. Trainer board was recognized as Zippy,
no power supplied to AVR, avrdude cannot talk to AVR, no relevant
entries in /sys/class/gpio, etc. On this list I was told that
newer version of u-boot is necessary to ensure correct
pin-muxing (thanks Koen and Dave!). In addition, EPROM on Trainer
board contains incorrect data and need to be re-flashed to be
recognized as Trainer and not as Zippy2.

With latest u-boot and reflashed EEPROM, the board is recognized
as Trainer. However there are still no corresponding entries in
/sys/class/gpio . Some GPIOs can be exported by doing echo PIN_NO

export but not all. For example pin 162 is not accessible even

after doing echo. It is sad because it is useful to power-cycle
AVR. Avdude still can not talk to AVR.

What is even worth is that for some reasons with new u-boot the
whole system become *extremely* slow. In addition error messages
sometimes printed on console (something like "please flush write
request... irq_number" - I do not remember exactly but can
reproduce it if necessary). Basically it is impossible to work
with the system because it is extremely slow.

Conclusions:

- I was unable to use Trainer with stable Angstrom version.

- With latest git version of u-boot the system is extremely slow
  and avrdude still can not talk to AVR.

3. Angstrom unstable

3.1 With corresponding (new) u-boot

Similar to the stable - very slow system (or even slower). Boot
takes ages. In addition very unstable. Kernel prints "division by
zero" and other thread crashes badnesses during boot. Even if you
are lucky and manage down to login prompt, keyboard is not always
working. If you are even more lucky and can log in, after certain
period of time the system will crash anyway printing the message
very similar to what is mentioned here [2]. I was pointed that it
might be power supply issue. Switching to external PSU does not
helps a lot. Maybe just a little bit.

As a positive aspect - avrdude can talk to AVR "out of the
box". Still no gpio entries in /sys.

3.2 With u-boot from [1]

After hours of frustration I decide to experiment mixing what is
works with what would be nice to have, i.e. well functioning
configuration 1 with latest kernel/image from unstable. I found
out that using unstable Angstrom with u-boot from [1] is the best
combination. In particular - works fast as expected. Pretty
stable. Avrdude can talk to AVR. Still no additional gpio entries
in /sys as in configuration 1.

Conclusions:

- unstable Angstrom with provided new u-boot is very slow and
  unstable.

- unstable Angstrom with u-boot from [1] shows the best results
  out of all configurations I was trying. Currently I decide to stick
  with this configuration.

What I am wondering is how u-boot and kernel image at [1] was
built? Are sources for exactly this version available somewhere?
I assume they should be (GPL?) but I did not found them. It would
be very interesting to find out what exactly leads to the case
where pinmuxes was done in the right way and corresponding
entries in /sys are created. I would really appreciate if someone
can help to find out why it is not the case with latest unstable.

Well, that is basically it. I can provide more details on each
aspect but the post is already rather long (sorry about that :slight_smile:
). Nevertheless, I hope it will be helpful for other BB/Trainer
warriors :slight_smile:

Regards,
Andrey.

[1] BeagleBoard Trainer - eLinux.org
[2] http://groups.google.com/group/beagleboard/browse_thread/thread/70914fbc41c625d9

2

Andrey,

I spent last week trying to bring up Trainer board from
Tincan
Tools connected to BB C3 and would like to summarize my
experience. There are also some unresolved issues remain
so I would be glad to get some hints.

tincantools is committed to creating excellent hardware products. i'd like to address some of your comments and asking for some additional feedback.

My goal was to use I2C level translation functionality to
control
motors and to make sure that i can use Arduino software
with AVR
micro-controller (to collect some sensor data).

could you provide more details about intended goal? are you planning to use the i2c connected to the omap3 or are you planning to use the atmega i2c interface?

To communicate with AVR, avrdude was necessary, which is
not
available in OE, but it is a story on it's own :slight_smile: . I
compiled it myself
and can share the experience (and .bb recipies) if someone
is
interested.

So I basically tried three configurations.

1. Using demo images offered here [1]

It works very well. Boots fast, all required GPIO pins are
available under /sys/class/gpio. However, avrdude was
unable to
talk to AVR so I assumed that there is no Arduino boot
loader and
it needs to be flushed. All my attempts to do it from
BeagleBoard (BB) was unsuccessful. So I flashed AVR with
Dragon
programmer. After that avrdude on BB was able to talk to
AVR as
expected and LED blinking program works fine.

Conclusions:

- AVR need to be flashed using external programmer to be
Arduino
software compatible.

- Provided images [1] work good but very minimalistic and
are
only useful to test that hardware works. That is why
I decide
to build own kernel and image.

The hardware on the Trainer is Arduino compatible but not pre-loaded with an Arduino bootloader. we will update the website to reflect that. the Trainer isn't currently Arduino certified thus not advertised as an Arduino:

TinCanTools is in the process of getting the Trainer certified. avrdude isn't required to "communicate" with the avr. it is one of several applications that can be used to work with the arduino bootloader. generally speaking any AVR board you purchase is going to need an external ISP programmer unless you are using some custom bootloader such as the Arduino:

within a few weeks the Trainer will ship pre-loaded with the SerIO firmware from Sparkfun which will allow for serial I/O control of the AVR's gpios:

2. Angstrom from stable brunch.

Does not work well, i.e. Trainer board was recognized as
Zippy,
no power supplied to AVR, avrdude cannot talk to AVR, no
relevant
entries in /sys/class/gpio, etc. On this list I was told
that
newer version of u-boot is necessary to ensure correct
pin-muxing (thanks Koen and Dave!). In addition, EPROM on
Trainer
board contains incorrect data and need to be re-flashed to
be
recognized as Trainer and not as Zippy2.

With latest u-boot and reflashed EEPROM, the board is
recognized
as Trainer. However there are still no corresponding
entries in
/sys/class/gpio . Some GPIOs can be exported by doing echo
PIN_NO
> export but not all. For example pin 162 is not
accessible even
after doing echo. It is sad because it is useful to
power-cycle
AVR. Avdude still can not talk to AVR.

there are a number of issues to address with this statement. reading of the pinmux information from the i2c eeprom in uboot support is relatively new, as well as the trainer being a new product. with this in mind the eeprom was improperly programmed with the product id. this has been already corrected. pinmux settings in u-boot simply assure that the pins are configured properly for their specific purpose, i.e. gpios. this does not insure that kernel has allocated the pin for a specific purpose. gpio_162 is most likely already allocated in the beagle board machine file that you are using, which makes it unavailable to be exported.

What is even worth is that for some reasons with new u-boot
the
whole system become *extremely* slow. In addition error
messages
sometimes printed on console (something like "please flush
write
request... irq_number" - I do not remember exactly but can
reproduce it if necessary). Basically it is impossible to
work
with the system because it is extremely slow.

most likely this is not related to the trainer, i suspect you have some other configuration issue.

Conclusions:

- I was unable to use Trainer with stable Angstrom
version.

- With latest git version of u-boot the system is extremely
slow
and avrdude still can not talk to AVR.

angstrom stable usually takes some time for it to sync up with new features and options that are added. with this in mind, the trainer has only been available for 2 weeks, which will make it probably atleast a month or more before stable will have the patches/changes included.
if you plan on using angstrom stable, you will need to manually add the patches.

3. Angstrom unstable

3.1 With corresponding (new) u-boot

Similar to the stable - very slow system (or even slower).
Boot
takes ages. In addition very unstable. Kernel prints
"division by
zero" and other thread crashes badnesses during boot. Even
if you
are lucky and manage down to login prompt, keyboard is not
always
working. If you are even more lucky and can log in, after
certain
period of time the system will crash anyway printing the
message
very similar to what is mentioned here [2]. I was pointed
that it
might be power supply issue. Switching to external PSU does
not
helps a lot. Maybe just a little bit.

As a positive aspect - avrdude can talk to AVR "out of the
box". Still no gpio entries in /sys.

3.2 With u-boot from [1]

After hours of frustration I decide to experiment mixing
what is
works with what would be nice to have, i.e. well
functioning
configuration 1 with latest kernel/image from unstable. I
found
out that using unstable Angstrom with u-boot from [1] is
the best
combination. In particular - works fast as expected.
Pretty
stable. Avrdude can talk to AVR. Still no additional gpio
entries
in /sys as in configuration 1.

again the sysfs gpio entries are simple usage of the gpio_export() function and can be included in device drivers or in your beagleboard file. patches for example usage of the trainer are in the process of being submitted to oe/angstrom.

Conclusions:

- unstable Angstrom with provided new u-boot is very slow
and
unstable.

- unstable Angstrom with u-boot from [1] shows the best
results
out of all configurations I was trying. Currently I
decide to stick
with this configuration.

What I am wondering is how u-boot and kernel image at [1]
was
built? Are sources for exactly this version available
somewhere?
I assume they should be (GPL?) but I did not found them. It
would
be very interesting to find out what exactly leads to the
case
where pinmuxes was done in the right way and corresponding
entries in /sys are created. I would really appreciate if
someone
can help to find out why it is not the case with latest
unstable.

i'll post the patches for the diagnostic/demo images for you to review. they are not intended for anything other than initial board testing.

Well, that is basically it. I can provide more details on
each
aspect but the post is already rather long (sorry about
that :slight_smile:
). Nevertheless, I hope it will be helpful for other
BB/Trainer
warriors :slight_smile:

basically what i'm getting from you is that you have a very specific usage environment in mind. can you take this opportunity to explain what you'd like to see as an out of the box experience with the trainer?

thanks
Dave

3

Hi Dave,

I spent last week trying to bring up Trainer board from
Tincan
Tools connected to BB C3 and would like to summarize my
experience. There are also some unresolved issues remain
so I would be glad to get some hints.

tincantools is committed to creating excellent hardware

I ordered the board at the same day the announcement was
published. I really like it and it is just great at least for
hobby developers like me. I am already quite happy with Trainer
board :slight_smile: ! Even though not everything works flawless yet, I am
by no way disappointed or so. I am totally understand that it is
a very new product and software around it need time to
mature. The goal of my post was to summarize my findings which
hopefully can help to improve the situation and by doing this
just "pay back" to the open source community for the software
which is available for free.

products. i'd like to address some of your comments and asking
for some additional feedback.

Sure, please see my answers below.

could you provide more details about intended goal? are you
planning to use the i2c connected to the omap3 or are you
planning to use the atmega i2c interface?

Currently my goal is to use i2c connected to the omap3. Also,
currently I am going to use avr to collect analog sensor data and
send the data to BB over available serial interface.

The hardware on the Trainer is Arduino compatible but not
pre-loaded with an Arduino bootloader. we will update the website
to reflect that.

That would be great. I was not sure at the beginning whether
Arduino bootloader is preinstalled or not. Consequently, I was
not sure whether I will need external programmer or not.

the Trainer isn't currently Arduino certified thus not
advertised as an Arduino:
Arduino - Home
TinCanTools is in the process of getting the Trainer
certified.

Well I did not realize that there is a difference between Arduino
compatible and Arduino certified :slight_smile: . Anyway seams like arduino
bootloader works fine on it.

avrdude isn't required to "communicate" with the
avr. it is one of several applications that can be used to work
with the arduino bootloader. generally speaking any AVR board you
purchase is going to need an external ISP programmer unless you
are using some custom bootloader such as the Arduino:

http://www.sparkfun.com/commerce/product_info.php?products_id=9231

I was not claiming that avrdude is required to "communicate". It
was just my guess based on (wrong) assumption that there is
arduino bootloader preinstalled. In addition, after flashing AVR
with external programmer I were using avrdude "communication"
with AVR as a test to check that pinmuxes are made right and
serial communication between BB and Trainers's AVR works.

within a few weeks the Trainer will ship pre-loaded with the
SerIO firmware from Sparkfun which will allow for serial I/O
control of the AVR's gpios:

http://www.sparkfun.com/commerce/product_info.php?products_id=9521

Good to know. Thanks for the information.

2. Angstrom from stable brunch.

Does not work well, i.e. Trainer board was recognized as
Zippy,
no power supplied to AVR, avrdude cannot talk to AVR, no
relevant
entries in /sys/class/gpio, etc. On this list I was told
that
newer version of u-boot is necessary to ensure correct
pin-muxing (thanks Koen and Dave!). In addition, EPROM on
Trainer
board contains incorrect data and need to be re-flashed to
be
recognized as Trainer and not as Zippy2.

With latest u-boot and reflashed EEPROM, the board is
recognized
as Trainer. However there are still no corresponding
entries in
/sys/class/gpio . Some GPIOs can be exported by doing echo
PIN_NO
> export but not all. For example pin 162 is not
accessible even
after doing echo. It is sad because it is useful to
power-cycle
AVR. Avdude still can not talk to AVR.

there are a number of issues to address with this
statement. reading of the pinmux information from the i2c eeprom
in uboot support is relatively new, as well as the trainer being
a new product. with this in mind the eeprom was improperly
programmed with the product id. this has been already corrected.

Not a big deal. But honesly, I think wrong product id in eeprom
could be catch earlier by internal quality control :wink: . If it
is called product Id than it should be different for different
products I guess :slight_smile: .

pinmux settings in u-boot simply assure that the pins are
configured properly for their specific purpose, i.e. gpios. this
does not insure that kernel has allocated the pin for a specific
purpose. gpio_162 is most likely already allocated in the beagle
board machine file that you are using, which makes it unavailable
to be exported.

I understand it. That is why I was wondering about how the demo
image is configured so that much more pins are visible in /sys
even without exporting.

What is even worth is that for some reasons with new u-boot
the
whole system become *extremely* slow. In addition error
messages
sometimes printed on console (something like "please flush
write
request... irq_number" - I do not remember exactly but can
reproduce it if necessary). Basically it is impossible to
work
with the system because it is extremely slow.

most likely this is not related to the trainer, i suspect you
have some other configuration issue.

I am also pretty sure that it is not related to Trainer board. It
just the Trainer board which leads me to the need for new
u-boot :slight_smile: and creates the scenario where the issue appears.

angstrom stable usually takes some time for it to sync up with
new features and options that are added. with this in mind, the
trainer has only been available for 2 weeks, which will make it
probably atleast a month or more before stable will have the
patches/changes included. if you plan on using angstrom stable,
you will need to manually add the patches.

My expectations are not different to what you mentioned
here. Also, since I am doing a hobby project, I have absolutely
no problem to experiment with unstable. This what I was actually
doing and documented the experience.

3.2 With u-boot from [1]

After hours of frustration I decide to experiment mixing
what is
works with what would be nice to have, i.e. well
functioning
configuration 1 with latest kernel/image from unstable. I
found
out that using unstable Angstrom with u-boot from [1] is
the best
combination. In particular - works fast as expected.
Pretty
stable. Avrdude can talk to AVR. Still no additional gpio
entries
in /sys as in configuration 1.

again the sysfs gpio entries are simple usage of the
gpio_export() function and can be included in device drivers or
in your beagleboard file. patches for example usage of the
trainer are in the process of being submitted to oe/angstrom.

again I understand that it depends on kernel usage of gpio and
again that is the reason why I was asking about particular
configuration for demo image because in this configuration the
best results were achieved.

i'll post the patches for the diagnostic/demo images for you to
review. they are not intended for anything other than initial
board testing.

I would be glad to review them and provide my feedback.

basically what i'm getting from you is that you have a very
specific usage environment in mind.

I would not consider my usage environment as a very specific. As
I mentioned above, what I want to do is:

- Control motors with i2c connected to omap3 and benefit from
  level shifting provided by Trainer. It works out of the box and
  absolutely no problems here.

- Collect analog sensor data using AVR's analog inputs,
  preprocess them a little bit on AVR and send to the BB over
  serial interface. For this purposes I am going to benefit from
  available arduino software. In particular from libraries and
  simple way to reprogramm the AVR over serial interface (no need
  for external programmer). That is why I was playing with avrdude.

I do not see anything specific in this scenario.

can you take this opportunity to explain what you'd like to see
as an out of the box experience with the trainer?

Sure. I think for the beginning it would be enough for me that:

- level-shifted i2c from omap3 works out of the box. This is the
  case now.

- Trainer's AVR is shiped preloaded with bootloader which will
  makes it possible to reprogramm AVR without external
  programmer (for example with arduino bootloader). I am not
  familiar with SerIO firmware, so maybe it is allowed exactly
  this. Otherwise you have to mention the need for external AVR
  programmer when purchasing Trainer board (since you mentioned
  Arduino, it might be not obvious for the customers because when
  bying Arduino controllers like Duemilanove, etc., no external
  programmer is needed).

- Power supply gpio pin for AVR (162 I guess) is available by
  default to power-cycle AVR if necessary without the need to
  reboot BB or push the reset button manually. I understand that
  it is not directly related to the board itself but to the
  u-boot/kernel.

Ideally it should work with latest u-boot/kernel/angstrom and
integrated back into corresponding sources and build
environment. I am allowed to dream here. Right? :slight_smile:

Once again thank you very much for the support and please
consider my post as an attempt to support the community around
very good Trainer board and not as pure criticism.

Regards,
Andrey.