I'll check the build process tonight. I haven't built from source yet.

The arduino-0007 installer for mac os x has unstripped avr development tools and duplicates of many of the tools in tools/avr/avr/bin. That could be slimmed down by about a factor of four by stripping and eliminating duplicates.

You can use the standard C library function atoi(). It takes a string in decimal and returns an integer. I just checked and it only adds about 120 bytes to the sketch.

SoftwareSerial has some timing issues. It doesn't push the tx pin high when started, that can ruin the first character, but you can work around that by setting it high when you set the pinmode for it.

Worse, the rather expensive math operation to compute the bit delay gets shuffled into an unfortunate code path and makes the start bit be about 1.5 bit times long ensuring that your bits are sampled on the edges instead of the centers

Still, I wouldn't expect you to get nothing from that. I'd expect you to get a few percent of your characters garbled, or all of them, depending on the timing of your receiver's uart.

(Patches are in the works for 0008 software serial to stabilize it.)

SoftwareSerial::begin() just stores your bit rate in an instance variable. It seems unlikely that could cause a problem directly unless you have run out of SRAM. If you don't do a ::begin() you will get a divide by zero error in print. I don't know what that does.

All of the outputs on the Arduino are PWM, that is just the way it works. You would only use the ones driven by the counter you mess with, and you could probably choose a mode where they would work, just not in "phase correct pwm" which  is the mode that causes downward counting.

Writing to a register, like TCCR1A is just like assigning a variable.

It is the delay(900) at the bottom. This waits for a counter that is incremented by TCNT0 rolling over so your code is always called not too long after the rollover.

About TCNT1, 16 bits is better, but... The way it is configured in the arduino I think it counts from 0 up to a limit based on your PWM output and then back down to 0. That would be difficult or impossible to interpret. You could change the counter mode, but you would lose the analog output.

The TCNT0 register from timer0 isn't really a part of the Arduino environment, it is the underlying hardware.

I wouldn't try to correlate TCNT0 rollovers and millis().  Millis is derived from the rollover count, but sometimes it jumps 1 and sometimes millis() jumps 2 because the timer doesn't rollover on a millisecond interval, plus doing long integer arithmetic really eats up the clock cycles and bytes so I avoid it unless I really need it.

If your time interval is less than 1024 microseconds, and I suspect if you move the gates close enough you can be certain of that, then you have either zero or one rollover in any measurement and when you subtract the times you know. If you got a negative time interval add 1024 microseconds. Be careful about when you convert from unsigned to signed.

The atmega8 and atmega168 manuals are from Atmel.  http:// http://www.atmel.com/dyn/products/devices.asp?family_id=607 will get you into the neighborhood.

You can use the pulseIn() function if you can arrange for your signal to arrive as a pulse. If this isn't possible because it involves two pins or someother reason then you must look outside the normal API.

If you look at the hardware level this becomes possible. Timer0 is an 8 bit counter that increments every 4 microseconds with a 16MHz Arduino in the standard configuration. You can read its value with TCNT0. You'll have to watch for when it rolls over and do the right thing.

You can read about the timers in the Atmel chip manual for your processor.

Be aware, the overflow interrupts do not fire if you are resetting the timers with a compare match. There is a different interrupt vector for that. I don't think that is your problem, but you will probably bump into it.

Some functions use cli() and sei(), but they should only disable interrupts for short times.

The timer0 overflow interrupt is used inside the Arduino libraries to implement the millisecond timing functions. I wonder if that one is taking precedence over yours?

For timer1, although there are two different output compare registers, you won't get to make two different frequencies because only one will get to clear the timer. That one will set the frequency and the other will only be able to control duty cycle.

If any of your frequencies are multiples of each other you could make your fastest one be on timer2 and use the timer2 compare match interrupt to count and toggle the slower one.

It should just happen. The way you typed it in the forum, you have spaces inside the angle brackets. It should not have spaces. You want it to be like this...

Code:

#include <avr/io.h>

I haven't tried, but with arduino-0008 the analog ins also show up as digital14 through digital19. You should be able to do something like a digitalWrite(14,HIGH) to turn them on.

tempalte has got a lot of the right parts, just not all together.

The packed bitfield structure is correct. That will let you access the 8 bits of the byte individually. But if you want to assign a byte into it, then you either need to put it inside a union or do some typecasting.

For whatever reason, it is not the habit of Arduino programmers or the avr-gcc people to use bit structures. They tend to shift and mask. At a first glance, the object code is about the same so it is a matter of preference.  (Personally, I like bit structs for fixed structures, but I don't code that way here.)

You can do this...

Code:

const char longstring[] = "aaa"
    "bbb"
   "ccc";

but you might make sure to learn about <avr/pgmspace.h> and PROGMEM because otherwise your strings all get copied into SRAM and you don't have much of that.

You should do your timer reprogramming inside your setup() function. This runs after the init in the libraries.

Your code will not effect the timing unless you disable interrupts for more than about... 1000-2000 microseconds.

I'm told the radio folks that really care about crystal stability make "crystal ovens", little insulated covers for the crystal with a temperature sensor and a resistor inside. Then they pick a temperature above any likely ambient temperature for the device and keep the crystal at that temperature by turning the resistor on and off. That should get you are very stable time source, though you'd have to calibrate it by measuring it over a long time period.

Oh right, I forgot about the phase correct aspect. It might not overflow, and you would certainly have to turn on the interrupt enable bit.

I subtract 1000000 because there will be a few left over each time each time, it will go from 999424 to 1000448 and I don't want to lose that 448. About every other time the while loop while run twice and eat up the accumulated remainders.