Well thanks guys for the explanations,
 I had to get that job out ( I was still working on it till 4 am this morning, but that's another story for Barsports that I will call "painting myself into a corner "

I tested my sketch for 90 minutes ( to guarantee a micros rollover ) and it is working, though I might lose a bit of a second at rollover time , once per soccer game.

I have one other job to get out this week, ( the giant robot controller ) and then hopefully I can do some RTFM on all these points that I seem to get stuck on.

Thanks guys

It is this bit, when micros has started again at zero, and our previous target is enormous, that I havn't had time to get my head around

if ( currentTime - previousTime >= oneSecond)                   it looks at first glance that current time ( say 100 ) - previous enormous count will be a minus figure for a long time.

Obviously if it is an unsigned long it wont be minus, so it is a large number greater than one Second ? 

I tried a few variations on that, but when I hit the countdown run button on the remote, it zapped through the first few seconds in rapid time, and then counted once per second, so I reverted to the micro version of the old sketch and it worked.

The project had to go out today, so I didn't have any time to experiment further, but hopefully after this week I can get some breathing space to see where I was going wrong !

It could be an extra 71 minutes  :-)

I am not too knowledgeable about 2s compliment etc, and binary digits falling away, but I have changed the clocks in my scoreboards to micros ( as suggested by Crossroads ) to get better accuracy.
I am not too worried about a 50 day rollover ( or whatever it is for micro() ) unless it happens in the middle of a soccer game, and they have to play all afternoon :-)

Will this simple bit of code solve the problem ? ( even if it loses a bit of time for one second at a rollover ? )

Code:

if ( micros () < (previousMicros - 1000000)) // its rolled over
{ previousMicros = micros() + 1000000;  } // reset to start again
 if(micros() > previousMicros)          //  this bit is working anyway
 { previousMicros = micros() + 1000000; secunits -- ;                   //  and so on counting down the timer

Well using the scraps of code below, I have fed it out with shiftout, and the waveforms for the 3 bytes look great,( dont worry about the glitches on the green trace, thats the scope )    so now I can try soldering !

Code:

#include <NewSoftSerial.h>
#define RXPIN 14//  
#define TXPIN 15 //
int   AC2DPin = 16;
char  serIn;  
#define SIMBAUD 9600
NewSoftSerial SIM(RXPIN, TXPIN);
#define latchPin 8  // rck
#define clockPin 19 // sck
#define dataPin 12  // ser in
#define blankPin 11  // notG
byte buf [4];

void setup()
{
  Serial.begin(9600);
  pinMode(AC2DPin, OUTPUT);
  digitalWrite ( 16, HIGH );
  pinMode(blankPin, OUTPUT);
  digitalWrite(blankPin, LOW);
  Serial.println("setup");
  pinMode ( latchPin, OUTPUT);
  pinMode ( clockPin, OUTPUT);
  pinMode ( dataPin, OUTPUT);
  SIM.begin(SIMBAUD);
}
//************************************
void loop()
{
  if (SIM.available() > 0) {   // get incoming byte:    
    Serial.println(" something available ");
    for (int w = 0; w <= 3; w++ ) {      
      Serial.print(" w=  ");
      Serial.print(w);
      buf [ w] =  SIM.read ();
      Serial.print("      value=  ");  
      Serial.println( int (buf [w]));
    }
    int s= buf [1];
    Serial.print("s =  ");  
    Serial.println(  (s));
    int t= buf [2];
    Serial.print("t =  ");  
    Serial.println( (t));
    int u= buf [3];
    Serial.print("u =  ");  
    Serial.println(  (u));
    digitalWrite(latchPin, LOW);            
    shiftOut(dataPin, clockPin, LSBFIRST, s);  
    shiftOut(dataPin, clockPin, LSBFIRST, t);
    shiftOut(dataPin, clockPin, LSBFIRST, u);  
    digitalWrite(latchPin, HIGH);
  }    
}

Come to think of it, this is supposed to be  o ,  136,  and 24   shifted out LSB first,  hm something wrong there I think. No thats right !

I think you are right, I am not sure how to do that,  if I start with a byte of 00000000  and then bitwise or  |  it with this data, might that work?

I am so scared of sending ascii to the shift register as the bytes wouldnt match the switches ( I could deduct 48 but I am not sure if that would work )

When I have got these projects out and get some time, I must study this, I hate being confused by simple things.

OK  I have sent all the data as bytes, and at the receive end I can see  0,  136,  and 24  as the three bytes ( thats just as I happened to connect four of the switch inputs on the remote control )

In fact if I Serial.print ( int ( buf [w] ) );  I see the IDnumber first and then the 3 data values:-

  something available
 w=  0      value=  101
 w=  1      value=  0
 w=  2      value=  136
 w=  3      value=  24

and if I Serial.print ( buf [w], BIN );  I get

 something available
 w=  0      value=  1100101
 w=  1      value=  0
 w=  2      value=  10001000
 w=  3      value=  11000

I have been looking at sorting out the bytes, but ( apart from the missing leading zeros ) this looks a lot like the bytes I set in a lookup table to send patterns to the LED displays via TPIC6B595 shift registers to light 7 segment displays.

If I just shiftout each of the 3 values to 3 shift registers, I shouldn't have to parse anything ?

The TPICs can stand the 24v supply , and as they sink, I can connect the drains to the gates of the highside P chan mosfets that drive the solenoids.

Anyone see a fault with this before I start soldering   :-)

Thanks Guys, I forgot to set notify so only just seen your helpful replies.

The value 296 (decimal) requires 9 bits

       yes I just typed imaginary numbers, well spotted.
Each of the byte represents the setting of 8 switches so 255 is the max.

If you add the BIN parameter the put will be as you desire.
Where is the data going?  To a computer?

Thats great , I have used that before but couldn't find it      , thanks again    (  RTFM  !  )



The data is going to another 328 to drive 24 solenoids on the robot via some 595s and MOSFETS 

LOL, thats just one of the things I was looking at to see how many individual "parts" of 3 digit numbers it would spew out :-)

It is the same for 4, but of course you just get the first four out.

I know I have been through this before, but I cant find which project I cracked it on ( probably with all you guys help ! )

I finished off one of the projects I am on during the night, it was the one with the MAX chips driving 6 x 7 seg displays via a radio link.

I thought I would battle on it as I hadnt used the chip before, but it went like a dream, and I was feeling chuffed with myself, despite the pressure to get all 3 jobs done.

So today I tried to finish of another job, which I thought would be simple      scanning 24 switches, and sending their data to a robot for controlling the hydraulics.

I want to try and keep the duty cycle down and hopefully get these units approved in South Africa ( which is a minefield )

So I scan the 24 switches, using 3 CD4017s as a port expander, and read the data back to an input pin.
No problem there,   and then I have managed to combine the individual switch readings into 3  integer bytes, which I can display on the monitor fine ( along with a security code 4th byte )  for instance it says it sent    101 , 296, 03, 091

I send them off to the SIM20 transceiver, with newsoftserial,  ( I cant show all the code as its a mess of testing parts )

 

Code:

void transmit () {
 msg [0] = cust;                               //  msg [4] was declared as an unsigned int
 msg [1]  = Group0;
 msg [2] = Group1;
 msg [3] = Group2;

  SIM.print(msg [0]);
  SIM.print(msg [1]);
  SIM.print(msg [2]); 
  SIM.print(msg [3]); 
 
Serial.print ( " data gone " );
   delay ( 200 );  // ensures packet sent

  }  // end of transmit

 and I can see the 4 bytes going out on the scope on the data pin fine,

but when its received with several variations of the testing code all I can get is the numbers as 1,0,1, 2,9,6,3, 91

where what I need to be able to pick out each switch state is  0010010  10100010 01010011 00101010  for example :-

I always have a problem with this,  how can you look at  56 for example, and know if it is number 56 or if its ascii  for 8 ?

And I can see how to convert to int() etc, but can't find how to get to B0001010 or whatever.

I have been working 20 hours a day for a week  and its showing !   Can someone give me clue to the best method to do this ?

Code:

#include <NewSoftSerial.h>
#define RXPIN 14//   
#define TXPIN 15 //
int   AC2DPin = 16;
char  serIn; 
#define SIMBAUD 9600
NewSoftSerial SIM(RXPIN, TXPIN);
int buf [4];
//char character = 0; // for incoming serial data
void setup()
{
  Serial.begin(9600);
  pinMode(AC2DPin, OUTPUT);
  digitalWrite ( 16, HIGH );
  SIM.begin(SIMBAUD);
}
//************************************
void loop()
{
  if (SIM.available() > 0) {   // get incoming byte:   
    Serial.println(" something available ");
    for (int w = 0; w <= 8; w++ ) {       //  or whatever I put here doesnt wotrk of course
      Serial.print(" w=  ");
      Serial.print(w );
      buf [ w] =  SIM.read ();
      Serial.print("      value=  "); 
      Serial.println( (buf [w]));
    }
  }     
}

[OK I have just found bitread()]

I usually send the settings of bcd switches via virtualwire or easytransfer,  with a separate byte for each switches 4 bits.

One of the projects I am on now has 24 switches that I must send the position of.  I need to end up with 32 outputs to drive individual solenoid drivers.

I could waste a whole byte for each switch, but it I am thinking I could sample each switch ( I have 4 CD4017s stepping through the switches ) and send them as 3 bytes

I could then take the 1 or 0 for each switch, and move the bit one place to the left, and so on, in 3 batches,  so I would end up with 3 bytes to send.

I basically do this with my bcd switches, so I can sort that out, but I am not sure of the best way at the receive end, to separate the bits from the bytes.

I can probably come up with an overcomplicated method of generating 0000001 and bitwise and it with the received byte, then 0000010 and so on, but I am sure there is a simpler way ?

OK  I have just found bitread()

OK thanks, I was looking at the http://www.atmel.com/Images/doc8161.pdf   version

Yes its the screenshot from the datasheet, but its confusing me as the same page on the 328 without the P  shows the 3 different speeds per voltage ?

But the datasheet I was looking at http://www.atmel.com/Images/doc8161.pdf with the single voltage is dated 2009, and the one dated 2010 shows the 3 voltage ranges ????

[P]

I saw that speed grade for the 328,  but the 328P says 20 Mhz for 1.8 to 5.5 v..