<wolfspraul>
actually xiangfu is mostly offline the next 2 days, I think :-)
<wolfspraul>
Alarm: so unless someone else beats him, stay around a little but yeah, xiangfu has dmx equipment and has used it with m1
<Alarm>
wpwrak: I will stay online and wait, thank you :)
<xiangfu>
Alarm, Hi
<Alarm>
xiangfu: Hi,do you know how to use DMX Flickernoise?
Gurty has joined #milkymist
<xiangfu>
Alarm, if you using latest firmware. by default Flickernoise is working as Fixture mode.
<xiangfu>
Alarm, which mean the DMX port is by-pass mode and DMX patch can react on idmx* variables.
<xiangfu>
idmx == input dmx values.
<xiangfu>
Alarm, do you have a DMX controller? or you want use Milkymist one as Controller?
<Alarm>
xiangfu: I have a projector set to DMX address 1. I want the projector controller with M1
<lekernel_>
ah. so make sure you disable "chain" mode in the DMX settings.
<wolfspraul>
there u go, not offline yet :-)
<xiangfu>
Alarm, yes. 1. disable the 'Chain' under 'DMX settings'
<Alarm>
xiangfu: ok. idmx = adress ?
<xiangfu>
Alarm, wait you may lose this setting. when you restart M1. after click 'ok' the title changed from 'Control panel' to 'Control panel *'
<wolfspraul>
we should never loose any setting
<xiangfu>
you can save the settings by click the 'Save' under 'Control panel' that is for future using.
<xiangfu>
wolfspraul, yes. but you mean have different setting.
<xiangfu>
keyboard-mode
<xiangfu>
dmx-mode.
<xiangfu>
that have to be same as a performance configure file.
<xiangfu>
s/mean/may
<wolfspraul>
sounds scary :-)
<xiangfu>
Alarm, if you using Milkymist one as Controller. we use the 'dmx*' variables. not 'idmx*'
<xiangfu>
Alarm, since your projector is set to 1. you can use the 'dmx1' in patches for control your projector.
<xiangfu>
wolfspraul, agree. complicate.
kristianpaul has joined #milkymist
<Alarm>
xiangfu: the table DMX use for ?
<wolfspraul>
I'm not that worried, since exactly 0 real-life users will make it through those difficulties. that means we can change/simplify without breaking any user habits.
<wolfspraul>
that's a good thing
<xiangfu>
Alarm, it's used for manually control DMX fixture.
<wolfspraul>
feel free to simplify that stuff
<xiangfu>
Alarm, you can connect to projector to M1 now. and controller that my slip the 'DMX desk' --> '1-8' --> '1'
<xiangfu>
s/connect to/connect
<xiangfu>
s/my/by
* xiangfu
sorry. so many typo recently.
<Alarm>
Xiangfu if I vary the values of potentiometer 1 to 3 (RGB) I would have to vary the colors of the projector ?
<xiangfu>
Alarm, sorry. what you mean? you projector have only one address right?
<xiangfu>
Alarm, what is the value means of that address? usually it's should be like 0: off, 1~50: red ,51~100: green. ...
<Alarm>
xiangfu: set the DMX address by switches on my projector (here 1). In the manual, they say there are 6 channels. The first 3 channels regulate the RGB colors.
<xiangfu>
(if I vary the values of potentiometer 1 to 3 (RGB) ) the projector will change color. yes. you right.
<Alarm>
Hum, On the projector I have two IN and OUT connectors. Should I add a line termination resistor?
<Alarm>
M1 TX -> projector IN-> ? OUT
<lekernel>
if your cable is short enough, there shouldn't be a need for termination resistors
<wolfspraul>
as soon as m1 supports any kind of video format, even animated gifs, we should really convert that 30 second indian milkymist commercial and ship it on each m1 :-)
<wolfspraul>
maybe we find another way to use it too, since it's already out there and promoting milkymist... :-)
<wolfspraul>
maybe a series of frameshots from the clip, on a poster
<wolfspraul>
but with the correct milkymist.org url, of course
<GitHub194>
[migen/master] bus/dfi: reset active low signals to 1 - Sebastien Bourdeauducq
<kristianpaul>
lol
fpgaminer has joined #milkymist
<lekernel>
roh: is the Raumfahrtagentur DMZ on Mondays or Sundays?
mumptai has joined #milkymist
fpgaminer has joined #milkymist
kristianpaul has joined #milkymist
kristianpaul has joined #milkymist
<roh>
lekernel: ?
<roh>
lekernel: you mean.. nobody there?
<lekernel>
I'm not there. but you're saying "Der Sonntag der Kosmonauten - Immer Montags im Stattcafe". that's confusing :)
fpgaminer has joined #milkymist
fpgaminer has joined #milkymist
fpgaminer has joined #milkymist
<roh>
lekernel: yeah. thats intent. also... its not happening atm , since the cafe next door isnt open on mondays *sigh*
hypermodern has joined #milkymist
xxiao has joined #milkymist
fpgaminer has joined #milkymist
kristianpaul has joined #milkymist
kristianpaul has joined #milkymist
fpgaminer has joined #milkymist
dvdk has joined #milkymist
<GitHub169>
[milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/r1t3_Q
<GitHub169>
[milkymist-ng/master] tb/asmicon: global test bench - Sebastien Bourdeauducq
<GitHub169>
[milkymist-ng/master] asmicon: various fixes. Now produces convincing refresh/read sequences. - Sebastien Bourdeauducq
<mwalle>
lekernel: i'm trying to understand the usb core, one thing i noticed is why there are blocking assignments in a sequential block? (softusb_rx.v:152)
<mwalle>
and another thing, maybe wpwrak can answer this, too: why do you have to wait for RX_ACTIVE (eg. WAIT_ACTIVE()), isnt that already included in rx_valid and therefore in RX_PENDING (WAIT_RX())?
fpgaminer has joined #milkymist
<wpwrak>
a reception could also fail to produce valid data
<wpwrak>
not sure if we have such a case at the moment. perhaps if the bit stuffing goes wrong
<mwalle>
wpwrak: that is for the case where SIE_RX_ERROR is 1 and RX_PENDING is 0 ?
<wpwrak>
ah yes, that's in rx_error
fpgaminer has joined #milkymist
<wpwrak>
indeed, seems that we could get rid of WAIT_ACTIVE
<mwalle>
wpwrak: ahh but if WAIT_ACTIVE is omitted, you jump out of WAIT_RX because RX_ACTIVE may not be 1
<lekernel>
mwalle: seems you could use the non-blocking ones there as well
fpgaminer has joined #milkymist
<lekernel>
I don't remember why I used the blocking ones there. maybe some older code made use of them.
<mwalle>
lekernel: seems? isnt the rule of thumb: combinatorial -> blocking, sequential -> non-blocking?
<lekernel>
no
<lekernel>
you can use non blocking assignments in combinatorial always blocks as well
<lekernel>
your block will simply be run again after one delta cycle, until it has stabilized
<lekernel>
and in sequential code, blocking assignments can work like VHDL variables
<mwalle>
lekernel: but that only applies to simulation, right?
<lekernel>
the only problem is (in simulation) verilog doesn't guarantee the order of execution when an always block communicates through blocking assignments (in VHDL variables are local to a process, so this problem cannot exist)
<wpwrak>
mwalle: i mean that one could wait either for data, error, or timeout. that should cover roughly the same cases. but ... would need some testing. so that's an idea for the future great USB low-level test :)
<lekernel>
for synthesis it doesn't matter whether you use blocking or non blocking in combinatorial blocks
<lekernel>
but there is a difference in sequential blocks
<mwalle>
oh, that i didnt know :)
<lekernel>
if you look at the geninterp18 code
<lekernel>
l57 reads the value of err set from l56 in the same cycle
<lekernel>
if I used non blocking assignment on err, it would have been the value from the previous cycle
<mwalle>
yeah, and i thought that in hardware l57 still holds the old value
<lekernel>
no, the synthesizer will do the right thing when you use the blocking assignment
fpgaminer has joined #milkymist
<lekernel>
simulators, however, may not
<lekernel>
you should communicate between blocks using non-blocking assignments only (which my code doesn't do, but should)
<lekernel>
otherwise there is non-determinism coming from the order the different always blocks are run, which can lead to funny intermittent simulation problems (pipelines becoming pass-throughs, etc.)
<lekernel>
and, of course, simulation vs. synthesis mismatches
<mwalle>
so the synthesizer just infer temporary signals for you?