LUFA Port, Source Control
Posts have been sparse lately, partly because I’m being worked hard most of the time, and partly because I haven’t thought up many new developments. One thing I have done is fixed up the new LUFA SVN repository, so that it conforms to the usual trunk/branches/tags layout present in most SVN repositories. Actually, it’s another great learning experience for me; while I’ve used SVN in the past for my projects (the 430+ odd commits to the LUFA SVN should be ample indication of that) I’ve never really sat down and started to learn the standard layouts, and what each of the standard directories in the repository actually *do*.
So far, the tags directory is conspicuously empty, despite there being plenty of named commits (e.g. “Commit for 1.5.3 release”) in the repository. That’s because I can’t figure out how to populate it correctly, so if you are a SVN guru please leave a comment or contact me in some way. All the guides on the internet I’ve found which deal with copying over a given trunk revision to a new tag directory deal with online SVN repositories, served up by a remote SVN server. I on the other hand keep all my projects in local SVN repositories, and synchronise the online ones using the svnsync tool. Trying to do the same with these local repositories throws up errors about the source and destination being in different repositories. Again, if you know how to fix this, please contact me.
I’ve been offered a nice little ARM based board (Atmel SAM7) by Casainho, a LUFA user. This give me the doubly unique experience of using the ARM architecture (so far I’ve only used AVRs and TI microprocessors) and also porting of an existing architecture to a new architecture. Actually, that’s not quite right, as the new port won’t be a new branch, but will aim to be a multi-targetable trunk instead. I’ve never attempted to write code that is targetable at more than one architecture (more than one chip inside of an architecture yes, as is the case with LUFA currently – it can be compiled to run on any Atmel USB AVR) and this will be a fascinating endeavour. Right now I’m planning in my head the best way to do it, but I’m thinking it’s going to require some major hacking up of the code to remove anything architecture-specific.
I’m also looking for a donation of AVR UC3B hardware, which is the more basic 32-bit AVRs. The UC3B line is a direct 32-bit successor to the 8-bit AVRs, and is very similar in core register design, and so porting LUFA to it should be quite simple. The UC3A 32-bit AVRs on the other hand are entirely different beasts with completely different USB controllers, and would require far more effort.
Right now I’d like to get LUFA running on both the AVR8 and AVR32 UC3B microcontrollers, so that it can become the “standard” AVR USB stack. Adding support for other architectures is a bit leap, but hopefully a good one. It all comes down to the ultimate question: is the LUFA API better than the existing USB stacks for other architectures, and so is it worth porting it? Only time (and users’ comments) will tell…
University starts again next week. Bah humbug.
Dean, don’t forget to ask me help on putting that AT91SAM7 working with the JTAG debugger/programmer (that I also offer). I have some experience on doing “GUI visual” debug with ARM using GNU Debugger + OpenOCD + Eclipse.
Also, that AT91SAM7 have a USB bootloader like the AVR USB, which means any user can program it using Sam-ba (utility from Atmel) on GNU/Linux, MS Windows, etc.
I wrote some quick instructions on how to setup all the tools for do the debug:
http://code.google.com/p/rockboxplayer/wiki/DevelopmentEnvironmentSetup
http://code.google.com/p/rockboxplayer/wiki/EclipseWithJTAGDebugSetup
AVR32UC32B: Is an EVK1101 sufficient for your needs? I’m assuming you have a JTAG ICE MKII, which I think is the minimum programmer. DigiKey is currently showing a date of 4/12 for the EVK1101 — I have one on backorder for myself. Shoot me a private e-mail.
On multi-target: It’s inevitable that you will end up with some platform specific code. If it ‘twer me, I’d be looking for a way to isolate the hardware specific stuff into a low-level library with a well defined api. That way, it’s simply a matter of flipping a single variable in the Makefile that adds one of N .o files to the $OBJECTS variable to select the target. Going multi-target should be an interesting exercise. In the end, the code will very likely benefit from the refactoring.
In subversion there is no actual difference between a “branch” and a “tag”. They are both just copies of what most people call “trunk” at a point in time. The only difference between them is the meaning and purpose that developers apply to them.
Branches usually continue to receive commits after being created and diverge from trunk. Those changes may or may not be merged back into trunk down the road. Branches probably aren’t that useful with a dev team of 1, but you might create one to work on some experimental feature that will really destabilize things for a while. Then after you are ready either abandon it or merge it back to trunk.
Tags are mostly used to take a snapshot that you don’t plan to ever modify. For example, at each release. Then you can always get back to the way the code was at that point.
SVN doesn’t enforce and differences between a tag, a branch, or any other cop. They are just conventions. Oh and copies within a single repository are light weight. Only referenced are actually copied and then diffs between the copies (when any commits are made).
The subversion book talks about all this in more detail: http://svnbook.red-bean.com/
One more comment, given you described version control usage (with svnsync) I think you’d be happier with a newer distributed version control system. I’ve tried many of them and my personal favorite is Bazaar (http://bazaar-vcs.org/). Unless you are Linux only, then Git might be a consideration but I still prefer Bazaar myself even on Linux.