skipwich has quit [Remote host closed the connection]
skipwich has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
lane has quit [Server closed connection]
lane has joined #glasgow
<_whitenotifier-a>
[glasgow] joelpmichael opened issue #1007: Off-By-1 error in glasgow.gateware.clockgen.ClockGen causes incorrect clock frequency to be generated - https://github.com/GlasgowEmbedded/glasgow/issues/1007
tom has joined #glasgow
cr1901_ has quit [Read error: Connection reset by peer]
cr1901 has joined #glasgow
chipb has quit [Server closed connection]
chipb has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
mwk has quit [Ping timeout: 252 seconds]
mwk has joined #glasgow
mwk has quit [Ping timeout: 248 seconds]
mwk has joined #glasgow
mei[m] has quit [Quit: Idle timeout reached: 172800s]
ali_as has quit [Ping timeout: 260 seconds]
ali_as has joined #glasgow
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
lxdr533 has quit [Remote host closed the connection]
lxdr533 has joined #glasgow
<tpw_rules>
so i don't know a lot about the problem or glasgow, but could glasgow be used to help debug cortex m0+ interrupt latency? i.e. read the current interrupt and whether my problematic interrupt is pending at a few dozen khz at least
<tpw_rules>
i have a super mega complex program (the micropython interpreter) and something is keeping my interrupt from running for more than 320us and breaking things
ali_as has quit [Ping timeout: 276 seconds]
ali_as has joined #glasgow
ali_as has quit [Remote host closed the connection]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
zyp[m] has joined #glasgow
<zyp[m]>
unfortunately cortex-m0+ doesn't have DWT like cortex-m3 and higher, otherwise you could have it trace interrupt enter/exit events over SWO
<tpw_rules>
that's what i had gathered, i was hoping glasgow could do a super fast poll
<zyp[m]>
I guess you could try having it poll IPSR in a loop and trace when it changes
<tpw_rules>
that and primask. i just don't really know enough about the stack to actually do that
<tpw_rules>
(or if one could expect it to be fast enough to read those registers at 10KHz)
<zyp[m]>
reading a core register consists of a write to DCRSR and a read from DCRDR, with the MEM-AP set up to use the banked data feature, that should be doable in just two SWD accesses
<zyp[m]>
not sure how fast glasgow can do SWCLK, but polling them at 10kHz seems well within what should be possible
<zyp[m]>
two SWD accesses is on the order of 100 SWCLK cycles
dne has quit [Remote host closed the connection]
dne has joined #glasgow
redstarcomrade has joined #glasgow
<whitequark[cis]>
glasgow supports up to 48 MHz SWCLK out of the box
<tpw_rules>
how might i script it in that way?
<tpw_rules>
would i have to edit the amaranth code?
<tpw_rules>
also i ended up just manually examining the NVIC and patching the SDK irq code to add a timer/breakpoint. so i think i've got it. but that is what i said the last four times too
<tpw_rules>
i really need to sit down and have a quiet weekend with my glasgow, i hardly understand the thing sadly
<whitequark[cis]>
yes, you'll have to implement a command sequencer in amaranth to get predictable request-to-request latency at 10 kHz
<tpw_rules>
is there any draft "applet for dummmies" yet?
<whitequark[cis]>
no
<tpw_rules>
okay, thanks. i will find some time and dig