Need a creative mind... - Page 1
Forum section: electronics / projects

author: MarkF
author_rank: Super Contributor
timestamp: November 06, 2015, 07:29:31 am
content: I have 10 signals that I've not able to route. Can anyone meet the challenge?This board interfaces with 3 other boards and designed to be stackable like the Arduino shields. So, none of the headers can move and the board size must remain the same size. In addition, I don't want to go to 4 layers.Good luck.

author: ataradov
author_rank: Super Contributor
timestamp: November 06, 2015, 07:49:12 am
content: It is hard to do without CAD files, but it does not appear to be hard at all. There is plenty of space to route everything:1. Rotate Q2.2. Bring out all the signals from PICs to the corresponding left and right area in the blue layer.3. Drop them down to Q1 and Q2 in the red layer.It is hard to trace from rats nest, but it looks like you may need a few weird layer transitions, but there is plenty of space to do that and it is not like you are routing high speed signals.

author: MarkF
author_rank: Super Contributor
timestamp: November 06, 2015, 08:00:24 am
content: Quote from: ataradov on November 06, 2015, 07:49:12 amExactly. I've not been able to do that while still maintaining the power and ground pours for each chip.I'm using DipTrace if you'd like to give it a try.

author: ataradov
author_rank: Super Contributor
timestamp: November 06, 2015, 08:10:26 am
content: What's wrong with breaking the pours? It is nice to have them, but if you can't route the traces, pours will have to go.The routing and placement in general looks messy and can be optimized a bit.Attach the PCB file if you can. I can't guarantee that I'll do it, but someone else might. The board has plenty of space, it should not be that hard to route it in 2 layers.

author: ataradov
author_rank: Super Contributor
timestamp: November 06, 2015, 08:12:42 am
content: For example, is there a reason why pin 8 of the PICs is routed in red so it could jump to the blue layer?I would try to move U6-U15 up a bit, and move Q1 and Q2 parallel to the connector. Prevailing direction will be vertical, it all will go into one layer. After that, sort out horizontal stuff.

author: MarkF
author_rank: Super Contributor
timestamp: November 06, 2015, 08:29:13 am
content: Quote from: ataradov on November 06, 2015, 08:12:42 amI have attached the CAD file to my first post.Pin 8 is one of two grounds for the PIC. It's jumped to the top layer in order to jump the 10MHz clock and connect to GND. Also, the 5V needs to travel between the PICs in order to provide power to U6-U15.I originally intended to socket the chips if I couldn't get everything routed. And I have a bunch of 20 pin sockets. The PICs have to be socketed so I can remove them for re-programming if the need arises.I think what you are missing here is that ALL power and ground for the chips is done via the copper pours.

author: ataradov
author_rank: Super Contributor
timestamp: November 06, 2015, 08:33:10 am
content: Quote from: MarkF on November 06, 2015, 08:29:13 amBut ultimately this pin ends up connected to the blue layer. Why jump anywhere? Why not just connect it to the blue layer?

author: MarkF
author_rank: Super Contributor
timestamp: November 06, 2015, 08:36:50 am
content: Quote from: ataradov on November 06, 2015, 08:33:10 amThere is NO direct path to the blue area. The blue areas on each side the pin 8 are islands.

author: ataradov
author_rank: Super Contributor
timestamp: November 06, 2015, 08:39:02 am
content: Ok, I see it now. Yeah, routing by looking at the image is hardIt is late now, I'll see if I have time tomorrow to play with it.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: November 06, 2015, 09:05:17 am
content: Route signals and VCC while mostly ignoring GND. Finish up with GND pour on both sides, stitching to ensure connectivity and good EMI performance. Push and reroute traces as needed to shorten GND paths / save on stitching.The horizontal-vertical bias you've already got going should be trivial to follow to route the remaining traces.Tim

author: fcb
author_rank: Super Contributor
timestamp: November 06, 2015, 09:16:31 am
content: Quote from: T3sl4co1l on November 06, 2015, 09:05:17 am+1

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 06, 2015, 10:01:19 am
content: Lose the power pours. As long as you have local decoupling they're simply not necessary5 PICs? Seriously? hard to see why this would be anywhere close to necessary - remember 32 bit PICs with 256K flash and 64K RAM are available in DIPCombine the LM358's into LM324's

author: MarkF
author_rank: Super Contributor
timestamp: November 06, 2015, 12:49:41 pm
content: Nice to see you again Tim. This is a continuation of my model railroad interface.I've been hanging onto those copper pours for power and ground routing. They have really been holding me back. I my own defense, this is my very first PCB design.Quote from: mikeselectricstuff on November 06, 2015, 10:01:19 amIt's not the processing power of the PICs that is the limiting factor. It's the pin count to do the I/O and communicate to the master processor. Although each PIC is updating the analog outputs at a little over 25 KHz.

author: Kalvin
author_rank: Super Contributor
timestamp: November 06, 2015, 01:24:38 pm
content: Use some 0 ohm (smd or through-hole) resistors to help routing.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 06, 2015, 01:54:17 pm
content: Quote from: MarkF on November 06, 2015, 12:49:41 pmPICs are expensive bus expanders - shift-registers on SPI will give all the outputs you need much cheaper. Or just use a PIC with a more appropriate pin count.

author: eneuro
author_rank: Super Contributor
timestamp: November 06, 2015, 03:31:53 pm
content: Quote from: MarkF on November 06, 2015, 12:49:41 pmUse genetic alghorithms, to check for any existing solution, but probably forgeting about this project for a few days will be easier and it will let you find better design with another components

author: nctnico
author_rank: Super Contributor
timestamp: November 06, 2015, 03:50:52 pm
content: I'd adhere more strictly to having all traces vertical on one layer and horizontal on the other. This way you can route power in a grid and have a decoupling capacitor at the intersection. This way each chip is powered from 3 or 4 directions. However, if you use one microcontroller things will be much easier. Using more than 1 microcontroller on a board is a tell tale sign things will go very bad because making them work together is much more difficult than it looks. Seen it happen lots of times!

author: MarkF
author_rank: Super Contributor
timestamp: November 06, 2015, 04:10:47 pm
content: The main function of the PICs is to generate a PWM signal to drive the HO railroad locomotives:Below a set-point, the PIC generates a 200 Hz PWM waveform with 128 steps for slow speed start,Above the set-point, the PIC outputs a DC voltage so not to heat up the motors,The initial set-point is 4 volts. I hope to use the same set-point for all my locomotives. I still need to flush out each locomotive with different numbers of cars.There is a periodic sync pulse (every 10 sec) and the common clock for all 15 PICs to keep the PWM signals in sync with each other. The PWM is generated by an interrupt and control is done by polling the master microcontroller. This has been a major concern but something I can't really address until everything is tied together.The secondary functions are to reverse direction via a relay and sense a short circuit on the track. In total there could be a max of 3 analog boards controlling 30 blocks (sections) of track. Each PIC communicates to a master microcontroller which interfaces to a laptop to tie everything together. There are 3 other boards: the master controller with USB interface, the relay driver board for turnouts and layout lighting, and the sensor input board to monitor track conditions (i.e. the location of locomotives and rolling stock cars)As for parts: I have all the PICs, DACs and Op-amps on hand. This board has to make do with what I have.Also, the software for the PIC16F876 is already written and tested.Here is a picture of the layout. At last count there are about 22 different blocks needing PWM/DC voltage, direction control and short circuit sensing.Edit.The interrupt service routine is called at 15.6 KHz and generates a 120 Hz / 128 step PWM. The sync pulse is polled at the beginning of the interrupt (every 8 ms). A 20 ms sync pulse should be more than enough to guarantee a sync and reset the PWM step count to zero. Sorry, they say your memory is the first thing to go.

author: macboy
author_rank: Super Contributor
timestamp: November 06, 2015, 08:40:43 pm
content: Consider the current path for decoupling caps C1-C5. Draw a line from the Vdd pin, into power plane, through the cap, into the ground plane, and back to the Vss pin(s). How big is that loop? The general wisdom to "place decoupling caps close to the device" implies a short path to the power pins. Your caps are right next to the PICs but is your current path short?

author: T3sl4co1l
author_rank: Super Contributor
timestamp: November 06, 2015, 09:55:43 pm
content: Quote from: MarkF on November 06, 2015, 12:49:41 pmYeah, that's tempting but it screws you over much more than it helps (as you're finding). Multiple net pours are fine for multilayer, but aren't practical in just two.Inevitably, you have to have tracks crossing, in a 2 layer design. If it's not signal traces (use LOTS of vias, making it look like the buses of signals are going out of their way to allow huge expanses of VCC/GND fill), it's for VCC/GND (so you have annoying little jumpers every so often, stitching one layer around a trace cutting through it).So having GND fill, and routing VCC and signals as traces, is much more practical. You probably get better overall performance (and by that, I mean for signals and harmonics extending into the 100MHz+ range, where it actually matters -- slow logic hardly cares, functionally speaking). Note that includes using local bypasses on the supplies, which is probably better than depending upon two relatively distant (~0.062", say?) pours to do it.It's practical to use about half the layers for supply nets. So, you can do GND one side, VCC and signals the other, with as few back side connections as possible, and single side component placement of course (preferably SMT so nothing even pokes through the back side). It makes more sense for N > 2 (i.e., a 4 layer board can have a proper pair of nets).And while you can have even more signal layers in denser boards, it's still worthwhile to alternate or pair signal and ground layers so that this proportion remains about constant. You get even better supplies, you can have more of them (and in an 8 or 12 layer board, say, you're probably going to need all of them!), and you can route a whole lot more signals (which was probably the point, as you'd probably be doing BGAs on both sides for this many layers).Cheers,Tim

author: KL27x
author_rank: Super Contributor
timestamp: November 07, 2015, 01:35:21 am
content: Quote16F1947 - PK2 approved.Not stalking you, lol. Just happened to notice this post.

author: ataradov
author_rank: Super Contributor
timestamp: November 07, 2015, 10:10:28 am
content: Here is my attempt. This is not intended to be a final design, just an illustration. The routing is messy and grid alignment is not perfect in many places.I did not do copper pours, but all supply lines are routed. I just don't want to spend a lot of time on this board.Routing can be improved vastly if you move some components around, I tried to keep original layout as much as possible.I did not route pull-up resistor assemblies, you will see why. It is better to reassign the resistors between the pins. It will make schematic a mess, but will layout way better.I don't know specific EMI considerations for this project, so I was routing for a reasonably low nose environment.

author: nctnico
author_rank: Super Contributor
timestamp: November 07, 2015, 12:03:13 pm
content: If what you need is PWM then why not use LED drivers? These also use PWM! Besides that an ARM controller has enough pins and processing power to generate a boat load of low frequency PWM signals (even through shift registers if you want) AND control the tracks. This whole setup can be made so much simpler!

author: MarkF
author_rank: Super Contributor
timestamp: November 07, 2015, 02:10:30 pm
content: A few responses:mikeselectricstuff, AcHmed99 and KL27x:The PIC16F1947 would be a major design change this late in the game. It will take me some time to study in order to determine if it would meet my requirements. There's a lot to consider with a MCU that I'm not familiar with. Plus with a large SMD chip like that, I have no way to run any sample code until I have the boards made.nctnico:I'm NOT generating a pure PWM signal to control the locomotive speed. I only use PWM at slow speed and start up. At some voltage set point, I will switch to a DC signal. Hence, the DACs.ataradov :Thanks for all your time. I downloaded your CAD file and will check out what you came up with over the next few days.blueskull:I'm trying to stay with a 2 layer PCB because my DipTrace license only supports 2 layers.AcHmed99:I currently only have a PICkit 2 because I haven't needed anything more. I do have a device file that contains the PIC16F1947 but have never used it. I'm not opposed to getting a PICkit 3 if I need one. I just need to do the research on this bigger MCU. There's a lot of risk when trying to generate 10 PWM signals with 64 steps at 120 Hz. The PIC16F876s I already had and it only took me a day or two to write the code and check the timing both for the PWM and the communication with the master MCU.

author: Ian.M
author_rank: Super Contributor
timestamp: November 07, 2015, 04:30:44 pm
content: As you can see, most of us certainly wouldn't go down the same road developing this project. However, for a one-off, or at least very small volume production, a lot of the suggestions to use a better chip and cram more functionality into it are not particularly helpful.You have a PICkit 2 and a fully set up development environment you are famliar with. To use Microchip's latest and greatest chips, you'd need to spend approx $50 USD on a PICkit 3 + however many days it takes to get the current MPLAB X set up and working. There's also the risk that you will be one of the few unlucky ones and will end up having to find a different PC because for some nebulous and inscrutable reason it isn't stable (or plain doesn't work) on your current one. Saving a few bucks on a couple of tubes of chips + having to take the time to learn a new processor core just doesn't make sense, especially when you already have stock in hand. Upgrading is an investment in the future, not this current project.However, your board is over-complex. Given a 20MHz clock, a PIC16F876 can produce a 19.5KHz 10 bit hardware PWM. The lowest PWM frequency it can do directly is with the same clock is 1.2KHz, but if you diddle with the PWM registers in the Timer 2 ISR, you can skip cycles with the output either '1' or '0' so with a six cycle counter in the ISR, and a bit of code you could generate the 200Hz low speed PWM mostly using the hardware PWM. The only extra complication would be switching in and out a low pass filter when you transition between fast PWM to generate an analog voltage, and slow PWM. You can actually do that directly by returning the filter cap's ground leg to a PIC I/O pin rather than ground. Set the pin low to connect the cap and enable low pass, set it as input(hi-Z) to disconnect it and disable filtering. That gets the part count down to two chips per channel.Next, make each channel *ENTIRELY* self-contained, so adding another channel is simple copy/paste. That means ditch the ULN2003 chips and replace them with sensitive gate MOSFETs. You will need clamping diodes as well but those are best fitted across the relay coils, not at the driver. For the same reason, move the channel address decoder to the top left of the board so its outputs can run across the board near the other horizontal tracks and enter the channel module block at the same relative location. Reallocate PIC pins to make these hanges happen.As others have suggested, stitched ground fill both sides and local 0.1uF decoupling for both the PIC and the OPAMP, and use individual pullups withon each channel and just about all your routing problems should simply go away.How I would have done it, constrained by a PICkit 2 debugger for development:There is no need to be running high speed clocks over iboard to board interconnects. That's a potential EMI nightmare. Each board with PICs on it would have its own 20MHz crystal clock. The first PIC would have the crystal and the others would have a daisy-chain clock running from OSC2 (out) to OSC1 (in). You don't need to sync the PWMs and in fact its an advantage not to as if they are synced it increases the stress on the PSU.I wouldn't have used a parallel data bus. I would have used a one wire logic level serial bus using RS232 framing, probably at 19.2Kbaud (but check the data transfer rate needed) by connecting a Schottky diode between TX and RX to effectively make the TX pin open drain so all the channels can share a bus with a simple pullup. /MCLR reset to all devices (as you have) for initialisation and emergency stop. To identify each chip, there would be a daisy-chained ID line from each PIC to the next, with a pullup between chips. It would be set to '0' by the master at the first chip's input side. When /MCLR is released, if the ID_in is high, the PIC loops waiting for it to go low. As soon as it goes low, the PIC waits for the master controller to send it an address. It acknowledges, sets its ID_out low stores that address and responds only to commands prefixed with that address from then on. The master then sends the next address to the next PIC in the chain. When the master sends an address but doesn't get an acknowledge, it knows all the PICs have been enumerated.Each PIC only replies in response to a command from the master. The master can send a break on the line to end a command and reply prematurely if it needs to free the bus. Therefore one doesn't have to worry about bus collisions.lI *MIGHT* wire-or an 'attention' (IRQ) iine back to the master so each PIC can urgently report fault conditions. To do so, when the master receives the attention signal, it would set the ID line high, All the PICs pass along the ID line change as soon as possible. If a PIC has signalled for attention, it reports with its address and the fault code before passing the ID line change along, and releases the attention IRQ line. Once the attention IRQ goes high the master knows all reports have been received, sets ID low again and business as usual resumes. As the comms is in a format that can easily be generated by a PC, I don't need to write the master code to test all the slaves, but can start testing with a terminal program on a PC that lets me manually control the handshake lines.I'd use PIC16F886 chips, they are 1/3 the price of PIC16F876 and less than half the price of PIC16F876A. As all these chips have two hardware PWM modules (but only one PWM timer) After the initial one channel prototype had been fully tested, I'd have reworked the code to put two channels in one PIC, with a quad OPAMP for the filter/buffer to get it down to one chip per channel. Each PIC would have two addresses, and from the master's and motor drive board's viewpoints would be indistinguishable from a daisy-chained pair of single channel PICs.All code would be written in C for easier portability to different PICs and much better maintainability than MPASM assembler. Data structures would be in a header shared with the master PIC (if present) and PC application source code.If you *did* want to go to mass production, then upgrading to a PIC16F1xxx part with more PWM channels, and putting the output stages, relays and a 5V regulator on the same board as the PIC so you have one board that has all you need for somewhere between four and six channels makes sense. That would be a 4 layer surface mount board, prototyped with interior power/ground planes for ease of hack and patch rework but respun with interior signals and exterior planes to reduce EMI before production.

author: nctnico
author_rank: Super Contributor
timestamp: November 07, 2015, 05:55:45 pm
content: Quote from: Ian.M on November 07, 2015, 04:30:44 pmI've been down that road a couple of times and learned that it often takes less time to use a better suited chip than trying to contort a part you have into doing something special (even though it doesn't look like you want to do something special at first glance). It really helps to avoid the 'if you only have a hammer then everything looks like a nail' way of thinking. Projects are much more fun which the right parts because it will be easier to work on and finished quicker. The problem posed in the first post makes my point! Food for thought

author: MarkF
author_rank: Super Contributor
timestamp: November 18, 2015, 10:29:08 pm
content: I finally was able to route the analog PCB (RR-AO.png). It's not pretty but I was able to make all the connections.The OVERVIEW.png shows all six board types. There will be one RR-USB PCB that controls all of the I/O and it supports up to three of each of the other large boards (10 PCBs in total). I originally intended to stack them with stackable headers used for the Arduino Shields. However, the PICs will need to be in sockets so that I can re-program them. The PCBs will be stacked about 1" to 1.5" apart to allow for the sockets. I've decided to connect them with ribbon cable with multiple drops like parallel disk drives and floppies in old PCs. The RR-USB board has one column of each J1 and J2 for the address and data buses grounded (i.e. every other pin in the ribbon cable will be ground).The two small PCBs are the drivers for the layout. There could be up to 30 of those.Any thoughts "if" or "what" line termination I might need for the address and data buses?

author: MarkF
author_rank: Super Contributor
timestamp: November 22, 2015, 04:40:47 am
content: I thought some of you would like to see the DipTrace 3D visualization.

author: Kalvin
author_rank: Super Contributor
timestamp: November 22, 2015, 11:05:22 am
content: Quote from: MarkF on November 18, 2015, 10:29:08 pmYou PCBs look really nice! I don't think that you need terminations for the address and data buses. It typically doesn't matter if the address or data buses ring little until they settle for the final logic level (the ringing may cause crosstalk interference to any control signal traces running in parallel at close proximity, though). The control signals like Clocks, Read, Write and Address Strobe need to be well-behaved and may require some termination. A simple series termination at the driving end of the PCB trace is often sufficient. If the series termination is not enough or the impedance is not well controlled, you should be able to use a simple Schottky diode clamp termination at the receiving end of the trace. You can improve signal integrity by selecting a logic family/devices which have slower signal rise/fall times and which doesn't have the most powerful bus drivers available.