sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
FelixVi has quit [Ping timeout: 250 seconds]
kuldeep has quit [Ping timeout: 244 seconds]
sandeepkr has quit [Ping timeout: 240 seconds]
sandeepkr has joined #m-labs
kuldeep has joined #m-labs
<sb0>
whitequark, what's the status of #318?
<sb0>
also I suppose that Aleksey is not going to touch Qt?
<sb0>
e.g. #464 ...
<sb0>
or any of those in my email...
<sb0>
rjo, what about #40? drop it from 2.0?
<sb0>
it seems no one is really asking for that at this point
<sb0>
same for the fancy scientific spinbox
<sb0>
I suppose a proper implementation should be built based directly on QAbstractSpinBox. QDoubleSpinbox hacks are messy and buggy.
rohitksingh has joined #m-labs
cr1901 has quit [Ping timeout: 276 seconds]
<mithro>
Heyo - I'm trying to understand the timer object. I don't quite understand what the EventManager object is doing? I think it is used to capture the hitting zero event but I don't understand were the result from that is used?
<sb0>
mithro, would you write the corresponding documentation after I answer your questions? :)
cr1901 has joined #m-labs
<mithro>
sb0: I was actually looking at the CSR documentation I started writing for you today
<sb0>
yes. the idea is you create one EventManager, that takes multiple event sources
<mithro>
sb0: And they seem to have the idea that they "get triggered, and then have to be cleared" ?
<sb0>
the EventManager drives one IRQ line, and provides interrupt management CSRs
<sb0>
each event source adds one bit to the CSRs of the EventManager
<mithro>
sb0: Yeah - that idea seemed pretty straight forward to me
<mithro>
sb0: What I don't quite understand is the pending/status/clearing stuff
<sb0>
okay, so "status" corresponds to the current state of the even source
<mithro>
sb0: I think it is asserts the clear signal when you write to the status register?
<sb0>
for example, a "busy" event source that corresponds to a character being sent by the UART will have status=1 while transmitting, status=0 when idle
<sb0>
"pending" means something has happened that calls for the attention of the CPU
<sb0>
to keep the character transmission example, pending will be set to 1 when status goes to 0 (transmission completed)
<sb0>
and pending is cleared by the cpu acking the interrupt
<sb0>
by writing 1 to clear the corresponding bit in the pending register
<sb0>
finally, "enable" in the EventManager tells which bits in "pending" will assert the IRQ line, it's used for masking interrupts
<sb0>
now. there are different types of EventSources
<sb0>
EventSourceProcess is the one I described above, which is what one would use for the character transmission
<sb0>
EventSourcePulse is for point-in-time events, where status is always 0, but which can still cause a pending interrupt
sandeepkr has quit [Quit: Leaving]
<sb0>
EventSourceLevel disables the pending w1c mechanism and lets the user clear the interrupt by another means
<sb0>
one would use EventSourceLevel in more complicated cases
<mithro>
So doing XXX_ev_pending_write(XXX_ev_status_read()) would effectively "ack" all currently asserted ones?
<sb0>
no, as I said, EventSourcePulse has status permanently to 0
<mithro>
I think I'm getting pending and status confused
<sb0>
what you're looking for is XXX_ev_pending_write(XXX_ev_pending_read())
<sb0>
but this code is generally wrong as well, because it races.
<sb0>
if an event triggers between XXX_ev_pending_read() and XXX_ev_pending_write(), then it won't be cleared
<sb0>
or after XXX_ev_pending_write(), even.
<mithro>
sb0: sure - but that is what you wanted right - x = XXX_ev_pending_read(); if (x) { do something; XXX_ev_pending_write(x); }
<sb0>
yes. and if the event triggers in-between, then the ISR is reentered and produces the correct behavior.
<mithro>
that way if something comes in while you are handling it, it will be there when you next come around to service it
<sb0>
yes.
<mithro>
sb0: So - What is the status for then?
<sb0>
for busy-waiting on EventSourceProcess for example. and debugging - getting a peek into the status of the core.
<sb0>
you can do things like: start_process(); while(XXX_ev_status_read() & PROCESS_BUSY);
<sb0>
that can be done as well by looking at pending, but it's less elegant:
<mithro>
sb0: So I can set status to anything, only trigger matters for causing the pending output to occur?
<sb0>
if you're using EventSourceProcess it will derive pending from status.
<sb0>
status is read-only from the CPU.
<mithro>
sb0: Okay - yeah I see that now
<sb0>
btw this stuff is in misoc now
<mithro>
sb0: Okay, I owe you two bits of doco now
<mithro>
sb0: Lucily I have 3 days this week to work on this
sandeepkr has joined #m-labs
<mithro>
sb0: I'm trying to create a simple little thing which when you hold a button down for long enough it asserts a value in the CSR which has to be cleared. Just changed it to use the EventManager stuff above and will see if it works shortly -- but was thinking that this might already exist and I just missed it?
<rjo>
sb0: i think the scientific spinbox does provide the right API. what makes you think that that would be a hack?
<rjo>
i don't think #40 should be dropped. if you take a random example from e.g. raghu, you will see that a proper way to spec latiencies would help him a lot.
<rjo>
sb0: and fee free to reassign #391 to you. you know that a bit better than i do. an maybe #451 if you still got time.
<sb0>
rjo, the API is fine, the implementation is not
<rjo>
sb0: if there is no implementation that is not a hack then the API is not fine.
<rjo>
sb0: ah. i meant "the qdoublespinbox does provide the right API"
<rjo>
... for a scientificspinbox.
<sb0>
ah
<sb0>
I don't think so, you basically need to redefine all text processing functions to whack-a-mole all the pesky corner cases
<sb0>
might as well rebuild all from the ground up
<rjo>
there are just one or two text processing methods. and it needs to look that way anyway: you have to track the value and the text and validate/modify/parse the latter and format the former etc.
<sb0>
yes, but the functions that do that in QDoubleSpinBox do not help you
<sb0>
QAbstractSpinBox is essentially like QDoubleSpinbox without the unusable functions anyway
<rjo>
half of them do. like the min/max/step/precision getters and setters.
<rjo>
and the signal emission stuff
<rjo>
that's roughly half of qspinbox.cpp
<sb0>
precision doesn't work when the number has an exponent
<sb0>
step doesn't do steps that depend on the exponent (if any)
<rjo>
sure they work.
<sb0>
well in the sense that it will set a "precision" attribute on the class, yes
<sb0>
but everything else is broken
<rjo>
not broken at all. if reusing one method from QDoubleSpinBox for ScientificSpinBox makes for less code, then it would be wirth it.
<rjo>
and from the looks of it at least half of QDoubleSpinBox would be reused.
<rjo>
let's see. swapping them is easy. getting the scientific-specific logic right is hard.
<sb0>
should it be kept for 2.0 and who does it?
<rjo>
i'll do it.
<rjo>
i'd like to have it for 2.0
<rjo>
not having a useful and intuitive spinbox for physics has been pissing me of for decades now.
<sb0>
as you can see from the buggy example you found online, there are many annoying corner cases
<rjo>
sure. it's like the scanwidget. but a bit less complicated. and without the visuals.
<rjo>
i know about corner cases. i have hit many of them over the years ;)
<rjo>
one interesting case is the stepping behavior. there are two approaches here: either have step always act on the mantissa alone (and have the formatting handle the jumps in exponent). that has weird behavior in the sense that the stepping becomes logarithmic and you will never get to zero or different sign by stepping.
<sb0>
yes, the logarithmic step is not consistent with the "step" parameter of get_attribute
<rjo>
or you have "small step" (no ctrl) act linearly and "big step" (with ctrl) act logarithmically.