Possible routing issues when chip L is involved

Help
1

I haven’t dug into this much yet, but I’ve observed that some paths involving chip L aren’t being physically configured. A simple example is 1-108, 2-109, shown below. Note that the bridge array has nothing configured for chip A, despite having defined a net which uses it.

This is with release v1.1.1.1, but I also tried with current main (fb41f84).

                        Menu

        n = show netlist
        b = show bridge array
        w = waveGen
        f = load formatted nodeFile
        p = paste new Wokwi diagram
        l = LED brightness / test
        d = toggle debug flags
        r = reset Arduino

f
1-108, 2-109
number of nets: 8
path[0] net: 6
path[1] net: 7
number unique of nets: 2
pathIndex: 2
numberOfPaths: 2

0  [1,I_POS,Net 6],     1  [2,I_NEG,Net 7],     

time to sort: 2018us


number of nets: 8
path[0] net: 6
path[1] net: 7
number unique of nets: 4
pathIndex: 2
numberOfPaths: 2

0  [1,I_POS,Net 6],     1  [2,I_NEG,Net 7],     

time to sort: 1675us

path[0]
nodes [1-108]

finding chips for nodes: 1-I_POS

node: 1
 
chip: L

node: 2
 
special function candidate chips: L 
chip: L
 



path[1]
nodes [2-109]

finding chips for nodes: 2-I_NEG

node: 1
 
chip: A

node: 2
 
special function candidate chips: L 
chip: L
 



paths with candidates:


B: 0
C: 0
D: 0
E: 0
F: 0
G: 0
H: 0
I: 0
J: 0
K: 0
A: 1
L: 3

path[0] net: 6           I_POS to 1
path[1] net: 7           2 to I_NEG

                        Menu

        n = show netlist
        b = show bridge array
        w = waveGen
        f = load formatted nodeFile
        p = paste new Wokwi diagram
        l = LED brightness / test
        d = toggle debug flags
        r = reset Arduino

path 0  NANO to SF 
L  x[0]:1   y[0]:0       L  x[1]:8   y[1]:0         x[2]:-1   y[2]:-1       x[3]:-1   y[3]:-1    

path 1  BB to SF 
A  x[0]:-1   y[0]:-1     L  x[1]:-1   y[1]:-1       x[2]:-1   y[2]:-1       x[3]:-1   y[3]:-1    

b


Bridge Array

0  [I_POS,1,Net 6],     1  [2,I_NEG,Net 7],     


Paths

path    net     node1   type    chip0   x0      y0      node2   type    chip1   x1      y1      altPath sameChp pathType        chipL   chip2   xy2       x3      y3

0       6       I_POS   2       L       1       0       1       2       L       8       0       0       1       NANO to SF      1 
1       7       2       0       A       -1      -1      I_NEG   2       L       -1      -1      1       0       BB to SF        1 

path    net     node1   type    chip0   x0      y0      node2   type    chip1   x1      y1      altPath sameChp pathType        chipL   chip2   xy2       x3      y3



Chip Status

chip    0    1    2    3    4    5    6    7    8    9    10   11   12   13   14   15           0    1    2    3    4    5    6    7
A       -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1           -1   -1   -1   -1   -1   -1   -1   -1    
B       -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1           -1   -1   -1   -1   -1   -1   -1   -1    
C       -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1           -1   -1   -1   -1   -1   -1   -1   -1    
D       -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1           -1   -1   -1   -1   -1   -1   -1   -1    
E       -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1           -1   -1   -1   -1   -1   -1   -1   -1    
F       -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1           -1   -1   -1   -1   -1   -1   -1   -1    
G       -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1           -1   -1   -1   -1   -1   -1   -1   -1    
H       -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1           -1   -1   -1   -1   -1   -1   -1   -1   

chip    0    1    2    3    4    5    6    7    8    9    10   11   12   13   14   15           0    1    2    3    4    5    6    7 
I       -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1           -1   -1   -1   -1   -1   -1   -1   -1    
J       -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1           -1   -1   -1   -1   -1   -1   -1   -1    
K       -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1   -1           -1   -1   -1   -1   -1   -1   -1   -1    
L       -1   6    -1   -1   -1   -1   -1   -1   6    -1   -1   -1   -1   -1   -1   -1           6    -1   -1   -1   -1   -1   -1   -1    


Revision 3



                        Menu

        n = show netlist
        b = show bridge array
        w = waveGen
        f = load formatted nodeFile
        p = paste new Wokwi diagram
        l = LED brightness / test
        d = toggle debug flags
        r = reset Arduino
1 Like
2

Try it with the Rev 3 firmware I put up today. Or the same one attached here. The issue was the connection map wasn’t fully updated from Rev 2 to 3 so it was looking for those few different connections in the wrong place.

Let me know what happens
firmware.uf2 (357 KB)

3

Oh wait, that’s actually a fresh bug. It should be setting the sameChip flag so it knows that I_NEG and row 1 are on the X inputs of the same chip. Should be a quick fix once I find the bit of code that should be doing it.

Honestly, the 4 corners of the breadboard (1,30,31,60) are a shit show, I would advise not counting on them unless you’re looking for bugs until I can nail them down a bit better. They pretty much act like their own category of connection types.

4

Ah, gotcha. Yeah, I got the same result with that firmware.

I can avoid the corners for now for non-bug-testing uses :laughing:

5

Yeah and now I need to put in some interface to show you the results of the current sensor readings. The firmware can read them just fine, I just haven’t come up with how I want that shown to the user without filling the terminal output with pages of readings.

Any thoughts on what you’d like to see are appreciated.

6

My first thought would be a menu entry that prints the output periodically, but with just a carriage return at the end of the line so it keeps overwriting the same line (assuming the terminal isn’t configured to treat \r as \r\n). That way it doesn’t fill the terminal output, but it can still be logged if you want to see past values.

1 Like
7

That’s actually a great idea. I always forget I can just use /r without /n. Maybe a little box with whatever readings it’s currently taking.

The original version of the firmware used a bunch of xTerm hacks to draw a semi-gui in the terminal. But it was just too much of a mess to do add anything without also adding a million bugs. But it was pretty cool, maybe I’ll look into reviving that in the future for the style points.

image
image1440×1798 260 KB

Here’s the code for that in the old breadWare repo:

1 Like