Author Topic: EEVblog #975 - Human vs Autorouter  (Read 12459 times)

0 Members and 1 Guest are viewing this topic.

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 11969
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #975 - Human vs Autorouter
« Reply #50 on: March 01, 2017, 06:14:24 pm »

a simple 8 bit shift register can drive two nixies.
so one 'module' would be one 8 bit shift register, two 74142 and an array of HV drivers. it would be a nice compartimentalized module ready for cloning. you could even use an i2c io expander instead of a shift register.
drive two nixies directly from an i2c bus.


The way I'd have done it :
Route one nixie to a line of 10 pads, whichever way is easiest for layout. Repeat for each digit.
Route one driver to a line of pads, whichever way is easiest for layout. Repeat for each driver, spaced at 8/10ths of the nixie spacing.
Route the pad rows together in order, then delete the pads.

Easy to route, and easy to re-use if you remember to save a copy of the nixie+pads and driver+pads.

The mapping from drivers to nixies is consistent so you only need to do mapping for one digit. You can treat the whole display as a string of bits, ten per tube, all shifted out to the drivers.
If there are any unused outputs, have them at the far end so you don't need to worry about padding.
 
If your hardware supports 10 bit SPI, even simpler, If not, bit-bash it as speed isn't going to be an issue, and probably simpler than merging the 10-bit values together to form whatever word size your SPI port likes, but you could easily do the latter if you wanted.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7211
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #975 - Human vs Autorouter
« Reply #51 on: March 01, 2017, 06:19:54 pm »
So you'd increase the chip count and use obsolete parts for the sake of a few bytes of lookup table?  :palm:

Then why use obsolete nixies in the first place ????
nixies and nixie drivers and 74142 all belong to the same era : the dark ages.

i'd sod all of them and replace all of that with a supertex hv driver.

one plcc44 drives 3 nixies directly. 8 nixies would be driven by 3 chips. simple.

actually the whoel nixie bang can be driven by one chip  : HV57009
that's a 96 bt hv driver shift register.
there is even an128 bit version. but that is a BGA ...

« Last Edit: March 01, 2017, 06:25:48 pm by free_electron »
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 11969
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #975 - Human vs Autorouter
« Reply #52 on: March 01, 2017, 07:29:58 pm »
nixies and nixie drivers and 74142 all belong to the same era : the dark ages.
The obsolete thing was just an aside - this was a more general argument about use of parts and PCB layout - the same arguments could just as easily apply to LED displays or arrays of mechanical actuators etc.



Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: digsys

Offline EPTech

  • Regular Contributor
  • *
  • Posts: 157
  • Country: be
    • EP Technical Services
Re: EEVblog #975 - Human vs Autorouter
« Reply #53 on: March 01, 2017, 07:40:08 pm »
Hi all,

I have always done manual routing. I never took the step towards autorouting because I always assumed that the time it would take me to, properly set it up, tweak the rules and relaunch the autorouter for who knows how many iterations, would come close to the time it would take me to route the PCB myself. I do like that you can define some basic rules that help you real-time with manual routing. When I used to route PCB's with Ultiboard 5.72, you had to route first and then launch the DRC, solve the issues and rerun DRC, and so on, until no more DR errors were flagged.

Happy routing.

Kind greetings,

Pascal.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 8907
  • Country: us
Re: EEVblog #975 - Human vs Autorouter
« Reply #54 on: March 01, 2017, 07:53:50 pm »
Because nixies look cool. In most cases I don't care what the drivers look like, and if I were going to use 74142's I'd build the whole clock out of period correct devices.

There are lots of simple ways to easily and reliably drive a bunch of nixies. They may not fit your idealistic obsession with identical subsections that can be cloned but who cares? The code is trivial regardless of how it's wired. Once you've written the code, it can be reused as many times as needed. Hardware costs money, the goal is to simplify hardware and it's ridiculous to make the hardware more complex just to make the code a little simpler. A string of 74HC595s is cheap and works great when coupled with HV transistors or integrated driver ICs. There also are some HV shift registers out there designed for driving VFDs that can be used. Those Supertex drivers do work well but unless you get them as samples they're somewhat hard to find and relatively expensive, and internally they're the same as a string of 74595's with HV transistors on the outputs.

Whatever the hardware looks like, you're still working with groups of 8 bits in software. I can whip up a lookup table in about 5 minutes that will work with any wiring layout you want and the whole clock code fits in an AVR with 2K of flash with loads of room to spare. The whole point of using a microcontroller is that all the heavy lifting can be done in software and the hardware can be greatly simplified over what would be required to use jellybean logic.

« Last Edit: March 01, 2017, 07:55:46 pm by james_s »
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1075
  • Country: nz
  • Currently at SiFive, previously Samsung R&D
Re: EEVblog #975 - Human vs Autorouter
« Reply #55 on: March 01, 2017, 10:20:00 pm »
Why on earth not do the pin swapping? It would have made the routing so much easier and obvious it would probably have been faster in total. Could have spent some time doing a super neat "fanout" of one nixie tube and then copy pasted that. It would have looked tidier, there would be more room for clearances, the signal paths would have been more similar (not that it matters), and I would believe doable without a single track on the back.

You don't get something for nothing. Pin swapping means you have to spend more time and effort coding compared to having all the segments in sequence.
Also, might have been faster on the PCB, might have not, you don't know.

The extra coding amounts to one global array mapping the pretty pin number to the physical pin number, and one extra memory reference to look it up every time you want to set or clear a pin. Have you got ... what? ... 80 bytes of memory to spare?

 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1075
  • Country: nz
  • Currently at SiFive, previously Samsung R&D
Re: EEVblog #975 - Human vs Autorouter
« Reply #56 on: March 01, 2017, 11:00:38 pm »
why not simply use channel design. route one tube and clone the rooms ?
10 channel nixies, 8 chennel drivers.

so: bad electrical design. should have used 10 channel drivers.  now the software is also going to be a mess to control this. why not make a proper single tube drive module.

Why is the software a mess?

Something like this:

Code: [Select]
#define NUMDIGITS 8
 #define NUMDRIVERS 10

byte prettyToPhysPin[] = {..., }; // 80 entries, according to routing layout

byte display[NUMDIGITS];

void outputDisplay(){
  byte pinOutData[NUMDRIVERS];
  for (int i=0; i<NUMDRIVERS; ++i) pinOutData[i] = 0;

  for (int digit=0; digit<NUMDIGITS; ++digit){
    int physPin = prettyToPhysPin[digit*10 + display[digit]];
    pinOutData[physPin/8] |= (1<<(physPin%8));
  }

  digitalWrite(latchPin, LOW);
  for (int i=0; i<NUMDRIVERS; ++i)
    shiftOut(dataPin, clockPin, LSBFIRST, pinOutData[i]);
  digitalWrite(latchPin, HIGH);
}

Easy peasy.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 8907
  • Country: us
Re: EEVblog #975 - Human vs Autorouter
« Reply #57 on: March 01, 2017, 11:05:12 pm »
The extra coding amounts to one global array mapping the pretty pin number to the physical pin number, and one extra memory reference to look it up every time you want to set or clear a pin. Have you got ... what? ... 80 bytes of memory to spare?

The way I look at it, I figured it out on my own, more than 15 years ago as a 20-something self taught "engineer" with no formal programming lessons beyond the Apple II BASIC elective I took in 7th grade, so it can't be particularly hard. It was my first microcontroller project ever at the time, and I don't claim to be a programmer even now, just a guy who can write some code if the need arises. I built about a dozen clocks using various hardware designs and display types, and all of them fit into what are now primitive AVRs with only 2k of flash with room to spare. There is no reason to even worry about optimizing code for a clock unless that's something you enjoy doing. The code could be an absolutely horrible, terrible mess that breaks all kinds of rules and it won't even matter, all it has to do is keep time and update the display. It will spend the vast majority of its cycles spinning in loops waiting for things to happen.
 

Offline AF6LJ

  • Supporter
  • ****
  • Posts: 2901
  • Country: us
Re: EEVblog #975 - Human vs Autorouter
« Reply #58 on: March 03, 2017, 03:12:09 am »
That's nuts even if you left out the grounds in the autorouter, you would spend more time fixing all the crap than it would take to have routed it yourself.
That was really good Dave thanks for posting this.
Sue AF6LJ
Test Equipment Addict, And Proud Of It.
 

Offline mash107

  • Contributor
  • Posts: 23
  • Country: us
Re: EEVblog #975 - Human vs Autorouter
« Reply #59 on: March 09, 2017, 01:18:12 am »
In this episode... Dave Jones reprises his role as John Henry... showing that man is greater than machine once ad for all ;)

Well done!
 

Offline djacobow

  • Super Contributor
  • ***
  • Posts: 1033
  • Country: us
  • takin' it apart since the 70's
Re: EEVblog #975 - Human vs Autorouter
« Reply #60 on: March 21, 2017, 10:37:11 pm »
Someone should build an "autorouter" that is just an API for your PCB tool on your end, and a room full of layout folks on the other end.

Key is coming up with an appropriate "objective function" that captures a lot of the goodness that is hard to describe to a computer ("neatness","regularity","clarity","what were you thinking?", etc) and that is difficult to game. Then the "router" gets paid according to how well he or she does. Maybe from the router's perspective, it's set up like a video game, like in The Last Starfighter or Ender's Game.

If you are clever enough, you can set up the work for the "router" in such a way that he or she doesn't need to know the first thing about PCBs and electricity. Just "solve this abstract puzzle according to these rules."

I'm 82% joking, and 18% fearful that someone will take up this very idea.


 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1075
  • Country: nz
  • Currently at SiFive, previously Samsung R&D
Re: EEVblog #975 - Human vs Autorouter
« Reply #61 on: March 21, 2017, 11:29:14 pm »
The results from those programs are pretty shocking -- or should I say, from those features in those programs. Maybe they haven't put much thought or effort into them.

I'm pretty sure I could do a *far* better job of auto-routing, if I spend a year on the problem. And with much faster results too.

The problem is I'm gainfully employed doing other kinds of optimisation problems (compiler for mobile phone GPUs, at the moment) that will have huge revenue streams later. I doubt the market for a truly good PCB layout algorithm is very large.
 

Offline xjordanx

  • Contributor
  • Posts: 27
  • Country: us
Re: EEVblog #975 - Human vs Autorouter
« Reply #62 on: April 06, 2017, 11:05:28 pm »
Hi All,

I think you should see this video with Dave's design from Charles, the Product Manager at Altium in charge of routing. He's given this video to Dave, but Dave hasn't had a chance to post it anywhere yet as a response.

You should definitely check out the "ActiveRoute" tool, which Dave didn't mention. It's user-guided automation, so best of both worlds:
https://youtu.be/yaxSUBfTy7A
 
The following users thanked this post: hammy, thm_w, Bud, Dubbie


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf