PCB Design Layout Challenge

Files: LED_Driver_Board_Layout_Challenge.zip (47.3 KB)

As I was doing the layout for this PCB I started to wonder how others might approach some of the design issues. I AM NOT ASKING FOR ANYONE TO DESIGN THIS PCB FOR ME; the Zip file includes my current final design.

At least four current rules:

  1. J4 must be at the very bottom of the board with Pin 1 on left (as seen from the front/top of the board).
  2. J1 - J3 must be in the upper right hand corner of the board, on the front/top, with the terminal openings towards the center of the board (Yes, I know this is unusual). NOTE: I think they are currently rotated towards the edge of the board.
  3. Must pass DRC for the minimums of a currently in business PCB manufacture.
  4. The board must be less than 1.3"/35.5mm along the X-axis.

This is not a super simple board to create; not terribly hard either. I figure it will take someone with my skill level about 1.5 hours to complete. It did take me nearly double that from start to end of the file, but quite a bit of that time was me figureing out 1 and 2.

I will provide the 3D model file for the screw terminals in a future post.

I will answer any other questions that there might be.

I HATE LAWYERS: This is an attempt at a fun little hobby board using the ATMEGA328P-PU MCU. While it may potentially have some commercial applications, I have no intention of doing so at this point in time. The Design Files are Free Open Source for anyone to use in their own personal/commercial applications, and I do not make any claims to any IP rights. The PCB layout design rights provided by challengers are retained by the individual challengers.

I’d just clean it up a bit.
Moved all SMD to one side (bottom), move all traces to bottom, leave Top as continuous ground plane.
LED_Driver_Board_ORIGINAL.kicad_pcb (191.7 KB)

1 Like

something like this?
Rotation (or repin) of J1 - J3 would make things flow a bit nicer

1 Like

In this case the cable entries will be colliding with the ATMEGA mcu

1 Like

Files, including 3D models for the screw terminals:

Conn_On Shore Technology_OSTTE020104.zip (60.6 KB)

Perhaps you know that the 328P has an Internal Oscillator (8Mhz) and can, thus, eliminate using external Oscillator).

Removing that and the Caps won’t necessarily give more room to move stuff but, it may be useful and, certainly knowing about it is good. You’d need to install the ‘BreadBoard’ board in board manager.

In previous IDE versions, the list of AVR’s was vast and excellent but, now (being Open Source) the provider pared it down…

I’ve programmed many chips with it (with and without XTL’s)

screenshot shows example

1 Like

Correct. The biggest issue I faced was dealing with the physical realities around this board.

I like your rotation of VR1. However, moving C5/C6 to the same side of the board seems a little cluttered.

I noticed that you kept the large trace widths between J1 pin1 and J4 pin 1; again another reality is the current along that path. And, I’m taking a second look at your desicions in trace routing. I don’t normally go inbetween MCU pins if I can avoid it.

I have the need for speed…

For production run I’d avoid dual side SMT assembly as much as possible. So keeping SMT components on only one side of PCB seems natural to me.
Routing the trace between MCU pins with currently available PCB technology is not providing any risks (I normally work with solder-mask coated boards, and 6mil spacing is considered normal). With some of my designs I even route a trace between SO8 pins and not have any production issues with that “design feature”. But solid groundplane is a must for me (even if not 100% needed by design).

1 Like

FYI… Regarding the 328P chips and Speed

I like speed, too. And, once upon a time I thought I was getting the Max speed by using external XTL. Then, I did some testing and learned just how foolish my ‘thinking’ was.

Realizing that Arduino loads the chip with stuff specific the Arduino’s syntax and, being a ‘C’ programmer, I coded several approaches for spitting out High/Low on a Port without using Arduino syntax.

I used various ‘C’ and Bit-Bang approaches and a O’scope. So as to not cause extra delay, I added a 1 mico-second delay (not milli-second). {could have used a ‘NOP’, instead).
Also, I use Main/While, instead of Setup/Loop for max speed increase and avoiding Arduino bloating…

Summary of what I learned:
• The fastest the chip will pump out via a Port is 4Mhz. This is consistent with testing many Geeks discover. It’s well documented in Books.

Since it’s been a few years, I loaded a 328p chip (not an Arduino UNO) with examples of code from my Speed-Code and hooked up the O’scope…

Attached is my code - fairly self explanatory: just Uncomment one section at a time and program the chip…

The .INO file attached and Text of the Code (for amusement of others not wanting to bother with Arduino IDE)

Speed_wo_delay_ARD.ino (2.6 KB)

EDIT - Comment out the Delay to achieve 4MHz

The Code
/* Author: B.T.

  • Port speed testing w/o delay. SUMMARY: Binary and Hex are fastest at 3.98MHz
    _BV at 3.98 MHz. Shift is 1.1 MHz. sbi/cbi is 414 kHz.
    RESULTS: At delay=1us, Binary, Hex and BV are the fastest. */
    //-------------------------- DECLARATIONS ------------------------------------
    #include <stdio.h>
    #include <avr/io.h>
    #include <avr/interrupt.h>
    #include <util/delay.h>

#define DELAYTIME 1 // each on, off
#define LED_PIN PINC
#define LED_DDR DDRC
// sbi / cbi function (actuual’s are depricated in C )
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))

#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
//------------------------------- MAIN ---------------------------------------
int main(void) {
LED_DDR = 0x09; // setup output A0, A3 (=C0, C3)
// 0000 1001 = 0 9
while (1) {
// Group 1, binary set/clear Speed Result = 3.95 MHz
LED_PORT = 0b00001001;

        LED_PORT    = 0b00000000;


// Group 2, hex set/clear Speed Result = 3.95 MHz
// LED_PORT = 0x09;
// _delay_us(DELAYTIME);
// LED_PORT = 0x00;
// _delay_us(DELAYTIME);

// Group 3, shift set/clear Speed Result = 1.1 MHz
// LED_PORT ^= ((1 << 0) | (1 << 3)); // A0, A3 (=C0, C3)
// _delay_us(DELAYTIME);

// LED_PORT &= ~((0 << 0) | (0 << 3));
// _delay_us(DELAYTIME);

// Group 4, sbi/cbi set/clear Speed Result = 260 kHz
// sbi(LED_PORT, 3); // A3 (=C3), ≠ multiples
// _delay_us(DELAYTIME);

// cbi(LED_PORT, 3);
// _delay_us(DELAYTIME);

/* Group 5, BV bit set/clear Speed Result:
with &= ~ off: 2.6 MHz, with = ~ off: 3.98 MHz */
// LED_PORT = _BV(0) | _BV(3); // turn on #0 and #3
// _delay_us(DELAYTIME);
// LED_PORT = ~(_BV(0) | _BV(3)); // turn off #0 and #3
// _delay_us(DELAYTIME);
return (0); // never reached
}//end main


You may have forgoten to change some registers:

These lines of code just might change your results if used on Port B:
SPCR |= (1<<SPE)|(1<<MSTR)|(1<<CPOL)|(1<<CPHA);
SPSR |= (1<<SPI2X);

Thanks, but, Not using SPI and if changing to other registers, same results if memory is correct(?).

Really odd thing (perhaps not so odd, given Open Source) is I just updated the Arduino IDE (and foolishly, but intentionally, overwrote/replaced previous old IDE) and, now, all ‘Hell’ has broken loose with old codes and lib’s… (and worse, I hand coded the IDEcolors/etc and now have to Redo it… There’s probably some plugin for it in today’s world…)

I grabbed the posted code from a file bin with many files and I did not review it - I guess I could spend time looking at them but, the point wasn’t ‘to do exactly as I posted’ but, rather use the inference to investigate there are things about Arduino worth having clarity about by exploring code usage via testing…

And, given that Arduino IDE has ‘stuff’ well known for bloating and bogging-down speed, I can’t say that any old code would produce same result as old IDE. Perhaps I shouldn’t have posted it, my mistake…

FYI - Regarding ‘Bloating’ old IDE screenshot below shows amount of Bytes written for both Arduino and ‘C’ syntax when uploaded (turning On/Off the same port/pins)

Please do not foul this forum with “arduino” :wink:

1 Like

Several times, you’ve posted what Not to post - in the end, you reminded me of a Self Anointed police/guru…

But, you won’t need to worry about my future posts, there won’t be any…

Unfortunately, if one wanted to use an ATMEGA328P-PU MCU, mention of “arduino” may not be easily avoided. If it is actually possible to write software to get the same clocks with the crystal removed, then that would promote a change to the design layout of the board.


I did notice @paulvdhs’ post ended with a :wink:

I took it to be a “tongue in cheek” statement of his personal dislike for “arduino”. I doubt he was attempting to be offensive.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.