another ben-wpan status update

Werner Almesberger werner at openmoko.org
Tue Feb 22 00:10:13 EST 2011


On the atusb hardware side, I completed most of the design verification
of the new AVR-based board. Here's a partially populated one in the
process of being examined:

http://downloads.qi-hardware.com/people/werner/wpan/tmp/atusb-20110131-bench.jpg

Here is its sibling:

http://downloads.qi-hardware.com/people/werner/wpan/tmp/atusb-20110131.jpg

The second board has all the good looks, but it seems that I managed to
break a pad internally (maybe the bond wire got unstuck), so it only
works if I push down on the transceiver.

The breakage probably resulted from excessive bending of the board when
inserting the USB connector. I've adjusted CNC tolerances and shortened
the board a little to avoid such problems in the future.


On the atusb firmware side, I looked a bit more at LUFA and still
couldn't convince myself that I should deal with its complexity, little
of which would be of actual use in this project, at least not for now.
I then proceeded with FreakUSB.

A few patches later, the board would enumerate and I could talk to it.
Implementing the basic commands was easy, but it took me a while to
figure out how to receive additional data from the host in a USB
control transfer with this stack.

The next problem was that the stack doesn't like transfers larger than
the endpoint size. For IEEE 802.15.4, we need to transfer about twice
the maximum endpoint size. FreakUSB implements a FIFO scheme that gets
in the way in this case, and isn't really useful in this application
even if it works. After a failed attempt at a quick and dirty fix, I
finally decided that I had learned enough about the chip that I might
as well implement my own stack [1], reusing what I had already done for
the C8051F326 [2].

Things progressed quickly, except for an  UDADDR |= ADDEN;  that should
have been  UDADDR |= 1 << ADDEN;  that kept me guessing for a couple of
days. With the help of an ad hoc USB probe [3] and my old protocol
decoder software [4, 5], I finally figured out where things went wrong,
and spotted the bug. Here's the board on the examination table:

http://downloads.qi-hardware.com/people/werner/wpan/tmp/atusb-20110131-usbdbg.jpg

With my stack working, I could transfer full-sized messages without
problems, which then allowed me to put the transceiver into constant
wave mode. The spectrum looks good, as expected.

What's missing in the atusb firmware:

- I added tentative support for the ATmega32U2 to avrdude (a copy and
  paste job - I don't really understand all the bits and pieces of
  those chip descriptions [6]), but I haven't tested yet whether this
  gives me access to all the Flash and particularly the boot loader.

- I still have to port the DFU boot loader. I'll probably work on this
  when the prototype boards are already on their way, so I'll just ship
  atusb-pgm adapters with all of them.

- the USB stack doesn't have complete enough error handling for serious
  use yet

- likewise, communication usually fails after a while. This may be due
  to the lack of error handling.


On to atben: When getting ready to make the samples, an idea for making
the whole layout a lot more compact and tidier struck me. So I redid
the layout once - and then two more times when noticing problems while
making the new boards.

Here's the final result, along with its predecessors:

http://downloads.qi-hardware.com/people/werner/wpan/tmp/atben-110219-compare.jpg

The upper left board is the old design without a crystal that caught a
lot of noise from the Ben's clock. In the middle is the revised biggish
design with a crystal. Finally, in the bottom right, we have the latest
design. It's almost as short as the one without the crystal.

I also kept the traces on the part of the board that gets inserted into
the 8:10 card slot straight, to avoid problems in case of accidental
contact with metal parts that run in parallel with the traces. I don't
think I've ever experienced any such shorts, but better safe than
sorry.

Here is a comparison of the long and the short board when inserted into
a Ben:

http://downloads.qi-hardware.com/people/werner/wpan/tmp/atben-110219-compare-inserted.jpg

A first quick transmit test showed a very clean and strong signal,
perhaps the best I've seen so far.


What's next:

- do more RF tests (transmit power over frequency, noise floor, and
  look for spectral contamination outside the allowed range) for all
  the boards, atben and atusb. This is not only part of the design
  verification but also to make sure I don't send out a sample with a
  soldering defect.

- make two more of the new atben boards and test them

- populate four atusb boards (I already made the PCBs)

- finally send out the samples


References:

[1] http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/atusb/fw/usb
[2] http://projects.qi-hardware.com/index.php/p/f32xbase/source/tree/master/fw
[3] http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/zprobe
[4] http://svn.openmoko.org/developers/werner/ahrt/host/tmc/
[5] http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/atusb/fw/an
[6] http://projects.qi-hardware.com/index.php/p/ben-blinkenlights/source/tree/master/uart/avrdude/patches/atmega32u2.patch

- Werner




More information about the discussion mailing list


interactive