<wolfspraul>
wpwrak: 4.4v reset test is running - cool! any early peek yet?
<kristianpaul>
yeap :-)
<kristianpaul>
yes tell us :-)
<wpwrak>
see the latest mail :)
<roh>
nice one
<roh>
congrats
<wpwrak>
thanks ! it's good when things start to make sense :)
<wolfspraul>
yes, sounds good!
<wolfspraul>
why consider another reset ic if we already design-verified the one you have now?
<wolfspraul>
also, we are planning to make this change to a gate, no?
<wolfspraul>
should we dismiss that now that we have done this extensive testing and found everything to be stable?
<wolfspraul>
I want to make as few changes as possible from a solution that we believe is 100% stable and good
<lekernel>
wpwrak, very cool :) thanks for all this testing!
<wpwrak>
lekernel: thanks ! still a bit more testing to do :) but i'm starting to feel good about all this
<wpwrak>
i find ed leckie's suggestion to use a triple voltage monitor interesting. operating on 5 V may indeed expose the reset circuit to new hazards. e.g., if a USB peripherals with unreasonably large Vbus caps is plugged in, it might cause a glitch on 5 V. of course, this glitch as such would already be bad. but we may not notice it now.
<wpwrak>
with the reset chip watching 5 V directly, such a relative minor upset could reset the whole M1.
<lekernel>
there is a large electrolytic capacitor close to the USB ports to prevent this, and more caps elsewhere on the board ...
<wpwrak>
the big caps sometimes have a bad ESR, letting transients still get through. i think there's also parasitic inductance to consider, but that's already above my head :)
<wpwrak>
that's basically why you put small caps very close to chips and bigger silo caps at a distance
<wpwrak>
well, it's not the only reason. another reason are the current loops
<lekernel>
we have 220uF close to the two ports, and the USB spec specifies a maximum of 10uF (iirc) at the device side... so the device would have to violate the USB spec quite badly to cause problems
<lekernel>
yes, there are ceramic caps on 5V elsewhere on the board, too
<wpwrak>
a usb device violating the specs ? what are the odds ? ;-))
<wpwrak>
well, i'll just play a bit with my reworked M1, see if it acts funny. right now, i'm seeing a number of unexpected transitions into standby. but i'm not yet sure where they come from
<wpwrak>
(e.g., could be just the cable mess on my desk)
<wpwrak>
and i think i've figured out how to do midi ;-) in the longer run, this may want an abstraction layer on top of the "generic" patches, but let's see
<wpwrak>
damn. we need a lot more variables for the GFPU.
<wpwrak>
i can already see patches with dozens of midiX parameters
<lekernel>
this shouldn't be a fundamental problem
<lekernel>
the PFPU register file is mapped in block RAM, which is quite efficient
<lekernel>
we can have thousands of registers if you like :-)
<wpwrak>
want ! ;-
<wpwrak>
)
<lekernel>
another factor is simply pruning the registers which are not needed during preallocation
<lekernel>
the only serious problem I see with having tons of registers, is whether the LM32 can keep up loading/reading them at each frame
<wpwrak>
well, first i have to add more controls to my MIDI system. so far, it's the kaossilator making music and feeding the M1 with midi control data. when it isn't set as a dedicated midi controller, is send only about half the things it has out (and it isn't such a superb controller to start with)
<wpwrak>
for midi, could they be updated just when a message arrives ?
<lekernel>
no
<lekernel>
in fact the complete PFPU is reloaded twice per frame
<lekernel>
once to compute the per-frame equations - it's perhaps not necessary to use the full PFPU acceleration there, it was merely a matter of reusing the existing infrastructure
<lekernel>
then all the registers and program space are reloaded to compute the per-vertex equation
<lekernel>
all this happens at each frame
<lekernel>
you can, however, just update the corresponding value in system memory when the MIDI message arrive
<lekernel>
and do the floating point conversion only once
<lekernel>
(actually it may even already do that in fact... I don't remember)
<lekernel>
so far the main CPU hogs are 1) drawing waves, borders, etc. (especially when they are translucent) and 2) audio filtering
<lekernel>
maybe this PFPU reloading will continue to be a small overhead, even with thousands of registers
<lekernel>
I don't know
<lekernel>
we can also DMAize it without much trouble too :-)
<wpwrak>
heh :)
<wolfspraul>
wpwrak: do you think we still need to or should investigate the gate?
<wolfspraul>
or we just leave everything as-is with your latest configuration?
<wpwrak>
i'd rather have the gate than the current "analog computer" :)
<lekernel>
you still have the capacitor fix?
<wpwrak>
it shouldn't need much investigating, though.
<wpwrak>
i guess i do ... i've kinda lost track of the latest state of chaos there :)
<wolfspraul>
you mentioned finding a better reset ic
<wolfspraul>
(the possibility of that)
<wolfspraul>
is that worth it?
<wolfspraul>
I want to remove any 'potential improvemens' asap and have a 'proposed rc4 circuit', then Adam can do a second verification on his side
<wolfspraul>
if you feel uneasy about your board, maybe Adam can send you a second one?
<wolfspraul>
that would also make it easier to run your test series
<wpwrak>
i think my board is fine. my concern with the rest chip is more that we're testing a rail that may be easily upset
<wolfspraul>
I read it but it sounds hypothetical
<wpwrak>
testing the "stable" rails would thus make more sense. but ... we need to test several of them, or it won't work
<wolfspraul>
I would focus all my energy on known and understood problems and improvements, we have plenty of them
<wpwrak>
(hypothetical) not sure
<wpwrak>
i'm now eyeing each reset with suspicion :)
<wolfspraul>
hmm, ok
<wolfspraul>
I just hope we reach a stable point soon, not to loose focus
<wolfspraul>
seems some ideas are floating right now, switch to gate yes/no, different reset ic yes/no, different power rail yes/no/which one
<wolfspraul>
also whether adam verifies it, send you a second (reworked?) board or not etc.
<wolfspraul>
almost feels like we have too much data now :-)
<wolfspraul>
let me know which way you think is *reasonable*
<wpwrak>
naw. now we have enough data to actually understand what's happening :)
<wpwrak>
did you notice that things speeded up quite a bit lately ? that's because i can now tell pretty quickly if the system is behaving normally or not
<wpwrak>
i need a bit more experimenting with voltage ranges and insults to the 5 V rail. e.g., connect/disconnect things
<wpwrak>
if the 5 V rail doesn't cause trouble at 5.0 V, i'd recommend using a reset chip with a ~4.0 V threshold, so make sure we don't run into trouble if we have a little less than 5.0 V
<wpwrak>
if the 5 V rail is too unstable, then it's the three-inputs reset IC
<wpwrak>
independent from that, the diode should become a gate
<wolfspraul>
ok ko
<wolfspraul>
ok ok
<wolfspraul>
:-)
<wolfspraul>
got it
<wolfspraul>
so switch to gate is a must, unless we find proof that there is a problem
<wolfspraul>
better reset ic is most likely a given too
<wolfspraul>
that means we need to source it
<wolfspraul>
that looks like you keep up the experiments, and in due time when you have a conclusion Adam sources a few of the (then latest) reset ics
<wolfspraul>
he already has enough gates I believe
<wolfspraul>
then Adam can rework two boards to the latest proposed rc4 standard, and ship one to you for double-checking, if you like
<wolfspraul>
does that sound roughly right?
<wpwrak>
sounds good, yes
<wpwrak>
btw, setting up midi was easier than i thought. controls are a little jerky. not sure if this is just quantization (127 meager values, hah !), normal patch response time, or something being sluggish (M1 or kaossilator)
<lekernel>
all midi is 127 values
<wpwrak>
yes .. kinda anachronistic. well, some cheat and split the range
<wpwrak>
hmm, when i send a lot of MIDI messages, rendering slows down noticeably
<wpwrak>
basically stops while the message burst arrives
<wpwrak>
(lot of messages) e.g., kick a slider from 0 to 127
<lekernel>
mh?
<lekernel>
worksforme
<roh>
iek
<wpwrak>
it's not that the system would fail. the rendering just slows down while there's a lot of MIDI traffic
<lekernel>
maybe your controller sends a lot more messages than mine, it's perfect with the m-key I have
<lekernel>
no slowdown and low response time
<lekernel>
or you've just hit some bug, I can't see how trivial 31kbps data processing can slow down the LM32... there are way more heavy tasks running
<wpwrak>
oopps. now it froze :)
<wpwrak>
btw, how do i save the MIDI settings ?
<lekernel>
in the performance file
<wpwrak>
grmbl. and i lost my patch. i could have sworn i saved it ...
<lekernel>
also works for me, the flash cache is flushed every 10 second to address this very problem
<wpwrak>
now the slowdown is gone. (still reconstructing my patch, though)
<lekernel>
yeah... probably some unrelated bug
<lekernel>
maybe the lag bug in another form?
<lekernel>
FYI what the lag bug does is make RTEMS spend 99% of the CPU time in the idle task even though there are runnable tasks
<wpwrak>
hmm, dunno. didn't check on serial.
<wpwrak>
hmm, i can't figure out how to save midi controls. no matter what i try, the next time i boot, they're gone
<wpwrak>
luckily, it's just four numbers to type in ...