NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
Hawk777 has quit [Quit: Leaving.]
tsal has quit [Ping timeout: 260 seconds]
tsal has joined #openocd
jn_ has joined #openocd
jn_ has joined #openocd
jn_ has quit [Changing host]
jn has quit [Ping timeout: 276 seconds]
_whitelogger has joined #openocd
_whitelogger has joined #openocd
nerozero has joined #openocd
manoj has joined #openocd
manoj has quit [Quit: Client closed]
Haohmaru has joined #openocd
jfsimon has quit [Ping timeout: 260 seconds]
jfsimon has joined #openocd
jfsimon has quit [Read error: Connection reset by peer]
jfsimon has joined #openocd
<mawk> hi
<mawk> I can't run multiple openocd instances using the raspberrypi-native interface, even when all of them are using different GPIO pins and have the tcl/gdb/telnet disabled
<mawk> it seems like they are competing for access to the GPIOs
<mawk> they can't toggle SRST together
<Haohmaru> no common pins between the different instances?
<Haohmaru> is this like openocd using crapberry-pie's pins to "bitbang" SWD ?
<Haohmaru> SWD+reset perhaps
<Haohmaru> are they using some sort of.. how was it called, PORT.OUTSET = 0x01; to set a pin without touching the other pin values like it's common on fancy MCUs?
<Haohmaru> "atomic" port registers or something
<Haohmaru> versus the dumber kind, like on an old atmega/pic PORTB |= 0x01;
<PaulFertser> mawk: yes, "native" interface can't atomically r/m/w bits.
<Haohmaru> huh
<Haohmaru> even if the pins are unique?
<PaulFertser> mawk: probably if you switch to "srst_push_pull" it'll do the trick
<PaulFertser> Because then you'll avoid r-m-w
<PaulFertser> Default is open-drain and for that the driver has to switch between input (for 1) and output (for 0).
<PaulFertser> mawk: but you if you want SWD then you'll probably need SWDIO on different ports as SWDIO needs to be switched between input and output all the time by definition.
<Haohmaru> GPIO_SET and GPIO_CLR looks like it's the "fancy atomic" scheme, but..
<PaulFertser> Haohmaru: yes, that's my point
<Haohmaru> mmm bcm2835_gpio_synchronize();
<Haohmaru> was ist das ;P~
<PaulFertser> Haohmaru: "git blame" and commit message will answer
<Haohmaru> sorry, i don't schprachen ze git very much
<Haohmaru> but it begins to smell like maybe it's not as simple, maybe there's some scheme similar to "virtual ports" on the xmega/SAME stuff
<Haohmaru> or maybe something completely different
<Haohmaru> in any case, i don't even have (nor want to have) any SBCs
<Haohmaru> iirc on XMEGA you had a few virtual ports which was like, the same periph struct as a normal port but at a different address, and you can modify a pile of the registers in that, and then afaiu, you can "apply" that whole setup to an actual real port periph with like 1 instruction
<Haohmaru> but i haven't used it and i'm not sure if the above is correct ^
Haohmaru has quit [Quit: saionara]
Hawk777 has joined #openocd
<mawk> it's already push pull PaulFertser
<mawk> what do you mean by different ports§
<mawk> all of my three sets of STDIO, SWCLK, SRST are on different pins
<mawk> you mean different GPIO chip?
Foxyloxy_ has joined #openocd
Foxyloxy has quit [Ping timeout: 240 seconds]
nerozero has quit [Ping timeout: 248 seconds]
<antto> mawk, pins are often grouped into ports
<antto> one effect of this is so they can be represented as bits in a byte/word so you can read or write the current states of a whole port of pins at a single point in time, for things like parallel communication
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #openocd
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #openocd
<mawk> ah I see
<mawk> but there are 32 accessible pins
<mawk> and they're all grouped together
<mawk> there are 32 more but they're not on the pin header
<mawk> and internal stuff is connected to them anyway
<mawk> PaulFertser: and if I use the old sysfs interface? that should be pin-level access right
<mawk> instead of group-level access
<mawk> and the kernel will serialize operations
<mawk> then it will be a bit slower but whatever
<mawk> Hammdist: ARM has the same thing
<mawk> bitfields at a specific address
<mawk> but it's just an addressing trick
<mawk> amd64 doesn't have it that I know of
indy has quit [Ping timeout: 276 seconds]
indy has joined #openocd
akaWolf has quit [Quit: Lost terminal]
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #openocd
<PaulFertser> mawk: libgpiod should work
<PaulFertser> sysfsgpio is much much slower
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #openocd