ben-wpan: new atusb binaries and updated GPIO tests
werner at almesberger.net
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:
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,
ATUSB_GPIO, and ATUSB_SLP_TR
- 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
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
- show WLAN channels in atrf-rssi -g
- add proper interrupt notification to atusb firmware (right now, the
host has to poll)
More information about the discussion