<wolfspraul>
there are two ways to improve the button, one is NC3FAH1-0, which replaces the push button with a 'retention spring'
<wolfspraul>
and the other one is NC3FAHL1, which turns the connector 90 degree to the left, leaving the push button
<lekernel_>
if you want to improve that, turn 90 degrees
<wolfspraul>
we have enough space, so we can turn the connector. or if you think the 'retention spring' is enough, we can leave it upright.
<lekernel_>
and turn the other connector as well (there's a button on the cable)
<lekernel_>
but then it bumps into the MIDI cables etc. so tbh I'd prefer to leave everything as it is
<wolfspraul>
ok, so you think that 'push'/lock mechanism is better than 'retention spring'?
<lekernel_>
i've never had problems unplugging the dmx cable on several occasions
<wolfspraul>
why does it bump into the MIDI cables?
<lekernel_>
if you turn the DMX RX 90 degrees too
<wolfspraul>
you mean inside the case?
<lekernel_>
the button ***on the cable*** bumps into either the other DMX plug or MIDI
<wolfspraul>
yes, on top is best for RX
<wolfspraul>
also far easier to press than the TX push button, because it's on the cable, i.e. further out (away from the box)
<lekernel_>
it would look weird to have only one of those connectors turned 90 degrees
<wolfspraul>
my question was about push/lock vs. retention spring, and you answered it - retention spring is worse. correct?
<lekernel_>
probably more trouble than the current position of the release button
<lekernel_>
if you really want to change things, the retention spring is more acceptable than turning only one connector 90 degrees
<wolfspraul>
and if you had to choose between retention spring or push button, and you knew the difficulty of reaching the push button with our case, you would still choose the push button?
<lekernel_>
btw there's also the option of making a notch in the top cover plate of the case
<wolfspraul>
yes, definitely. That's another option.
<lekernel_>
well I know the difficulty. I have used this thing several times already :)
<wolfspraul>
so you would still choose this instead of the retention spring?
<lekernel_>
yes
<wolfspraul>
maybe at the time we chose this connector we weren't aware of the retention spring solution?
<wolfspraul>
or we were aware and still prefer the push button, the way it is now?
<lekernel_>
ok well
<lekernel_>
use that retention spring connector :)
<wolfspraul>
he :-) I'm just trying to understand, not kick anybody around.
<wolfspraul>
I also need to defend this product to sell it.
<lekernel_>
hopefully it's even footprint compatible
<wolfspraul>
we can also leave it as is, push button on top
<wolfspraul>
I guess we have a total of 4 options now
<wolfspraul>
1) push button on top, acrylic as is
<wolfspraul>
2) push button on top, cut out acrylic a little
<wolfspraul>
3) retention spring on top
<wolfspraul>
4) push button on left, without rotating the RX one
<wolfspraul>
if we rotate RX, we cannot reach the unlock button on that cable
<wolfspraul>
maybe we just go for option #1 until we hear more customer feedback
<wolfspraul>
I'm fine with that. It's not outright bad, it's just a little squeezed in there...
<lekernel_>
or just use the retention sprint version... if it's drop-in compatible just go ahead
<wolfspraul>
ok, will check. if it's compatible, we switch to that then.
<carlobar>
hi, i was trying synthesize the HPDCM controler, but i got an error related to the ODDR2. In spartan-3e fpga the DDR_ALIGNMENT="C0" is not supported: http://www.xilinx.com/support/answers/24478.htm
<carlobar>
only DDR_ALIGNMENT = "NONE" is supported, can i use that option, or is necessary implement  DDR_ALIGNMENT="C0"?  thanks
<lekernel_>
iirc all DDR_ALIGNMENT does is enable an extra register built into the ODDR block... so you might check that and try implementing that register in the fabric
<carlobar>
ok, ill do that, thanks
<kristianpaul>
larsc: had you worked with nuttx ?
<kristianpaul>
or knew about it..
<kristianpaul>
i just read it was like luclinux but can fit on low memory footprint devices, like microcontrollers
<guyzmo>
\o/
<guyzmo>
finally compiled gcc
<kristianpaul>
:-)
<guyzmo>
actually I had to add --with-libiconv-prefix to ports prefix
<guyzmo>
(as well as mpc, gmp and mpfr)
<Fallenou>
congratz guyzmo
<guyzmo>
;)
<kristianpaul>
wonders if a netbook can support ISE sistensis..
<kristianpaul>
for milkymist :D
<kristianpaul>
need a laptop with more speed, 799Mhz are getting short for firefox !!! :(
<guyzmo>
kristianpaul - lm32-rtems4.11-gcc: bsp_specs: No such file or directory
<guyzmo>
what is bsp_specs and where can I find it ?
<guyzmo>
:)
<kristianpaul>
did you compiled the rtems toolchain also?
<kristianpaul>
cant you resume CTI from you current ind state?
<kristianpaul>
:-)
<kristianpaul>
s/ind/mind
<carlobar>
hi, im trying to simulate the milkymist SoC, but i got this error: lm32_instruction_unit.v:154: sorry: constant user functions are not currently supported: clogb2(). I had asked it before, but i lost the link with the solution, can someone help me again?
<kristianpaul>
ah, yes i remenber this chart
<kristianpaul>
chat*
<kristianpaul>
carlobar: you need replace clogb2
<kristianpaul>
solution is not yet implemented
<carlobar>
hi kristianpaul: do i have to use another function?
<kristianpaul>
actually replace what it does
<kristianpaul>
that was said by lars i remenber
<kristianpaul>
let me check
<kristianpaul>
10:07 < larsc> carlobar: you could replace the clogb2 call with it's result