Thanks again.  Once I started hand-routing it turns out not to be that bad and I can see what I'm doing.  It makes me think twice about pin assignment and such.  i bet when i'm done i could turn it back to the autorouter and it would do a good job.

@jack: thanks.
"I put ground planes on both sides which helps a fair amount."
I know how to do the polygon/rats-nest thing after the routing - is that the same thing?
"Then I try to place the components as logically as possible." ok
"Then I try the autorouter, 10 mil grid." ok
"If it's a real mess, I reconsider my "logical" placement of components and move things around."
I guess that's where I am.  How would you pick what  to move where?

I'm doing my first PCB using Eagle and I'm struggling with the routing.  I'm not good at layout type things so I'm relying on the auto-router.  To get 100% routed I have to go with 10 mil traces and separation  for signals and 16/10 for VCC and ground and set the routing grid at 4 or less.  Even then I end up with dozens of vias and a jagged looking board.  There's lots of room and I've moved a few things around but it's hard to see any improvement.

Are there any general approaches I could take to improving it?  I did try hand-routing VCC and ground first but it just took me a long time to do and the result didn't seem any better.

The board holds an smd atmega328 with a power supply and ttl serial connections.  There's a 74hc166 shift register and a 74hc02 glue chip connecting to a 30 pin connector which interfaces with an existing board.



In the board layout the power supply is top right, the atmega is below it, iscp beside it.  the top chip near the 30 pin connector is the 74166 shift register and the 7402 is below that.   I would like to leave the bottom part of the board clear although that's not critical except for the icsp and other connectors.


any pointers or tips gratefully accepted.  Maybe for my next stab I'll try printing off the board and hand routing a chip at a time.

Thanks very much for the hard numbers and the revised int0 times. I'm writing a midterm today but i'll be retrying an interrupt tomorrow.

Oh, I should have said, the problem seems to be missing the positive going pulse about one time in 50 or so.  Also. this processor is only running at 8mhz.

run1802
Hello World!
Hello Word!
Hello World!
Hello World!
Hello World!
Hello World
Hello World!
Hello World!
Hello World!
Hello orld!
Hell World!
Hello World!
Hello World!
Hello World!

apropos of the polling logic, I realized that given my timing, it wasn't necessary to check for the low condition so I pulled that out completely.  I'm now only missing one in 500 or so pulses/characters.  The target processor will be 16mhz so the problem may go away completely if the millis update routine completes in <my pulse duration.

I'm using a polling loop to wait for a pulse from an external system that lasts 1-2 us. There's a good 5000us between pulses.

I'm polling rather than interrupting because I need to get the data in very quickly.

The following logic woks if I disable interrupts:

Code:

  noInterrupts();
  while(true){ //loop for 1802 program output
    while (PINB & 0x10); //make sure 1802 signal is low
    while ((PINB&0x10)==0); //wait for it to come high
    char1802=busin(); //grab the character **this will take several us**
    Serial.print(char1802); //running at 19200 - maybe as much as 1ms
  }

I don't think the delays in grabbing or forwarding the character are the problem.  It's something like the millis() service routine happening during or over the pulse. 

I don't really want to disable interrupts - anybody got a better idea?  I keep thinking maybe the polling logic is wrong.

could you just have a tight loop that reads all 12 bits and does a table lookup or hash function to get the 4 output bits?  Don't worry about changes - just translate 12 bits to 4.

Easiest approach to rc from arduino to car might be to get a cheap car and take apart the transmitter box to hook the arduino in. I did this with an rc plane and was able to control it easily. I'm sure a car would be too.

I was actually trying to fly the plane on a programmed path with feedback via a webcam watching for it - very little luck with that.

It all runs on one windows box with chrome - right? I just add the labscript package?

I can see it being useful for some hardware poking - i'll try it out.

I run a wall follower with two sensors. 1 in front and 1 to the side.

So how did you do it?

I believe standard copper clad is .035 "

I imagine yours would etch more easily though.

If you have the space to make your traces wider maybe thinner is better!

So, I wrote a short blink sketch. I used #define to set the hex values, now using them in the program is easy.
This compiles to 846 bytes (IDE 0023) but using digitalWrite() to do the same thing compiles to 1034 bytes. After seeing this, it's hard to think of a good reason to use digitalWrite anymore

Code:

#define D13high  | 0x20;  //hex code to write Digital Pin 13 HIGH
#define D13low & 0xDF;  //hex code to write Digital Pin 13 LOW

void setup()
{
  pinMode(13, OUTPUT);
}
void loop()
{
  for(int i = 0; i < 10; i++)
  {
    PORTB = PORTB D13high;  //set Digital 13 HIGH
    delay(100);
    PORTB = PORTB D13low;   //set Digital 13 LOW
    delay(100);
  }
  while(1);
}

Until you want to change the pin you're using!

I like your code - thanks for sharing.

ok, way better idea.  The single digital pin will drive both outputs either high or low but, if I tri-state the pin, resistors will pull the outputs to the reset state.  much simpler and i can control the sequencing in software.