The atmel mega16 has alot more space as the atmel tiny2313 (the name kind of suggest this). It has twice the amount of pins, which is nice. The best improvement is flash and sram. The mega 16 comes with 16kbyte program space (vs 2kb) and 1k of sram (vs 128b).

This is a huge improvement.  So now I had the space to get my ds1820 temperature sensor(s) to work.  Grabbing some code found via google modifying it a bit to be more correct it worked
after a fashion.

There is one nice thing on the tiny that I kind of miss on the atmega16, that is beside the 2 external interrupts it has a bus-wide interrupt. So if any of the lines of the bus changed state, I would get a interrupt, this is very nice for efficient keypads.  On the atmega16, I have just 2 interrupts.  What I did now (and it works pretty good, but it’s ugly), I just constantly poll (when the atmel is doing nothing anyway) the inputs for changes.   I need to find a nice solution for this.
Having all the space I need, in less then 2 hours I had most of the code done, and I am now going to play around making a pcb.  (suggestions for software is welcome.)

More in-depth stuff coming later…..

Qball

p.s. I am looking for some open source software that can take visual diff’s from images. anybody knows if this exists?

Realizing that using a 16bit value for bit-masks is quiet inefficient on a 8bit avr. Because I don’t store a value larger then 8bit in there, I split the 16bit variable into 2x8bit  variables.

This saves allot of cycles  moving stuff unneeded  around. It will also run faster, but this wasn’t bottleneck.

The actual gain was around 15%,  it now only uses 1792 bytes. So now I can add features again.

There is one optimalisation left todo, I store “Mon”,  “Tue”, etc in an array, this is constantly kept in sram. It would be nice if I could do this smarter, so it won’t use the sram.

Qball

p.s. still looking for features to add.

This can lead to some unexpected problems, for example the uart. The uart (serial port) needs to transmit/recieve the data at a certain speed, for example 57k6 bit/sec. The whole crux is that it has to generate this from the main  clock, and this isn’t always a nice match.

So if you f.e. run your atmel with a 8mhz crystal the atmel produces an error of -3.5%, and for 115k2 even worse: 8.5%. This can lead to a problem with certain serial ports. So when it works fine on your desktop pc, it can fail on your laptop, or when using a serial->usb dongle (this happened to me, on more then one occasion)
Because this are those little bugs that can be hard to figure out, so I thought lets blog about it.

More atmel related blogs to come, I don’t know at what level you people will still read it. Should I go into much details?

Qball

This wasn’t true,  I run the counter with a prescaler of 1/256. So the value of the clock is incremented every 256 cycles. So between calling the signal, and setting it to 0, I have more then sufficient clock cycles. I just have todo it within 256 cycles. One problem solved or not?

In the documentation it’s not 100% clear if the signal is directly called when the counter matches, or one counter cycle (so 256 clock cycle later).  I have to look into this, but solving this misunderstanding did give me a way to correctly backtrace what it does.

Q