Extension Extravaganza
Recently, the final build of Atmel Studio 6.1 (the production ready one) was released, bringing with it some interesting new features. It also brought along some internal changes to the way the ASF extension works, which LUFA depends on, requiring me to build a new version of my extension. I thought this was a good opportunity to get back into the PC side of programming for a little while, so I pulled out my copy of Visual Studio, fired it up, and got to work. Well, tried to, as things have really changed since I developed with Visual Basic and WinForms. Damn you, XAML!
LUFA Extension
The new LUFA release is much improved; one of the major issues I saw with the previous version was the overwhelming amount of “now what?” feedback from users. First impressions are very important, so if users install your product and receive no feedback on how to use it, they aren’t going to be a happy chappy. To combat this I’ve added an integration binary to the extension which presents a new first-run Getting Started page, which covers the fundamentals of how to create examples, add/remove LUFA modules and access the documentation:
Yes, I know my CSS and HTML skills are non-existent, so I kept it simple. Actually, it turns out the integrated web browser in Visual Studio 2010 is a modified IE7 engine, so any sort of fancy tricks wouldn’t work well anyway. I like the new page, and it’s got good feedback so far, so mission accomplished I think. You’ll see this on fresh installs of LUFA or – if you had the somewhat broken release I originally pushed – every darn time you add or remove any extension. Sorry about that, I blame poor Atmel Studio SDK docs and insufficient testing on my part.
Also new are the bootloaders, as the new ASF changes means I can finally add them to the extension without having to make one example for every single device and bootloader combination. Unfortunately I’ve still had to class them by target memory size, but it’s miles better than the alternative and much more friendly than command line compiling. They’re all included in the new release, as example projects.
Finally comes the help. I’ve previously wired up the module help to the online documentation, so that you can use the ASF Explorer window of Atmel Studio to view the documentation for a particular module. However, that’s not ideal, so the new release also comes with an integrated version of the manual inside the regular Atmel Studio Help functionality. You’ll be prompted to install it the first time the extension is installed (I’m not paying for a darn signing certificate, so users need to click a few confirmations instead) and once added the full LUFA manual will be available, including F1 look-up on (most) LUFA constants, variables, functions, enums and the like.
Making the integrated help was a task in itself – special thanks to my friend Morten, who’s authored the Docbook to HV1 transform needed to make it work. Over the last few weeks I’ve learned far more about XSLT than any many ought to, but it’s all worth it. The end result isn’t perfect, but it’s as good as automatically converted Doxygen XML->DocBook->HV1 is going to get.
Data Size Viewer Extension
Second on my list of new Atmel Studio extensions is the Data Size Viewer, created in collaborated with the aforementioned Morten. This implements a basic working version of something I’ve wanted to see integrated into Atmel Studio for a long time, so I went ahead and made it myself. When installed, this will add a new tool window that will display the symbols (variables, functions, etc.) from the compiled ELF binary in a project, and their corresponding sizes within the compiled binary. Sorting this list can answer the question of “where the hell did all my FLASH and RAM go?” in an easier manner than manually reading through the LSS file, and symbols can be double-clicked to jump to their definitions in your source code. It’s a basic extension, but one I already find myself using quite a bit.
Build Taskbar Overlay Extension
Ok, this one’s just a bit of eye-candy. However, at work it’s not uncommon for me to start a project build that will take several minutes to complete – the Windows ports of the AVR32 and ARM toolchains aren’t the speediest of things – and it’s nice to be able to minimize the program and do other things in the meantime. On Windows 7 machines this will add a small icon overlay to the Atmel Studio icon in the taskbar, showing when a build is in progress (clock icon), completed successfully (green tick icon) or failed (red cross icon).
Virtual Debug Channel Extension
Actually, this one’s a failed experiment, although I had a prototype working. Using nothing but a debugger I was able to print messages out from a running XMEGA inside Atmel Studio in a special build output window, using a tiny extension I wrote late Friday night. This works by shoving the data into a global array in the target, then using an inline assembly breakpoint instruction to signal my Atmel Studio extension to pick up the data, write it to the output window, and resume execution.
While it worked, I’m afraid it’s just not a good solution, since breakpoints cause the entire context (including watched variables, open debug windows, etc.) to be refreshed each time which is really, really slow. Perhaps in the future something better could be implemented by the real Atmel Tools team, perhaps using data breakpoints.
That’s it for now. If you have extension requests let me know; I’m always looking for new side projects.
Nice work on the Data Size Extension Viewer Dean!
Something like the virtual debug extension would be pretty neat to have. However it’d be cool if it was fast, almost non-intrusive, like the ITM in the cortex M cores. I would advise the Atmel dev team to put this on high priority.
After a while since I last played around with LUFA, I think I’ll give a quick look at the new Atmel Studio integrated LUFA.
Keep up the good work!
Hello I found a bug in the library for ATXMEGA. On the atxmega128a1u (and may be some other) the USB endpoint table uses 16-byte alignment, instead of 16-bit alignment (according the errata).
—
Alexey Vergin
Hi Alexey,
Yes, I’ve mentioned that in the release notes – that errata is only for early silicon XMEGA A1 parts, so adding workarounds for it really isn’t all that important. I don’t believe very many of the faulty revision parts ever made it out into the wild, and newer silicon/other XMEGA parts are not affected by it.
Cheers!
– Dean