<d1b2>
<Attie> whitequark: sorry to ask more questions about resets... but it seems that registers don't get reset when the applet is restarted - is that correct?
<d1b2>
<Attie> it also seems that rw registers may only be written to from the glasgow utility (not the gateware), which makes sense if true, but was a little unexpected
<whitequark>
yes and yes
<whitequark>
in general, try to avoid using registers
<whitequark>
for... this reason basically
<d1b2>
<Attie> oh, okay
<whitequark>
that's what the serdes+sideband business is all about
<d1b2>
<Attie> i'm working on a frequency / duty counter, and they seemed appropriate for getting 32-bit values in/out
<d1b2>
<Attie> i'll take a look - 8-bit FIFO based?
<whitequark>
hmmm
<whitequark>
as a separate applet?
<whitequark>
in that case registers are actually reasonably appropriate
<whitequark>
i was thinking you were still working on i2s stuff
<d1b2>
<Attie> ah, sorry - yes a separate applet
<d1b2>
<Attie> sort of grown out of the i2s stuff
<d1b2>
<Attie> i wanted to get i2s to autodetect bitrate / sample rate, and figured this also made sense as a standalone
<whitequark>
hmm
<whitequark>
have you seen the UART autobaud thing?
<d1b2>
<Attie> i have, but didn't look too closely at it
<whitequark>
take a closer look
<d1b2>
<Attie> okay!
<d1b2>
<Attie> (for guidance on register usage / or not... or because it may do this task already?)
<whitequark>
register usage is fine for something like autobaud
<whitequark>
the problems really start when you need register r/w synchronized with the main applet fifos
<whitequark>
because i think it might well be generalizable for i2s
<whitequark>
or rather, no generalization is needed
<d1b2>
<Attie> for i2s we have a bit clock and frame clock, which makes the task a lot easier
<d1b2>
<Attie> if i'm understanding your intent correctly
<whitequark>
ohhh
<d1b2>
<Attie> but we need to resolve "n syc_clock cycles" to a real number, like 44.1kHz for the sample rate in the wav file
<d1b2>
<Attie> *sys_clock
<whitequark>
ok that's way easier than uart autobaud
<whitequark>
i think you should make that a part of the i2s applet itself
<whitequark>
i would probably use an r/o register and assume that the i2s bitrate doesn't really change much, so no synchronization is needed
<whitequark>
basically use a doubly buffered counter
<whitequark>
the first stage counts up until the next posedge, the second stage captures the count
<whitequark>
and you can read out the second stage through the i2c register
<whitequark>
nice and simple
<d1b2>
<Attie> i think that's basically what I've done, though I used distinct "detect bitrate" / "detect frame rate" / "capture audio" states... the first two can be skipped if the user wishes
<d1b2>
<Attie> i wanted to break that functionality out though, into a standalone frequency / duty-cycle counter
<whitequark>
hmm
<d1b2>
<Attie> that could give you details like period / low-time / high-time, over a number of cycles
<d1b2>
<Attie> periodic waveform required of course
<whitequark>
distinct states would also work
<whitequark>
distinct states work better if the i2s stream is not always on
<d1b2>
<Attie> yeah (in my case it isn't) - the other side of the equation is that:
<d1b2>
<Attie> A) we loose the first n samples / bits, because we're doing auto-detect - which can be disabled if you know what you're working with
<d1b2>
<Attie> B) i believe we need to declare the sample rate and sample size upfront for the wave package, before we write any samples out
<whitequark>
yep, i think you made a good decision there
<d1b2>
<Attie> cool, thanks for the sanity check
<_whitenotifier-f>
[glasgow] attie opened pull request #216: applet.interface.freq_counter: implement a frequency and duty-cycle counter - https://git.io/JTU6D
<_whitenotifier-f>
[glasgow] electroniceel commented on pull request #216: applet.interface.freq_counter: implement a frequency and duty-cycle counter - https://git.io/JTkef
<_whitenotifier-f>
[glasgow] attie commented on pull request #216: applet.interface.freq_counter: implement a frequency and duty-cycle counter - https://git.io/JTkI1
millerresearch has joined #glasgow
millerresearch has quit [Remote host closed the connection]
new_glasgow_user has joined #glasgow
<new_glasgow_user>
'glasgow run selftest pins-ext' and '... pins-loop' say PASS, but '... pins-int' says FAIL (all pins fail high). Should I be worried?
<electronic_eel>
new_glasgow_user: no, this is a know issue
<new_glasgow_user>
oh good, thank you
<electronic_eel>
the selftest isn't really working for revC devices, it was designed for revA and revB, but not adapted to revC yet