Richard Sharpe wrote: > This weekend I want to try building a simple > device driver that gives access to the ATMega registers via /sys/... > as an initial version of the driver to give me some experience with > it. The driver might also be useful for debugging other projects using > the ATMega in that way ...
Do you mean transceiver registers ? The ATmega itself only acts as a protocol converter (USB control transfers to register accesses with SPI). Regarding the ATmega's firmware, this is where we are: - I wrote my own very basic USB stack a while ago for the IDBG [1] project. This stack implements enumeration, vendor-specific control transfers, and bulk transfers. It was originally for the SiLab C8051F326. The stack also implements DFU. - I later cleaned this stack up a bit, put it into the f32xbase project on qi-hw, and used it for the first atusb prototypes. All this is still around, under ben-wpan/atusb-sil/ DFU invocation was automatic after reset, with a timeout. So if you wanted to flash new firmware, you would unplug and re-plug atusb, and quickly (< 2 s) issue the dfu-util -d 0x20b7:0x1540 -D atusb.bin command. If you don't need DFU, you just wait those 2 seconds, and the DFU boot loader will jump to the "application", which resets the USB stack, enumerates again, and then provides the USB-to-ATRF register/buffer access. - after switching to the ATmega32U2, I reused my stack after generalizing and simplifying it a little (the interface between board-specific and general code was too convoluted in the older version). The new stack lives in atusb/fw/ and only supports the ATmega32U2. I plan to re-introduce support for the SiLabs chips at some point in time, though. (I'll mean to adapt the low-level driver, which should be easy; plus find a nice way to express the SDCC-specific compiler quirks, which won't be too hard either; and finally see how many SDCC compiler bugs I hit and work around them in a not too ugly way, which is what will be the fun part.) - there is still a bug somewhere in the initialization that makes the Linux host reset the atusb board a number of times before it accepts its enumeration. Also, the stack only works if I let the ATmega do a full chip reset on USB bus reset. If I try to handle the bus reset via software, enumeration fails. These two bugs mean that DFU currently can't be used, because the chip gets reset when the application tries to restart the USB stack, thus jumping back into the DFU boot loader. Until this is fixed, the only way to change the firmware is with the atben-pgm cable and avrdude. Regarding user space interfaces, sysfs access to the equivalent of ben-wpan/tools/include/atrf.h could indeed be nice for debugging. Ultimately, I think the driver will have to be able to reset the transceiver if there's a communication problem, so it would have to remember all the transceiver's configuration state. The transceiver has "standard" state, e.g., channel selection, and also non-standard state, e.g., selection of the Atmel-specific high-speed mode (you can experiment with it with atrf-txrx's option -r). There's another user-space interface that would be useful to have, and that's access to the Ben's 8:10 card pins via UIO. Right now, I use mmap and hit the GPIO registers of the Jz4720 directly. This is nice and simple, but it has the the drawback of not giving access to interrupts. UIO has interrupts. So it would be nice to have at least access to this part. Whether UIO would be a good replacement for the rest of the GPIO operations would depend on how much overhead it causes. One problem to solve for atben is how to share the port with the MMC/SD/SDIO driver. I'm not quite sure what's the best way to handle this. For now, I just disable the MMC driver manually, with echo jz4740-mmc.0 >/sys/bus/platform/drivers/jz4740-mmc/unbind Port sharing is also an issue for any other non-MMC/SD/SDIO card we plug into the 8:10 card slot, e.g., anything that uses UBB. During development, we can just build the kernel without an MMC driver, or with the driver(s) as module(s). There's also a somewhat nasty issue with power: when the MMC driver detects the presence of a card, it powers it up straight away and then reads its configuration registers. This is okay for cards that draw very little current when just talking to their configuration part. MMC/SD/SDIO cards are like this. Unfortunately, atben or things connected to UBB don't/may not have such a low-power mode. In particular, bypass capacitors may cause some significant inrush current. The result is that the Ben's 3.3 V rail gets overloaded for a moment, causing the voltage to drop low enough for the Ben to freeze. The work-around for this issue is to drive all the 8:10 card pins high for a moment before enabling VDD, which allows the capacitors to pre-charge to a safe level. My plan for now is to first build Lars' 2.6.38 kernel, see if it behaves, then toss in the patches from linux-zigbee, add the platform-specific tweaks, and see if anything works with atben (such as detecing the presence of the card). Then push it all into a ben-wpan branch on qi-hw/qi-kernel.git I haven't used git for projects with multiple branches or multiple committers yet, so please holler if I'm doing anything wrong. Have you built a kernel for the Ben yet ? If not, maybe this is useful (builds but I haven't tried to run it yet): http://pastebin.com/ue0CA5nL mknnk and nnui are from wernermisc/bin/ [1] http://www.almesberger.net/misc/idbg/ - Werner _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
