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
Thihi_ joined #milkymist
Thihi joined #milkymist
krispaul joined #milkymist
krispaul joined #milkymist
<wpwrak>
hmm, is there any useful way for viewing output variables of the PFPU ? the variable monitor only seems to know about input variables
<kristianpaul>
wpwrak: r u using xiangfu scripts to compile rtems/FN latelly?
<wpwrak>
i normally use my own snippets
<wpwrak>
his scripts tend to do more things than i need. and i'm too lazy to figure out what internal dependencies they have (or not :)
<kristianpaul>
ok i'll check out
<wpwrak>
wernermisc/m1/BUILD-CHEAT-SHEET is what i use
<kristianpaul>
ubuntu 11.10 ?
<wpwrak>
it calls itself "Ubuntu 10.04.2 LTS"
<wpwrak>
but i also have packages from 10.10
<kristianpaul>
hum.. LTS well i dint tried that with my notebook hw.. i hope all went ok..
<kristianpaul>
just because rtems seems very picky about autotools ver sometimes.. i guess recent software dont hurt
<wpwrak>
autotools is always picky :)
<wpwrak>
often, the most efficient way for compiling something that uses autotools is to write a makefile
<wpwrak>
if you're quick, that may even be faster than running the whole auto* ritual :)
<kristianpaul>
haha
<wpwrak>
hmm, 6 % 2 -> 2. gotta love those rounding errors ...
xiangfu joined #milkymist
aeris joined #milkymist
elldekaa joined #milkymist
elldekaa joined #milkymist
wolfspraul joined #milkymist
r33p joined #milkymist
lekernel_ joined #milkymist
xiangfu joined #milkymist
xiangfu joined #milkymist
azonenberg joined #milkymist
wolfspraul joined #milkymist
<GitHub165>
[milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/H3yxvA
<GitHub165>
[milkymist/master] libfpvm: use C operator precedence - Werner Almesberger
mumptai joined #milkymist
<wpwrak>
lekernel_: thanks ! btw, % is a tough cookie. e.g., 6 % 2 gives you flat out 2. took me a while to figure that one out :) it's of course all because of rounding errors. probably nearly impossible to fix, too :-(
kilae joined #milkymist
r33p joined #milkymist
<wpwrak>
lekernel_: by the way, what's your take on adding USB ports ? i'm in a bit of a dilemma there: from a usability side, it's a clear "yes". from a cowardly engineer side (let's keep changes small), its a clear "no".
<wpwrak>
wolfspraul: what's the plan for video codec testing ? will the supposed signal quality improvements be verified ? or do we just take them for given if no overly visible regression shows up ?
<wpwrak>
wolfspraul: also, who will test the various video sources and update software support for them ?
<lekernel_>
since the C isn't more expensive than the B (which is being slowly phased out btw) and supports a few more things, no regressions is sufficient
<lekernel_>
in theory, software support is simple... if reg 0x11 == 0x19, then use the new multiplexer settings
<wpwrak>
sound good. are we sure the ID and the multiplexer are the only differences ?
<lekernel_>
that's the point of doing regression testing...
<wpwrak>
hehe ;-)
<wpwrak>
i mean, did anyone do an item per item check of the data sheets ? or have analog devices even been so kind to provide some sort migration guide ? (some companies do actually pamper us poor engineers this way ;-)
<wpwrak>
it's a pity that they seem to have radically changed the format of the documentation. so it's hard to spot differences.
<wpwrak>
okay, so this needs a second look. good that there aren't all that many registers to tweak.
<lekernel_>
yes, as long as you don't follow the obscure "ADI recommended programming sequence" which didn't have a visible effect compared to programming only merely the muxes on the B :)
<lekernel_>
though the chip certainly sucks more current (we don't shut down unused ADCs) but it's not like I care about such details
<wpwrak>
yeah, these sequences have a tendency of doing things in very obscure ways. sometimes, you figure out later that they did have some reason for it. but most of the time, it's just a mystery.
<wpwrak>
ah well, having room for optimizations is always a good thing :)
<wolfspraul>
ah that may be why the video-in codec gets to hot and power consumption goes up when it's used :-)
<wolfspraul>
s/gets to hot/gets so hot/
<wpwrak>
besides, if we add more USB host ports, the few mA idling ADCs contribute to global warming will be our least concern :)
<wpwrak>
oh, it gets hot ? that's more interesting then :)
<wolfspraul>
video-in codec is one of the hottest chips on m1, just judging from finger-touching, we don't have hard data yet
<lekernel_>
as long as it works...
<wolfspraul>
then I read about Sebastien happily ignoring "obscure" recommendations which don't have "visible" effects :-)
<lekernel_>
and it's quite a power-hungry component no matter what
<lekernel_>
oh, I did test the recommended sequence
<wolfspraul>
yeah I was just laughing
<lekernel_>
the chip also gets noticeably hot with it
<wolfspraul>
because it fit so well with 'visible' and 'hot' :-)
<wolfspraul>
sure, I have no hard data either
<wolfspraul>
one day we need to do proper temperature testing
<lekernel_>
but if you look at the datasheet figures, they tell you the chip does consume some nontrivial amount of power
<wpwrak>
sebastien needs better IR vision ? :)
<lekernel_>
it's nothing unusual or wrong with it getting hot
<wpwrak>
i guess it's nothing compared to the camera. that one i find a little scary
<wpwrak>
it's a big piece of metal and the heat source must be small. so it must indeed get incredibly hot in there.
<wolfspraul>
yes true, known issue
<wolfspraul>
next time we look at the camera, maybe we can switch to a s-video or even hdmi cam, who knows
<wolfspraul>
I don't want to touch that now, no need
<wpwrak>
heh :)
<wpwrak>
maybe we can even figure out some deinterlacing. that would give the camera quite a bit of a boost :)
<wpwrak>
not sure if the rest of the pipeline would be happy with getting twice the amount of data, though
<lekernel_>
deinterlacing is certainly as much work as hdmi
<lekernel_>
bbl
<wpwrak>
maybe. don't now what level of pain hdmi would be
<wpwrak>
alas, the simple de-interlacing algorithms either produce ugly results or they need a higher frame rate
<wpwrak>
wolfspraul: that distributor you were talking to, what geographical region did he have in mind ?
<wpwrak>
(for the sales estimate)
gbraad joined #milkymist
gbraad joined #milkymist
xiangfu joined #milkymist
<kristianpaul>
jtag-serial pod get hot too
<wpwrak>
i'm a bit surprised by how cool the fpga stays. maybe this means we're not making it work hard enough :)
<kristianpaul>
yeah ;)
<kristianpaul>
wpwrak: you want it to run at 200Mhz and put your finger on it? :-)
<kristianpaul>
quilt for patches nice :-)
elldekaa joined #milkymist
sh4rm4 joined #milkymist
lekernel joined #milkymist
<lekernel>
wpwrak: btw, xilinx's response regarding xdl was along the lines of "this is an unsupported tool, don't touch it" :(
<wpwrak>
why am i not surprised :-(
<lekernel>
that came from the general tech support, though. I can "insist" a bit more, but I'm not sure if it's worth fighting this battle
<lekernel>
renaming works, right?
<wpwrak>
only partially. if i build the reduced soc, it makes the error go away. if i build the full soc, something tries to match with the commaized names, and fails
<wpwrak>
not sure if this is merely a case of me having missed some renames or if the reason lies deeper
<wpwrak>
there's also the limitation that i can't just bring out inputs. but maybe that's again a case of not having tried the right item.
<wpwrak>
with all the bugs, these experiment are rather time-consuming. i was twice or thrice times at the point of giving up before i even found a way to get it to work as much as it does now.
<wpwrak>
plan B would be to simply parse the damn verilog, insert the taps into the source, and write out a "shadow" tree (or maybe even leave things in the source, with appropriate markup)
<kristianpaul>
*g* for B :-)
<lekernel>
maybe input signals have a prefix in the XDL
<lekernel>
like _IBUF or something
<lekernel>
s/prefix/suffix
<lekernel>
btw, there might be the option of scripting FPGA Editor, but I'm not sure about the bugs or feasibility...
<wpwrak>
yeah. maybe they appear under multiple names. my script does check that the name exists, but it doesn't search for aliases.
<lekernel>
the problem with B is you get the full 30-minute compilation
<lekernel>
using XDL properly, this can be reduced to a few dozen seconds
<wpwrak>
(fpga editor) putting a lot of work into something that depends on through and through proprietary software is not what really excites me ;-)
<lekernel>
yeah, sure
<lekernel>
neither do I :)
<wpwrak>
(plan B) yes, i'm painfully aware of those 30 minutes ...
<lekernel>
and XDL also has the quality of being very close to the bare metal
<lekernel>
the only proprietary layer is the bitstream encoder
<wpwrak>
oh, i like the xdl approach. it's just that the conversion seems very buggy.
<wpwrak>
has .ncd been "cracked" yet ?
<lekernel>
not afaik... and that's one hairy proprietary file format
<wpwrak>
(xdl) it was basically half an hour of writing the few lines that make the changes and then a long and frustrating day and night to halfway work around the bugs in the conversion process
<wpwrak>
(ncd) :-(
<lekernel>
also the ncd info seems to depend on the chip database, which would need to be understood as well
<xiangfu>
I am writing a blog about this small event.
<lars_>
hm, xiangfu i can't even access your site at all, always getting a reset packet
<kristianpaul>
what people was doing in fron this media wall?
<lekernel>
lars_: I guess blocking that reset packet solves the problem? :)
<xiangfu>
kristianpaul, screen-04 is modify the patch: Pulsating photography.fn
<wpwrak>
(speed) glacially slow here, too
<lekernel>
"when your TV is bring. you can buy a Milkymist One :)" hmm... not sure this is a good message
<kristianpaul>
lars_: 123.114.250.54 same ip?
<xiangfu>
lars_, too bad. :(
<xiangfu>
lekernel, oh. I just want kidding. :)
<xiangfu>
lars_, I will update more picture to qi-hardware server. and upload the whole video record about this event.
<wpwrak>
lekernel: maybe s/bring/bling/ ? :)
<xiangfu>
this event is at Qsinghua University. I have a friend there. and he have expensive video record device. :)
<wpwrak>
friends with expensive toys are good to have ;-)
<xiangfu>
I make the Milkymist One rendering, before and after her speech. not much VJ/IT people here. it's most all about Architecture
<xiangfu>
lekernel, she may include one m1 to her Media wall.
<xiangfu>
since we have Video-in. so she also think about build some Camera in :)
<xiangfu>
wpwrak, about this Media Wall. seems only MIDI stuff missing. :)
<kristianpaul>
indeed, a remote control with MIDI support will be interesting to see interacting i think
<wpwrak>
we need to talk more to VJs. all those fringe interests are cute, but they don't really help to bring the core product forward. i.e., there are probably lots of things a VJ would like to change that we don't even know about.
<wpwrak>
xiangfu: so far, anything usb-midi i connected works. so i think you can just visit your local toy market and look for something nice :)
<xiangfu>
wpwrak, (would like to change ..) that is what 'configure' mode goes for.
<xiangfu>
wpwrak, I think this Media wall is most using 'simple' mode. :)
<xiangfu>
so maybe there are two direction for m1.
<wpwrak>
(change) naw, meant more profound changes. on the whole workflow. but perhaps it's too early for that and we first need to develop our own ideas, then see what real VJs think about it
<xiangfu>
so we can learn form VJ and put them to 'simple' automatic mode :)
<xiangfu>
wpwrak, yes.
<wpwrak>
heh, maybe you can steal an effect or two for "simple" mode. why not :)
<xiangfu>
wpwrak, (anything usb-midi i connected works) cool. you so fast.
<wpwrak>
btw, if you want to go shopping for inexpensive MIDI controllers, something like the icon icreativ may be interesting. it's not without flaws, but it may be the best low-cost compromise i've seen so far.
<wpwrak>
MSRP USD 125 and made in china. so there may even be clones ..
<wpwrak>
(well, local "parallel brands")
<wpwrak>
what makes this device interesting is that it has a pad and that you can assign various functions to the pad. such as piano, x/y pad, faders, etc.
<xiangfu>
wpwrak, found 'icon icreativ' at taobao.com . yes. it's ~ USD125.
<wpwrak>
it's also nice and solid. 32 x 10 cm, and almost 1 kg. about the size of a small computer keyboard (HHKB-style)
<wpwrak>
its big flaw is that not only the pad's LEDs have a resolution of 16 x 8 (which is fine), but also the control changes generated from pad touches have that resolution: 16x8 for x/y pad use, 8 levels for faders, and so on
<wpwrak>
all the rest of the device is very well thought-out. just that bit is weird.
<wpwrak>
it has a mechanical fader with full resolution (128 values), so you can use that for sensitive things. with my tornado RMX, i hardly notice the low resolution. of course, with the pacman, it's rather obvious
<xiangfu>
full resolution cost money? or have to make the device bigger?
<wpwrak>
but still, i think it's a nice all-on-one device at a low price point. oh, and i would get it in black, not in ugly white :)
<wpwrak>
xiangfu: full resolution would probably mean to change one byte in their firmware ;-)
<wpwrak>
xiangfu: well, maybe not. but at least 2-4x the current resolution should be doable. the electronics can't be so crappy that only 16x8 works.
<lekernel>
wpwrak: what about writing about the new release into some specialized magazine instead of freecode.com where no one will give a shit?
<lekernel>
sorry xiangfu
<xiangfu>
lekernel, wow, (magazine) my English is not that food for magazine. :) I can try to post to some Chinese IT news website.
<kristianpaul>
hey dont speak hard to freecode.com, it has been there for a while
<lekernel>
xiangfu: I know, but there are Chinese magazines too.
<xiangfu>
lekernel, freecode is just simple for me. not needs write much. just paste from email to the website. :)
<kristianpaul>
:-)
<xiangfu>
lekernel, yes. I will try to do Chinese magazines.
<wpwrak>
hmm. uses an STC12C5A60S2 MCU. peculiar choice
<lekernel>
kristianpaul: I'm not criticizing freecode.com, we have the same problem on every single open source website. everyone has their project, and FN is buried among hundreds of thousands of one-man hobby projects and the like.
<lekernel>
=> no impact
<wpwrak>
and i think they should invest into an SMT machine. ugly soldering.
<wpwrak>
xiangfu: (new features) usb-midi ?
<lekernel>
no, images
<xiangfu>
wpwrak, not include in 1.1 :)
<xiangfu>
included
<wpwrak>
ah, i see :)
<xiangfu>
will be in next release.
<lekernel>
that accompanied with a little tutorial on how to use images (with some MIDI/audio/DMX interaction) would be nice
<xiangfu>
lekernel, is the 'milkymist.com' is down?
<xiangfu>
we will only have milkymist.org in future? right.
<lekernel>
.com redirects on .org... at least supposedly
<wpwrak>
(tutorial) on my list :) but i first want a few more controls. and those - and other things - want a cleaned-up compiler :)
<wpwrak>
heh, and a fat USB-to-parallel converter ;-)
<wpwrak>
that design is so 1990es ;)
<kristianpaul>
oh
<wpwrak>
naturally, the ADC is a separate chip as well
<kristianpaul>
is this LV3 ?
<lekernel>
kristianpaul: LV3 is AVR. you're not attentive...
<wpwrak>
;-)
<kristianpaul>
no i'm not i havent time to read backlog this days
<kristianpaul>
but thanks for the head up ;-)
<wpwrak>
it's the iCON i-Creativ. i already had a peek into the LV3 before. though i think it may have more than one MCU in there. but didn't take it apart completely
<wpwrak>
"The XPT2046 is a 4-wire resistive touch screen controller [...]"
<wpwrak>
12 bit resolution. i think doing a little better than 16x8 shouldn't be all *that* hard :)
elldekaa joined #milkymist
sh4rm4 joined #milkymist
<wpwrak>
its always fun to see how marketing worms its way around USB speeds. from the PDIUSBD12 data sheet: "Complies with the Universal Serial Bus specification Rev. 2.0 (basic speed)". and then: "High performance [...]" and"High-speed (2 Mbytes/s) parallel interface [...]"
<wpwrak>
rule #1: never say "high-speed usb" (i.e., don't lie). rule #2: never say "full-speed" (i.e., don't admit it's not high-speed either). rule #3: use "high" and "high-speed" as often as possible without referring to USB (i.e., let the customer's brain create the lie for you)
<wpwrak>
and they've been too cheap to make the internal pull-up on D+ 5%. instead it's 25%, with a lengthy explanation in the data sheet. hmm. who wants to bet they found out about this well after they had the critter in or very near production ? ;-)
<wpwrak>
at least philips had the decency to mention it at all. not many would.
<lekernel>
yeah... actually, avoiding such chips was part of the reason why I went with the transceivers alone
<lekernel>
this backfired a bit, though...
<wpwrak>
naw, you have that big FPGA there. using some of those "i'm scared of usb" chips would be a great embarrassment. it's like having a ferrari at home but only using a tricycle because you're afraid to drive it. with great power comes great responsibility ;-)
<lars_>
if you are only 3 years old you would probably opt for the tricycle
<kristianpaul>
"Mix of blocking and non-blocking assignments to variable <cycle_count_reg> is not a recommended coding practice." :-|
<kristianpaul>
okay sie 12.3 found more bugs :-)
<kristianpaul>
x/sie/xst
<kristianpaul>
now why it consider and error
<kristianpaul>
s/12/13
<lekernel>
if you knew what blocking and non-blocking assignments were, and I posted links to this several times, the answer would be obvious
<kristianpaul>
yes sure, i wanted to mean, the bug was there i just was re-using some namuru code without debug line by line ;-)
<kristianpaul>
of course i'm not attentive so i surelly dont read this warning in previous 13.2 :p
<wpwrak>
lars_: not sure. your parents would opt for you choosing the tricycle, though :)
elldekaa joined #milkymist
ab5tract joined #milkymist
cocoadaemon joined #milkymist
<lars_>
is there some reset command in `jtag` so i don't have to powercycle the board after flashing a new image?