1
\$\begingroup\$

I have a MCU board with a number of GPIO pins that I'm connecting to some peripherals, sensors, etc. I would like to place and autoroute these in Eagle.

In firmware, it's easy to re-assign any pin to any purpose. However in the Eagle schematic, I must "hard-wire" each connection. The Eagle autorouter then gets tied in knots trying to connect the exact pins I specified. (Whereas in reality, switching GPIO "4" and "5" for example, is an equally valid route, just a small software change.)

Is there any way to give Eagle a set of GPIO source pins and destinations, and let it route 1-1 connections between any two pairs such that it gets an optimal solution? Hack solutions welcome :)

\$\endgroup\$
  • \$\begingroup\$ Your question may seem reasonable on its surface, as it doesn't feel like it would be that difficult for a human to do. But for a computer, the number of iterations it would require to find an optimized solution would be astronomical. For any more than a few traces, you'd need a server farm's worth of processing power to solve it in a reasonable amount of time. \$\endgroup\$ – Dan Laks Aug 1 '16 at 7:28
  • \$\begingroup\$ Not true, because you don't need to search the entire solution space, nor do you need the absolute best solution. The number of possible routes is n! where n the number of pin-pairs. This is only "astronomical" if you decide to compute every possibility. With a brute-force approach, even auto-routing itself is not viable. (i.e. n-layer board with m pins has n^m of possible routes given that each pin can be routed in any signal layer). You only need a solution good enough for all "flex" pins to route. I think it could be feasible on a PC for around ~8-10 GPIO's, which is a useful feature. \$\endgroup\$ – Ismail Degani Aug 1 '16 at 23:16
3
\$\begingroup\$

No. The auto-router cannot change which pin is connected where.

Very few things in the layout editor are allowed to back annotate the schematic. This is a safety feature to prevent the schematic getting modified without you specifically going and doing so. The last thing you want is for the autorouter to start wiring things up differently from the schematic...

The solution is to let it tie itself up in knots, and then once it is done, manually make the required changes to untangle the knots. The autorouter is not a be all to end all. It is a tool to help with the routing, yes, but it is up to you as the designer to clean up after it and ensure the traces go sensible places and are reasonable thicknesses (etc.).


Furthermore, swapping GPIOs is not always straight forward. You might require hardware serial or SPI interfaces. These are typically on fixed pins. How is the autorouter to know that. Maybe in a different design you don't need the SPI and are free to swap those pins around, again how is it to know that. If it is the same library symbol, it couldn't tell between different designs how flexible you are with pins.

\$\endgroup\$
  • \$\begingroup\$ On Cortex M3s, and many more platforms, peripherals can be mapped to a variety of pins and pin combos \$\endgroup\$ – Scott Seidman Jul 31 '16 at 23:26
  • \$\begingroup\$ @ScottSeidman while true, it doesn't change the fact that having the autorouter autonomously change the pins and schematic is a bad idea. \$\endgroup\$ – Tom Carpenter Jul 31 '16 at 23:46
  • \$\begingroup\$ @TomCarpenter Why is changing schematic pins any worse than vanilla autorouting? Presumably Eagle wouldn't "autonomously" change pins -- rather it would simply present the proposed pin changes as another routing option. In other words, you're just giving the autorouter another dimension of flexibility to search for solutions. \$\endgroup\$ – Ismail Degani Aug 1 '16 at 23:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.