4040B 12-stage binary ripple counter and R-2R resistor network

[tggzzz]

I get a spikey looking result.

Because the pin operations on an arduino are not atomic?

It can be easily resolved, however.

What do you mean by atomic?

Being "atomic" is neither necessary nor sufficient - it is irrelevant.

What matters is that the outputs all switch at the same time.

You can never get perfection in that respect, so there will always be glitches as one signal changes slightly before another. Such glitches are minimised by ensuring equal and low loading, driving from a single device, and using a single clock to latch all outputs simultaneously.

[dannyf]

What do you mean by atomic?

If you arduino's pin operation functions, they are pin-oriented, meaning that they operate on one pin at a time. Say that you are outputing 0b0111 on  the four pins and you want to go to 0b1000 next. As you can only write one pin at a time, you may set the msb first, making the output to be 0b1111, and then clear the lowest three pins, outputing 0b1011, then 0b1001 and then 0b1000.

The right approach is to work on the port so that all the state changes on the pins take place at the same time.

[dentaku]

What do you mean by atomic?

If you arduino's pin operation functions, they are pin-oriented, meaning that they operate on one pin at a time. Say that you are outputing 0b0111 on  the four pins and you want to go to 0b1000 next. As you can only write one pin at a time, you may set the msb first, making the output to be 0b1111, and then clear the lowest three pins, outputing 0b1011, then 0b1001 and then 0b1000.

The right approach is to work on the port so that all the state changes on the pins take place at the same time.

OK. I have never used a microcontroller until recently so I was keeping it simple using a sketch I found that outputs on digital pins 2,3,4,5 and uses delayMicroseconds to se the frequency.

void setup() 
{ 
  pinMode(2,OUTPUT);
  pinMode(3,OUTPUT); 
  pinMode(4,OUTPUT); 
  pinMode(5,OUTPUT);
} 

void loop() 
{ 
  for(int i=0;i<14;i++)  // increment automatically
  { 
    int a=i%2;      // calculate LSB   
    int b=i/2 %2;     
    int c=i/4 %2;       
    int d=i/8 %2;
    digitalWrite(5,d); //write MSB
    digitalWrite(4,c);   
    digitalWrite(3,b);   
    digitalWrite(2,a);  // write LSB 
    delayMicroseconds(100);     // wait for x us
  } 
} 

[dannyf]

That wouldn't be atomic.

If the pins are on the same port, you can use a shadow variable to form the desired value and then export it to the port data register.

Something like this:

Code: [Select]

  sDAC_PORT = ((i&0x08)?(1<<5):0) | //form the msb on PORT.5
                          ((i&0x04)?(1<<6):0) | //form the 2nd msb on PORT.6
                          ((i&0x02)?(1<<2):0) | //form the 3rd msb on PORT.2
                          ((i&0x01)?(1<<4):0);  //form the lsb on PORT.4
  DAC_PORT = sDAC_PORT; //export the shadow variable

With this approach, the pin changes will be synchronized.

It obviously gets slightly trickier when the port is also driving other devices.

[dentaku]

OK, I did some more research and if I count on PORTB (I could have used D but I decided to use B) it works fine with no spikyness using this code and using pins 8,9,10 and 11.

Code: [Select]

void setup ()
{
  DDRB = 255; //pinMode (8, OUTPUT); pinMode (9, OUTOUT)...
}

void loop ()
{
  PORTB ++;
  delayMicroseconds (100);
}
I guess I'm going to have to do some more reading and see if I can do this without tying up ALL of PORTB just to count to 16 because I'm assuming just changing to DDRB = 255 to DDRB = 15 doesn't free up pins 12 and 13 even though I don't need them just to count to 16.

EDIT... I see you posted while I was still typing my last message