The Sky Has Fallen

This last weekend was an absolute torture; everyone’s favorite rickety website finally keeled over once and for all and went into an extended outage for three whole days, until someone at Atmel noticed and flicked the lights back on. I do love AVRFreaks, and judging by the amount of noise I heard about it while it was down everyone else does too. One does hope that the added support requests sent to Atmel directly instead of being fielded by fellow suckers engineers will convince them to allocate some funding for proper maintenance in the future. Here’s hoping.

Actually, last week made me think that the sky was falling and the 2012 Apocalypse had come early for another reason; the new XMEGAs models are out! Atmel has been all quiet on the XMEGA front since the initial launch a few years ago, which was itself horribly delayed from the initial product announcements. Since the initial silicon revisions, people complained about three things: lack of a DIP package, lack of USB, and fairly show-stopper bugs in the analogue circuitry. I must confess that until now I’ve pretty much ignored the XMEGA chips along with the AVR32s, until I started my Atmel internship late last year. With these new chip revisions we’re still stuck with surface mount only packages, but the analogue portions of the chip have been corrected and a new USB controller added.

That’s right – USB XMEGAs are here! I confess this isn’t a surprise to me at all, since I’ve had a pair of boards with then for over a year now, but I haven’t been able to use them properly without the release of the datasheets. Looking over the datasheet (which has colour now!) sections on the new controller yields some very, very impressive capabilities – standard SRAM access via internal DMA for endpoint data and control, up to 31 endpoints (15 IN, 15 IN, one CONTROL) and support for up to 1023 byte Isochronous endpoint packets. In fact, the only thing missing from the new design is High Speed support, although this is largely useless at 32MHz without the heavy lifting capabilities of the AVR32s.

The bad news is that the controller design is very, very different to the previous models, and thus very different to the way the LUFA API is structured. That leaves me with two alternatives: press on and shoehorn the XMEGA controller to work with the current API at a reduced performance, or redesign the entire library from scratch (probably killing performance on the older controllers as a result). It’s not the situation I really wanted to be in, but on the upside a redesign would really open up the XMEGA’s capabilities.

I’ve already been playing around prototyping against the new designs using what I have, but I’m going to put that on hold for the moment; partly because the silicon revision I have is an unreleased (buggy) internal sample with unknown issues, and because right now I want to finish up the AVR32 port ready to ship next month. On that front, I’m now in the process of testing out Host mode support, and working out the best way to port the demos in a way that won’t make them extremely ugly, or multiply the amount of maintenance needed by me to keep everything organized. Suggestions welcome.

 

Tomorrow I’m scheduled to receive the results of my mid-year exams, which I’m a little apprehensive about now that I’ve signed the contract for Atmel starting early next year – if I managed to fail something (doubtful, but you can’t rule it out until the results are released) then I’ll be in a bit of a bind to finish my degrees before the end of the year. I’m fairly confident I did fine, but I’ll sleep easier once I have the transcript in my hands.

I’m due to start coding up my final year project (Bluetooth Stack) soon, now that the replacement parts and revision 2 of my PCB have been ordered – from next semester onwards, I should be coding up a storm. I’m going to need to think of an appropriate name for the project once I’m done, as I plan on releasing it as a LUFA-style package to the world once it’s complete. Anyone have any ideas for a clever name that doesn’t clash with existing project names?

Tomorrow, once I’ve warmed up a bit and found the camera, I should be able to post a nice overview of the near hardware I’ve received over the last month and a bit for evaluation and testing – a Stingray board from XBit Electronics, Matt’s new Micropendous-A boards (made in quantity!) and a teensy-tiny USB2AX dongle.

 

Comments: 6

Leave a reply »

 
 
 

How about BLUetooth FRamework [for AVR] (BLUFRA)? Maybe too similar to LUFA 🙂

 

Right now I’m thinking “LUBeS – the Lightweight Universal Bluetooth Stack”, but I’m not sure if that will be too hard to Google, or put too many people off…

– Dean

 

Hi Dean,

Has the postie delivered your results yet?

CHeers,

Ross

 

This morning:

Applied Management for Engineers: B
Advanced Signal Processing: B
Advanced Digital Design: A
Computer Protocol Engineering: C

Darn happy – thought I wasn’t going to pass CPE due to rather low quality teaching/materials.

– Dean

 

Congratulations Dean! Looks like you will be northward bound …

Cheers,

Ross

 

Bluetooth stack name proposals: BLUFA, Bluecherry, BLOOM, BLUSB, BLUSBEAN, BLISDOM.

Take a look at this bluetooth stack:
http://scanlime.org/2010/04/embedded-bluetooth-for-2/

 

Leave a Reply

 
(will not be published)
 
 
Comment
 
 

 

Vital Stats

  • 35 Years Old
  • Australian
  • Lover of embedded systems
  • Firmware engineer
  • Self-Proclaimed Geek

Latest Blog Posts

RSS