So here I am, using my precious weekend time to try to get caught up on a neglected aspect of a Big Project - an aspect which I should be able to get done in about one solid day's work - and a complication arises.
I have some AVR code, written in C, which I'd been running on an ATmega16, 'cause that's got a JTAG port. Compiles OK for the ATmega8, too, but in reality it'll be running on an ATmega168, just because I'm anticipating a certain amount of bloat to set in.
So now I change the Makefile to compile for the '168, and it has many errors, with sundry register names and such being undefined.
Apparently the register names got changed. Looks like some of the definitions also got changes, wherefore I am led to the belief that I'd better look carefully at the operation of the UART on the '168, just in case Atmel's gone and made it incompatible with the older models.
(I'm also having some concerns about Atmel as a business. It seems that many of their popular single-source products are on 6-month backorder, and in some cases their distributor stock check shows thousands of pieces in stock with a distributor whose own stock check comes up zero. This led me to check the financial news, which cheerfully informed me that Atmel had just had an unexpectedly good quarter. Er, guys? Boosting revenue by selling all you've got, and saving on costs by not making any more, is not a sustainable business plan. If I can't count on having the products available, I'll have to start designing in your competitors' parts instead, no matter how much of a pain they may be to code for. A device driver is a one-time annoyance; a procurement problem is forever.)
Recent Comments