Continuing with finalizing the design and making samples for Adam, Joachim, and Richard,
- I made two version 20110123 atben boards. This picture shows them and the 20110105 board for comparison. The main difference is the orientation of the crystal and slight reduction in length. http://downloads.qi-hardware.com/people/werner/wpan/tmp/atben-20110123-samples.jpg They "work" and perform similar to the 20110115 board I use as "gold" reference. In a few quick tests, noise seems to be a little higher and the maximum distance appears to be 10-20% shorter, but I need to compare them side by side to see if this is a real difference of the boards or just a variation in my test setup. - I have two more atben PCBs in the queue for soldering, once I've clarified the RF performance: http://downloads.qi-hardware.com/people/werner/wpan/tmp/atben-20110123-boards.jpg - I made five atusb version 20110123 PCBs: http://downloads.qi-hardware.com/people/werner/wpan/tmp/atusb-20110123-boards.jpg Then I realized that there's no way for me to get things done before Chinese New Year, and that I therefore have about one week of "spare time" to spend on an AVR-based redesign of atusb. The idea is to replace the SiLabs C8051F326 microcontroller with an Atmel ATmega32U2 (or ATmega16U2, etc.). The motivation is that AVRs are fairly popular in DIY circles while 8051-based chips tend to be treated with distaste, so the ATmega32U2 should be a more attractive choice and would lower the barrier for others to contribute to the firmware. If I can get this to work reasonably quickly, it would make sense to forego the C8051F326-based design for atusb and Working in this direction, - I redesigned the microcontroller side of atusb for the new chip, http://projects.qi-hardware.com/schhist/atusb/pdf_head/USB.pdf adapted the layout accordingly, and made two PCBs. Here you can see a partially populated one in my torture chamber: http://downloads.qi-hardware.com/people/werner/wpan/tmp/atusb-20110131-bench.jpg - in order to bring AVR firmware flashing capabilities to the Ben, I built a series of boards and wrote a NanoNote driver for avrdude. More about this in a separate mail. - getting a proper development environment for the relatively new ATmega32U2 is a bit of a challenge. The solution is to build the AVR toolchain (binutils, gcc, and libc) from the latest sources. There doesn't seem to be any avrdude support for the ATmega32U2 so far, but the AT90USB162 is supposed to be similar enough. One obvious difference is the memory size, which means that making a proper boot loader will be difficult. (I plan to have a DFU boot loader, so that one can update the firmware over USB. Plan B is to use in-circuit flash programming - see the extra boards - which is inconvenient, but tolerable for prototypes.) - I've verified that the AVR runs properly on the clock provided by the transceiver and that it can command a clock rate increase (by sending a command over SPI). So far, I haven't discovered any bugs in the new hardware design and only a few small things that I may improve in the next version (places that were difficult to solder). What's next: - I haven't decided on the USB stack yet. Possible choices include LUFA (MIT license), the Salewski stack (GPL), and FreakUSB (BSD). LUFA has everything and three or four kitchen sinks, but I'm mildly horrified by the prospect of having to juggle several dozen options to prod LUFA in the right direction. Also the structure of at least the DFU code makes it hard to use it in the way I intend. The other stacks are much leaner and look friendlier. A fourth option would be to just adapt the stack I already wrote for the C8051F326. We'll see. ("Stack" may sound pompous in this context - all atusb needs at the moment are the low-level drivers and the device equivalent of libusb, no fancy device classes and all that.) - port the firmware that handles communication with the transceiver - once the digital side of the design is fully verified, populate the second PCB and test clock stability and RF performance. - if everything goes well, clean up the layout and make at least three more of the new atusb boards. - verify that the in-circuit programming adapter (see next mail) is reliable enough for production use. If not, make a proper fixture. - send the samples out Next update hopefully soon. - Werner _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
