Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: Advice for SMD board design

  1. #1
    Join Date
    Dec 2010
    Location
    SF Bay Area
    Posts
    782
    Post Thanks / Like

    Default Advice for SMD board design

    OK, so I'm going all-in with my new design. I'm using a new design tool (KiCad), a new uController, new cabling, new pixels, new drivers. What could possibly go wrong?

    Actually, the learning will be fun. I'm going to also move to all (whenever possible) SMD parts. I previously used THT because it was easy, comfortable, and mostly the line drivers were mounted in sockets, so if something had the magic smoke escape I could easily perform a field repair. But that's never happened in 7 years. And they are gigantic. And I have a small board size goal to meet. It's been recommended that I go with 0603 parts rather than the 1206 or 0805 I planned on - so I'll do that.

    I'm still stuck with rather large connectors to get signals off the board. RJ45 are really convenient but really big too. I can experiment with Molex style connectors, but with 64 signal wires to connect, that's a lot of Molex connector pin crimping. And I am *not* going to purchase an official Molex crimping tool at $400, so I imagine it would be an even slower job fussing with a knock-off or a generic crimping die set for my Greenlee/Paladin crimping frame.

    To use the RJ45 jacks I'll need to either surpass my board size goal, or be creative with mounting parts on both sides of the board. Is this feasible with just a 2-layer board, or for all practical purposes does this mean I'll need to go with a 4-layer board? Things that have already occurred me:

    I don't plan to use a reflow oven so I *could* have SMD parts on both sides, I suppose. But I plan to have only THT on the other side.
    Every signal will have to go through (at least) one via, since the drivers will need to be on the opposite (board) side from the connectors. That's how I will meet board size goals.
    In the past I've used the bottom layer as a ground plane and been able to avoid all but a few traces cutting it up. If I have only two layers, I will be really cutting the ground plane up - this is what triggered the idea that I may need to go to four layers. If that's the case, the larger 2-layer board size will still be cheaper than the smaller 4-layer board. I can make it fit in a different enclosure if needed.

    Thoughts, advice? Thanks to the experience board layout folks. I'll be posting the final design for critique before sending out for fab.

  2. #2
    Join Date
    Dec 2011
    Location
    Key West, FL
    Posts
    3,633
    Post Thanks / Like

    Default Re: Advice for SMD board design

    Quote Originally Posted by ags0000 View Post
    I don't plan to use a reflow oven so I *could* have SMD parts on both sides, I suppose. But I plan to have only THT on the other side.
    .
    Toaster ovens work well for smd parts on both sides - just no big ones on the bottom - weight

    The solder paste holds small to medium parts on the bottom - you just need to support the board from the shelf in a way that does not interfere with bottom parts.

    When the top flows - so does the bottom.

    Most connectors are thru-hole - so solder them after you reflow.

    Several videos out there that demonstrate the process.

    If you're not yet set on KiCad - look into DipTrace.

    I purchased Eagle - did not like it, tried KiCad - did not like it either, have been using DipTrace for 5 years now and enjoy it.

    When you are doing your own board design, don't expect to find a lot of pre-made footprints for your parts. They all have the jelly-bean parts but for most of your ICs - expect to make your own footprints, That's the main reason I like DipTrace and not Eagle of KiCad -- too difficult to quickly create footprints.

    If your working with signals over 10 to 20mhz - really consider 4 layer boards - they are not much more expensive.

    You did not say which micro you are planning to use. I suggest breaking away from the hobby micros and use an ARM - available from multiple vendors.

    Hope that helps.
    Link to my DownLoad Site: [B][COLOR=#ff0000][URL]http://www.joehinkle.com/HLS[/URL]

    [/COLOR][/B][IMG]http://joehinkle.com/HLS/HLS%20Logo%20Small.jpg[/IMG]

  3. Thanks ags0000 thanked for this post
  4. #3
    Join Date
    Nov 2013
    Posts
    88
    Post Thanks / Like

    Default Re: Advice for SMD board design

    IMO Some of the standard footprints are fine for reflow but a bit stingy for hand work. I like to elongate the pads to have a little more copper past the end of the "leg". YMMV.

  5. #4
    Join Date
    Dec 2010
    Location
    SF Bay Area
    Posts
    782
    Post Thanks / Like

    Default Re: Advice for SMD board design

    @JHinkle I'm not following on the toaster oven & 2-sided component board reflow. "When the top flows - so does the bottom". That makes sense, so I would expect that when the "other" side is up, the parts will fall off the bottom. Unless your point is that surface tension keeps the bottom parts on (except the heavy ones) even when the paste is flowing.

    As I expected, I'm finding that 80% of my time is spent re-learning a new tool, not designing this (quite simple) board. I did a lot of research and gave consideration to my new design tool. I'm tired of dragging around a machine running Windows, so macOS support was a big benefit. I had become proficient with DesignSpark PCB, but it's clear that will never support macOS, nor wine. I don't even mind running a virtual machine, but hate to give up 10-20 GB from my SSD drive for an OS that I use for one thing only.

    DipTrace was a contender (it does support macOS). I think you may want to look at the recent v4 (or v5 RC) of KiCad. I haven't been a long-term user, but from what I've read it has come a long way in the past 5 years. See here. A big positive for me was to learn that most (all?) of work done by CERN is now on KiCad, and they are funding with dedicated (human) resources to move the project forward. So it will either be an open-source project that won't be deprecated or become obsolete due to corporate M&A and/or market challenges, or it could be yet another abandoned open-source project that no one is paying attention to. The CERN backing gives me hope it will be the former.

    At Oshpark (and I will consider others based on separate posts and replies) a 2-layer board is 2x the price of a 4-layer board of the same size. I have one clock that is running at 50MHz. If a 4-layer board is really needed I can do that. My real question is whether all the vias and cuts to the bottom copper for a two-sided (SMD parts) board make it generally infeasible - particularly for50 or 25MHz signals.

    I'm building a cape for the BeagleBone Black, so it's an ARM micro. But more importantly, I'm using the PRUSS that runs in real time with 5ns instructions. That's where the 50MHz clock comes from.

  6. #5
    Join Date
    Dec 2011
    Location
    Key West, FL
    Posts
    3,633
    Post Thanks / Like

    Default Re: Advice for SMD board design

    Parts both sides - surface tension from solder paste. You can consider putting you caps and resistors on the bottom which really open up the top.

    The purpose of my statement was not to suggest you do put parts on both sides - just to comment on your statement where you suggested reflow at home with parts on both sides was not doable.

    I looked at board pricing a month ago - and based my comments on pricing them (China based suppliers). Checked today and see that 4 layer boards have gone up significantly in price. If your hi-speed design allows - go bigger two sided before 4 layer (determined by hi-speed signal requirements). I had a large board 8in x 6in that was done using 2 layers all during my prototype builds. I ended going into production with that board as a 4 layer board just to be able to route large current traces and stay withing my requirements for board temperatures - the board can supply 64 amps through 16 output ports - all day and stay very cool.

    You can use route back and forth between layers those traces running 50mhz signals - just keep them to a minimum. Watch parallel traces containing hi-speed and low-side signals for coupling. If you are working with a pair of differential hi-speed signals (like an Ethernet pair) - make sure you use your CAD tool for differential pair routing to control impedance and phase shift.

    I suggest you "NEVER" let your CAD tool do auto-routing for you. Learn to route yourself. Route power and ground to your ICs first (keep digital and analog grounds separate and join at one place where you main ground comes into the board), hi-speed signals second (minimum jumping between layers), and finally use the remaining board space for the low-speed or static signals (jumps between layers not a concern - just get them routed).

    If you are looking at selling the board then, will you need FCC approval. If so - then EMI and all kinds of other radiation concerns come into play. I recently finished a FM transmitter board for my EasyLights Pixel controller board and found that controlling EMI on a complicated board can be difficult - I learned a lot getting approval but it also cost a lot of money along the way - paying for a LAB to test your board only to find out it failed FCC radiation requirements - multiple times gets costly.

    Depending on how many 50mhz related ICs you have - putting those in a small FPGA can can really help since they are designed for implementing and routing those types of signals.

    Hope that helps.

    Have fun and keep learning - you're never too old.
    Last edited by JHinkle; 03-04-2018 at 09:07 AM.
    Link to my DownLoad Site: [B][COLOR=#ff0000][URL]http://www.joehinkle.com/HLS[/URL]

    [/COLOR][/B][IMG]http://joehinkle.com/HLS/HLS%20Logo%20Small.jpg[/IMG]

  7. Thanks ags0000 thanked for this post
  8. #6
    Join Date
    Dec 2012
    Location
    Framingham, MA
    Posts
    483
    Post Thanks / Like

    Default Re: Advice for SMD board design

    All my recent boards for the BeagleBone and PocketBeagle (have you looked at the PB?, physically much smaller, but less usable gpio pins (44) and no eMMC or network so you would have to add USB/spi versions of those) have been done in KiCad. That said, I've been using one of the nightlies for KiCad 5 which definitely is better than 4. My F32-B and redesigned Octo's were done in KiCad 4 last year, but the PocketScroller and F8-PB are done in the 5 nightly. When I hit the size limits in Eagle last year, I did look at DipTrace, but I didn't like it. Don't really remember why. KiCad worked much better for me. KiCad does have "hand solder" footprints for most of the SMD sizes which expands the pads a bit. If you are doing the SMD work yourself, probably recommended.


    For the F8-PB, I did go all surface mount, but I also discovered I cannot do it. Thus, I just have Elecrow do the boards and the assembly. Slower, but at least I get boards with the SMD parts actually soldered on correctly.
    Dan Kulp

  9. Thanks ags0000 thanked for this post
  10. #7
    Join Date
    Dec 2012
    Location
    Framingham, MA
    Posts
    483
    Post Thanks / Like

    Default Re: Advice for SMD board design

    Quote Originally Posted by ags0000 View Post
    At Oshpark (and I will consider others based on separate posts and replies) a 2-layer board is 2x the price of a 4-layer board of the same size. I have one clock that is running at 50MHz. If a 4-layer board is really needed I can do that. My real question is whether all the vias and cuts to the bottom copper for a two-sided (SMD parts) board make it generally infeasible - particularly for50 or 25MHz signals.

    I'm building a cape for the BeagleBone Black, so it's an ARM micro. But more importantly, I'm using the PRUSS that runs in real time with 5ns instructions. That's where the 50MHz clock comes from.
    I'm really curious about your use case and how you managed to get everything synced (or if that matters). The only way to get 50mhz from the pru is using the r30 registers. That's certainly fine (and what I do for DMX and PixelNet), but it does limit you to 8-10 outputs from each PRU. It also really limits data going in/out of the PRU which is a completely separate topic. Once you reach the r30 limit, you have to write to the gpio addresses, and there are significant and relatively unpredictable delays to do so (particularly for GPIO0, the other 3 gpio's aren't nearly so bad). Thus, there really isn't a way to synchronize the outputs on the GPIO's with any type of signal on the r30 outputs.

    Anyway, I'd love to hear about any workarounds or issues you've run into. The one that constantly annoys me is the gpio0 delays. We're talking 50-100 clock cycles on the PRU. For ws2811 pixel protocols, that's a big problem. I've been able to reduce the issue by eliminating some of the main CPU idle states, but that's obviously at the expense of power usage and is still not 100%. I've considered building my own kernel to completely remove all the power management stuff, but that's been a fairly low priority at this point.
    Dan Kulp

  11. #8
    Join Date
    Dec 2010
    Location
    SF Bay Area
    Posts
    782
    Post Thanks / Like

    Default Re: Advice for SMD board design

    @dkulp I'm using the KiCad 5 nightlies too - though I see they've just released RC1. I'm using a BBBW and need to have access to 10 PRU outputs (from the same PRU) so I think I'll stay with the full-sized version. I hope I've not set myself up for a headache by going with the 0603 parts (with hand-solder footprints). I guess the only way to know for sure is to try it.

    For your Octoscroller remake, did you go with IDC connectors/cables? I'm still fussing with how to get 8 sets of 4 signals from a centrally-located controller to "satellite" enclosures with power supplies. I'll need to run the signals about 8' from the controller. Currently I'm thinking of pairing each signal with ground in a twisted pair in Cat5/6 cable. Even though they are not balanced signals, my hope is the twisting schedule and not having two different signals in a pair will be OK. The problems I'm trying to resolve are:

    1) the RJ45 jacks take up a lot of space on the controller board
    2) Molex-style connectors are much smaller, saving board space, but then I have to crimp a bunch of pins by hand - at least on one end of the cable
    3) I thought of using IDC cable, making termination really simple. But the cable doesn't seem to be meant for being exposed in weather, and I'm not sure of the signal integrity impact - even if I use 8 conductor cable with each signal line physically separated by a ground line.
    4) I really only need one ground in each bundle, as a reference to tie the power supply ground to the same level as the ground on the controller board. Running 4 per cable won't hurt, but I'm not sure if it really will do me much good.

  12. #9
    Join Date
    Dec 2012
    Location
    Framingham, MA
    Posts
    483
    Post Thanks / Like

    Default Re: Advice for SMD board design

    You can get exactly 10 outputs from PRU0 on the PB:
    Code:
    	P1_29_INFO="pru0_in7 default gpio3_21 gpio3_21 gpio3_21 gpio3_21 eqep0_strobe pru0_out7 pru0_in7"
    	P1_31_INFO="pru0_in4 default gpio3_18 gpio3_18 gpio3_18 gpio3_18 eqep0a_in pru0_out4 pru0_in4"
    	P1_33_INFO="pru0_in1 default gpio3_15 gpio3_15 gpio3_15 gpio3_15 spi1_d0 ehrpwm0b pru0_out1 pru0_in1"
    	P1_36_INFO="ehrpwm0a default gpio3_14 gpio3_14 gpio3_14 gpio3_14 spi1_sclk ehrpwm0a pru0_out0 pru0_in0"
    	P2_24_INFO="gpio1_12 default gpio1_12 gpio1_12 gpio1_12 gpio1_12 eqep2a_in pru0_out14"
    	P2_28_INFO="pru0_in6 default gpio3_20 gpio3_20 gpio3_20 gpio3_20 eqep0_index pru0_out6 pru0_in6"
    	P2_30_INFO="pru0_in3 default gpio3_17 gpio3_17 gpio3_17 gpio3_17 spi1_cs0 ehrpwm0_synci pru0_out3 pru0_in3"
    	P2_32_INFO="pru0_in2 default gpio3_16 gpio3_16 gpio3_16 gpio3_16 spi1_d1 ehrpwm0_tripzone_input pru0_out2 pru0_in2"
    	P2_33_INFO="gpio1_13 default gpio1_13 gpio1_13 gpio1_13 gpio1_13 eqep2b_in pru0_out15"
    	P2_34_INFO="pru0_in5 default gpio3_19 gpio3_19 gpio3_19 gpio3_19 eqep0b_in pru0_out5 pru0_in5"
    Only get 6 off of PRU1.

    For the Octo, I pretty much kept it exactly the same, I just redid the pinouts. The wireless on the BBGW consumes a bunch of pins including ALL of the pins for address lines on the original Octo. Thus, the redone octo moves a bunch of pins around to use the stuff that is available on all the BeagleBone deriviatives. Plus, it groups things better so we don't need to output all 4 GPIO's if you only use a few outputs. From a cable/signal perspective, it's exactly the same.

    The PocketScroller is a little more interesting. For that, I put all the "control" lines on the pins that can be r30 controlled. Thus, I can do the address outs and latch and such without writing to the GPIO's. I was hoping that would help, with refreshes and such, but due to the async nature of writing to the GPIO's, I actually have to READ from the GPIO prior to doing the r30 stuff. That somewhat diminished the benefit I was hoping to achieve. That said, it almost completely removes the ghosting we were seeing.
    Dan Kulp

  13. #10
    Join Date
    Dec 2010
    Location
    SF Bay Area
    Posts
    782
    Post Thanks / Like

    Default Re: Advice for SMD board design

    On BBB (&BBBW) there are 10 PRU_0 I/O available, and 11 PRU_1 I/O (by disabling HDMI - but not eMMC). I didn't want to deal with synchronizing the two PRUs so I'm just using PRU0. I am able to use only the direct PRU I/O for high speed signals. I use GPIO for things like reset and output enable - things to setup/teardown the (on-cape) system but not used during actively sending pixel data. Without any mods to the kernel, I can get precise timing out of the PRU that way, with no sensitivity to contention for any shared resources (mostly memory or memory-mapped registers like GPIO). I will some day experiment and see what impact it would have if ARM processor was trying to access the PRU DRAM while I was accessing it with the PRU. My guess is there would be possibility for stalls there since it then becomes a shared resource, even though separated from the ARM core by the OCP Slave port. Currently I have only one userspace process interfacing with the PRUSS, and it is obedient to the signals from the PRU, waiting to be given the ready signal before an access occurs. My design is very purpose-built, nothing like the flexibility of the FPP/BBB work you do. I think you can drive more pixels also. My design is inflexible and drives 8k WS2811 pixels at 50Hz refresh, so I can make a lot of constraining decisions that you probably can't. But it is rock-solid (as long as I can figure out the cape design with a 50MHz signal on it).

    I was really surprised when I first looked at the original Octoscroller source, and found that it was using all GPIO lines. I really don't know how it worked reliably at all.

    Back to your BBB work - did you consider making any changes to the connectors/cables, or leave it as-is ("if it's not broke, don't fix it")? Things I've been wondering are along the lines of:

    * How fast are the signals going down the IDC ribbon cable?
    * Any issues with signal integrity?
    * Any steps taken to shield them (e.g. separating with a ground wire between each adjacent signal line)
    * Is it reasonable to have the ribbon cables (but not the connectors) exposed to the weather, or are they always in an enclosure (like a P10 panel box)?

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •