The purpose of this assignment is to give you experience with the AVR’s timers and the use of interrupts. You are to repeat assignment #1, this time performing the timing using an interrupt-driven timer. You are to write an interrupt service routine (ISR) for one of the hardware timers on the AVR. Each time the timer interrupts, you should update a counter variable. Then, when determining the amount of time that the switch is held down, use the counter value. Then, use the counter again to determine how long to turn on the LED. As before, in addition to writing the code, determine the size of the code in your program, including main and the ISR.

For reference, all the first assignment did was to time how long you held down a button, wait a second, then to light up the lights for the same duration. The difference is this assignment uses timers and interrupts wheras the other just looped.

When I stumbled across this I was curious as to where 0x9e370001 came from. After a bit of searching, I found this:
(from “Understanding the Linux Kernel”)

The Magic Constant

You might wonder where the 0xe370001 constant (= 2,654,404,609) comes from. This hash function is based on a multiplication of the index by a suitable large number, so that the result overflows and the value remaining in the 32-bit variable can be considered as the result of a modulus operation. Knuth suggested that good results are obtained when the large multiplier is a prime approximately in golden ration to 2^32 (32 bit being the size of x86 registers). Now, 2,654,404,609 is a prime near to 2^32 * (sqrt(5) -1)/2 that can also be easily multiplied by additions and bit shifts, because it is equal to 2^31 + 2^29 -2^25 -2^19-2^16+1.

In other words, pulled out of Knuth’s and other’s asses.

Do people just sit around thinking about this type of stuff? My guess would be yes. All I know is my new favorite number is now 2,654,404,609.

This morning I got to thinking. What happens if parents die before their kids? The world could be flooded with zombies.

Some background. Unix allows a child to get the PID of its parent or the execution state of its children. For example, a parent can spawn a child to complete some process, and then wait to check when the child has terminated.Â If the child is dead, it’s termination code will tell the parent whether or not the task was completed succesfully.

So Anyway, Unix kernels can’t discard data in the process descriptor fields right after a process terminates. They can only kill themselves completely after their parent has issued a wait()-like call (seen whether their task was completed).Â This is why zombies were introduced: although the process is dead, it must live until the parent is notified of it’s death.

So if a parent dies to leave orphaned children, the world could theoretically be flooded with these zombies, since there are no parents to issue wait()-like system calls. This problem is solved by forcing all orphans to become children of Init. In this way, Init will destroy zombies while checking for the termination of one of its legitimate children through wait()-like calls.

The release_task() function detaches the last data structures from the descriptor table – or “blows their brains out” if you will.

Obviously, everything I’m saying is not about processes, but about real zombies and an unsung hero named init.