<kristianpaul> wpwrak: i'm curios you like linux of course, but had you tried to run it on M1?
<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 ...