Memos From the Cube

It’s been two weeks since I last posted here, but it feels like months. I’ve been absolutely flat out working to try to get all my University assignments and projects up to scratch, putting in 9-6 days every day during the week even though I’ve only got classes scheduled for a fraction of that. I’ll try to make up for it now in my stolen downtime for the day via a long post.

Primarily, my time has been taken up by two assignments:

Assignment 1: Programming FPGAs

Yes, I’m back into the land of VHDL again, this time moving up from tiny CPLD devices in my introduction to digital design subject to a somewhat larger Cyclone II FPGA. While I haven’t even thought about VHDL in over a year now (last year was entirely Computer Science subjects, courtesy of my double degree and scheduling) I’ve been pleasantly surprised how quickly I’ve remembered everything. Since I have a sequential programming background I initially found parallel design quite mind-bending, but I’ve now somewhat mastered the (warped) way of thinking required. That makes me a happy chappy, since I’m no longer fighting myself to finish my first assignment: an asynchronous ALU coded entirely in VHDL.

I’m all done with it now, with even most of the report all written up, including simulation. I’ve found it quite funny that I’ve become the go-to guy for VHDL code almost immediately, despite me being in the same boat as half the other students. Unfortunately I’m way too time poor at the moment, or I would snap up one of the awesome Altera DE2 boards we’re developing with and see what else I can code up at home.

Actually, all that’s got me thinking – why not create a processor with a regular core, plus a small amount of programmable logic? Companies could produce the one chip with zero on-die peripherals, and instead produce tools so that the engineer could drag-drop the desired peripherals (SPI, I2C, timers, etc) to create the custom chip they need. Done cheaply enough, it could really take off – not only does the company save money by only needing to create the one low cost design, the engineer could do such advanced things as adding custom coded peripherals to speed up execution in addition to the hand-holding default drag-drop interface. Think of how many times you’ve thought something like “I really love the Atmel AVR model X, but I wish it had Y timers with PWM instead of the Z USARTs I’m not using…” and tell me you wouldn’t jump all over that.

Assignment 2: Power/Voltage/Current Meter

In order to prepare us for our large-scale project next year, we’ve been tasked with a somewhat simpler project to complete this semester, to familiarize ourselves with the tasks of creating a schematic, choosing footprints, laying out and drilling boards, soldering surface mount components and programming microcontrollers. Most of those I’ve somewhat perplexed they haven’t taught us up to now, but according to the lecturers “throwing you all in the deep end makes you learn quicker”. Bah humbug.

Unfortunately for me, not only is my project (an isolated power meter) set for me, the schematics are also similarly fixed, so I’m stuck with using a tool I don’t know, laying out what must be the most over engineered piece of junk known to mankind. To me a power meter is something requiring only a few analogue parts, a LCD and a modern AVR or similar processor. No such luck here – we must use the truly awful Z8 microprocessor that was developed when bows and arrows were considered “the next best thing”, along with four switchmode power supplies producing no less than five voltage rails.

Five. Voltage. Rails.

And we have to lay them out, with no previous experience laying out such much as a morse code beeper, let along anything so complicated. What makes it more fun is that they are teaching us the critical design knowlege (current loops? What are those?) in parallel with our efforts, so we’re finding the need to rip up large sections and re do them after almost every lecture.

Having said that, I am indeed learning quickly; I’ve been showing off my progress periodically on Twitter with my Altium efforts (initial design, second design – I’ll post an updated and near complete screenshot of my latest layout on Monday) during the week and receiving some very helpful comments. Before now I never really understood why PCB artwork was called artwork, but now I do; layout truly is an art, and those who are naturally good at it should just get a job as a hardware designer. Just as I regularly cringe at the code produced by hardware orientated people, they too cringe when they see my horrible hardware attempts, but I’ve learned that there should indeed be different people allocated for the two different tasks.

And LUFA stuff too…

In LUFA news, I just about cried when I received this bug report, along with a solution from Martin Degelsegger – it pointed out a critical flaw in the way LUFA allocates endpoints and pipes in the class driver which didn’t seem to have any easy solution. I admit it is my fault for not seeing the one-line warning in the USB AVR datasheets, but I still feel like kicking the Atmel engineer who designed the damned thing; if endpoints or pipes are allocated with a non-ascending index, the bank memory locations in the internal controller DPRAM can be silently overlapped at random offsets even though the controller reports a successful allocation. That’s damned nasty and something I had no idea about until now, as I was only aware of the “bank memory fragmentation will break everything” caveat warned quite prominently in the datasheet.

I’ve not yet totally QA’d my fix, but I’ve adjusted the Endpoint_ConfigureEndpoint() and Pipe_ConfigurePipe() routines to work around the solution. Basically, the routines cache the configuration of all the endpoints and pipes, then clears them before reallocating them in order with the new endpoint or pipe inserted in the correct place. That seems to fix the problem with out any obvious side effects, other than the deletion of anything currently in the endpoint or pipe banks. Given that endpoint and pipe configuration is done during the enumeration process before any non-control endpoint or pipe is used, this doesn’t seem to be a problem.

Finally today is an update on my competition for a free USBTINY-MKII programmer – with the above people added to the list, we’ve got two new contenders:

A. Paulin (One entry)
B. Paddock (Three entries)
A. Rohde (One entry)
N. Braun (One entry)
Simon [No Given Last Name, Google Code issue report] (One entry)
J. Bowen (One entry)
M. Degelsegger (Two entries)

Which makes things really interesting. I’ll clarify the competition here; only one programmer per winner, so while multiple entries will increase your chance of winning a programmer, it won’t increase your chances of winning more than one programmer. If you think you’ve found a bug, report it before the 30th to get your chance of winning too!

Even if you’re not going to enter into the running for a free programmer, Tom’s just released news on some really neat little adapters for his programmer (although they are generic and will in fact work with any AVR programmer) to make it easy to insert into breadboards (including one with 3.3V voltage regulation) and program AVRs with the RSTDSBL fuse set. Check them out, and if you’re interested bug him until he releases them up for sale – scroll down the linked page for the pictures and information. (Tom’s decided not to sell these for now. Perhaps he’ll sell them as cheap kits in the future).