@Pluggy: I actually bought a DSO, a frequency counter and an efratom time normal (in order to ensure proper overkill ). Conclusion: my code was off by one cycle (=1/16 ppm). The rest was due to the crystal setup. I discussed this with a professional electrical engineer. He explained to me that with the arduino like setup it may be possible to get into the 100ppm range. But this is not at all reliable. The main issues are temperature, voltage and of course aging.

True: the original Arduino did not drift that much at room temperature. However if you need guaranteed timing better than 100ppm, a 100ppm crystal is not at all sufficient. You will need a VXCO, TXCO or something along these lines. It also seems that dedicated time keeping chips (based on 32kHz crystals) offer much better precision than the standard setup and they are comparatively cheap (compared to TXCOs).

There is one more thing I learned by now: crystal oscillators are mechanical devices and thus the frequency may drift in the presence of vibrations as well.

Udo

My experience with Arduino is that depending on your specific board it may be off to 200ppm. With an oscillator instead of a crystal even more. The question is: do you need high resolution, high precsission or both?

You can get cheap efratom time normals from Ebay

Udo

You suspect that pulsing might make the LED appear brighter. However this is not true. I remember at least one investigation where they come to the conclusion that depending on the frequency pulsed lights will appear dimmer.

Also the efficiency of LEDs will decrease beyond some current levels. Again you will get less light per average current then by not pulsing.

Usuaally the reason for PWM is dimming. AFAIK there is no known means to make it appear brighter on a given average current with high frequent PWM.

Udo

@Benf: thanks a lot. I should have read AVR 042 more carefully. I will just drop the resistor and connect reset with some unneeded IO Pins. Makes my whole layout a lot simpler

@Gbulmer: of course it is the size. That's the whole point why I had to switch to SMD. TTH would have been a lot easier. I could have used a simpler beginner project with eagle, but then again: you grow with your challenges

I am currently underway to create my very first PCB with eagle. Since I want to have very small results I already switched to SMD parts. However one issue is bogging me:

Either I have to go for two layers or I have to ommit the pullup for the reset pin. However for my idea I do not need all IO pins. So I wonder if it would be a reasonable idea to connect reset to one of the IO pins and activate its pullup resistor.

Any comments on this idea? Is this reasonable or are there any hidden pitfalls with this approach? I do NOT intend to pull the pin low in order to trigger a reset. I already read the application note that says that is is not a good idea. However no application note states something about using IO pullups to connect with reset.

Udo

Yes, LDRs are slow. Their reaction time (best case) is measured in milliseconds. However if your instrumentation is not very sensitive to small changes then you may see reactions times in the seconds range.

Udo

I am doing something similar and the Arduino is most probably not the problem. Unless your program is very inefficient. My current results are: (running @16 MHz): maximum lag: 0.5us, time resolution 1 us, frequency jitter <1us, precision better 100ppm. I am still working to get the crystal more precise.  But the Atmels are definitely fast enough. The analog parts surrounding it give rise to much bigger delays. For example it is hard  to find an affordable flash faster than 20us. Except you are willing to pay >1000 or you are going to build your own flash.

I would guess either the LDR is the issue, or you are polling the LDR. If you use analog in for detection you still have a sample rate of ~50 kHz (or 200us period time).

Udo

Have a look here

http://news.jeelabs.org/2010/01/06/pin-io-performance/

Theoretical limit is to output the clock frequency. This is achieved by setting proper fuses. With PWM you can get clock frequency/2. With assembler you can get clock frequency/2 for short periods of time. If you allow != 50% duty cycle you can get clock speed/4 with assembler. If you insist on 50% duty cycle clock speed/6 can be achieved.

I have no clue what you mean by "faster than assembler".

Udo

Go for an ISP like the AVR ISP MKII. The MKII comes with AVR Studio and this can of course download. Avrdude can download as well. However if the fuses are set accordingly a download is almost impossible. At least impossible with cheap equipment. With very advanced enigneering skills (or enough money) you can download no matter what the fuses are. I doubt that you would be willing to go that far though.

Cheers, Udo

Could it be that your switch does not behave digital but analog and thus causes the Arduino to flip back and forth while the switch is in transition?

Cheers, Udo

Ok, I was not after

Code:

const uint8_t * c_no_page_adr = (uint8_t *) -1;

What I needed was

Code:

uint8_t * const c_no_page_adr = (uint8_t *) -1;

arghh, yes, this was really stupid

Example of a stupid pointer mistake today:

I coded

Code:

const uint8_t c_no_page_adr = (uint8_t *) -1;

instead of

Code:

#define c_no_page_adr ((uint8_t *) -1)

Once I included the header file twice the compiler started complaining and I just did not get it.

Btw: any wizard out there who could tell me how to declare such a constant as a constant instead of using a macro?

Cheers, Udo

Hey, you got the point --> do not feel stupid. You should see my mistakes ...

Ah, seems your comment and mine face a race condition. So the question is due to insufficient knowledge of pointers. This can be fixed easily.

uint8_t *p__ is a pointer pointing to a byte
uint16_t *p__ is a pointer pointing to two bytes

Both pointers will allocate the same amount of memory and can hold addresses in the whole address range. That is they use two bytes. You fill them like

p__ = (unit8_t *) 256

and immediately you see they can address >255 bytes.

Cheers. Udo