kristianpaul | wpwrak: i'm curios you like linux of course, but had you tried to run it on M1? | 00:03 |
---|---|---|
kristianpaul | http://neophob.com/2011/09/pixelcontroller-universal-opensource-light-control-solution/ | 00:40 |
wolfspraul | wpwrak: 4.4v reset test is running - cool! any early peek yet? | 00:47 |
kristianpaul | yeap :-) | 00:57 |
kristianpaul | yes tell us :-) | 00:57 |
wpwrak | see the latest mail :) | 01:34 |
roh | nice one | 01:38 |
roh | congrats | 01:38 |
wpwrak | thanks ! it's good when things start to make sense :) | 01:40 |
wolfspraul | yes, sounds good! | 01:41 |
wolfspraul | why consider another reset ic if we already design-verified the one you have now? | 01:41 |
wolfspraul | also, we are planning to make this change to a gate, no? | 01:42 |
wolfspraul | should we dismiss that now that we have done this extensive testing and found everything to be stable? | 01:43 |
wolfspraul | I want to make as few changes as possible from a solution that we believe is 100% stable and good | 01:57 |
lekernel | wpwrak, very cool :) thanks for all this testing! | 07:32 |
wpwrak | lekernel: thanks ! still a bit more testing to do :) but i'm starting to feel good about all this | 10:21 |
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. | 10:23 |
wpwrak | with the reset chip watching 5 V directly, such a relative minor upset could reset the whole M1. | 10:24 |
lekernel | there is a large electrolytic capacitor close to the USB ports to prevent this, and more caps elsewhere on the board ... | 10:30 |
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 :) | 10:32 |
wpwrak | that's basically why you put small caps very close to chips and bigger silo caps at a distance | 10:33 |
wpwrak | well, it's not the only reason. another reason are the current loops | 10:33 |
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 | 10:33 |
lekernel | yes, there are ceramic caps on 5V elsewhere on the board, too | 10:34 |
wpwrak | a usb device violating the specs ? what are the odds ? ;-)) | 10:34 |
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 | 10:35 |
wpwrak | (e.g., could be just the cable mess on my desk) | 10:36 |
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 | 10:45 |
wpwrak | damn. we need a lot more variables for the GFPU. | 12:18 |
wpwrak | i can already see patches with dozens of midiX parameters | 12:18 |
lekernel | this shouldn't be a fundamental problem | 12:19 |
lekernel | the PFPU register file is mapped in block RAM, which is quite efficient | 12:19 |
lekernel | we can have thousands of registers if you like :-) | 12:19 |
wpwrak | want ! ;- | 12:20 |
wpwrak | ) | 12:20 |
lekernel | another factor is simply pruning the registers which are not needed during preallocation | 12:20 |
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 | 12:21 |
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) | 12:21 |
wpwrak | for midi, could they be updated just when a message arrives ? | 12:22 |
lekernel | no | 12:22 |
lekernel | in fact the complete PFPU is reloaded twice per frame | 12:22 |
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 | 12:23 |
lekernel | then all the registers and program space are reloaded to compute the per-vertex equation | 12:23 |
lekernel | all this happens at each frame | 12:23 |
lekernel | you can, however, just update the corresponding value in system memory when the MIDI message arrive | 12:24 |
lekernel | and do the floating point conversion only once | 12:25 |
lekernel | (actually it may even already do that in fact... I don't remember) | 12:25 |
lekernel | so far the main CPU hogs are 1) drawing waves, borders, etc. (especially when they are translucent) and 2) audio filtering | 12:27 |
lekernel | maybe this PFPU reloading will continue to be a small overhead, even with thousands of registers | 12:29 |
lekernel | I don't know | 12:29 |
lekernel | we can also DMAize it without much trouble too :-) | 12:30 |
wpwrak | heh :) | 12:34 |
wolfspraul | wpwrak: do you think we still need to or should investigate the gate? | 12:48 |
wolfspraul | or we just leave everything as-is with your latest configuration? | 12:48 |
wpwrak | i'd rather have the gate than the current "analog computer" :) | 12:48 |
lekernel | you still have the capacitor fix? | 12:49 |
wpwrak | it shouldn't need much investigating, though. | 12:49 |
wpwrak | i guess i do ... i've kinda lost track of the latest state of chaos there :) | 12:49 |
wolfspraul | you mentioned finding a better reset ic | 13:04 |
wolfspraul | (the possibility of that) | 13:05 |
wolfspraul | is that worth it? | 13:05 |
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 | 13:06 |
wolfspraul | if you feel uneasy about your board, maybe Adam can send you a second one? | 13:07 |
wolfspraul | that would also make it easier to run your test series | 13:08 |
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 | 13:08 |
wolfspraul | I read it but it sounds hypothetical | 13:09 |
wpwrak | testing the "stable" rails would thus make more sense. but ... we need to test several of them, or it won't work | 13:10 |
wolfspraul | I would focus all my energy on known and understood problems and improvements, we have plenty of them | 13:10 |
wpwrak | (hypothetical) not sure | 13:10 |
wpwrak | i'm now eyeing each reset with suspicion :) | 13:11 |
wolfspraul | hmm, ok | 13:13 |
wolfspraul | I just hope we reach a stable point soon, not to loose focus | 13:14 |
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 | 13:14 |
wolfspraul | also whether adam verifies it, send you a second (reworked?) board or not etc. | 13:15 |
wolfspraul | almost feels like we have too much data now :-) | 13:15 |
wolfspraul | let me know which way you think is *reasonable* | 13:15 |
wpwrak | naw. now we have enough data to actually understand what's happening :) | 13:15 |
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 | 13:16 |
wpwrak | i need a bit more experimenting with voltage ranges and insults to the 5 V rail. e.g., connect/disconnect things | 13:17 |
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 | 13:18 |
wpwrak | if the 5 V rail is too unstable, then it's the three-inputs reset IC | 13:19 |
wpwrak | independent from that, the diode should become a gate | 13:19 |
wolfspraul | ok ko | 13:19 |
wolfspraul | ok ok | 13:19 |
wolfspraul | :-) | 13:19 |
wolfspraul | got it | 13:19 |
wolfspraul | so switch to gate is a must, unless we find proof that there is a problem | 13:20 |
wolfspraul | better reset ic is most likely a given too | 13:20 |
wolfspraul | that means we need to source it | 13:20 |
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 | 13:21 |
wolfspraul | he already has enough gates I believe | 13:21 |
wolfspraul | then Adam can rework two boards to the latest proposed rc4 standard, and ship one to you for double-checking, if you like | 13:21 |
wolfspraul | does that sound roughly right? | 13:21 |
wpwrak | sounds good, yes | 13:22 |
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) | 13:35 |
lekernel | all midi is 127 values | 13:39 |
wpwrak | yes .. kinda anachronistic. well, some cheat and split the range | 13:42 |
wpwrak | hmm, when i send a lot of MIDI messages, rendering slows down noticeably | 14:18 |
wpwrak | basically stops while the message burst arrives | 14:18 |
wpwrak | (lot of messages) e.g., kick a slider from 0 to 127 | 14:19 |
lekernel | mh? | 14:23 |
lekernel | worksforme | 14:23 |
roh | iek | 14:23 |
wpwrak | it's not that the system would fail. the rendering just slows down while there's a lot of MIDI traffic | 14:24 |
lekernel | maybe your controller sends a lot more messages than mine, it's perfect with the m-key I have | 14:24 |
lekernel | no slowdown and low response time | 14:24 |
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 | 14:25 |
wpwrak | oopps. now it froze :) | 14:25 |
wpwrak | btw, how do i save the MIDI settings ? | 14:27 |
lekernel | in the performance file | 14:28 |
wpwrak | grmbl. and i lost my patch. i could have sworn i saved it ... | 14:32 |
lekernel | also works for me, the flash cache is flushed every 10 second to address this very problem | 14:35 |
wpwrak | now the slowdown is gone. (still reconstructing my patch, though) | 14:36 |
lekernel | yeah... probably some unrelated bug | 14:37 |
lekernel | maybe the lag bug in another form? | 14:37 |
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 | 14:39 |
wpwrak | hmm, dunno. didn't check on serial. | 14:47 |
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 | 18:45 |
wpwrak | luckily, it's just four numbers to type in ... | 18:45 |
--- Sun Oct 30 2011 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!