[Libre-soc-bugs] [Bug 50] nmigen pinmux

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=50

--- Comment #70 from andrey at technepisteme.xyz ---
(In reply to Luke Kenneth Casson Leighton from comment #69)
> (In reply to andrey from comment #68)
> annotated on the other hand (showing something important) is a
> different matter.
>...
> that's not possible.  it's now permanently and irrevocably taking up
> space on the server - in a postgresql database - that i have to pay money
> for.
Sorry about that. Will keep in mind from now on.

> 
> > To get a UART pad: 
> > uart_pad = top.jtag.resource_table_pads[('uart', 0)]
> 
> shouldn't be.  amazed it works.
Why? Is it not meant to be accessed this way?

The UART rx/tx jtag.boundary_scan_pads dict seem to be missing the records for
the signals, which is why I couldn't access them in the same way as the GPIO or
I2C.

The I2C signals are present:
Printing top.jtag.boundary_scan_pads['i2c_0__sda__i']
{'i': (sig i2c_0__sda__i__i)}
And type of printing top.jtag.boundary_scan_pads['i2c_0__sda__i']['i']
<class 'nmigen.hdl.ast.Signal'>

While the UART equivalent
Printing top.jtag.boundary_scan_pads['uart_0__rx__i']
{}

The access via jtag.resource_table_pads works:
Printing type of top.jtag.resource_table_pads[('uart',0)].rx.i
<class 'nmigen.hdl.ast.Signal'>

How can the UART signals be added to the dict? Is this an issue with Blinker
definition, or something to add to jtag.py?



Also, UART and I2C basic tests have been implemented.
For the I2C test I connected the SDA i/o and SCL i/o as an internal loopback
(similar to what you did with the UART). For o/e I have a separate test port.
No complex logic is present, just toggle low and high and check signal
propagated from pad to pad.

So once we resolve the little UART issue, what comes next?

-- 
You are receiving this mail because:
You are on the CC list for the bug.