Topic for #milkymist is now Milkymist One, Milkymist SoC & Flickernoise development channel (LLHDL/Antares are welcome too) :: Logs: http://en.qi-hardware.com/mmlogs :: JFDI
elldekaa joined #milkymist
lekernel joined #milkymist
aw joined #milkymist
aw_ joined #milkymist
wolfspraul joined #milkymist
wolfspraul joined #milkymist
<wolfspraul>
aw_: good morning!
<wolfspraul>
thanks a lot for pushing Werner's package and the one for our new Australian customer out yesterday
<wolfspraul>
lots of details, all done - THANKS!
<wolfspraul>
now, let's chat about rc4 status
<aw_>
wolfspraul, hi good morning !
<wolfspraul>
I understand the reset ic, usb power switch and adv7181c already are 'almost' design-verified
<aw_>
I ought to and tried to send them.
<wolfspraul>
are you 100% confident about those 3 changes?
<aw_>
not 100% confident though. because we only have finished one board without reliability test like Werner did tons of power-cycles.
<wolfspraul>
well sure
<wolfspraul>
but so far it all looks good, right?
<wolfspraul>
so you will finish a second board, and eventually Werner will get his and test some more...
<wolfspraul>
but it sounds like those 3 are 'almost' finished, to me :-)
<aw_>
yes, all looks good so far now.
<wolfspraul>
do we want to remove the audio expansion header in rc4 ?
<aw_>
mmm ... this I've not looked into but just knew Joerg's good idea.
<wolfspraul>
that's not Joerg's idea
<wolfspraul>
Joerg said something about R11, but I am wondering whether we should just *remove* the entire audio expansion header
<aw_>
1. If I am a hacker with enthusiasm on audio, I would still like to keep it. But this seems that very rare condition to use it
<aw_>
hup ? so misunderstood by me.
<wolfspraul>
we have too many loose ends on Milkymist One already, removing this expansion header means one less of them
<wolfspraul>
no you are right, but Joerg tried to fix the audio expansion header and I am wondering whether we should remove it :-)
<wolfspraul>
let's see what Werner or Sebastien think
<wolfspraul>
I rather focus our super limited resources on making more out of the fpga expansion header
<wolfspraul>
aw_: ok, which other big items do we still have now?
<wolfspraul>
1. dvi-i, single-link or dual-link. 6-layer vs. 8-layer pcb, question whether we should move fpga pins and break (some) bitstream compatibility
<wolfspraul>
2. new leds
<aw_>
Until now, I don't see any hacker except Werner who may try to use this audio expansion header to link/connect with other instruments.
<wolfspraul>
Werner is not using the audio expansion header and doubt has plans to do so
<wolfspraul>
but let's see what he says later
<wolfspraul>
aw_: did you hear about the idea of increasing the number of USB connectors?
<wolfspraul>
it's just an idea, and most likely will cause too many space problems
<wolfspraul>
we definitely don't want to change pcb size
<wolfspraul>
but if you go to the layout house, maybe they can just think about that as well, 3 or 4 usb ports...
<aw_>
about idea of those expected adding fpga pins, I think that we should a clear 'fpga pins of allocations' to estimate how many pins will be added in usb/DVI/led/usb.
<aw_>
I'll estimate adding pins then go to make an appointment with house.
<wpwrak>
wolfspraul: you're 100% right ;-)
<aw_>
I seemed heard from you about increasing the number of usb con. But don't know the final.
<wolfspraul>
wait
<wolfspraul>
aw_: one by one
<wpwrak>
wolfspraul: i don't care about J3. if it's there, it doesn't bother me. if it goes, i won't mourn its passing
<wolfspraul>
aw_: please let's plan to remove j3 in rc4, unless Sebastien objects
<wolfspraul>
we have too many loose ends, and that is one of the best to start cutting, imho
<wolfspraul>
aw_: can you add that to the wiki page or should I do it?
<aw_>
wolfspraul, you meant directly add 'remove' idea in known issue wiki page firstly ?
<wolfspraul>
yes
<wolfspraul>
remove J3 (audio expansion header)
<wolfspraul>
I don't remember Sebastien fighting for it strongly anywhere, but if I'm wrong and he objects we just keep it, otherwise remove
<wolfspraul>
I know the product and future path well enough to feel that this is a good move :-)
<wolfspraul>
aw_: then, second thing
<wolfspraul>
about "adding fpga pins" - let's clarify the language
<wolfspraul>
by default, we don't want to change any current pin/wire assignments
<wolfspraul>
so when we 'add' new wires, they have to be routed to pins that are currently free (!)
<wolfspraul>
that's the first idea
<aw_>
I don't know what the reasons about 'remove' J3 is. Just because Werner don't care ?
<aw_>
yes, go on
<wolfspraul>
nobody uses it today or tomorrow
<wolfspraul>
aw_: no it's not just because Werner doesn't care, that would be a bit drastic :-)
<wpwrak>
and i think it contains some signals that don't really make sense. i think that was what started the discussion. don't remember the details, though
<wolfspraul>
we discussed J3 before several times, and there was always confusion, lack of interest, etc.
<wpwrak>
(drastic) poof, there go 99.99% of the world ;-)
<wolfspraul>
so the bottom line of that now is that I say "let's remove it"
<wolfspraul>
and then I find out whether someone objects
<wolfspraul>
but in order to get those people to speak up, let's just start by removing it :-)
<wolfspraul>
so add to the wiki page etc.
<aw_>
1. usb switches circuit: 6 pins are added, FLG * 2, LED (usb-A/B) * 2, EN * 2
<aw_>
okay .. I'll remove J3 later
<wolfspraul>
yeah :-)
<wolfspraul>
thanks
<wolfspraul>
the only reason to keep it would be an objection from Sebastien, which we will find out about in a few hours
<wolfspraul>
otherwise it's gone
<wolfspraul>
(or maybe someone makes a killer argument why to keep it, who knows :-))
<aw_>
2. reset circuit: IO_L48N_1 * 1
<aw_>
wait ... I don't want to discuss too many though. :-)
<wolfspraul>
yes
<wolfspraul>
sorry
<wolfspraul>
J3 is settled for now
<wolfspraul>
now ... new fpga pins
<wolfspraul>
go on
<aw_>
for me, I need firm data which is the added(expected) pins that I talk to house. :-)
<aw_>
so let's estimate how many we 'probably' add in. :-)
<aw_>
so:
<aw_>
a) usb power switch: 6 pins.
<aw_>
b) reset circuit: IO_L48N_1 * 1pin
<wolfspraul>
the 6 pins from usb already include 2 leds, right?
<wpwrak>
maybe mention J3 on the list ? some people may not pay attention to everything that happens here
<aw_>
yes, 2 of 6 pins are 2 leds came from fpga
<wolfspraul>
oh wait
<wolfspraul>
the J3 is already on the wiki :-)
<wpwrak>
the LEDs wouldn't be just USB. it would be one LED per connector. USB, video, MIDI, ...
<wolfspraul>
we discussed this several times already :-)
<wolfspraul>
wiki says "DNP J3 in RC4, and all resistors connected only to it (which is R6 to R12, but keep R2 to R5 and R14 to R16) "
<wpwrak>
wiki is the attic ;-)
<wolfspraul>
I think not only 'dnp', but totally remove
<aw_>
c) there's an idea about leds array (maybe), so this may also combine those two led from usb switch circuit.
<wolfspraul>
led array?
<wolfspraul>
what is that?
<aw_>
led array likes one arrow with 8 leds.
<wpwrak>
i think the led array was a misunderstanding. all we really talked about was a lot of leds
<wolfspraul>
aw_: we only want 1 type of led on the whole board
<wolfspraul>
so same as the D1/D2/D3 we have now, or we change all leds to that one from digikey
<aw_>
i see
<aw_>
so how many real leds related to CONs we want ? so let's define now. Can we ?
<wolfspraul>
wait
<wolfspraul>
it's all on the wiki already
<wolfspraul>
let's go through the items like you started
<wolfspraul>
so 6 new wires for usb, including leds
<wolfspraul>
b) reset circuit: IO_L48N_1 * 1pin
<wolfspraul>
I didn't know there was a new wire from the reset circuit to the fpga :-)
<aw_>
oah ~ sorry. so total is 14 pcs led
<wolfspraul>
what is that for?
<wpwrak>
the led situation is still unclear. lekernel wants white leds, but that would mean that they need a fet/bjt to switch (and supply from 5V)
<wpwrak>
we also don't have the locations yet
<wolfspraul>
aw_: yes, *proposed* is 14, including 2 usb, from wiki "total of 14 new leds proposed: 2*dmx, 2*midi, 3*video-in, power, 2*usb, ir, dvi-i, ethernet, memcard "
<wolfspraul>
but we need to see what fits etc
<aw_>
ha ~ good
<wolfspraul>
so first we try to list all our *goals*
<wpwrak>
issue #3 is that, if at some point in time we go for an M2 with a metal (= not transparent) mounting plate, adding LEDs will be harder. so that might imply a feature regression
<wolfspraul>
and then we prioritize the goals
<wolfspraul>
the leds are not a very high priority for me
<wolfspraul>
but I like the idea you proposed about demand/activity/problems
<wolfspraul>
aw_: highest priority now (with reset/usb power/adv7181c done) is dvi-i
<aw_>
i need to calculate how many we would like, so i have firm account to discuss with house.
<wolfspraul>
I think we should first try to get our highest-priority problems solved
<wolfspraul>
and then the lesser ones, if still possible
<aw_>
wolfspraul, okay on priority
<wolfspraul>
of course we can keep the lesser ones in mind from the beginning
<wolfspraul>
but there is no point in adding leds and then removing them again when we start working on dvi-i :-)
<wolfspraul>
I didn't even know we already added 2 leds for usb
<wolfspraul>
but ok, fine. leave them there now, use same leds as d1/d2/d3 for simplicity
<aw_>
okay on same leds.
<wolfspraul>
next big thing is dvi-i
<wolfspraul>
single-link or dual-link
<wolfspraul>
6-layer vs. 8-layer (need info on costs and risks to go to 8-layer)
<wolfspraul>
in my opinion dual-link would be good because easily accessible pins would be exported and could be used for hacking purposes
<wolfspraul>
even if we don't need dual-link for pure high-res reasons
<aw_>
wpwrak, btw, the shipment to you that I didn't soldering tow wires from J21 for usb switch two pins, fyi. :)
<wolfspraul>
in the dvi-i/single/dual-link work, there is a twist
<wolfspraul>
aw_: let me explain
<wolfspraul>
werner proposed to move *existing* vga/codec wires to a new place, basically cleaning up some of the current wiring
<wolfspraul>
or maybe move the memcard to a new place
<wolfspraul>
anyway he wants to make space for the new digital video wires on the same side as the dvi-i connector will be
<aw_>
when heard of that 8-layer to approach for dvi purpose, it's tough though. :)
<wolfspraul>
moving existing wires (memcard I believe) is a challenge for the Milkymist project overall, in my opinion
<wolfspraul>
not necessarily a bad challenge, but a challenge
<wolfspraul>
we have to support old and new users, possibly do more builds, explain people which one they need, or auto-detect, etc.
<wolfspraul>
a lot of small little usability details that we are already weak at
<wolfspraul>
do we want that challenge now?
<wolfspraul>
I don't know
<wolfspraul>
depends on how bad dvi wiring is without moving memcard (or whatever it was)
<wolfspraul>
but I don't want to be the only one who has to care about users that fall into traps because later we are too lazy to communicate and smooth over the breakage we caused
<wolfspraul>
wpwrak: aw_ what do you think?
<wolfspraul>
aw_: do you understand what I'm talking about?
<aw_>
wolfspraul, understood the background of dvi need in m1 now.
<wpwrak>
my concern would be that you have to run a lot of signals across the FPGA if you don't rearrange. this can produce the most interesting signal integrity problems
<wolfspraul>
yes
<wpwrak>
and, of course, increases routing pressure just where it's already the worst
<wolfspraul>
aw_: do you understand that?
<wolfspraul>
we need to make sure this message goes to Adam and layout folks without too much loss-in-translation
<wolfspraul>
otherwise very bad things may happen :-)
<wolfspraul>
aw_: basically we are thinking how to route the new digital video signals to the fpga
<wolfspraul>
I think with single-link we have 6 new wires, with dual-link 12. is that correct?
<aw_>
i could only to probe/know some real routes if house they really did dvi in 6 layers. like wpwrak just said 'rearrange' and 'increasing routing pressure' already let m1 get the WORST even if we stick on 6 layers.
<wolfspraul>
of course, we have to define what we want first
<wolfspraul>
we want dual-link
<wolfspraul>
we want to stay with 6 layers
<wolfspraul>
we want to not move existing pins
<wolfspraul>
now... most likely we cannot get all three of those things
<wolfspraul>
so we are thinking ahead how/where to make compromise
<wpwrak>
i think you need the clock too. so 8 for single, 14 for dual
<wolfspraul>
aw_: so let's first define the goals, as I wrote above
<wolfspraul>
1. dual-link, total of 8+6=14 new wires
<wolfspraul>
2. stay with 6 layers
<wpwrak>
all you really care about are those fast signals. the rest can come from the other end of the board ;-)
<wolfspraul>
3. do not move existing pins on fpga like memcard
<wolfspraul>
most likely we cannot achieve all these goals
<wolfspraul>
that depends on feedback from layout
<aw_>
wpwrak, I don't think lekernel will agree even to rearrange those a lot of signals due to added routes for dvi. But your three 'wants' will never be happened to take if we still take conditions into 'most interesting digital/analog signal integrity'.
<wolfspraul>
yes
<wolfspraul>
we know that
<wolfspraul>
but first we define the goals
<wolfspraul>
then we find out the problems
<wolfspraul>
then we compromise
<wolfspraul>
we can do single-link, no problem
<wolfspraul>
dual-link is really only for hacking, because in my opinion it neatly exposes some wires, easily accessible outside
<wolfspraul>
we can move memcard wires
<wolfspraul>
I also have no problem with that, I like the challenge of making milkymist in general more flexible/robust/documented to survive such changes
<wolfspraul>
but it's a lot of work too!
<wolfspraul>
unless we don't care about our users and just create a fragmented mess where everybody who doesn't like to go through messy tools and sources will just die
<wolfspraul>
we can go to 8-layer, but that depends on feedback from layout or Adam about costs and risks
<wolfspraul>
hey
<wolfspraul>
worst case
<wolfspraul>
no dvi at all :-)
<wolfspraul>
aw_: we try to explain the goals and compromise thoughts here, to get us all onto the same idea...
<wolfspraul>
do you roughly understand those thoughts?
<aw_>
wolfspraul, yes. i know what you are doing to me and get the same picture.
<wolfspraul>
yes, good. great.
<wolfspraul>
so are we all 100% in sync already?
<wolfspraul>
Werner, Adam, Wolfgang ?
<wolfspraul>
anything I forgot?
<aw_>
thinking ... second
<wolfspraul>
let me try to lookup which signals werner proposed moving
<wolfspraul>
werner "Would moving some of the bank 0 I/Os to bank 2 to make room be an
<wolfspraul>
option ? If bank 0 is U22A, SD_* and LED1/2 may be suitable
<wolfspraul>
candidates for a relocation."
<wpwrak>
what voltage is this anyway ?
<wpwrak>
ah, sebastien's mail already has the bank. perfect
<wolfspraul>
I don't understand the exact consequences of moving pins
<wolfspraul>
that's a problem (for me :-))
<wolfspraul>
if we succeed, it's definitely good for milkymist as a platform. but this is a communication and documentation challenge as much as a pure source/hacking challenge, and I'm not even sure everybody understands what that means :-)
<wolfspraul>
it's super easy to change a few numbers in the sources, of course
<wolfspraul>
but how about builds? how about testing? how do people find out which build/image/binary they need? can we auto-detect? etc.
<wolfspraul>
do we even have the patience to go through those things?
<wpwrak>
i think the consequences would be:
<wpwrak>
- some build-time switch
<wpwrak>
- twice the distribution build time
<wolfspraul>
can the 'twiceness' be localized to the bitstream?
<wpwrak>
- "rushed" changes would only be available for one hw version (most likely the latest)
<wolfspraul>
in other words, is this change transparent for bios/rtems ?
<wpwrak>
yes, i think the rest of the system could probably stay the same
<wolfspraul>
so the web update could detect which hw revision it's running on and download the appropriate bitstream?
<wpwrak>
maybe you cuold even have a run-time switch in the fpga, but that may create routing pressure issues in there and may have other unintended consequences. so i wouldn't count on that possibility
<wolfspraul>
how big is the testing risk? i.e. if the person doing build testing only has the latest hw revision, can he assume the differences to older hw revisions are small enough to avoid having to do separate testing on the older hw?
<aw_>
wpwrak, i think i need to absorb sebastien's mail and see the directional trend of routes on wiring bank2.
<wolfspraul>
aw_: yes, think about all this a little, that's good
<wolfspraul>
it is important that we do dvi well
<wpwrak>
i think once the two versions have been tested, there's little risk of regression on the part that's not receiving continuous attention
<wolfspraul>
I totally agree that we don't need that TI TMDS buffer
<wolfspraul>
the only reason the TI TMDS buffer is on that devel board is because TI paid and that's how devel boards are financed...
<wolfspraul>
wpwrak: ok, so..
<wolfspraul>
you still think moving memcard and 2 leds to another bank is a good idea?
<wpwrak>
i'll bookmark this comment for the day we find some reason why we need that driver chip ;-))
<wolfspraul>
oh sure, i understand
<wolfspraul>
everything has risks
<wolfspraul>
but blindly adding 'safety' chips is also a risk
<wolfspraul>
a bigger one than following practical design experience of people who have made working products without this chip
<wolfspraul>
if we one day understand very well why this tmds buffer chip should have been there from day 1, so be it
<wolfspraul>
I looked into it a while ago and some people gave me feedback, and I remember "not needed"
<wolfspraul>
that's just me though
<wolfspraul>
wpwrak: in general I even like the idea of moving/cleanup up fpga pins, because we will have more of that kind of challenge in the future
<wolfspraul>
so maybe we can just take it on now :-)
<wolfspraul>
plus, Sebastien may say, the memcard is even disabled in software right now
<wolfspraul>
so worst case we break something nobody can be using anyway, he he
<wolfspraul>
Milkymist logic
<wolfspraul>
but seriously, if we can survive such a pin move and support everybody well, it's actually a win for Milkymist imho
<wpwrak>
(banks) if you look at the schematics and the board, you see that everything video is nicely on the same side
<wpwrak>
(banks) U22C is just on the other end of the chip -> routing hell
<wpwrak>
(driver chip) not sure if they measured our kind of scenario, i.e., with possibly long cables and such
<wolfspraul>
let's see what Sebastien says about moving memcard/led pins, we need his help on those matters anyway
<wolfspraul>
I described my current thinking about the idea
<wolfspraul>
I like it, but I think it's a challenge. good or bad challenge, or good or bad timing - I am not sure.
<wpwrak>
(survive the move) this sound to me a bit like the fear of going from one .c file to having multiple compilation units ;-) at some point in time, pin reassignment is inevitable. the only thing you can choose is whether you become good at doing it earlier or later
<wolfspraul>
yes
<wolfspraul>
it's just about timing of the challenge, agreed
<wolfspraul>
but I don't want to rush into this and cause breakages and ignore the pain of our users
<wolfspraul>
I think you know what I mean
<wolfspraul>
the ti tmds buffer chip is meant for cases where the connector is far away from the signal processing chip, for example in a large TV
<wpwrak>
what does the distance to the connector matter if there are meters of cable afterwards ?
<wolfspraul>
that doesn't mean that it cannot be helpful in other cases as well, I don't know how the different parts are standardized, cables etc. but we should plan without this chip, the only reason we discuss it is because TI made sure it's on one particular devel board
<wolfspraul>
wpwrak: yes but we are talking about standards, and they set requirements for connectors, cables, etc. I would think...
<wpwrak>
(only because it's there) yeah, that's true :)
<wolfspraul>
if the signal arrives in too bad of a shape due to an out-of-standard cable, I wouldn't count on a wonder-chip to help me either...
<wpwrak>
hehe :)
<wolfspraul>
and actually on that devel board, one hdmi input goes through that tmds buffer, the other one doesn't :-)
<wolfspraul>
that's all fine for a devel board, but for now we can and should plan without this chip
<wolfspraul>
it's meant for large tvs where the connector is 1m or more apart from the signal processing chip
rejon joined #milkymist
<wolfspraul>
even if we need this chip, there is no shortcut for us to understand why we need it
<wolfspraul>
or worst case we have to try on a that devel board, for example, where we can quickly switch to an hdmi path with and without that chip
<wolfspraul>
but adding blindly is wrong
<wolfspraul>
(especially with prior experience that it is not needed, see the links from stekern)
<wpwrak>
yeah. life's easier with fewer chips anyway :)
n0carri3r joined #milkymist
xiangfu joined #milkymist
wolfspraul joined #milkymist
lekernel joined #milkymist
aw_ joined #milkymist
aw joined #milkymist
wolfspraul joined #milkymist
n0carri3r joined #milkymist
elldekaa joined #milkymist
errordeveloper joined #milkymist
elldekaa joined #milkymist
<xiangfu>
Hi
<xiangfu>
I am play the DMX device now.
<xiangfu>
and try to learn the DMX stuff.
<xiangfu>
there are address and channels.
<xiangfu>
DMX-light is kind of simple then the DMX-MOVING-HEAD
<Scopeuk>
what are you trying to do xiangfu?
<xiangfu>
wow. those kind of device have the 'Sound Activated modes'
<xiangfu>
one LED light, one Moving-Head, one Laser.
<xiangfu>
one DMX controller.
<Scopeuk>
got it all up and running?
<xiangfu>
Scopeuk, learning now.
<xiangfu>
Scopeuk, I tried LED light and Moving Head.
<xiangfu>
I can control that under 'DMX desk' under flickernoise.
<xiangfu>
and the only one DMX-output patch works out of box.
<xiangfu>
I want understand the 'channels' and how to connect them all to m1.
<Scopeuk>
ok
<Scopeuk>
dmx protocal has 512 channels
<Scopeuk>
each channel has a data value between 0 and 128
<Scopeuk>
well 0 and 127**
<xiangfu>
Scopeuk, is those kind device can connect like light----moving_head----laser---m1?
<Scopeuk>
yes
<Scopeuk>
each device has an address
<Scopeuk>
this is itsfirst address
<Scopeuk>
first channel**
<Scopeuk>
each light (lets call them fixtures to include the laser) will use a number of channels probably 3 or 4 for the led light, around 6 to 12 for the moving head and i'd guess between 4 and 10 for the laser
<Scopeuk>
generally you set each fixture so that none of its channels overlap with the other fixtures, then you run a wire from dmx out on the controler to dmx in on the first fixture
<Scopeuk>
then from that fixtures dmx out to the next fixtures dmx in
<Scopeuk>
generally your much better off running a single chain through each light. if you need to split it is highly recomended you use a "dmx buffer" which is basicalyl a big set of opto isoltors
<xiangfu>
Scopeuk, ok.
<xiangfu>
Scopeuk, there are 'address' and 'channels' right?
<Scopeuk>
the address of a light is the number of the first channel it will listen to
<xiangfu>
ok.
<xiangfu>
"each channel has a data value between 0 and 128"
<xiangfu>
but in the manual. it said ' 0 ~ 255 '
<xiangfu>
like:
<xiangfu>
| CH2 | play speed | 0 ~ 255 |
<xiangfu>
we need a DMX value display under 'DMX desk'
<Scopeuk>
sorry it is 255, 127 is midi
<Scopeuk>
sorry
azonenberg joined #milkymist
Martoni joined #milkymist
<xiangfu>
Scopeuk, sorry. what do mean " each device have an address, this is the first channel"
<xiangfu>
just a little bit confuse in 'address' and 'channel'
<Scopeuk>
let me phrase it diferently
<Scopeuk>
your lightting desk or M1 outputs 512 channels, the device has an "address" setting, this address is a channel number, the adress specifies the first channel which has an effect on the light (the address will determine which channel on your desk relates to CH1 in your lights manual)
<xiangfu>
Scopeuk, thanks. I got it.
<Scopeuk>
ok i gotta run, good luck
<xiangfu>
is this device have 5 channels. and I set the address to 1. then it will react when m1-DMX-DESK-1/2/3/4/5 changed
<xiangfu>
s/is/if
<xiangfu>
if I set the address to 10. it will react when m1-DMX-DESK-10/11/12/13/14 changed.
<xiangfu>
Scopeuk-AFK, thanks
<xiangfu>
ok. just play those three devices.
<xiangfu>
(only problem is those devices is really Noisy)
<xiangfu>
m1 works out of box with those kind of DMX device.
<xiangfu>
we have to improve our flickernoise to support more output in patches.
<xiangfu>
so far. it like. m1 can control 8 DMX-lights, because there are 8 DMX variable output. and DMX-light only needs one channel.
<xiangfu>
the laser using 3 channels. and moving-head using 5 or 13 channels(depends on the configure)
<xiangfu>
what is the 'Chain' and 'DMX spy' for?
<lekernel>
chain -> connect the M1 DMX out to M1 DMX in (otherwise DMX out is controlled from the patch)
<lekernel>
DMX spy -> display last modified channels in DMX in
<azonenberg>
wpwrak: what i was saying earlier today
<azonenberg>
was that it passes timing
<azonenberg>
faster than the numbers the datasheet says it should
<azonenberg>
i havent yet tested to see if it actually works
<azonenberg>
lekernel: So apparently my really fast adder is pointless
<azonenberg>
BUFGs, according to the datasheet, top out at 400 MHz
<azonenberg>
and i'm pretty sure the normal xilinx 32-bit adder still works at that speed
<azonenberg>
But somehow my design passes timing at 500
<azonenberg>
so either trce doesnt check component switching limits on PLLs and BUFGs
<azonenberg>
or i'm misreading something
<xiangfu>
about Media wall and DMX devices.
<xiangfu>
there are 4 lights. 1 laser. (not sure if there is moving-head device inside media wall, didn't see that in media wall)
<xiangfu>
let's said there are 4 lights + 1 laser + 1 moving-head inside media wall.
<xiangfu>
then for now. patches can controller 4 light + 1 laser or only moving-head.
<xiangfu>
light needs one channel
<xiangfu>
laser needs three channel
<xiangfu>
moving-head needs 5 channels
<wolfspraul>
interesting
<wolfspraul>
what exactly can those things do?
<wolfspraul>
the light can be turned on/off?
<xiangfu>
we have 8 DMX output variables in flickernoise.
<wolfspraul>
each pixel/led individually? or only all of them together?
<xiangfu>
we should make it to 512. :D
<wolfspraul>
can the color be controlled?
<wolfspraul>
intensity?
<xiangfu>
( light can be turned on/off?) yes.
<lekernel>
azonenberg: you can route clocks without BUFGs, only you'll get a lot of skew *g*
<wolfspraul>
I don't mean in theory in the protocol, but with the specific equipment you bought and have now...
<azonenberg>
lekernel: lol
<azonenberg>
Not an option :p
<azonenberg>
I mean even 400 would be nice
<xiangfu>
the light have 6~8 colors ( I count them manually. nothing in manual :)
<xiangfu>
yes. color can be controlled.
<lekernel>
ah? I thought your design was about squeezing every picosecond out of the timing :)
<wolfspraul>
you can switch between those fixed colors? like green, blue, red?
<xiangfu>
pixel/led individually. not this device.
<lekernel>
you should rewrite a new P&R algorithm that doesn't use the BUFG, since they are slow ;)
<azonenberg>
Lol
<wolfspraul>
how about intensity?
<azonenberg>
lekernel: I also have to be able to fill the entire device with a working design
<xiangfu>
wolfspraul, yes.
<xiangfu>
switch between those fixed colors <-- yes
<xiangfu>
intensity <--- no.
<wolfspraul>
wow so it's either full on, or totally off?
<xiangfu>
it can be configure to 'auto color chase'
<xiangfu>
wolfspraul, full on or totally off: yes.
<wolfspraul>
more like a giant blinking led :-)
<xiangfu>
wolfspraul, yes.
<wolfspraul>
would be great if each pixel could be controlled individually, colors could be set more freely, intensity could be controlled :-)
<wolfspraul>
but ok, we start
<wolfspraul>
so we have 4 of those giant blinking leds, ok
<wolfspraul>
you can probably lit your entire room with one of them, no?
<xiangfu>
wolfspraul, sort of.
<wpwrak>
azonenberg: if you can try to make it run at way out of whack speeds, perhaps you can find out if that speed limit is being checked ? it wouldn't be uncommon for a data sheet to give you a pessimistic estimate, and the real device still performing well under worse conditions
<wolfspraul>
xiangfu: and how about the laser
<wolfspraul>
how exactly does it work?
<wolfspraul>
can you control the color? intensity? direction? (how freely)
<wolfspraul>
is it 1 beam or what?
<wolfspraul>
I think you have to take some videos :-)
<wolfspraul>
how quickly can the laser move?
<xiangfu>
control color <-- no
<xiangfu>
intensity <-- no
<xiangfu>
direction <-- no
<xiangfu>
not 1 beam.
<wpwrak>
controlling the color of a laser is kinda hard ;-) not impossible, but ...
<azonenberg>
wpwrak: What i mean is, there are two differnet specs
<azonenberg>
timing analysis and the datasheet disagree
<azonenberg>
so 500 is either barely within spec or 20% out of spec
<xiangfu>
it like some 'Pattern'
<azonenberg>
and i have no idea how far i'm pushing it
<azonenberg>
this is for a relatively accuracy-critical application so i dont want somethign that will misbehave if it gets warm etc
<azonenberg>
also...
<azonenberg>
how much do you guys know about spartan6 IO clocks?
<azonenberg>
Can you drive LUT logic with them?
<xiangfu>
some 'random pattern'
<xiangfu>
some 'random pattern' keep changing. I can control the change speed.
<xiangfu>
there are only 'green' and 'red' laser.
<wpwrak>
maybe the pattern is for safety. so that you can't aim the laser too long at the same spot
<wolfspraul>
wow so also not much control there ,interesting
<wolfspraul>
is that a limitation of the DMX protocol, or just of those lasers?
<xiangfu>
4 lasers: two green. two red.
<xiangfu>
wpwrak, (aim the laser too long) that is a weapon right? (just kidding)
<wpwrak>
azonenberg: i guess you;ll have to ask xilinx on how to interpret those limits. could be that they don't really expect people to read the data sheets and the tools are designed to enforce the real limits. but then, maybe not.
<xiangfu>
wolfspraul, DMX protocol is send out 512 channels with different value.
<xiangfu>
wolfspraul, how to use those value depends on the device design.
<azonenberg>
Well, in any case once exams are over i will be testing on the real chip
<azonenberg>
Of course, i have a problem there too
<azonenberg>
there is a heatsink on my board
<azonenberg>
i cant see if the chip is a -2 or a -3 :p
<wpwrak>
(4 lasers) oh, wow. isn't that twice the armament spaceship enterprise had ? :)
<azonenberg>
the datasheet is unclear
<lekernel>
what's that board?
<wolfspraul>
xiangfu: but the laser has 3 channels, right?
<wolfspraul>
why 3? one for green, one for red, one for?
<xiangfu>
wolfspraul, yes.
<xiangfu>
CH1: mode select
<xiangfu>
CH2: pattern select
<xiangfu>
CH3: speed controll
<wolfspraul>
ah ok
<wolfspraul>
what kind of integration makes sense for Milkymist, or for a particular patch?
<wolfspraul>
maybe just at the beginning of the patch you set the laser to a certain behavior?
<wolfspraul>
one needs to try that out with a real device I guess, and see what looks good and makes sense
<xiangfu>
we have DMX1~8 .
<xiangfu>
wolfspraul, I have tried the DMX-OUT patch with light.
<xiangfu>
for example. at the begin. we can set CH1 to 50 mean DMX mode.
<xiangfu>
then always change the CH2 by audio-in. the laser will change pattern depends on audio-in
<wolfspraul>
make some videos
<wolfspraul>
then we also need to try with jj and see what she likes, or what kidn of music she wants to play
<wolfspraul>
we can download a selection of free electronic music for example, if that's easy to find :-)
<xiangfu>
wolfspraul, first , needs to finish some patch.
<xiangfu>
the only one in patchpool. not react to audio-in.
<wpwrak>
making a collection of good electronic tracks would be useful for use in demos
<wpwrak>
it's not easy to find good tracks. there's a lot of free stuff around that's only instrumental, but that gets boring quickly when used for a demo
<xiangfu>
wolfspraul, the laser and moving-head device have 'Sound Activated Mode'
<wpwrak>
in a demo, you want something quick, with a strong character. after all, the viewer will most likely be sober, will have context-switched from something else and thus hasn't settled into a clubbing mood, etc.
<xiangfu>
mode basically is like : Shutdown, DMX, Sound Activated, Auto.
<xiangfu>
will try to finish one patch, make DMX react to audio-in
<xiangfu>
chain -> connect the M1 DMX out to M1 DMX in (otherwise DMX out is controlled from the patch)
<xiangfu>
this is cool. that make this happen. DMX_Controller --------- M1 ------ DMX_fixture_1 ------- DMX_fixture_2 ....
<wolfspraul>
don't understand
<wolfspraul>
in the current media wall, we have a dmx controller that is hooked up to the 4 leds and 1 laser, right?
<xiangfu>
it's like M1 can take control from DMX_Controller. and give back the control to DMX_controller.
<xiangfu>
wolfspraul, yes. then we just connect m1 between Controller and DMX_fixtures.
<wolfspraul>
yes that sounds good
<wolfspraul>
but for that m1 would need to continuously forward packages from dmx_in to dmx_out, no?
<wolfspraul>
is it doing that right now?
<xiangfu>
lekernel, ^^^^ :)
<xiangfu>
I don't know it's flickernoise side or FPGA side.
* xiangfu
checking now.
<xiangfu>
this is controlled by hardware. not software side I think. needs make sure with Sebastien.
<xiangfu>
Thru Mode:
<xiangfu>
'to be able to act as a traditional DMX receiving device. the transmitting DMX core can simply forward the incoming DMX signal
<xiangfu>
instead of transmitting the data from the host CPU.
<wolfspraul>
ideally we would want to plug the m1 into an existing wiring, and then be able to listen to or send out messages, in addition to passing through stuff. true?
<xiangfu>
if we do this: DMX_Controller------ DMX_fixture_1 ------- DMX_fixture_2 .... --------- M1
<xiangfu>
I don't know what happen. there are two DMX signal send out by DMX_controller and M1.
<xiangfu>
ok.
<xiangfu>
if we do this: DMX_Controller------ DMX_fixture_1 ------- DMX_fixture_2 --------- M1 --------- DMX_fixture_3 ------- DMX_fixture_4
<xiangfu>
Controller will control 1 and 2 and M1 will control 3 and 4
<xiangfu>
there will not two DMX signals. because M1 block the Controller signals.
<xiangfu>
in theory.
<lekernel>
if you enable "chain" mode, it will let the controller signals reach 3/4
<xiangfu>
lekernel, yes.
<lekernel>
but you won't be able to control 3/4 from the patches, only receive signals from controller
<xiangfu>
ok. then M1 is like the DMX device with 8 channels. COOL.
<wolfspraul>
I still don't get it
<wolfspraul>
so M1 can sit in between an existing DMX wiring and route/pass-through so that the devices that were on the bus don't notice any difference at first?
<xiangfu>
wolfspraul, true.
r33p joined #milkymist
<xiangfu>
wolfspraul, it like M1 can configure to be a DMX_device or DMX_controller.
<wolfspraul>
how about the media wall? will m1 be able to fit into/integrate with the existing dmx wiring and devices?
<xiangfu>
to reset the configuration on cancel or on open
<xiangfu>
the bug is like:
<xiangfu>
I fill 600 under DMX8.
<xiangfu>
when I click ok. it change 600 to 8. but not change the GUI value.
r33p joined #milkymist
wolfspraul joined #milkymist
<xiangfu>
so if I open_dmx then ok (for close the window) the 600 will be always in GUI.
<GitHub112>
[flickernoise] xiangfu pushed 1 new commit to master: http://git.io/6JBDkg
<GitHub112>
[flickernoise/master] fix the value check don't write 0 to dmx variables - Xiangfu Liu
<xiangfu>
push the value = i+1 first :)
<lekernel>
hmm the other (last one) should be ok too...
<lekernel>
these things are a little messy at times
aw joined #milkymist
aw_ joined #milkymist
<GitHub145>
[flickernoise] xiangfu pushed 1 new commit to master: http://git.io/QISXtw
<GitHub145>
[flickernoise/master] load dmx config when open window not close - Xiangfu Liu
<xiangfu>
wpwrak, will send another patch about makefile soon.
<wpwrak>
great !
<xiangfu>
fix the 80 problem some time lazy to wrap them. and I don't have the line(GUI) that indicate 80 in my Emacs. :(
wolfspraul joined #milkymist
<wpwrak>
hmm, the 80 characters limit should simply be the right border of the window, no ? or do you use a proportional font ?
<xiangfu>
mine is 125 to the right border of the window.
<xiangfu>
the window is 80. but I always make windows full-screen.
<wpwrak>
argh. so much wasted screen space !
wolfspraul joined #milkymist
wolfspraul joined #milkymist
<wolfspraul>
lekernel: I think you already ok'ed the DNP'ing of J3 earlier, just double-checking whether that's still ok
<wolfspraul>
I think we should remove it even, not just dnp, since we also have some new routing work to do...
<lekernel>
I don't think the routing in the J3 area is affected, is it?
wolfspraul joined #milkymist
<lekernel>
I don't think the routing in the J3 area is affected, is it?
<wpwrak>
shouldn't be unless J21 is moved
<wpwrak>
i wish we had something mechanically a bit more reliable for extensions. not just one connector on which any board would act as a lever. more like an inverted U shape, e.g., like the arduino shields or the usrp daughterboards
<wpwrak>
what also works is connector on one side and a purely mechanical support on the other. may be difficult to match connectors and standoffs, though
wolfspraul joined #milkymist
<wpwrak>
Great Chinese Firewall hard at work ? :)
<wolfspraul>
yeah, terrible
<wpwrak>
(bridge) e.g., there should be room around C25 and C237 (both unpopulated) for another header
<wpwrak>
that would create a bridge of about 5-6 cm
<xiangfu>
in the DMX-Light manual. there is some text :
<xiangfu>
At last fixture, the DMX cable has to be terminated with a terminator to reduce signal errors. Solder a 120-ohm 1/4W resistor between pin2(DMX-) and in 3(DMX+) into.
<xiangfu>
is that necessary for all DMX usage? like always have a Terminator at last fixture?
<lekernel>
it's only necessary for long cables, and the M1 has built in terminations and also acts as a repeater in chain mode
<wolfspraul>
lekernel: in case you wrote earlier, can you repeat? your feedback on:
<wolfspraul>
1. j3 dnp or remove
<xiangfu>
what is the 'repeater' mean?
<wolfspraul>
2. moving memcard and led wires to different bank to simplify dvi routing
<lekernel>
1. DNP, routing in this area shouldn't be affected imo
<lekernel>
2. will break bitstream compatibility
<wpwrak>
(2) #ifdef ?
<lekernel>
I don't think there's a UCF preprocessor
<wolfspraul>
we know (or assumed) that it breaks bitstream compatibility
<wolfspraul>
but the question is how you feel about it still :-)
<lekernel>
also, this will mean 4 bitstreams will have to built and will have to meet timing for each SoC modification
<lekernel>
well, this sounds rather messy
<wolfspraul>
so you would rather not do this right now
<lekernel>
it's better if it can be avoided, yes
<wolfspraul>
ok that's helpful
<lekernel>
are there problems for single-link DVI?
<lekernel>
I think the memory bandwidth will pretty much limit useful resolutions in dual-link modes anyway
<wolfspraul>
we don't know yet, werner proposed the cleanup as a fresh idea, and we wanted to understand the consequences of moving existing wires around
<wolfspraul>
I see dual-link as interesting mostly because it exports some easily accessible wires out of the box, for hacking
<wolfspraul>
yes I agree for the high video resolutions and framerates I doubt we will need dual-link anytime soon
<wolfspraul>
but some easily accessible wires coming out of the box? if it's easy sounds like useful to me, no?
<wpwrak>
if you can run two independent displays from dual-link, the 2nd link could also be used for a GUI, with very limited bandwidth requirements
<wolfspraul>
that's not how it's meant at least, it's dual-link not dual-head
<wolfspraul>
as I said I see them simply as wires for hacking, coming out of the box on a neat connector. anything wrong with that idea?
<lekernel>
it it comes at a large cost, better not do it and use J21 instead
<wolfspraul>
btw we are mixing different arguments now
<wolfspraul>
one is the value of dual-link over single-link, for what purpose the additional wires might be useful etc.
<wolfspraul>
the other one are the difficulties arising from moving existing wires, for example memcard and led
<wolfspraul>
the third one are actual routing problems, which we don't know yet
<wolfspraul>
so far I understand sebastien would rather not move existing wires now
<wolfspraul>
so we try to avoid that
<wpwrak>
heh, we should PWM VGA. then we'd have enough lines left ;-)
<wolfspraul>
so the easy ones first. I still did not hear any objection against removing j3.
<wolfspraul>
lekernel: do you favor dnp over removal of j3?
<lekernel>
dnp
<lekernel>
removal is probably more work actually
<wolfspraul>
ok, dnp
<wolfspraul>
thanks!
<wolfspraul>
move existing wires: rather not
<wolfspraul>
also answered
<wolfspraul>
then I have one remaining question ;-)
<wolfspraul>
how do you see the value of dual-link as a way to get hackable wires from the fpga out of the box, easily accessible on a connector
<wolfspraul>
?
<lekernel>
not very important, people who do electronics can as well open the case
<wolfspraul>
yes but they may want to give whatever they make to normal m1 users
<wpwrak>
i would see more value in improving J21. a DVI-based solution would be complex, just because you also need to bring out the regular video signal
<wpwrak>
so it would either have two DVI connectors, M and F. or it would require a splitter cable
<wolfspraul>
I'm always in favor of improving J21 :-)
<wpwrak>
(and still have one DVI connector)
<wolfspraul>
I tried to understand the 'value' of the idea, sounds like it's > 0 at least
<wolfspraul>
assuming there are no wiring problems
<wolfspraul>
I think dual-link is quite clear to me. not needed for high-res, and somewhat valuable for hacking purposes
<wolfspraul>
improve J21 - any time
<wpwrak>
i think dual link could be interesting for dual link/head. but for add-on circuits, i'd doubt its value.
<wolfspraul>
yes but you pointed to the splitter cable yourself, it does look like another form of 'expansion' to me
<wpwrak>
yes, but it's a complicated one. not many people will want to have to add a DVI connector to their experimental board
<wpwrak>
on the other hand, 100 mil headers are everywhere
<wpwrak>
so i see limited demand for DVI-as-hacking-interface
<wpwrak>
i can imagine uses for dual-link DVI-as-extra-video-output
<wpwrak>
and it may have value as dual-link DVI-with-synthetic-signal-for-prototyping
<wpwrak>
e.g., to find out whether a board with faster memory could drive this or that screen. or do demo what it would look like, etc.
<wpwrak>
or come up with some crazy architecture that generated screen content on the fly, without a frame buffer :)
<wolfspraul>
why do you think that Amazon DVI splitter will split the first and second link?
<wolfspraul>
the commenters seem to not get it to work, the description is also not clear
<wolfspraul>
the text says "same image on two monitors"
<wpwrak>
oh. i just thought it would work like this. same image sounds kind silly. lemme read the details ...
<wpwrak>
all those that have a description do indeed just seem to duplicate the signal
<wpwrak>
in some fora, they write things that suggest that dual -> 2 x single is possible. but it's not entirely clear if they really mean that
<wpwrak>
maybe there's a market opportunity - advanced DVI splitter cables ;-)
<wolfspraul>
that sounds like Sebastien said - limited value of dual-link for hacking, better to focus on the expansion header
<wolfspraul>
so we only need to do dual-link if it's really easy and doesn't cause much problems
rejon joined #milkymist
rejon joined #milkymist
serk17 joined #milkymist
xiangfu joined #milkymist
elldekaa joined #milkymist
wolfspraul joined #milkymist
antgreen joined #milkymist
n0carri3r joined #milkymist
Martoni joined #milkymist
serk17 joined #milkymist
cjdavis joined #milkymist
kilae joined #milkymist
<Scopeuk>
xiangfu, did you make any progress on the DMX stuff?