ben-wpan: new atusb binaries and updated GPIO tests

Werner Almesberger werner at
Sun Jun 12 07:53:32 EDT 2011

A few updates, mainly of interest for David (although all other
atben/atusb owners can use those things too):

- I've uploaded pre-compiled versions of the latest firmware:
  md5sum: 126a8db91e06180dff4676fdb60b26fe
  md5sum: 2e43af32a0002cb78ddd794dfe7ece11
  atrf-id: #158 Sat Jun 11 13:05:42 ART 2011
  also has the updated URLs.

  The main recent changes:

  - USB stack now uses interrupts, plus some minor cleanup
  - boot loader waits for 2.5 seconds instead of nominally 2.0 s
  - application supports DFU_DETACH
  - addition of various new requests, mainly for testing: ATUSB_TIMER,

- at tuxbrain HQ, the GPIO tests in the P_ON state of atusb didn't work
  reliably for no clear reason. The boards appeared to perform normally

  P_ON is the transceiver's power-on state, in which is sets up some
  weak pull-up and pull-down resistors and waits for the MCU to set up
  its I/Os and then tell the transceiver what to do. After that, it
  leaves P_ON, never to return.

  My mistake was to overlook that not even a reset returns the
  transceiver to P_ON. So the premise of the test, namely that the
  transceiver would be in P_ON with the pull-up/down resistors set, was
  incorrect. Instead it was in TRX_OFF, without such resistors, and all
  the test was really measuring were random parasitic effects.
  David, sorry for sending you chasing ghosts. I actually saw that
  behaviour on my own atusb prototype, but since that one also has a
  broken reset line, I usually reset it by (manually) power-cycling,
  which masked the flaw :-(

  I've now removed the P_ON test from atusb and added the corresponding
  items to the TRX_OFF test. atusb still gets tested in P_ON, because
  this board is always reset via power-cycling.

- another problem found at tuxbrain HQ is that atrf-xtal on atusb is
  quite sensitive to background activity of the PC. On a "good"
  machine, atrf-xtal gets results repeatable within about +/- 0.1 ppm
  with 10'000 samples. The same number of samples on a "bad" machine
  causes jumps in the order of 100 ppm. This test should be accurate
  to about +/- 10 ppm. Just when I thought a safety margin of two
  orders of magnitude was plenty ...

  It seems that the algorithm only really works well on a dual-core or
  better. It should be possible to increase accuracy also on very noisy
  systems by simply increasing the number of samples, but that gets
  boring quickly.

  This needs more analysis and then some improved filtering. For now, I
  recommend to just use a sufficiently potent machine.

That's all for now. On my to do list:

- finally split at86rf230 kernel driver into transceiver- and
  transport part
- show WLAN channels in atrf-rssi -g
- add proper interrupt notification to atusb firmware (right now, the
  host has to poll)

- Werner

More information about the discussion mailing list