| kristianpaul | larsc: you meant rtems right? | 00:58 |
|---|---|---|
| kristianpaul | or the libc.c file included in the milkymist repo | 00:59 |
| xiangfu | what is the 'qemu-lm32/tests/lm32 ' for? | 04:11 |
| xiangfu | wpwrak, the 'wheel' patch give me a black screen. I use the latest libfpvm and 'imaginarium' | 04:55 |
| wpwrak | xiangfu: have you set the first two faders to a non-zero value ? | 05:09 |
| wpwrak | (size and alpha) | 05:09 |
| xiangfu | wpwrak, I don't have LV3. | 05:10 |
| xiangfu | no midi controller connected. | 05:11 |
| xiangfu | the usb-midi never worked here. :( | 05:13 |
| xiangfu | I have ICON in my desk. | 05:13 |
| xiangfu | wpwrak, I got the picture. by assign all size and alpha to the ICON fad1 | 05:18 |
| xiangfu | now they are moving.. | 05:22 |
| wpwrak | so the icon is working ? over usb ? or via OSC ? | 05:23 |
| xiangfu | direct MIDI port. | 05:23 |
| xiangfu | usb: NO. | 05:23 |
| xiangfu | I connect the icon through my laptop. | 05:23 |
| xiangfu | ICON --> laptop(usb-midi conveter) --> M1 | 05:24 |
| xiangfu | ICON --> M1 . never work here :( | 05:24 |
| wpwrak | hmm ... maybe you need to update the SoC ? | 05:24 |
| wpwrak | there was a usb-related soc change. a long time ago. but maybe you haven't updated it since | 05:25 |
| xiangfu | wpwrak, I am flashing this one: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120214-0309/ | 05:28 |
| xiangfu | wpwrak, not working. by using 20120214-0309/soc.fpg | 05:32 |
| wpwrak | grmbl | 05:32 |
| xiangfu | wpwrak, maybe there is something different between build host and your laptop. | 05:33 |
| xiangfu | wpwrak, maybe I try your images first. | 05:33 |
| wpwrak | cladamw: btw, another option to kill the DCC5V issue would be to simply use a load switch with current limitation. e.g., this one doesn't look too bad: http://www.micrel.com/_PDF/mic2090_1.pdf | 05:35 |
| wpwrak | http://search.digikey.com/us/en/products/MIC2090-2YM5%20TR/576-3964-1-ND/2764090 | 05:36 |
| wpwrak | 73 us-cents @ 100 units | 05:36 |
| wolfspraul | I had a thought about USB client vs. host | 05:37 |
| wolfspraul | should one of the USB ports in R4 be a client? | 05:37 |
| wolfspraul | if not, how does this on-the-go stuff work actually, and can M1 signal host/client over otg (assuming software updates, but no electrical updates)? | 05:38 |
| wpwrak | dunno how otg works. if you want to turn a port into a traditional usb device, you need to rearrange a few resistors | 05:39 |
| wpwrak | so perhaps otg has special transceivers that switch the resistors | 05:40 |
| wolfspraul | should one of the R4 USB ports be a client? | 05:41 |
| wolfspraul | maybe it's better to skip that and look at otg right away, if it's a bigger thing then maybe in a future revision... | 05:43 |
| wpwrak | dunno. if it means taking away a host port, probably not. | 05:43 |
| cladamw | wpwrak, yours micrel part is fix limit 50mA which is better than mine I found from ON Semi. ;-) Nice, but a little bit price, 57 us-cent @ 100 pcs. yup, this candidate is surely better if don't care couple cents. ;-) | 05:43 |
| cladamw | wpwrak, thanks for spending time to find another part. :-) | 05:44 |
| wpwrak | cladamw: i just entered the parameters and picked the cheapest one ;-)) | 05:44 |
| wpwrak | wolfspraul: yes, otg or a dedicated device port (to avoid messy cabling) would be better | 05:45 |
| wolfspraul | sounds like work for R5... | 05:45 |
| wpwrak | we must leave some things for it ;-) | 05:46 |
| cladamw | wpwrak, wolfspraul we still have reservation on few resistors for usb client but unpopulated only. client question is good, but i don't think to include otg in R4, but if R5, is not bad. ;-) | 05:48 |
| cladamw | wpwrak, yours isn't the cheapest. well. Micrel's auto-retry version is better than latch off one, I like it. | 05:52 |
| wpwrak | yeah, it seems to be nicely done. that way, we won't have DCC5V silently burn half a watt or so if there's a short | 05:53 |
| cladamw | so should be p/n: MIC2090-1YM5 (auto-retry ) not 2YM5 (latch off). | 06:04 |
| wpwrak | oh, right. sorry. | 06:06 |
| cladamw | its output to cut 50mA is 6.5ms after "Enabled to short". that time is enough and good though. page 11. | 06:13 |
| wpwrak | tD_FAULT is just the indication. the response time of the current limiter seems to be tSC_RESP = 20 ns | 06:19 |
| roh | morning | 06:21 |
| roh | ignore otg. its hell, and nobody uses it in reality. support host and maybe client if needed. but that standards compliant mode switching is madness | 06:22 |
| cladamw | wpwrak, yup, tSC_RESP = 20 ns internally response only, but Iin & Iout starts to off after couple ms when short detected. no ? | 06:26 |
| cladamw | aha...Tautostart is 60ms typ. ;-) | 06:28 |
| wpwrak | (after a couple of ms) not sure. it seems that current and voltage change at pretty much the same time. | 06:29 |
| wpwrak | (60 ms) better than the cooling off period of a PTC :) | 06:30 |
| cladamw | oah...PTC needs long recovery time. Yup. with extra 20~30 usd cents to get a better chip & easy use & no much experiments. | 06:36 |
| wpwrak | happy ending ? ;-) | 06:39 |
| wolfspraul | roh: how does the switching work? | 06:39 |
| cladamw | wolfspraul, wpwrak, btw, i face your this fix version is a candidate to source. How do you think? need to order 3~5pcs in advance with PTC 50mA hold, or we order both or stick Micrel ? | 06:40 |
| wolfspraul | what? :-) | 06:40 |
| wolfspraul | I have no idea what you are talking about... | 06:40 |
| cladamw | urp? wpwrak picked a good part of Micrel current limit switch @ 0.729/100pcs which can solve DVI's DDC short/limit idea. | 06:42 |
| wolfspraul | and? any question I can help with? | 06:44 |
| cladamw | i think that we can order few 3~5pcs to do a quick test. :-) | 06:45 |
| wolfspraul | testing sounds good! | 06:46 |
| roh | wolfspraul: badly usually. ive seen otg 'compliant' nokia devices fighting each other for hours | 06:46 |
| cladamw | although from its data info there, we already like it though, wpwrak don't you ? | 06:46 |
| roh | funny game... they start wobbling each other up etc | 06:46 |
| roh | if you use the 'correct' otg cables (nobody has them) it _should_ work, but that seems to be theory | 06:47 |
| wpwrak | cladamw: yeah. i like it much better than any solution with discrete parts :) | 06:52 |
| wpwrak | roh: should be fun when both sides decide to supply power ;-) | 06:53 |
| roh | wpwrak: well... not sooo bad. the oc protection should trigger worst case | 06:53 |
| cladamw | wpwrak, oah..yup, yes. That ON semi part is a adj. version that means fine tune job to be done.(bad!), The Micrel is fixed version. Better ! | 06:54 |
| wpwrak | cladamw: keeps the component count low ;-) | 06:56 |
| wolfspraul | special cable even for otg? | 06:59 |
| cladamw | wpwrak, what do you mean? for MIC2090-1YM5, need two 10uF for its input/output. so three components only. | 06:59 |
| wpwrak | cladamw: yes. 3 instead of 4-5 for an adjustable solution | 07:01 |
| wpwrak | anyway, time to crawl to bed. gotta be up in the morning for the dentist. | 07:02 |
| cladamw | mm..needs another two resistors: R1/R3, C1/C2, chip itself. | 07:02 |
| cladamw | wpwrak, night. | 07:02 |
| qi-bot | The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120222-0643/ | 07:20 |
| roh | wolfspraul: http://en.wikipedia.org/wiki/USB_On-The-Go | 07:38 |
| roh | see connectors. it needs the id pin wired depending on device or host role | 07:38 |
| roh | i'd recomend getting hub to work before even thinking about usb-client or even usb-otg support... atleast thats my order of importance. | 07:43 |
| wolfspraul | oh sure :-) | 08:04 |
| wolfspraul | I am just thinking ahead because electrical issues cannot be software-updated... | 08:04 |
| wolfspraul | roh: I have a tool question. for the milkymist one case, we have the 2D laser files in qcad/dxf | 08:05 |
| wolfspraul | and then you have a 1-page svg manual, I think - drawn in which program? inkscape? | 08:05 |
| roh | yes. that was made with inkscape | 08:05 |
| wolfspraul | how about some cad software that would have a 3d version of the case? | 08:05 |
| roh | i dont have such a model | 08:06 |
| wolfspraul | so you can see more precisely than in the svg how it's assembled, which spacers/screws go where, etc. | 08:06 |
| wolfspraul | which software would you think could work for that? | 08:06 |
| wolfspraul | would it be separate from the qcad/dxf files? or can it be in qcad as well? | 08:06 |
| roh | qcad is a 2d only format | 08:06 |
| wolfspraul | ah | 08:07 |
| roh | s/format/program | 08:08 |
| wolfspraul | anything else on your mind in that direction? (3d) | 08:08 |
| roh | dxf can support 3d i guess.. not sure tho | 08:08 |
| roh | in tools? good question. all 3d stuff i made i did with openscad so far | 08:10 |
| roh | and used stl as fileformat | 08:10 |
| wolfspraul | ok nice, that's a starting point. I think openscad was also in werner's comparisons a way back. lemme check... | 08:12 |
| roh | i guess one could use the dxf file, cut the parts apart into seperate files or layers and extrude and assemble the parts in openscad to a 3d model, and add the spacers. | 08:16 |
| roh | i wonder if and how we could render a 3d view of the pcb. needs models of all parts etc | 08:17 |
| wolfspraul | kicad supports vrml export, but as you said I think many parameters are missing to make this really good | 08:18 |
| wolfspraul | and the kicad component libraries are a desert... | 08:18 |
| roh | hehe | 08:20 |
| roh | only a idea... a friend here at raumfahrtagentur rendered our hausbus-module from eagle | 08:21 |
| wolfspraul | I like 3D models and in fact any way of viewing/entrance point that makes it easy to get an understanding of what's inside, how it's assembled, etc. | 08:21 |
| roh | but also only into a png. i think he used some raytracer | 08:21 |
| wolfspraul | oh the vrml output works - just many details missing | 08:22 |
| wolfspraul | png also of course, no problem | 08:22 |
| roh | ive got no clue how and if to convert vrml into something like stl or so... but we'll find out | 08:27 |
| GitHub176 | [scripts] xiangfu pushed 1 new commit to master: http://git.io/5F95tA | 09:33 |
| GitHub176 | [scripts/master] update Xilinx ISE to 13.4 under build host - Xiangfu Liu | 09:33 |
| qi-bot | The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120222-0830/ | 09:34 |
| xiangfu | this build ^ using the milkymist hid branch and flickernoise imaginarium branch | 09:35 |
| xiangfu | http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120222-0830/VERSIONS | 09:35 |
| Action: xiangfu want people try Werner's midi stuff :D | 09:35 | |
| xiangfu | the next build will be use ISE 13.4 . | 09:36 |
| Fallenou | xiangfu: is it normal that path to ISE is hardcoded ? | 09:49 |
| Fallenou | mine is in /opt | 09:49 |
| lekernel | you can use the $XILINX environment variable set by settings??.sh | 09:55 |
| kristianpaul | morning | 10:49 |
| Fallenou | hi | 10:49 |
| wolfspraul | morning | 11:12 |
| qi-bot | The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120222-1044/ | 11:24 |
| lekernel | moin | 11:30 |
| xiangfu | Fallenou, by default it's installed to /opt/. | 12:07 |
| xiangfu | 'milkymist-firmware-20120222-1044/' is using 13.4 | 12:09 |
| lekernel | http://opencores.org/newsletter,2012,02 | 13:32 |
| Fallenou | ohoh | 13:35 |
| Fallenou | congratz ! | 13:35 |
| Fallenou | Sébastien Bourdeauducq, OpenCores user <= the signature is somehow very funny | 13:36 |
| qi-bot | The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120222-1315/ | 13:55 |
| qi-bot | The firmware (with branch M:hid, F:imaginarium) build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120222-1455/ | 15:35 |
| lekernel | wpwrak: green light for web updates? | 16:02 |
| wpwrak | hmm, don't you want to add ffmpeg too, so that we can close the chapter on image handling ? or is this still too far off ? | 16:13 |
| lekernel | yes, and try to sync with RTEMS upstream too... but except that, all OK? | 16:14 |
| wpwrak | oh, the images support is good to go as far as i'm concerned | 16:16 |
| lekernel | ok. I'll test on the hardware my brand new DDR PHY which now works in simulation, and then switch to FN a bit | 16:17 |
| wpwrak | for frame sequences, perhaps the best way to handle them would be to have a set of variables imageN_frame that works just like imageN_index, but on the respective frame of the image file | 16:17 |
| lekernel | I hope it won't end up in a massive PCB-level SI/timing clusterfuck | 16:18 |
| wpwrak | we can also provide variables imageN_frames that get set according to the number of frames in the selected image. you'd still get that one frame update delay, but if imageN_frames is used before setting imageN_index, that would even look natural. so i guess we can live with that. | 16:19 |
| wpwrak | (PHY fun) famous last words ;-) | 16:20 |
| Fallenou | I just noticed there is no "NEWS" part in the milkymist web site | 16:34 |
| Fallenou | on the first page it could be nice to have a few "news" | 16:34 |
| Fallenou | I think we would have plenty of content to put in it | 16:34 |
| Fallenou | since it's developing like crazy down here | 16:35 |
| Fallenou | to announce new midi stuff , more usb support, image support, new RC4 release etc | 16:36 |
| lekernel | ha! xilinx is now following us on twitter ... | 17:59 |
| larsc | lekernel: time for some ranting ;) | 19:06 |
| wolfspraul | Fallenou: R4, we removed the 'C' | 23:14 |
| wolfspraul | it's a revision/release now, no more 'candidate' :-) | 23:14 |
| --- Thu Feb 23 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!