Memos From the Cube

What a week. It’s odd that the most interesting shenanigans of my trip so far have all occurred on a work-day (or week day, at least) and not on the weekends. Actually, I’ve not been going out much on the weekends; after waking up at 6AM to get to work every day, I invariably end up sleeping until after midday on Saturdays and Sundays due to the lack of natural light to wake me up. Oops.

So firstly, I’m endeavoring to increase my collection of cool AVR swag by appropriating (with permission!) every bit of AVR marketing mania I can lay my sweaty little hands on. This week I’ve managed to start my very own AVR hat collection – a good thing in such a cold climate. I now have two genuine AVR hats, a beanie that more closely resembles a misshapen sock:

And secondly, the world’s shallowest baseball cap:

For that one I think they just put a brim over a Yarmulka and called it good, but a hat’s a hat and this is one hell of a hat. Look at that awesome design!

Now on to what’s been happening over the past few days. This has been a week of a few firsts for me. Last week I had to submit my code patch to my peers for a code review, so that they could examine what I had done and check it over for errors, style issues and other potential problems before it would be adopted into the production code. That was a new experience for me; over the last few years I’ve done several commercial applications, but always worked in isolation. When I write code I’m a development team of one, meaning once I’ve finished testing some code that I’m happy with, I can push it straight out for consumer use. The concept of having one’s peers scrutinize my code is an alien one to me, but I’m excited to have it done. Never before have I received such useful direct feedback on my work.

A code review has taught me something else about commercial quality code; it should be correct, but above all maintainable. If there is a slightly more compact way of achieving a goal that increases the difficulty of maintaining the code twofold, then it should be left as-is to ease future development. As a guy who worries over every bit and byte, this takes some getting used to, but after working on some existing code I can already see why this is the correct course to take. Compact code is usually complex code, and complex code hides errors.

Today I had a totally brown-pants moment; I was asked to present my current project (the one I’ve been working on over the past few weeks) in the weekly Apps meeting to my co-workers. I’m not the best public speaker at the best of times, but coupled with a complicated application based on many different components and you have a recipe for disaster. Luckily this was only an informal occasion to give the other engineers the heads up on what I am developing, and even luckier nothing went wrong. I was actually surprised that my demo actually worked; it is well known fact, nay, a cosmic law that at least 90% of demos go wrong in some way after working fine just before you stand up to present.

So far it looks like everyone’s happy with the work I’ve done so far and the goals I have achieved, but I’ll know more once I show off my design to the department that initiated the request. That will be another first for me; scheduling my own meeting about my project with the cross-department “big wigs”.

I’ve now got a couple of photos from the epic Atmel 2010 Christmas party, and while many are absolutely hilarious, all are completely unpublishable – or at least, unpublishable for as long as I want to stay employed and have any future career prospects in the industry. There’s a few regular ones from the start of the night which are nice, but ultimately I can’t release photos of the Atmel employees so I’d have to either blur the faces, or just do without. I think I’ll skip them for now, since no one wants to see photos of table full of food being eaten by variously sized, shaped and coloured blobs. There’s the Atmel New Years party coming up in two weeks (yes, they are aware of the date!) which should prove to be lots of fun but also a lot more controlled than the previous party, so hopefully there will be some nice photos to come out of that, which I can get permission to put up online.

Firstly, a public announcement that the LUFA Support Mailing list will be moved as of this Saturday, so that the URL and post address carry the LUFA name, and not the old MyUSB project name. This means that as of Saturday, any direct links to the support group will fail to work. Please use the indirect support jump URL instead to ensure that your links will continue to work, and if you are a group member read my announcement about the move for the new group email address.

Secondly, those following the SVN/GIT/BZR repositories will have noticed a new patch breaking the stream APIs for those currently using NO_STREAM_CALLBACKS. This new patch makes the (previously Callback) parameter of all the stream functions mandatory, but as before this can be set to NULL if the transfer should be completed as a single chunk. The callback function is now a value pointer, which can be made to point to a uint16_t where the total number of bytes processed in the current stream is to be stored. When used, this will cause the stream functions to abort after each packet with the error code ENDPOINT_RWSTREAM_IncompleteTransfer or PIPE_RWSTREAM_IncompleteTransfer, allowing you to do cool things like:

/* Write the CSW to the endpoint */
BytesTransferred = 0;
while (Endpoint_Write_Stream_LE(&CommandStatus, sizeof(CommandStatus),
                                &BytesTransferred) == ENDPOINT_RWSTREAM_IncompleteTransfer)
{
	/* Check if the current command is being aborted by the host */
	if (IsMassStoreReset)
	  return;
}

In your code to get both the previous callback-like behavior (except more strongly linked to the current transfer at hand – no more callback functions!) as well as a way to obtain the number of bytes processed in the stream after an error has occurred. This was previously impossible with the old callback system, so I think the new behavior will be of great benefit to many users.