<whitequark>
hm, but we export the files only when we know the design is in a good enough state for manufacturing
<d1b2>
<nerdyscout> it is configured to run only on master branch. so if you keep this clean it should be save. and it can do ERC+DRC as well 😉
<electronic_eel>
we currently update the gerber, bom and pdf-schematic files for the current revision whenever that is updated. so you can already get all that in master
<electronic_eel>
getting a pdf or svg schematic or something similar of a non-master branch would be nice though. i have wanted to look something up from the wip-revC2 branch in the past when on the go and without kicad
<d1b2>
<esden> yeah, maybe gerber files should not be generated automatically. But the rest is useful. But it does bring up the debate how much autogenerated stuff should ever be included in a GIT repository... but practicability vs version control cleanliness is a complicated debate.
<electronic_eel>
could it maybe be written to a webserver, wiki or the like instead? i concur that a git repo is not the best place
<d1b2>
<nerdyscout> kicad-exports just generates the files in the CI, you could use any action (https://github.com/marketplace?) to do whatever you like with those files.
<d1b2>
<nerdyscout> even if you run it manually it can be useful to generate every time all exports with the same settings
ExeciN has quit [Quit: so long king Bowser]
puck has quit [Remote host closed the connection]
puck has joined #glasgow
<electronic_eel>
ok, I found the first issue with revC2
<electronic_eel>
the INA233 is a SMBus-device, so it uses the smbus features, like alert request
<electronic_eel>
unfortunately the smbus alert request address clashes with one of our DACs
<whitequark>
ouch
<whitequark>
what is the impact?
<electronic_eel>
and the only way I've found so far to bring the INA233 to release that stupid ALERT line is to completely reset it
<electronic_eel>
now it has all kinds of commands called CLEAR_FAULTS and stuff like it, but they don't touch the stupid ALERT line
<whitequark>
ok, so we need a revC3
<electronic_eel>
it seems like the engineers at TI haven't though about anyone not using the smbus alert request
<whitequark>
hahahahaha don't get me started on TI and I2C
<electronic_eel>
whitequark: not so sure, we could work around it
<electronic_eel>
so with reset i meant sending it a reset command via i2c (RESTORE_DEFAULT_ALL)
<whitequark>
hrm
<whitequark>
what is the impact of that compared to resetting it more properly?
<electronic_eel>
currently the logic in the firmware is that a alert is noticed and the alert line cleared, but the adc still has it
<electronic_eel>
then when the firmware gets a control request to query for alerts it can send it again
<electronic_eel>
only after that it is cleared
<electronic_eel>
also you can still query the set limits from the adc
<electronic_eel>
so when we reset it, this data is gone
<electronic_eel>
we'd have to either cache it or read out, reset, write back
bvernoux has quit [Quit: Leaving]
<whitequark>
probably the latter. hrm.
<whitequark>
i guess if an alert immediately disables the Vreg there is nothing bad that can happen during the reset
<electronic_eel>
no, there won't happen anything bad there. it is just reading the data out that is a bit more inconvenient
<whitequark>
ok, sounds acceptable. though we could still group that with the other things we wanted for revC3
<electronic_eel>
they even have a bit in their control register that is called "alert behavior". it should allow you to switch between latched and "transparent". but i haven't found out how it works yet
<whitequark>
hmm
<electronic_eel>
from the name and options i would have guessed the alert line is released once the fault is cleared
<electronic_eel>
but that doesn't seem to be the case
<electronic_eel>
so i'll now write the code for read out, reset, write back and see if i can get that to behave
<electronic_eel>
if we need to do a revC3 now because of other grave bugs, we can change the dac address too
<electronic_eel>
i think the problems with the alert line come from the fact that smbus requires you to release the alert line once the target could successfully send its address as answer to the alert request
<electronic_eel>
that means you need some logic to release it, even if the fault is still there
<electronic_eel>
and only activate it again if another fault pops up
<d1b2>
<esden> Changing the address on the DAC only means changing the strapping, right?
<whitequark>
yes
<electronic_eel>
esden: yes
<electronic_eel>
so a junior state machine designer could become confused by this, but obviously not the pros at ti...
<d1b2>
<esden> Let's lump it in with the changes for revC3... I am ok with doing one more revision before the full production run, as long as we don't make massive chip shuffles that throw the whole bom and quoting situation into the air once again.
<d1b2>
<esden> unless we have a showstopper bug obviously
<whitequark>
yeah
<electronic_eel>
esden: do you have any feedback about the tvs diodes?
<d1b2>
<esden> no not yet... Arrow is not very fast 🙂
<d1b2>
<esden> I will poke them this week again.
<electronic_eel>
if they are as fast with deliveries as with quotes...
<d1b2>
<esden> erm... those are usually factory deliveries so they always take 6-8 weeks or longer...
<d1b2>
<esden> but that is normal
<d1b2>
<esden> and you get a timeframe
<d1b2>
<esden> but that would be the same with the parts from any western supplier
<electronic_eel>
i've just been thinking over the firmware logic we currently have for the alerts
<electronic_eel>
i'm not so sure that read out, reset, write back is the best way forward here
<electronic_eel>
think about the over current alerts we'll have in the future
<electronic_eel>
you want to know that one happened
<whitequark>
correct. i actually think the entire alert logic should be redesigned
<electronic_eel>
but once the port vio is off, there won't be any more ocp alert
<whitequark>
i was going to do that but i realized that we don't need the ST_ERROR bit at all
<whitequark>
it is only there because of a grave misunderstanding of USB i had
<whitequark>
so i went to fix that, but it is a deep hole
<electronic_eel>
i saw that you simplified the led handling, but haven't taken a deeper look yet
<whitequark>
as i still need to finish multiple CXXRTL deliverables, i'm not sure exactly when i'll be able to redesign the logic
<electronic_eel>
but does the alert thing for the adcs depend on this?
<whitequark>
technically, no
<electronic_eel>
i could change the alert logic for the adcs now, instead of going roundabout ways to implement some hacks to make the old one work
<whitequark>
thing is, right now ST_ERROR and ST_ALERT are coupled, and they shouldn't be
<electronic_eel>
we should just have a common understanding how it should be in the future
<whitequark>
any way forward that keeps them coupled means a future mistake we have to fix
<electronic_eel>
ST_ERROR and ST_ALERT both show the ERR led. does there need to be any more coupling than this?
<whitequark>
ST_ERROR should not light up the ERR LED
<whitequark>
and it should not exist
<whitequark>
sigh, this is very frustrating to discuss
<electronic_eel>
hmm, why?
<whitequark>
because i can not fix things properly but i'm forced to decide on the way forward
<electronic_eel>
so what if we ignore ST_ERROR for now and just focus on ST_ALERT and the adc alerts
<whitequark>
well a proper design for alerts would feature a separate endpoint, EP1IN, which the software polls for status
<whitequark>
and something to clear them as well through the control endpoint (or maybe even self-clearing? i don't know)
<electronic_eel>
why is that necessary or what does that improve? it sounds more complicated to me at first glance
<whitequark>
right now if you have an alert condition while an applet runs, the applet has no idea unless it explicitly checks
<whitequark>
which is dumb and makes alerts largely useless
<whitequark>
since the applet code just plows on without any indication, and then when you *restart* the CLI, you get an error for a condition that may have already cleared
<whitequark>
(the *limit* itself is useful--the alert triggered by going outside of the limit is essentially just noise right now)
<electronic_eel>
if we had this extra error endpoint, how would the python code in the applet find out about it and handle it?
<whitequark>
it wouldn't
<whitequark>
it is not the job of python code in the applet to work directly with USB anything
<electronic_eel>
ok, not the code in the applet, the glasgow framework code
<whitequark>
the glasgow framework code has intrinsic knowledge of any endpoints, so it would just be hardcoded essentially
<whitequark>
in GlasgowHardwareDevice
<whitequark>
then in the CLI runner, it would set up polling, and (for a start) terminate the applet asynchronously with an error if an alert happens
<whitequark>
once we have that, alerts would actually become useful, and we can think about customizing their handling
<whitequark>
but that would be the absolute minimum of acceptable functionality to me
<electronic_eel>
but the info from the alert endpoint would be just that some kind of alert happened at port A, not any details?
<electronic_eel>
or just that any kind of alert happened anywhere?
<whitequark>
i think it should include all information required to form a complete report
<whitequark>
how much exactly depends on the capabilities of the new ADC
<electronic_eel>
ok, so why don't we start like this: we create a data structure in firmware to store this data
<electronic_eel>
then take the current control request and build it's data from this data structure (instead of polling the adc)
<whitequark>
i don't know
<whitequark>
i'm not ready to sign off on any concrete plan until i actually read the INA233 datasheet and think about the best way to integrate it
<whitequark>
and that will only happen once i'm done with CXXRTL because i'm quite late on that
<electronic_eel>
i'd like to get revC2 firmware to the same level as revC1, so that i can continue to characterize the other changes
<whitequark>
well, that means i'll need to pull off some more 48-hour workdays to get both CXXRTL and this done
<whitequark>
i guess that also works
<electronic_eel>
the question is if we can't find an easy way forward without having to design and implement the perfect solution
<whitequark>
the easiest way to decouple our workload is for you to implement alert handling as it happens in revC1
<electronic_eel>
i think this will be it then
<whitequark>
sounds good. thanks :)
<electronic_eel>
if i think a bit forward (=testing current limiting), i think i'll have to cache the alert state of the ina233 though
<electronic_eel>
since a overcurrent alert will simply not be there anymore
<electronic_eel>
so i think i'll keep the same basic logic and interface and just get the alerts for the ina233 from a alert mask byte
<electronic_eel>
for revC1 and below everything will stay as it is
<electronic_eel>
later we'll overhaul all this with the new interface, but until then i can test how this works out and how the ina233 works
<whitequark>
yep, sounds good
egg|laptop|egg has quit [Remote host closed the connection]