<xiangfu>
wpwrak, not working. by using 20120214-0309/soc.fpg
<wpwrak>
grmbl
<xiangfu>
wpwrak, maybe there is something different between build host and your laptop.
<xiangfu>
wpwrak, maybe I try your images first.
<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
<wolfspraul>
I had a thought about USB client vs. host
<wolfspraul>
should one of the USB ports in R4 be a client?
<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)?
<wpwrak>
dunno how otg works. if you want to turn a port into a traditional usb device, you need to rearrange a few resistors
<wpwrak>
so perhaps otg has special transceivers that switch the resistors
<wolfspraul>
should one of the R4 USB ports be a client?
<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...
<wpwrak>
dunno. if it means taking away a host port, probably not.
<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. ;-)
<cladamw>
wpwrak, thanks for spending time to find another part. :-)
<wpwrak>
cladamw: i just entered the parameters and picked the cheapest one ;-))
<wpwrak>
wolfspraul: yes, otg or a dedicated device port (to avoid messy cabling) would be better
<wolfspraul>
sounds like work for R5...
<wpwrak>
we must leave some things for it ;-)
<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. ;-)
<cladamw>
wpwrak, yours isn't the cheapest. well. Micrel's auto-retry version is better than latch off one, I like it.
<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
<cladamw>
so should be p/n: MIC2090-1YM5 (auto-retry ) not 2YM5 (latch off).
<wpwrak>
oh, right. sorry.
<cladamw>
its output to cut 50mA is 6.5ms after "Enabled to short". that time is enough and good though. page 11.
<wpwrak>
tD_FAULT is just the indication. the response time of the current limiter seems to be tSC_RESP = 20 ns
<roh>
morning
<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
<cladamw>
wpwrak, yup, tSC_RESP = 20 ns internally response only, but Iin & Iout starts to off after couple ms when short detected. no ?
<cladamw>
aha...Tautostart is 60ms typ. ;-)
<wpwrak>
(after a couple of ms) not sure. it seems that current and voltage change at pretty much the same time.
<wpwrak>
(60 ms) better than the cooling off period of a PTC :)
<cladamw>
oah...PTC needs long recovery time. Yup. with extra 20~30 usd cents to get a better chip & easy use & no much experiments.
<wpwrak>
happy ending ? ;-)
<wolfspraul>
roh: how does the switching work?
<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 ?
<wolfspraul>
what? :-)
<wolfspraul>
I have no idea what you are talking about...
<cladamw>
urp? wpwrak picked a good part of Micrel current limit switch @ 0.729/100pcs which can solve DVI's DDC short/limit idea.
<wolfspraul>
and? any question I can help with?
<cladamw>
i think that we can order few 3~5pcs to do a quick test. :-)
<wolfspraul>
testing sounds good!
<roh>
wolfspraul: badly usually. ive seen otg 'compliant' nokia devices fighting each other for hours
<cladamw>
although from its data info there, we already like it though, wpwrak don't you ?
<roh>
funny game... they start wobbling each other up etc
<roh>
if you use the 'correct' otg cables (nobody has them) it _should_ work, but that seems to be theory
rhinoplatform has joined #milkymist
<wpwrak>
cladamw: yeah. i like it much better than any solution with discrete parts :)
<wpwrak>
roh: should be fun when both sides decide to supply power ;-)
<roh>
wpwrak: well... not sooo bad. the oc protection should trigger worst case
<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 !
<wpwrak>
cladamw: keeps the component count low ;-)
<wolfspraul>
special cable even for otg?
<cladamw>
wpwrak, what do you mean? for MIC2090-1YM5, need two 10uF for its input/output. so three components only.
<wpwrak>
cladamw: yes. 3 instead of 4-5 for an adjustable solution
<wpwrak>
anyway, time to crawl to bed. gotta be up in the morning for the dentist.
<cladamw>
mm..needs another two resistors: R1/R3, C1/C2, chip itself.
<roh>
see connectors. it needs the id pin wired depending on device or host role
<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.
<wolfspraul>
oh sure :-)
<wolfspraul>
I am just thinking ahead because electrical issues cannot be software-updated...
<wolfspraul>
roh: I have a tool question. for the milkymist one case, we have the 2D laser files in qcad/dxf
<wolfspraul>
and then you have a 1-page svg manual, I think - drawn in which program? inkscape?
<roh>
yes. that was made with inkscape
<wolfspraul>
how about some cad software that would have a 3d version of the case?
<roh>
i dont have such a model
<wolfspraul>
so you can see more precisely than in the svg how it's assembled, which spacers/screws go where, etc.
<wolfspraul>
which software would you think could work for that?
<wolfspraul>
would it be separate from the qcad/dxf files? or can it be in qcad as well?
<roh>
qcad is a 2d only format
<wolfspraul>
ah
<roh>
s/format/program
<wolfspraul>
anything else on your mind in that direction? (3d)
<roh>
dxf can support 3d i guess.. not sure tho
<roh>
in tools? good question. all 3d stuff i made i did with openscad so far
<roh>
and used stl as fileformat
<wolfspraul>
ok nice, that's a starting point. I think openscad was also in werner's comparisons a way back. lemme check...
<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.
<roh>
i wonder if and how we could render a 3d view of the pcb. needs models of all parts etc
<wolfspraul>
kicad supports vrml export, but as you said I think many parameters are missing to make this really good
<wolfspraul>
and the kicad component libraries are a desert...
<roh>
hehe
<roh>
only a idea... a friend here at raumfahrtagentur rendered our hausbus-module from eagle
<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.
<roh>
but also only into a png. i think he used some raytracer
<wolfspraul>
oh the vrml output works - just many details missing
<wolfspraul>
png also of course, no problem
<roh>
ive got no clue how and if to convert vrml into something like stl or so... but we'll find out
LmtdAt has joined #milkymist
<GitHub176>
[scripts] xiangfu pushed 1 new commit to master: http://git.io/5F95tA
<GitHub176>
[scripts/master] update Xilinx ISE to 13.4 under build host - Xiangfu Liu
<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 ?
elldekaa has joined #milkymist
<lekernel>
yes, and try to sync with RTEMS upstream too... but except that, all OK?
<wpwrak>
oh, the images support is good to go as far as i'm concerned
<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
<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
<lekernel>
I hope it won't end up in a massive PCB-level SI/timing clusterfuck
<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.
<wpwrak>
(PHY fun) famous last words ;-)
sh4rm4 has joined #milkymist
<Fallenou>
I just noticed there is no "NEWS" part in the milkymist web site
<Fallenou>
on the first page it could be nice to have a few "news"
<Fallenou>
I think we would have plenty of content to put in it
<Fallenou>
since it's developing like crazy down here
<Fallenou>
to announce new midi stuff , more usb support, image support, new RC4 release etc