i have an Arduino board with an atmega328 and i use the arduino software version 17. To generate a normal timer interrupt i tried to initialize the OCR1A register with a 16-bit hex-value for the 16-bit timer.

OCR1A = 0x0ABD;

My program didn't work right, so i made a check. I found out that the problem is that when i requested the value from the register

So is there a problem with the arduino software not being able to write into 16bit registers? Or what did i do wrong?I know there's a TEMP register used for the high-byte to write into OCR1A simultaneously. But even though i loaded the <avr/interrupt.h> and the <avr/io.h> he doesn't know the expression TEMP.

My problem is actually that i don't really know how to access the 16-bit registers. And how can i check whether the compiler understands operations like:int a = 1000;OCR1A = a;Because in assembler you have to put your high-byte first in the TEMP register and then after that when you load the low-byte into the OCR1A the high-byte gets into the OCR1A automatically.But i don't know if this background stuff is all done by the compiler.

• Upload doesn't work? Do a loop-back test.• There's absolutely NO excuse for not having an ISP!• Your AVR needs a brain surgery? Use the online FUSE calculator.• My projects: RGB LED matrix, RGB LED ring, various ATtiny gadgets...• Microsoft is not the answer. It is the question, and the answer is NO!

• Upload doesn't work? Do a loop-back test.• There's absolutely NO excuse for not having an ISP!• Your AVR needs a brain surgery? Use the online FUSE calculator.• My projects: RGB LED matrix, RGB LED ring, various ATtiny gadgets...• Microsoft is not the answer. It is the question, and the answer is NO!

I've done some further checks with LEDs as indicators of HIGH/LOW bytes in a 16bit variable (unsigned int). I've also compiled it outside the Arduino IDE and the behaviour is the same. Still the assembler code looks ok as far as the order of reads/writes is concerned.

It boils down to this:

First I stop TIMER1 by setting the prescaler accordingly. Then it let the compiler write 0xFFFF into TCNT1 (16bit reg), assuming it knows how to do it correctly and instantly read it back into an uint16_t variable called timer1. I use 8 LEDs to show the LOW/HIGH byte contents of timer1 and print the results to serial as well.

The LOW byte content of timer1 is correct (0xFF) and 8 LEDs light up. The HIGH byte though is ZERO. If i replace the readout of TCNT1 into timer1 with just "timer1 = 0xFFFF", LOW/HIGH byte content of timer1 is correct and the 8 LEDs light up twice. The serial output is correct as well in this case.

So apparently reading TCTN1 into timer1 fails. Manually reading LOW/HIGH of TCNT1 using TCNT1L and then TCNT1H fails as well.

• Upload doesn't work? Do a loop-back test.• There's absolutely NO excuse for not having an ISP!• Your AVR needs a brain surgery? Use the online FUSE calculator.• My projects: RGB LED matrix, RGB LED ring, various ATtiny gadgets...• Microsoft is not the answer. It is the question, and the answer is NO!

I've started a thread on avrfreaks.net with basically the same question. Maybe some of the experts there know what the problem is.

• Upload doesn't work? Do a loop-back test.• There's absolutely NO excuse for not having an ISP!• Your AVR needs a brain surgery? Use the online FUSE calculator.• My projects: RGB LED matrix, RGB LED ring, various ATtiny gadgets...• Microsoft is not the answer. It is the question, and the answer is NO!

You should see timer1 increase by however many ticks of 64us it takes to do the loop. You should see the timer value and the millis value correspond (multiply the timer value by .064 to get milliseconds)

I plugged my test code into some other piece of code I have, which also uses timer1, and it works there. It precharges timer1 to some value very close to 0xFFFF to increase the frequency of the overflow interrupt.

What is the difference ? As you may very well already know, timer1 can be a 16bit counter, but doesn't have to be. Anyhow, it only works as it should when the WGM10 bit of TCCR1A is zero.

Now the question arises is why WGM10 is not 0, although the datasheet claims the default value for TCCR1A is 0.

• Upload doesn't work? Do a loop-back test.• There's absolutely NO excuse for not having an ISP!• Your AVR needs a brain surgery? Use the online FUSE calculator.• My projects: RGB LED matrix, RGB LED ring, various ATtiny gadgets...• Microsoft is not the answer. It is the question, and the answer is NO!

Is there a way to selectively disable arduino glue when not needed ? If all the analogWrite stuff is never called at all for example, don't mess with the timer registers ? But there's also delay and so on. Maybe it's time to move on. I guess the arduino ide just can't provide a more open way of "include this, configure that, but exclude ...". Maybe an 'advanced mode' with e.g. a PWM.h include for the timers and so on. If the core were split up like that, more experienced users could decide what they really need.

• Upload doesn't work? Do a loop-back test.• There's absolutely NO excuse for not having an ISP!• Your AVR needs a brain surgery? Use the online FUSE calculator.• My projects: RGB LED matrix, RGB LED ring, various ATtiny gadgets...• Microsoft is not the answer. It is the question, and the answer is NO!

I think the problem may be more with your expectations than with Arduino Saying it sucks because there is no simple way to cut holes in the security blanket is missing the point of Arduino - its purpose is the security blanket.

I wouldn't disagree that Arduino hardware initialization would benefit from being more flexible, but supporting more boards would IMO be a higher priority than disabling Arduino functionality for experienced programmers.

Anyway, there is nothing stopping you from modifying the initialization code in wiring.c to make it do what you want. And if you create a board variant in the hardware/cores directory for the hacked core, you can switch between the standard version and your customized core as needed.