Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
lekernel_ has joined #milkymist
sh4rm4 has joined #milkymist
cladamw has joined #milkymist
xiangfu has joined #milkymist
<cladamw>
wpwrak, hi, Joerg replied with comments but forgot to cc. so he thought that "The basic schematics to detect plug-in are nice and OK". ;-)
<wpwrak>
whee, congratulations !
<wpwrak>
it's not easy to please joerg ;-)
<roh>
cladamw: do we plan to wire the spdif out to some header?
<cladamw>
roh, wow. you are the first one to ask this spdif question now after rc3. good question. wpwrak how do think about first 'potential' use case ?
<roh>
the mm1 could be used as a synthesizer for audio too with other sw. and digital out is the best possible quality.
<wpwrak>
i don't know spdif. never used it.
<roh>
wpwrak: serial uncompressed audio. consumer standard. its used via toslink optical or rca electrical ports.
<roh>
i use it where possible. no ground loops, cheap, no white noise anymore.
<roh>
i dont think one should invest lots of money, i just think its there, and it would be nice not to waste it if there is a free pin on some extension header
<cladamw>
wpwrak, roh, in rc3, yes m1 have spdif out, but latest proposed for R4 draft, it's gone. phew~ now seems goes back to use case again. :)
<roh>
the signal itself is cmos level i think. manchmester encoded or so
<roh>
cladamw: ah. why was it removed? not enough pins left?
<cladamw>
the spdif was wired to J3 which decided to remove whole J3 though in irc channel discussion, need to search.
<cladamw>
also the new idea of U-Shaped expansion female headers and layout routes for DVI-I, those are some reasons to reserve space, etc...
<roh>
i see. maybe we can add some unsoldered holes in 2.54 spacing. 4 pins with 5 or 3.3V, gnd and spdif-en and spdif-out. but on some other expansion would be fine too
<kristianpaul>
oh interesting new PHY IP core from xilinx :)
<kristianpaul>
how fast is the system memory with this?
<cladamw>
i quite don't know how many user will use this great stuff in music industries, but needs to ask sebastien wolfspraul werner how they feel this feature in the end though. ;-)
<roh>
sure.
<roh>
in the end one would need sw anyhow
<cladamw>
wpwrak, regards to DMX/MIDI insertion/detection features, do you have any idea ?
<wpwrak>
(spdif) i have no opinion on it, except that, if you add it, don't make it a big deal
<cladamw>
wpwrak, :-)
<wpwrak>
(midi insertion) i suppose you could measure the current you can sink on the TX port. but ... do you really want to do that ?
<wpwrak>
on RX ... not sure what the idle state is. if it's pin 4 high and ping 5 low, then you could detect the current
<wpwrak>
i.e., MIDI_RX would change once something it connected
<wpwrak>
s/it/is/
<cladamw>
yes, i thought about current measuring way, but i've never tried midi device. so... still need to read more on http://www.midi.org/techspecs/index.php
<wpwrak>
i wouldn't bother with trying to detect tx insertion. we don't even know if all midi devices implement the interface like this. maybe some use voltage sensing and have a high impedance.
<cladamw>
the current sink from TX may always be variable. not easy to determine how threshold will be.
<wpwrak>
yup
<wpwrak>
that's what i suspect as well
<cladamw>
like CMRR amplifier to detect variable voltage changes. not sure... need to study again.
Fallenou has joined #milkymist
<GitHub98>
[flickernoise] wpwrak pushed 2 new commits to direct-midi: http://git.io/_4Z3Kw
<GitHub98>
[flickernoise/direct-midi] First draft of MIDI documentation - Werner Almesberger
<GitHub98>
[flickernoise/direct-midi] T.fnp: improved structure of patch - Werner Almesberger
cladamw has joined #milkymist
<wolfspraul>
I don't know spdif either, but if roh likes it that's a good argument for keeping it somewhere. Let's see what Sebastien says :-)
* roh
just wrote down a wire protocol spec for something we are working on at rfa
<roh>
or rather a rfc of one and only for the L1 and parts of L2
<roh>
a decentralised SPS :)
<cladamw>
wolfspraul, (insertion/detection) seem now we have: DC power-in detect, audio line-in/out, else we don't know yet ot even too much works needed or adding chips, like midi ports, i think it needs differential amplifier chip to sense current but also not indicates a cable plugged (if there's no power turned on on midi device side)
<cladamw>
(i.e. if a midi cable with source device(no power) plug-in to M1 midi rx connector, in this case, i currently don't know how to add circuits for it.
<wolfspraul>
wait, wait. no complications.
<wolfspraul>
first let's document, for each connector
<wolfspraul>
can we do that in the wiki?
<wolfspraul>
let's document what we have now
<wolfspraul>
then we need to think about what is desirable
<wpwrak>
i would just not try to detect insertion in cases like MIDI TX :)
<cladamw>
wpwrak, yes, after lunch while I was brainstorming myself, it's too complex. i don't want to use a current like cmrr or differetial amplifier to sense it. ;-)
<cladamw>
wolfspraul, reload link again. I just added some links for it. ;-)
<wolfspraul>
oh yes, sure. we do *not* want to add anything first.
<wolfspraul>
just try to understand, use case, etc.
<wpwrak>
beware the overengineer;-)
<cladamw>
wpwrak, the answer from me for MIDI insertion, i give it up. ;-) your answer was too veiled not technical though. ;-)
<wpwrak>
cladamw: yeah, i think we may be able to handle cable detection of MIDI RX, though. lemme check ...
<wpwrak>
(handle) that is, in software
<cladamw>
wpwrak, (make sense) wolfspraul wanted when any cable inserts, then M1 shows up that it's coming. but how about even user don't turn on their own midi device power ? if no power, no sense current you can pick up. ;-) but how about like voltage like finger touch ?
<wolfspraul>
no, wait
<wolfspraul>
I want to *understand* the cable insertion/removal detection for each connector
<wolfspraul>
some may have it implicitly (like ethernet), for some it may not create any conceivable value, for some it may be electrically easy, for some it may be electrically hard, and so on
<wolfspraul>
give me 30 min, I'm right back...
<cladamw>
yuh...like i said and like wener said we should not do midi TX insertion. ;-)
<wolfspraul>
sure
wolfspraul has joined #milkymist
<wpwrak>
hmm no, when idle, MIDI doesn't have current (checked TP31). so, no cable detection for MIDI RX. we can detect bus activity, though.
<roh>
wpwrak: there are din-sockets with switch
<roh>
same for dmx
<roh>
the only way to detect a connector afaik
<roh>
(on midi and dmx)
<cladamw>
(detect bus activity) means software? or hardware?
<wpwrak>
cladamw: software
<wpwrak>
roh: a while ago i looked and at least digi-key doesn't seem to have DIN with switch. so they may not be terribly common. perhaps in .de, homeland of DIN ...
<larsc>
lekernel_: everything works fine (more or less). It is just that I still explicitly handle the case of combinatorical logic, while in theory the generic model should also cover it.
elldekaa has joined #milkymist
juliusb has joined #milkymist
<lekernel>
kristianpaul: aiming for 10 gbps
Martoni has joined #milkymist
cladamw has joined #milkymist
wolfspraul has joined #milkymist
<wpwrak>
grmbl. our pinned rtems predates the merge of milkymist-midi-opt.patch
<wpwrak>
xiangfu: have you tried building a more recent version of rtems lately ?
<xiangfu>
wpwrak, no. not yet.
<xiangfu>
wpwrak, but I can trigger it on build host
<wpwrak>
lemme first see what happens :)
<xiangfu>
I also trigger that on build host. that is what build host for :)
<xiangfu>
ok. done. it will report in 2 hours
<wpwrak>
by the way, do we really need fix-ftpd-root.patch ? i've been trying to make sense of it, but it really looks like a no-op
<xiangfu>
it already merged in upstream.
<wpwrak>
ah, great
<xiangfu>
wpwrak, with out this patch. it do have problem. like it try to setup the ftpd-root by used define after ftpd thread running.
<wpwrak>
feb 2. perfect
<xiangfu>
s/used/user
<xiangfu>
but when the thread running. it will only check is the chroot correct. not check user define ftpd-root. any more.
<xiangfu>
so we better move those code before thread running . (hope you understand my English :)
<xiangfu>
kristianpaul, I have make cgminer works fine with FPGA mining core. you can try it now.
<wpwrak>
i think i got it :) okay, sounds good then
<xiangfu>
kristianpaul, code have commit to openwrt-package
<GitHub38>
[migen/master] bank: omit device write register when access_bus==READ_ONLY and access_dev==WRITE_ONLY - Sebastien Bourdeauducq
Hodapp has joined #milkymist
LmAt has joined #milkymist
<GitHub113>
[flickernoise] wpwrak pushed 2 new commits to master: http://git.io/Zjsscw
<GitHub113>
[flickernoise/master] Merge branch 'direct-midi' - Werner Almesberger
<GitHub113>
[flickernoise/master] experimental/: removed leftover from development branch - Werner Almesberger
elldekaa has joined #milkymist
aeris- has joined #milkymist
lekernel has joined #milkymist
aeris- has joined #milkymist
<wpwrak>
that's kinda embarrassing ;-)
<wpwrak>
/* work around /* and // */ -> re2c: error: line 111, column 6: ambiguous /* found
<larsc>
one does not simply work around /* ;)
<wpwrak>
yeah. 311 regression test cases :)
<GitHub193>
[flickernoise] wpwrak created imaginarium (+7 new commits): http://git.io/OuaJXw
<GitHub193>
[flickernoise/imaginarium] compiler: also disallow tabs and carriage return in file names - Werner Almesberger
<GitHub193>
[flickernoise/imaginarium] compiler: use named regular expressions for file names - Werner Almesberger
<GitHub193>
[flickernoise/imaginarium] compiler: introduce alternative "imagefiles" syntax (WIP) - Werner Almesberger
hypermodern has joined #milkymist
<wpwrak>
btw, would somethine like patchpool/experimental/ be a good place for patches that shouldn't be auto-installed ? or is the update mechanism recursive ?
<GitHub184>
[flickernoise] wpwrak pushed 2 new commits to imaginarium: http://git.io/V6M7vQ
<GitHub184>
[flickernoise/imaginarium] images: added image selection with imageN_index - Werner Almesberger
<GitHub184>
[flickernoise/imaginarium] experimental/N.fnp: demonstration of imageN_index, based on pacman.fnp - Werner Almesberger