AVR-Chat

Hi Chuck,
 
You need to put 1 decoupling cap per VCC pin on the device, as close to each
pin as possible. I would also consider putting a small 0805 inductor between
the VCC and AVCC to reduce noise at this input. Also put a 0.1uF decoupling
at this pin too. AREF can be fed from the same point. I assume you ADC input
is not critical anyway, but these measures will give a cleaner output and
good practice. I use the same setup with an MCP3424 from Microchip which I
run at 16 bit and it is very quiet using this supply input.
 
As someone else suggested, you don't need the reset IC. This reduces your
cost as at AVR has a very good built in reset circuit. I have never had a
single issue with them using the internal reset.
 
Looking at the PCB, your power rails look a little on the light side. You
might want to setup the auto router (if it allows this) to use thicker
tracks for the power rails. GND is not a real issue if you can plan to lay
down a GND plane but the VCC needs to be a little thicker and depends on the
current draw at each point in the circuit. I don't know what the digital
outputs are capable of as this is likely to be the point to consider this.
 
You don't have any termination on the CAN bus. You need to consider adding a
link selectable 120R resistor for this.
 
I am not sure your arbitration will work well using the UART and remember
you will see the transmission on the receive side. The reason it may fail is
that your initial bit bang could be the same for 2 devices transmitting at
the same time prior to the UART stage. After the UART is started, any
difference will cause an arbitration on the bus and possible loss of the
message due to corruption and unless you read back the transmitted message
you won't see this! Interesting concept and I would be interested to seeing
how it works out for you. With the amount of work coding wise you need here
to support this, you could have used the CAN based micros and used the same
time to get them working. Not as hard is it seems by the way. The only
downside is that the devices are larger with more pins.
 
Have you considered manual routing. Ideally the CAN High and Low should be
routed as a differential pair but if your bus speed is low, you should be OK
with the way it is now.
 
Your 7805 based design should be OK but as you have no heat sink, just
ensure that you total circuit current is kept low to avoid this running hot
and starting to fail on the output. The National Semi switching regulators
are really easy to design with and their webench design environment makes
this even easier. I have never had a design not work using the webench.
 
Any reason why the switch S2 is spread all over the IO Pins? Could not you
connect direct to PORT B and move the other IO on Port B to the other pins
used by S2. This will make software much simpler.
 
One last thing, that is mainly just cosmetic. On your inputs at the bottom
of the schematic, the GND connections don't look the same as the other GND
connections.
 
Good luck with the project and keep us all updated. Good job so far and good
to see you having a real go at rolling your own. A good learning exercise
too.
 
Dave.
 
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Chuck Hackett
Sent: 06 November 2010 22:55
To: AVR-Chat
Subject: [AVR-Chat] Looking for critique on board layout
 
  
I know this is dangerous, but ... :-)

I'm looking for a critique of the board layout for my first significant
project.

This board is designed to control signals for outdoor ride-on railroads
(which I
think I've spoken about here before). The board senses track voltages and
drives
multiple 3-LED signal heads accordingly. I have a previous, much larger
setup using
a commercial "development board" with an ATMega16 and an "interface" board I
made
for initial feasibility testing. I'm now adding communications (pseudo-CAN)
and
going to an ATMega32a (more program space for communications protocol,
etc.). There
were lots of design decisions that went into it that I won't go into here.
What I'm
looking for is feedback on the circuit design and board layout - be gentle
:-)

Images:
Schematic:
http://www.whitetrout.net/Chuck/temp/Signal_Interface_sch.pdf 
Board: http://www.whitetrout.net/Chuck/temp/Signal_Interface_brd.pdf 

Schematic:

- The power, track(rail) inputs, and data bus are protected (up to a point)
against
lightning/surge by TVS diodes. Low current, fast-blow fuses will be mounted
on a
"base board" in the enclosure that the board plugs into. No illusions about
successfully taking a close/direct hit. My previous prototype survived
several hits
with no problems other than blown fuses and one very close hit that took out
about
$8 worth of parts across two boards.

- The data bus is pseudo-CAN. I use a CAN driver but I'll be doing the
beginning-of-message bus arbitration by bit-banging (PD2, PD3) and then
switch to
the USART for actual data transfer. In the future I hope to switch to a
AT90CAN128
(built-in CAN support) but I wanted to limit the initial hardware/software
learning
curve so I could get the next version out faster. I realize that this will
severely
limit my speed/flexibility for now but it will allow me to test
communications on
the long (1,000's of feet) bus, etc. and I have to walk before I run.
Switching to
true CAN later will allow me to take advantage of standard CAN I/O
expanders, etc.

- I think I have addressed chip bypass issues - do I need more than one
bypass cap
on the ATMega32a?

- Later the 7805 linear regulator will be replaced by a switching regulator
to
reduce demand on the power bus (1,000's of feet long - I'm aware that there
are lots
of issues here). Again, I wanted to limit the introduction of too much new
technology in this go-around. 

- I will create a small "Diag" module that plugs onto the "Diag" header. It
will
have LCD screen, "joystick" menu, etc. - possibly based on the AVR
Butterfly. It
will use I2C (new to me) to communicate with the processor, monitor the CAN
bus
(hence I brought out CANH/CANL), etc. "Diag_Present" will be pulled low by
the
module to notify the processor that the module is connected and wants to
communicate
via the I2C bus (I considered periodic polling of the Diag I2C address but
thought
this wasteful of processor time). "Diag_Int" is there to allow the module to
interrupt the processor but I don't have a specific use at the moment. Other
signals I should bring out to this header?

- The Railroad Signal Head LEDs (10mm, ~10 ma each) will be connected to the
TLC59116 outputs. The LED commons will be connected to the unregulated V+ to
reduce
demand on the regulator and noise on VCC. 

- I picked a 14.7456 MHz crystal so that I would have 0% USART bit rate
error up to
230.4 Kbps. At the moment, I have no idea what bus rate I'll be able to
maintain on
the long cable. One of the purposes of this board version is to investigate
this.
At the moment I'm thinking that I'll be using a lower rate for arbitration
(via PD2,
PD3) and then switch to a higher rate for data transfer via the (interrupt
driven)
USART.

- Jumpers TB1-TB7 supply bias to the track. In some cases the bias is
supplied at
the distant end of the track section (to allow detection of a "broken rail")
by a
board with a similar network.

- Unused processor pins were brought out to the connector to allow for as
yet
unknown functionality - hey, I had extra pins :-) ...

Board:

- The board is 2.750" x 2.375" designed to fit into a standard PVC
"single-gang"
switch box enclosure available at Lowes/Home Depot, etc.

- The holes in the corners of the board are to facilitate locating pins to
facilitate machining both sides of the prototype boards using "Isolation
Milling"
(using pcb-gcode, MACH3 and a Sherline CNC mill).

- The TVS diodes are mounted on the bottom side of the board. I attempted to
keep
the traces short between the TVSs and the connector as well as ground.

- I couldn't seem to find (Mouser/Digikey) a socket for the crystal
(FOXSLF/147-20)
so I'm using pin sockets from MillMax for the moment (can anyone point me to
an
appropriate socket?).

- JP1 is on the bottom side. It plugs into a connector on the "base board"
within
the enclosure. The holes at the ends of JP1 are to mount a handle on the top
side
to facilitate insertion/removal of the board.

- Signal assignments to connector JP1 were chosen to make board layout/trace
routing
easier.

- I know that the 7805 does not have a large heat sink pad but I don't think
I'll be
drawing enough for that to be a problem (see also the next item).

- This board was auto-routed (I use Eagle). The ground needs to be
hand-routed but
I have been moving/changing things so much (ergo a lot of "ripup !; auto
!;") that I
have stayed with auto-route for the moment. I realize that this is a crutch
and
"real men" don't use the autorouter :-) This board is mostly to check
functionality
and develop the software, I'll hand route GND/VCC/V+ on the next board. I
was also
having problems with the auto-router and GND/VCC planes (the board would
auto-route
without them but not with them) so I eliminated them for the moment (I also
tried
"FreeRouter" on the web). I'll be re-addressing this issue when I hand-route
the
next board.

Well, that should give you enough to shoot at. I realize that there are a
lot of
design considerations, application considerations, etc. that will cause you
to ask
"why did you do it that way" but to describe all that would have required a
lot more
reading (and me to remember all the considerations) so I beg your
forgiveness on
that aspect. If something really jumps out at you, feel free to ask ...
 
Cheers,

Chuck Hackett




[Non-text portions of this message have been removed]