H. Mijail's Blog

I have found what looks like a hardware bug in the AT90CAN128! I guess I could be happy in a geeky way, but the number of hours spent trying to track the problem make it a bit difficult :P. The thing is that aborting a pending MOb in the CAN controller embedded in the AT90CAN128 can leave CONMOB in an unexpected state. I am not totally sure if this is a hardware bug… or could be Atmel's library at90CANlib_3_2 being buggy AND misleading.

Atmel Studio 6, which is (ununderstandably!*) based on Visual Studio (2010?), suddenly stopped showing anything in the Solution Explorer pane. The pane was there, it just remained empty, blank, apart from the "Properties" button (and the "Show all files" button shows up too, depending on the frontmost pane).

Long story short: Atmel Studio's inflexibility forces quite a strict isolation, which forces you towards the purist side (potential advantage) and makes compile-time library configuration very difficult (clear actual disadvantage). So it's not a very clear win - though I am rather liking it.

A small inline function to take a snapshot of all the ports as simultaneously as possible, which means 7 cycles from first to last, which means less than 0.5 usec from first to last at 16 MHz. Can't be faster. Had to be done in asm inline because if not gcc prefers to interleave the input instructions with store instructions. Done this way, the inputs come first and the storage comes later, generated automatically.

I found a strange situation when programming in C for AVRs. I have a bunch of structures to be worked on, but any of them can be flagged "active" or not at any given moment, to signal whether they need further work. My first approximation was to add a (uint8_t volatile: set in main, checked in interrupt time) member variable named "active" to the struct, to quickly check/set each structure. Shock: only looping through the array checking the "active" member variables was taking an enormous amount of time – about 20 clock cycles per access !