#milkymist IRC log for Saturday, 2011-10-29

kristianpaulwpwrak: i'm curios you like linux of course, but had you tried to run it on M1?00:03
wolfspraulwpwrak: 4.4v reset test is running - cool! any early peek yet?00:47
kristianpaulyeap :-)00:57
kristianpaulyes tell us :-)00:57
wpwraksee the latest mail :)01:34
rohnice one01:38
wpwrakthanks ! it's good when things start to make sense :)01:40
wolfspraulyes, sounds good!01:41
wolfspraulwhy consider another reset ic if we already design-verified the one you have now?01:41
wolfspraulalso, we are planning to make this change to a gate, no?01:42
wolfspraulshould we dismiss that now that we have done this extensive testing and found everything to be stable?01:43
wolfspraulI want to make as few changes as possible from a solution that we believe is 100% stable and good01:57
lekernelwpwrak, very cool :) thanks for all this testing!07:32
wpwraklekernel: thanks ! still a bit more testing to do :) but i'm starting to feel good about all this10:21
wpwraki 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.10:23
wpwrakwith the reset chip watching 5 V directly, such a relative minor upset could reset the whole M1.10:24
lekernelthere is a large electrolytic capacitor close to the USB ports to prevent this, and more caps elsewhere on the board ...10:30
wpwrakthe 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 :)10:32
wpwrakthat's basically why you put small caps very close to chips and bigger silo caps at a distance10:33
wpwrakwell, it's not the only reason. another reason are the current loops10:33
lekernelwe 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 problems10:33
lekernelyes, there are ceramic caps on 5V elsewhere on the board, too10:34
wpwraka usb device violating the specs ? what are the odds ? ;-))10:34
wpwrakwell, 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 from10:35
wpwrak(e.g., could be just the cable mess on my desk)10:36
wpwrakand 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 see10:45
wpwrakdamn. we need a lot more variables for the GFPU.12:18
wpwraki can already see patches with dozens of midiX parameters12:18
lekernelthis shouldn't be a fundamental problem12:19
lekernelthe PFPU register file is mapped in block RAM, which is quite efficient12:19
lekernelwe can have thousands of registers if you like :-)12:19
wpwrakwant ! ;-12:20
lekernelanother factor is simply pruning the registers which are not needed during preallocation12:20
lekernelthe only serious problem I see with having tons of registers, is whether the LM32 can keep up loading/reading them at each frame12:21
wpwrakwell, 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)12:21
wpwrakfor midi, could they be updated just when a message arrives ?12:22
lekernelin fact the complete PFPU is reloaded twice per frame12:22
lekernelonce 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 infrastructure12:23
lekernelthen all the registers and program space are reloaded to compute the per-vertex equation12:23
lekernelall this happens at each frame12:23
lekernelyou can, however, just update the corresponding value in system memory when the MIDI message arrive12:24
lekerneland do the floating point conversion only once12:25
lekernel(actually it may even already do that in fact... I don't remember)12:25
lekernelso far the main CPU hogs are 1) drawing waves, borders, etc. (especially when they are translucent) and 2) audio filtering12:27
lekernelmaybe this PFPU reloading will continue to be a small overhead, even with thousands of registers12:29
lekernelI don't know12:29
lekernelwe can also DMAize it without much trouble too :-)12:30
wpwrakheh :)12:34
wolfspraulwpwrak: do you think we still need to or should investigate the gate?12:48
wolfspraulor we just leave everything as-is with your latest configuration?12:48
wpwraki'd rather have the gate than the current "analog computer" :)12:48
lekernelyou still have the capacitor fix?12:49
wpwrakit shouldn't need much investigating, though.12:49
wpwraki guess i do ... i've kinda lost track of the latest state of chaos there :)12:49
wolfspraulyou mentioned finding a better reset ic13:04
wolfspraul(the possibility of that)13:05
wolfspraulis that worth it?13:05
wolfspraulI want to remove any 'potential improvemens' asap and have a 'proposed rc4 circuit', then Adam can do a second verification on his side13:06
wolfspraulif you feel uneasy about your board, maybe Adam can send you a second one?13:07
wolfspraulthat would also make it easier to run your test series13:08
wpwraki think my board is fine. my concern with the rest chip is more that we're testing a rail that may be easily upset13:08
wolfspraulI read it but it sounds hypothetical13:09
wpwraktesting the "stable" rails would thus make more sense. but ... we need to test several of them, or it won't work13:10
wolfspraulI would focus all my energy on known and understood problems and improvements, we have plenty of them13:10
wpwrak(hypothetical) not sure13:10
wpwraki'm now eyeing each reset with suspicion :)13:11
wolfspraulhmm, ok13:13
wolfspraulI just hope we reach a stable point soon, not to loose focus13:14
wolfspraulseems some ideas are floating right now, switch to gate yes/no, different reset ic yes/no, different power rail yes/no/which one13:14
wolfspraulalso whether adam verifies it, send you a second (reworked?) board or not etc.13:15
wolfspraulalmost feels like we have too much data now :-)13:15
wolfspraullet me know which way you think is *reasonable*13:15
wpwraknaw. now we have enough data to actually understand what's happening :)13:15
wpwrakdid 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 not13:16
wpwraki need a bit more experimenting with voltage ranges and insults to the 5 V rail. e.g., connect/disconnect things13:17
wpwrakif 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 V13:18
wpwrakif the 5 V rail is too unstable, then it's the three-inputs reset IC13:19
wpwrakindependent from that, the diode should become a gate13:19
wolfspraulok ko13:19
wolfspraulok ok13:19
wolfspraulgot it13:19
wolfspraulso switch to gate is a must, unless we find proof that there is a problem13:20
wolfspraulbetter reset ic is most likely a given too13:20
wolfspraulthat means we need to source it13:20
wolfspraulthat 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 ics13:21
wolfspraulhe already has enough gates I believe13:21
wolfspraulthen Adam can rework two boards to the latest proposed rc4 standard, and ship one to you for double-checking, if you like13:21
wolfsprauldoes that sound roughly right?13:21
wpwraksounds good, yes13:22
wpwrakbtw, 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)13:35
lekernelall midi is 127 values13:39
wpwrakyes .. kinda anachronistic. well, some cheat and split the range13:42
wpwrakhmm, when i send a lot of MIDI messages, rendering slows down noticeably14:18
wpwrakbasically stops while the message burst arrives14:18
wpwrak(lot of messages) e.g., kick a slider from 0 to 12714:19
wpwrakit's not that the system would fail. the rendering just slows down while there's a lot of MIDI traffic14:24
lekernelmaybe your controller sends a lot more messages than mine, it's perfect with the m-key I have14:24
lekernelno slowdown and low response time14:24
lekernelor 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 running14:25
wpwrakoopps. now it froze :)14:25
wpwrakbtw, how do i save the MIDI settings ?14:27
lekernelin the performance file14:28
wpwrakgrmbl. and i lost my patch. i could have sworn i saved it ...14:32
lekernelalso works for me, the flash cache is flushed every 10 second to address this very problem14:35
wpwraknow the slowdown is gone. (still reconstructing my patch, though)14:36
lekernelyeah... probably some unrelated bug14:37
lekernelmaybe the lag bug in another form?14:37
lekernelFYI what the lag bug does is make RTEMS spend 99% of the CPU time in the idle task even though there are runnable tasks14:39
wpwrakhmm, dunno. didn't check on serial.14:47
wpwrakhmm, i can't figure out how to save midi controls. no matter what i try, the next time i boot, they're gone18:45
wpwrakluckily, it's just four numbers to type in ...18:45
--- Sun Oct 30 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!