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: http://downloads.qi-hardware.com/people/werner/wpan/bindist/boot-ce16a16.hex md5sum: 126a8db91e06180dff4676fdb60b26fe http://downloads.qi-hardware.com/people/werner/wpan/bindist/atusb-ce16a16.bin md5sum: 2e43af32a0002cb78ddd794dfe7ece11 atrf-id: #158 Sat Jun 11 13:05:42 ART 2011 http://downloads.qi-hardware.com/people/werner/wpan/prod/setup.html 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 regardless. 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 _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
