I’m Chuffed! Also, bored.
Well, the last few days has had several successes for me.
USB Gamepad: As part of my Christmas present, my girlfriend got me a neat USB gamepad — basically, a USB Playstation controller. Since it has a USB connector, I naturally jammed it into my USBKEY so I could write a host driver for it. Imagine my surprise when the LUFA Josytick Host demo worked perfectly on it, without any modifications. I’m not used to having hardware just work with my own code. Perhaps this warm feeling is what LUFA users feel when they try the demos out themselves.
USB Temperature Datalogger: Actually, I’m currently becoming bored with LUFA. No, that’s not to say I don’t want to develop it anymore (far, far from it) — I’m just fresh out of ideas on how to improve it. On that note, if you have any suggestions on where LUFA can go from here, post a comment! In any case, I thought I’d spend a little time writing a simple LUFA project which hooks into ELMChan’s FAT library so that temperature samples can be recorded to the board’s Dataflash, and later read off with a computer. People have been bugging me requesting something like this for a while, so I thought I might as well add it in. It’s currently in the LUFA SVN, under Projects/TemperatureDataLogger. I’m not convinced that FatFS is the nicest FAT library around based on its code, but for now it’ll do until I (perhaps) write my own.
XPLAIN DAC: After my abysmal non-start with the AVR32 line of AVRs, I thought I’d try to use the XMEGA chip on the loaner XPLAIN board I received. I’ve not gotten into the XMEGAs before now, as they are rather like the Unobtanium mineral in the new-and-great Avatar movie; you hear a lot about them, but they’re bloody hard to get a hold of. Now that I’ve played with them a little, I have to say I’m in love. They’re programmable with the familiar AVR-GCC toolchain using makefiles and simple text editors, yet they have so many fantastic features. If only Atmel could ramp up production, I’d be recommending them for use in just about everything. On that note, I made a simple XPLAIN DAC demo, which outputs real-time 8-bit mono sound from the PC using a simple XMEGA DAC program and a modified LUFA Audio Output demo. Score another win for LUFA.
TPI Programming: While I’m still waiting on the arrival of some TINY10 AVR samples to test it with, I’ve basically finished the TPI programming protocol implementation in my AVRISP-MKII Clone project. I’m not convinced that it’s all correct just yet, but I don’t think I’ll need to change too much to get it running once the test hardware arrives.
Elektor Magazine: A few days ago I received a nice package from Antoine Authier from Elektor magazine, containing the English versions of the December/January Elektor magazine, plus the January magazine in several other languages. This is the magazine with Antoine’s article about LUFA, which has me grinning from ear-to-ear. My only regret is not catching the missing semicolon terminators on one or two of the included projects earlier, as having a paragraph dedicated to LUFA errata is a tad embarassing. Perhaps I’ll have to write some magazine articles of my own in the future.
New Server: Angus Peart (gussy from AVRFreaks) has been kind enough to use some of his small fortune to host FourWalledCubicle.com over the years entirely for free, and deserves a lot of kudos from everyone who either reads this tripe, or downloads any of my code. From the new year, Angus has moved the site onto a shiny new server here in Melbourne, Australia. Hopefully this hasn’t caused anything to glitch, but if you notice anything funny please contact me so I can get it all sorted out.
Heh, the mkII clone is pretty useful. Thanks for that.
Can you make a 16-bit version of the Xplain DAC example?
Another idea for lufa: A mass-storage device example for the Xplain board using the Dataflash.
Pir,
Actually, the existing MassStorage device demo should work fine on it, when compiled for the XPLAIN or XPLAIN_REV1 board target in the makefile — I added in the Dataflash drivers needed for it to work into the library board driver abstractions. Might be useful when combined with a FAT library on the XMEGA writing to the dataflash as a logger.
– Dean
Isn’t the Dataflash attached to the Xmega so that communication between the Xmega and at90usb1287 is needed?
It’s attached to both. The USB portion of the schematic clearly shows a connection from the USB AVR to “DATAFLASH SS”, and the SPI bus is connected to all three chips.
But I really should test it to make sure that it actually works ;).
– Dean
Yes, I’ll have to try to make a 16-bit mono one, bandwidth permitting. The trouble is that the USB AVR runs at 8MHz, and the sound samples are stereo 16-bit at 48KHz – which is a lot of data. While a 4MHz SPI bus (the maximum speed at 8MHz system clock) is theoretically capable of sending 16-bit mono at 48KHz, I’m not sure if it will work out in practice as timing will be very tight.
– Dean
I’ve just compiled the MassStorage example for the Xplain (with customized Makefile). The mass storage device is recognized as a 512B device and no write access can be performed. I’m not even shure if the data retreived from the Dataflash is valid (looked at a hex dump).
Right you are. I found the error in the Dataflash driver which was making the size reporting incorrectly to the host (incorrect check for the R1 XPLAIN board which did have only a 4MBit Dataflash) but I’m also having problems formatting the device. I’ll debug it some more and update when I have a fix.
– Dean
It’s all fixed now — the Mass Storage demo in the latest SVN revision enumerates and operates just fine as a Mass Storage device.
– Dean
Works great, thanks. What about combining the AudioOut example with a Mass Storage device? Is that possible as in the MassStorageKeyboard demo?
Doubtful, without sever audio distortion or a VERY slow Mass Storage interface. As the SPI bus is shared between the XMEGA and the Dataflash, I’d have to use some of the limited bandwidth for accessing the Dataflash, when the Audio code is already getting it reasonably close to its limits.
It would be possible if the host could be convinced to send a lower sample rate at mono 8-bit or 16-bit audo, but Windows seems to dislike anything other than 48KHz Stereo 16-bit.
– Dean
Hallo Dean,
through the article in elektor i found Your website, and
read, that You are working on an mkII clone – very interesting.
Some questions:
– Is the mkII only for programming, or as well usable for debugging (single stepping, breakpoint setting, variable and register watching)?
– Where does the code run, that You have in Your Projects/AvrIsp Subdirectory? Is this code running in a second AVR, which is connected with this one, that should be programmed / debugged?
– Is there a little more info available, about the actual state (what´s running, what´s planned, in which way to use this mkII clone)
– Michael
Michael,
Great! Glad to see that the Elektor article is getting my work some more publicity.
> – Is the mkII only for programming, or as well usable for debugging (single stepping, breakpoint setting, variable and register watching)?
Programming only, like the real AVRISP-MKII. In this case I’m limited by two factors: one, the real AVRISP-MKII cannot do debugging, thus I cannot, since the host software doesn’t even have it as an option, and the other is that Atmel has not made the JTAG or dW debugging protocols public.
> – Where does the code run, that You have in Your Projects/AvrIsp Subdirectory? Is this code running in a second AVR, which is connected with this one, that should be programmed / debugged?
The clone firmware needs to be loaded on a (second) USB AVR, which you then attach to the device you want to program. The USB AVR manages the communication between the host PC and the target’s programming interface.
> – Is there a little more info available, about the actual state (what´s running, what´s planned, in which way to use this mkII clone)
I wasn’t originally intending it to be a large separate project, but there’s been a lot of interest. Because of that the only documentation on it is located in the “AVRISP.txt” file in with the firmware source code. I’ll be writing up a proper manual on it soon. However, use is simple: just compile it for your USB AVR (change the MCU and F_CPU options in the makefile, run a “make clean” from the command line) load it in via the USB AVR’s inbuilt factory USB bootloader – so no programmer needed – and connect it to the PC/target AVR.
Cheers!
– Dean
Dean,
How about an STM32 (which would work on all ARM Cortex M3 devices) port of LUFA? The ST example libs kind of suck.
I have some hardware here you could use, possibly a JTAG as well.
Hi, what about a MMC/SD-Driver with FAT16 support (for example elmchan’s one) for the Xmega with Mass Storage via at90usb128?
I’m missing the USART-Bridge when using the AVRISP mkII clone. Is it possible to make a version which has two USB endpoints? Like AVRISP and CDC? That would make debugging a lot easier.
Michael,
You and me both – I’d love to have both functions at the same time. However, the Atmel USB drivers will only bind to the device if it has the exact descriptors of the official AVRISP-MKII, including the overall Class/Subclass/Protocol values, which means no compound devices. The best I could do at the moment would be to have a jumper on the XPLAIN board switch between functions, so you could attach a physical function switch.
The official Atmel XPLAIN programmer firmware will, when it works, use two CDC endpoints – one for debugging and one for programming, so when that is released I’ll be able to create a compatible version which will use the presumably new Atmel host software for programming.
– Dean
Dean, I have LUFA already tied into a HDD using an ata and fat32 library. If you would like the info let me know. I can send the rewritten code for the dataflashmanager files and the ata/fat32 library files. Shoot me an email.
– CReno
PS: We talked once about speeds in the LUFA Hardware mail list.
Dean saw the note about the gamepad. Looks like I’m finally going to have to learn C. I have a robotics application tha I wanted to use a gamepad for a controller. Got the PS2 controller interface, but USB would be better. Have you or anyone tried a wireless USB gamepad? I’ll let you know how it works when I figure out C. Been doing ASM for far too long.
Roger
Roger,
I haven’t tried a wireless gamepad, but if it is HID class compliant, it should just work. I don’t think the console controllers (XBox, PS2/PS3) controllers are standard HID – I remember one person going to great lengths to get them running under LUFA, since they use a lot of proprietary stuff. However, any wireless controller from a computer store should work great.
– Dean
Thanks for your input. As controllers go, that is my understanding also. The PS2 controller has an SPI interface which I have working. I will probably put the code I have on AVR Freaks Someday but I have tested it on only one wireless controller. Now I’ll have to figure out how to use your demo.
Thak you
Roger
Dean, once again your work pays me dividends. I just built and installed the MassStorage demo for the XPLAIN, saving me oodles of time. I’m going to attempt to fold it into the XPLAIN_Bridge project so I can quickly switch, probably via yet another jumper setting, between serial, flash drive, and PDI programmer…
Excellent Michael! Glad to hear my work is still useful to you. Let me know if you have any other enhancement ideas for me.
– Dean
Just finished merging the MassStorage demo with the XPLAINBridge project. I use a jumper across TDO and TMS to select flash drive mode. Very straight forward. If I knew more about USB, I’d attempt make the USB Serial Port and the Mass Storage device available at the same time…
Let me know if you want to fold the code into your baseline and I’ll send you a zip…