[Libre-soc-bugs] [Bug 846] Pinmux Pinspec Interconnect Auto-Generation
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Sat Oct 1 12:33:02 BST 2022
https://bugs.libre-soc.org/show_bug.cgi?id=846
--- Comment #5 from Andrey Miroshnikov <andrey at technepisteme.xyz> ---
Here's the latest commit:
https://git.libre-soc.org/?p=pinmux.git;a=blob;f=src/stage2.py;h=1669149e22bed1776e7aa7c9ace5772ca0a607f4;hb=HEAD
By reverse engineering the PinSpec "write()" method, I was initially able to
extract only the bank, pin, and mux information.
https://git.libre-soc.org/?p=pinmux.git;a=blob;f=src/spec/base.py;hb=HEAD#l51
ps.pinbanks.keys() <-- Gives the available banks for the chip (A/B/C/D etc)
ps.keys() <-- Gives all pins (summing all banks)
But running in interactive shell was useful to find the rest of the dicts.
Also I answered my own question before finishing this comment.
"keys()" is a method you added to the Pinouts class (which PinSpec inherits)
that internally calls .pins.keys().
ps.byspec <-- dict that has the signal names with IOType information
Now that I have the information, I'll integrate it into the pinmux block by
feeding PinSpec object directly!
There seems to be a strange recursive duplication.
ps.items() gives the pin information (as ps is PinSpec and inherits Pinouts),
but the same dict is returned by ps.gpio.pinouts.items()
and this can be continued for a while (tried up to 20 levels, 4 shown):
ps.gpio.pinouts.gpio.pinouts.gpio.pinouts.gpio.pinouts.items()
Is this a bug? It doesn't seem like there are infinite objects (otherwise my
RAM
wouldn't be happy), but perhaps a circular reference somewhere?
Also added new sections to the pinmux doc (they may need to move around, but
haven't focused on that yet), 4.1.1-4.1.4 covering the terminology and the
PinSpec and Pinouts classes.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list