Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
<wolfspraul>
wpwrak: one question I still had open was about m1's ability to detect cable insertion/removal, for video-in or midi
<wolfspraul>
it sounds as if the video decoder has registers, but can they be watched efficiently in software?
<wolfspraul>
and for midi - is it needed at all? or can we detect incoming messages anyway, and nothing beyond that is needed?
<wpwrak>
midi may be possible in theory. but messy. or you need a magic connector crafted by elves from the horn of unicorns
<wpwrak>
and yes, we can sometimes detect messages even if there's no explicit activity
<wolfspraul>
yes let's forget the connector, that seems to be the wrong path
<wolfspraul>
but when a message comes in, the fpga senses the signals and eventually sends an interrupt? or how does it work?
<wpwrak>
video .. you can look for sync. i suppose you can watch the regs. you'd have to switch sync channels by sw anyway, to there's little to be gained to have, say, a signal telling you that sync has been found in the current configuration
<wpwrak>
unless you want users to manually set the configuration and then report whether a compatible video signal has been detected
<wpwrak>
MIDI is basically a UART. so you receive a few bytes. if they arrive without framing errors, you're probably good :)
<wolfspraul>
hmm. so for both of them (video-in and midi), we don't need to go beyond what is currently possible in software, detection-wise?
<wolfspraul>
and I guess the situation is similar for dmx as it is for midi
<wpwrak>
i think so. for midi, it would mean opening a can of particularly disgusting worms
<wpwrak>
for video, hardware assistance beyond what's already there would add little value. besides, i'm sure you can poll those registers a few times per second without trouble.
<wpwrak>
i don't know dmx. but yes, i would expect it to be comparable.
<wolfspraul>
ok great, seem all settled then
<wolfspraul>
is my impression correct that R4 electrical seems 99% finished?
<wolfspraul>
we have this small issue of ADV7181C sourcing, a little slow but will get answers soon
<wolfspraul>
but most likely we can assume the C to still be easily sourcable, and then we should probably postpone a switch to D until later. why open that for no known benefits today...
<wpwrak>
i think we don't have the DCC5V switch in the schematics yet. but that's just editorial work.
<wolfspraul>
in the unlikely case that we are forced to switch to the D (or we discover something in it that we want very badly), that would be another todo item
<wpwrak>
(codec) whatever works :) did you ask them about their roadmap ?
<wpwrak>
yup
<wolfspraul>
ok cool! then we have... hmm. layout, kicad, boom, small run, usb fixes, test plan, sw updates.
<wolfspraul>
coffee first
<wpwrak>
yeah. death by boredom isn't in sight :)
<wolfspraul>
when do you think we should start the boom/kicad effort
<wolfspraul>
I would like to participate, but if it's another week or so out that would help me
<wpwrak>
the schematics conversion could start right after we finish the public review. if people participate in the review, they'll also have fresh memories
<wolfspraul>
even though we don't have hard data from them yet
<wolfspraul>
oh I understand [spdif j21/j22] all fine
<cladamw>
wolfspraul, 7181C which is very unclear to me.
<wolfspraul>
no, it's not
<wolfspraul>
that's what I tell you
<wolfspraul>
I tell you: relax, we will source it, and we will not point to you for that...
<wolfspraul>
if you get answers in taipei, great. otherwise we get answers in shanghai.
<wolfspraul>
and worst case in shenzhen, they always answer, right? :-)
<wolfspraul>
but at this point, we don't need to plan to upgrade to the D
<wolfspraul>
because for now I don't assume that there is some fatal flaw in the C and ADI wants to force its customers to D. I cannot imagine. I think the C will be available for years.
<wolfspraul>
and I don't think there is something so super attractive in the D for us that we want to hurry the upgrade now.
<wolfspraul>
we have plenty of time later
<wolfspraul>
so: C for now, and we will find out where to buy it...
<cladamw>
okay,
<wolfspraul>
the D would mean that we have to seriously study the datasheet
<wolfspraul>
and probably also the schematic, and definitely the layout
<wolfspraul>
not now, R5...
<cladamw>
Joerg's ideas on keying for J21/J22 is good.
<wolfspraul>
I meant "probably change the schematic, and definitely the layout"
<cladamw>
(7181D) okay, 'assume' to understand fully for R5. ;-)
<wolfspraul>
it's just for you to *assume* for now
<wolfspraul>
if there is a surprise, well, then we have to react
<wolfspraul>
but I think we can assume the C issue will resolve itself soon
<cladamw>
okay
<wolfspraul>
ADI is a very respected vendor, afaik
<wolfspraul>
do you have a rough timeline for layout already?
<wolfspraul>
I mean a date when you go there?
<cladamw>
we should send a final schematic review this week, then find mistakes from me in case, after that then following tasks:
<cladamw>
1. let house to placement then we depends on that for reviewing the all parts's placements, and see if house have serious feedback, meanwhile try to get mp sch from them then.
<cladamw>
2. generate dxf for mechanical file which i think Werner will like it also we use it to check carefully before starting a route, during this period, i think that there should be some tasks we'll meet:
<wolfspraul>
sure. I'm just curious how the scheduling with the layout folks goes.
<wolfspraul>
actually, what is the company exactly? do they have a url?
<wolfspraul>
I don't remember a name, we always seem to say 'layout house' :-)
<cladamw>
2.a) considering how complexity of 6 usb circuits from house and react.
<cladamw>
2.b) considering if add another one machenical hole to provide J21/J22 to strengthen and not cause too much bend while plugging extension board, which we didn't dully discuss in advance well though.
<wolfspraul>
what?
<wolfspraul>
:-)
<wolfspraul>
first time I hear that - 2.b)
<cladamw>
no, i chatted with werner before. ;-) but that time we took this consideration before route to discuss. ;-)
<cladamw>
you can imagine when user pull plug into their extension board on J21/J22, it must have strength on near fpga, we don't want in the end, the solderibilty will be faulty after plugging by bend pcb. ;-)
<cladamw>
so must be provided a mechanism around J21 to suffer. ;-)
<cladamw>
PLAB possesses a whole vertical service from ODM and OEM case. I found it after we started for rc1.
<wolfspraul>
hmm
<wolfspraul>
just looking at the board
<wolfspraul>
what are those big spots for C23 and C25 ?
<cladamw>
the area of C23 and C25 will be the placement for J22(10*2 header)
<cladamw>
wpwrak, how do you think that we take considering add mechanism strong way nearby C73 and J21's 19 and 20 pins ?
<wolfspraul>
what was C23 and C25 for?
<wolfspraul>
looks like some hugs caps, but for what?
<wolfspraul>
that space will be freed in R4?
<cladamw>
C23 C25 is for audio LNLVLOUT[R&L] which we DNP it while R3.
<cladamw>
now they will be smaller be as 0805 only in R4.
<cladamw>
which is suggested by Joerg. ;-)
<cladamw>
so C23 C25 would be the area for J22 in R4.
<wolfspraul>
smaller is good
<wolfspraul>
I understand your point about expansion board exercising mechanical stress on the fpga
<GitHub157>
[scripts] xiangfu pushed 1 new commit to master: http://git.io/bbr5fw
<GitHub157>
[scripts/master] reflash_m1.sh: update to 03-01, use the latest bios-rescue - Xiangfu Liu
<cladamw>
btw, it must be have a idea there around J21 for strengthen which is also a task before routing.
<wpwrak>
cladamw: near C73 sounds good. will it resist only push or also pull ?
<cladamw>
wpwrak, i'm thinking to use the same strength like J12 hole to place around either J21:20 external side (i.e. near C73) or J21:19 internal side(i.e. the place between J21 and R112).
<cladamw>
wpwrak, 'only' this added 'hole' not to impact DDRAM and digital routes from fpga too much then it could be safe. hoe do you think? I would leave this when I am in house to talk with them to find a suitable place to placement this mechanical hole.
<wpwrak>
phew. finally found J12 :-)
<wpwrak>
so this needs a case change ?
<cladamw>
just one another hole in bottom case, how do you think ?
<cladamw>
not for top case.
<wpwrak>
yes, probably unavoidable
<cladamw>
I don't think user will think out a 'bend' will potentially damage solderibility for fpga.
<cladamw>
yeap, so directly add this hole is very important.
<cladamw>
wpwrak, another possible place, like around L3, how do you think?
<wpwrak>
yes, may be less trouble for the routing
<wpwrak>
with DVI, the U18 area will get busy
<cladamw>
yes, we know it , just need to let house placement them firstly then we check all before start to route.
<wpwrak>
i somehow think they'll have a lot of fun ;-)
<cladamw>
wpwrak, ha.. R4 will provide house a tough work/fun. ;-)
<cladamw>
alright, so I think it's time that I go for every details to finish draft sch. then review irc first then list. ;-)
<cladamw>
wpwrak, any else to remind me ?
<wolfspraul>
oh I see
<wpwrak>
did you already add the DCC5V switch ?
<wolfspraul>
another foot/stand under the pcb?
<wpwrak>
yup
<wolfspraul>
ok
<cladamw>
wpwrak, not yet, will add.
LmAt has joined #milkymist
<roh>
wolfspraul: whats the timeline for R4?
<roh>
wolfspraul: just thinking ahead about cases ;)
<wolfspraul>
no exact timeline yet, and I don't have money for a large case production either, so I am exploring some crazy new ways to make case parts, such as cutting 3mm epoxy pcb cores at pcb makers :-)
<wolfspraul>
I haven't thought about it in detail yet
<wolfspraul>
also size of run
<wolfspraul>
first of all we will make a small 6 or 8 pc pcb only small run, because there are just too many changes
<wolfspraul>
especially the dvi-i part
<wolfspraul>
that one is clear now
<wolfspraul>
then the real run, we see
<wolfspraul>
do you have any ideas how to cut costs of the case?
<wolfspraul>
in parallel I am selling r3, actually it goes quite well. I am down to about 15.
<wolfspraul>
if someone orders another 10-pack I may run out fast, in which case I will have to accelerate the for-sale R4 run.
<wolfspraul>
if we cannot sell R3 before R4 comes out, my rough plan is to just upgrade the units I have in-stock
<wolfspraul>
I don't want to get stuck on R3 units. In that case I would only need some new side panels.
<wolfspraul>
but it looks like that won't happen
<wolfspraul>
if I get another larger order from somewhere, no need to upgrade
<wolfspraul>
so the R4 run will be clean, from-scratch
<wolfspraul>
that's about the status quo
<wolfspraul>
there are changes to the accessories too, just for completeness
<wolfspraul>
for one I am planning to remove the silicone keyboard and remote control
<wolfspraul>
and instead include one of those small usb-rf keyboard/mouse mini keyboards
<wolfspraul>
currently sampling from several vendors, testing, comparing, etc.
<wolfspraul>
then the m1 power supply is a little weak with 2A
<wolfspraul>
if we have more usb devices (r4 probably will have 4 ports)
<wolfspraul>
that's a problem, because the power supply vendor already went out of their way to support our r3 mini-run
<wolfspraul>
their normal moq is 5k
<wolfspraul>
:-)
<wolfspraul>
so we have to shed some tears and cry a little and maybe we get that updated/redesigned to 3A or 4A
<wolfspraul>
I do feel bad for them, I know they have a real business to run as well.
<wolfspraul>
oh, then we need to source a dvi-i to vga cable as well, I just realize
<wolfspraul>
roh: bottom line, I cannot promise anything right now
<roh>
sure
<roh>
we'll see... i think we can only cut cost massively if we change to a cheaper material and cutting techniques.
<wolfspraul>
what could that be?
<roh>
e.g. see if waterjet cut aluminium could be it... or even 'stamped' but that would need much more volume
<wolfspraul>
have you done anything with aluminum - or followed others?
<roh>
lasercutting isnt getting much cheaper since we cannot reduce the 'worktime' of the machine anymore. atleast not more than single percent
<roh>
gismo had some stuff waterjet cut around the corner. but that was steel i think. a mechanical sample for a brake-disk
<roh>
they want about 80E for them to switch on the machine. volume is another question
<roh>
the acryllic material isnt even the big part in the price calculation. its worktime and overhead to get stuff done which is the most expensive besides the lasering itself
<roh>
too many manual steps. e.g. the shielding sheets need to be all drilled and 'entgratet' by hand.. same for making the stickers and put them on the metal
<wolfspraul>
yes
<wolfspraul>
maybe joerg's aluminum-strip X may remove the need for that
<wolfspraul>
or a metallic case
<wolfspraul>
I will definitely try the 'use pcb maker' route, even if just to learn about price and what cutting they can do easily and not so easily
<wolfspraul>
as an experimental case
<wolfspraul>
btw, remember the wood one you made once? by now it has bent badly, won't fit together anymore
<roh>
well.. that would be either quite rough (v-cut and breaking it off) or milled
<roh>
(pcb stuff)
<wolfspraul>
not sure, pcbs can and are made in all sorts of shapes nowadays, but as always it comes down to cost, volume, amount of work, etc.
<roh>
bent? hm.. did it get wet?
<wolfspraul>
no, just humidity I guess
<roh>
ah. yes. that does evil stuff to unhandled wood too
<roh>
i fear that the mechanical concept we have now and the quality we want to archieve doesnt allow for any big cost cuts anymore if we dont push up the volume massively (atleast for the case)
<roh>
e.g. when it would come to a that big amount that we could invest that into a new, bigger machine here at raumfahrtagentur, we could also make a much better price i think
<roh>
my current estimate says that that could happen at something between 100 and 250 cases. given that material, machine and worktime prices stay the same
<wolfspraul>
oh I totally agree but I also think we are on exactly the right path
<roh>
molded case parts would ne nice, and much cheaper 'per thing' but have a extreme initial cost and are quite complex for a design we need to 'fold or clip around' the 4 sides. connectors on 4 sides make it not easy ;)
<wpwrak>
hmm, kristianpaul's laser-cutting wasn't so expensive
<wolfspraul>
we have a beautiful case, and a good pricepoint for the product
<wolfspraul>
one by one
<wpwrak>
so either that shop is losing money or they k
<wolfspraul>
we have a beautiful case, and we are trying to improve it now
<wpwrak>
operate with lower cost
<roh>
wpwrak: i think he basically got it for 'stamp money' since it was only one and they handled it as 'example'
<wolfspraul>
economically, electrically (emi), mechanically, etc.
<wolfspraul>
I don't believe in 'high volume' per se
<wolfspraul>
that's the mythical-man-month of hardware
<kristianpaul>
wpwrak: and i guess in china will be _super_ no expensive :)
<wolfspraul>
I have no problem at all if in the end we order more high-quality and high-cost cases from raumfahrtagentur
<roh>
sure. me neither. stuff costs what its worth. always a question of quality
<wolfspraul>
most important is that m1 stays in stock and gets better and attracts larger orders/customers/investors
<wolfspraul>
totally
<wolfspraul>
people argue that a 30 USD computer is too much, then they go and buy a 300 USD Nike shoe
<kristianpaul>
indeed, quality is very important for the end piece (full for mechanical details)
<wolfspraul>
go figure :-)
<wolfspraul>
and that Nike shoe has a 'bom' of < 5 USD ;-)
<wolfspraul>
so one by one
<roh>
i also think that atleast for now the 'everything opensource model' doesn work that easy as it does for us when one does too cheap devices in too high volumes
<kristianpaul>
may be raumfahrtagentur could outsource lase cutting some where else and reduce a bit prices?
<wolfspraul>
m1 has a beautiful, stunning and well engineered case today
<wolfspraul>
as I said I think 'high volume' is the MMM
<kristianpaul>
i mean, they know how get work done, thats is all about no? :)
<wolfspraul>
high volume starts with low volume
<wolfspraul>
always
<roh>
kristianpaul: i did that already last time. but it means a lot of work for me anyhow.
<wolfspraul>
someone is eating the cost / investing
<wolfspraul>
no no
<roh>
kristianpaul: i got the laser results back as '4 big bags'
<wolfspraul>
raumfahrtagentur did excellent
<wolfspraul>
a massive supporter of the project
<wolfspraul>
not in talk, but in us having excellent cased products shipping today
<roh>
wolfspraul: we now have even a small (currently .de only) webshop infrastructure for other products
<wolfspraul>
and we sold 65 of those beauties to-date - not bad
<roh>
nice
<wolfspraul>
I need to do better on my end
<wolfspraul>
for example I really hate the silicone kbd now :-)
<wolfspraul>
want to switch to those beautiful little remote thingies
<roh>
wolfspraul: you need to visit us at our new location when you are in berlin again .)
<wolfspraul>
definitely, but I'm cutting my travel costs. saving up for the case order :-)
<wolfspraul>
first I will do my pcb maker experiment now. raumfahrtagentur remains the trusted gold standard option for r4 cases.
<roh>
:)
<wolfspraul>
and our pricepoint of 499 USD allows us to make an actual high-quality product
<wolfspraul>
if we can fill that with value, the rest will sort itself out. orders or investors come in, volume goes up, costs go down, etc.
<wolfspraul>
and if not - no point in scaling volume either :-)
<wolfspraul>
that would only scale losses - for someone...
<roh>
we actually would like to do and sell more products at raumfahrtagentur, but we currently dont know what kind of and know that if it would be too complex or costly we cannot prefinance it
<wolfspraul>
and we all know we are well positioned for scale
<roh>
either somewhere in the middle between the mm1 pricepoint and an arduino, or much above the mm1 (but also lower volume)
<wolfspraul>
yes
<wolfspraul>
if you think through the case economics first, I think you are on a good path
<roh>
a friend of mine, elektra plans for some ultra-low-bandwith-p2p-pager project.
<wolfspraul>
nice!
<kristianpaul>
wow 15 left
<kristianpaul>
roh: nanonote powered i guess :)
<wolfspraul>
roh: website/blog?
<kristianpaul>
yes!?
<roh>
i showed her qi-hw and the nn but its kinda compatible and not.
<roh>
it will be foss for sure. and its 'compatible' in thinking, etc, but she cannot use the stuff we have as it is.
<wolfspraul>
sure
<wolfspraul>
it must work, reach regular people
<roh>
but i think it would ne interresting to have it as another product listed there, and maybe she can use the usb-vendor id etc
<kristianpaul>
oh yes pagers dont have keyboard ;-)
<wolfspraul>
for a p2p network to really take off, I believe there must be a way to reward the people helping to shuffle data around
<roh>
it will be a usb client device for now, doing a cdc-ethernet and a cdc-acm-serial. ethernet for packets and serial for radio config
<wolfspraul>
and the software stack must be stronger along the lines of delay tolerancy, because most likely an actual p2p network would be one with varying degrees of delay
<wolfspraul>
when those 2 things are addressed, maybe it can take of
<wolfspraul>
off
<wolfspraul>
imho
<roh>
i heard something about 6km distance per device. and the radio does use so little energy that repeaters can run from solar alone.
<wolfspraul>
excellent
<wolfspraul>
blog/url?
<wolfspraul>
(btw, we are abusing milkymist for general open hardware/qi talk again ;-))
<roh>
well.. its a pager so i think it could actually work, even with meshing. she wrote a book about that.
<wolfspraul>
fine by me
<kristianpaul>
abuse!:)
<wolfspraul>
yes totally, I love it
<roh>
i dont know if she has something online about it yet
<wolfspraul>
like I said, two things i always ask: 1) reward for data transfers 2) delay tolerant apps/stack/use cases
<roh>
i will tell her you like it and to register a project in the wiki and on projects
<wolfspraul>
me liking it doesn't mean much :-)
<kristianpaul>
i'm interesting on what she uses for wireless, please make her join qi-hw irc channel :)
<wolfspraul>
maybe it means it won't go anywhere ;-)
<kristianpaul>
to tell us mroe
<wolfspraul>
definitely
<roh>
kristianpaul: 802.15.4 i think. but on 700-900mhz radios
<kristianpaul>
oh
<roh>
atmel radio and i think stm32 as mcu for now. cortex-m3
<roh>
its in hw prototype status atm
<kristianpaul>
i tought was some ISM cheap tranceiver
<roh>
kristianpaul: it is. she chose the chips for availability and price i think.
<roh>
the goal is to use it with openwrt routers for now, and make a autonomous repeater later
<kristianpaul>
okay qi-hw talks after 2:00 UTC ;-) !
<kristianpaul>
settle? :)
wolfspraul has joined #milkymist
<kristianpaul>
Just kidding but is bad if i invite someone that not own a M1 to ask for collaboration for getting a port for its board?
<kristianpaul>
Even more less if may be he will need some help (as i do too somethimes) with to HDL fu related to clock domains? :-)
<kristianpaul>
So the point is... this is not a learn verilog channell but we do be open and collaborative with other people interested in milkysmit?
<wolfspraul>
huh?
<wolfspraul>
I don't understand
<wolfspraul>
of course this is also a learn-verilog channel
<kristianpaul>
or perhaps is a misundertood interesting, realizing for millymist first you need a lot of RTFM and thats all..
<wolfspraul>
if not he is invited to #qi-hardware, that is a learn-verilog channel for sure :-)
<wolfspraul>
a port of milkymist to other boards still helps milkymist, if it creates new documentation, blog posts, ideally even some documentation or code patches sent back and committed upstream
<wolfspraul>
that's my opinion
<kristianpaul>
good, just asking, open questions :)
<wolfspraul>
I would be as inclusive as possible
<wolfspraul>
on the other hand, starting on the m1 board will probably save most people *A LOT* of time and bugs that others have fixed before
<wolfspraul>
so it depends on the goals of the other person. if they have some board X and just want to port milkymist to it, for the heck of it, then they should do that.
<wolfspraul>
and if they want to reuse as much as possible code that works tooday, and has been bug-fixed by several people for several years, I think the money spent for an m1 board is well spent
<kristianpaul>
oh, absolutelly
<wolfspraul>
you can go either way, just need to know what you want
<kristianpaul>
you cant unleash milkysmist no more than getting a M1, for sure
pablojavier has joined #milkymist
<wolfspraul>
btw
<wolfspraul>
some numbers
<wolfspraul>
the last m1 run was 90 boards
<wolfspraul>
the plan was to make 80 full retail kits
<wolfspraul>
so we sourced accessories 80-85-90, depending on how likely we thought that some would fail our testing
<wolfspraul>
some things even 100, like the box
<wolfspraul>
the end result was that we indeed had 80 full boxes
<wolfspraul>
and another 8 bare boards
<wolfspraul>
88 that 100% passed all tests
<wolfspraul>
2 still fail, put aside
<wolfspraul>
by now I have sold all these 8 boards, so only full kits left now
<kristianpaul>
:)
<wolfspraul>
in other words - I am open-minded to selling bare boards, we really try to make ever case work
<wolfspraul>
every
<wolfspraul>
if it helps the milkymist project, it's good :-)
<kristianpaul>
are you still asked for bare boards?
<kristianpaul>
in comparison the the full kit
<kristianpaul>
ok, read you later gn8
<wolfspraul>
no
<wolfspraul>
it's very rare and doesn't make much sense anyway. basically just known friends of the project :-)
pablojavier has joined #milkymist
pablojavier has quit [#milkymist]
wolfspraul has joined #milkymist
rejon has joined #milkymist
cladamw has joined #milkymist
<cladamw>
xiangfu, one question, i found that my video 7181C input source input from green rca connector to blue in ? but adv 7181b in rc3 works well.
<cladamw>
xiangfu, i replaced video adv7181B part to adv7181C, will somewhere like bios or f/w to cause this ? or like *.h file already there to detect C version in latest image ?
<xiangfu>
cladamw, not sure. I think no needs change the source code.
<wolfspraul>
yes, definitely
<wolfspraul>
it was already discussed and it needs a few lines of C detection and different register initialization
<wolfspraul>
which I believe to some extent is already there because Werner has a C? or not soldered? don't know
<xiangfu>
cladamw, ok. then it will not working with current software.
<xiangfu>
cladamw, there is no code for 7181C for now.
<cladamw>
sorry that I should say the scenario on my rc3 with adv7181C is not 'always' from green input, sometimes if it disappear, then I plugged into blue then gui can show it.
<wolfspraul>
xiangfu: you can check the irclog backlog, it may be somewhere. or wait for sebastien or werner.
<cladamw>
xiangfu, oah...so there's no real codes for 7181c now, oah i see...phew...i was shocked a bit. ;-)
<cladamwa>
he...yes this maks me reflashed C from Werner, yes. I was thought it's already inlcuded in current image though, thanks.
<wpwrak>
for now, we just have that "proof of concept" code. no proper support in FN et al. the various other video in configurations (i.e., other than composite on green) FN supports need changing too.
<wolfspraul>
that makes me think that a direct switch to D also would have its advantages
<wolfspraul>
we will know C and D sourcing status soon
<wpwrak>
(switch to D) in my lazier moments i was thinking just that ;-))
<wpwrak>
but it's a relatively minor thing. just need some table somewhere. and then figure out how to test all of this. that's actually the main work.
<wolfspraul>
sure
<wolfspraul>
but since nothing must yet was done for the C, a direct switch to D looks attractive (just from that angle)
<wolfspraul>
I am a little worried about jumping on such a brand new chip though, even if it is available
<wolfspraul>
we've learnt a few lessons...
<wpwrak>
;-)
<wpwrak>
FREE beta testing :)
rejon has joined #milkymist
cladamwa has joined #milkymist
wolfspraul has joined #milkymist
hypermodern has quit [#milkymist]
<GitHub15>
[flickernoise] xiangfu pushed 1 new commit to master: http://git.io/6uQuRg
<GitHub15>
[flickernoise/master] fixed issue #35 take the currect settings to full screen - Xiangfu Liu
<wolfspraul>
xiangfu: I have a new usb-midi controller for you btw, m-audio xsession pro
<wolfspraul>
simple little thing (used one Jon gave me), but if it works itself (not broken), then it should work with m1 too. another device to test with... (will give you in our next meeting)
<wolfspraul>
when I plug it into my m1, the red power LED comes on - good first sign :-)
<xiangfu>
lekernel, nothing. update flickernoise. then the error come out.
<lekernel>
you probably forgot to upgrade RTEMS too (with my patch)
<xiangfu>
lekernel, ok. updating... and re-compile rtems.
<xiangfu>
wolfspraul, (m-audio xsession pro) another MIDI :)
<xiangfu>
lekernel, (full screen) will try to fix it today. :) sorry for that. maybe I git push -f. delete my commit at all :D
<xiangfu>
wolfspraul, when you press any button. if the are some 'active' under 'MIDI settings' ?
<xiangfu>
lekernel, I met another error: /opt/rtems-4.11/lm32-rtems4.11/milkymist/lib/libyaffs2.a(rtems_yaffs.o):(.rodata+0x3c): undefined reference to `rtems_filesystem_default_fpathconf'
<xiangfu>
rtems upsteam remove it under 'Sat Feb 11 20:35:53 2012 +0100'
<xiangfu>
'Removed fpathconf file system node handler.'
<xiangfu>
try to update the rtems-yaffs2
<xiangfu>
already fixed
Gurty has joined #milkymist
<xiangfu>
working on 'issues/35' again :(
<lekernel>
xiangfu: don't rewrite history, just use git revert xxx
<xiangfu>
"Does not take format changes into account" it works fine here. even with that patch. did I mis-understand you?
<lekernel>
xiangfu: but it's still out of sync - if you run the preview, then change format, and exit the preview, the buttons will not represent the new format
<lekernel>
xiangfu: the simplest way you can fix all problems is by preventing the renderer from touching the video-in settings when you use it for video preview
<lekernel>
xiangfu: alternatively, you can reload the config after you exit preview. but it makes everything a tad more complicated...
<xiangfu>
(preventing the renderer ) but it will be a little complicated on pass the video-in parameter to the renderer.
<xiangfu>
(alternatively, you can reload the config after you exit preview) I already did that on last comment patch. :P
<xiangfu>
there is a 'load_videoin_config()' in stop_callback.
<lekernel>
hm, true. sorry, missed it
<lekernel>
xiangfu: sounds OK except it probably needs another set_config() when you click one of the format buttons
<lekernel>
otherwise it'll revert to the old format when clicking the preview button
<xiangfu>
oh. yes
<lekernel>
that's what I meant with "Does not take format changes into account"
<GitHub96>
[flickernoise] xiangfu pushed 1 new commit to master: http://git.io/-oG0ig
<GitHub96>
[flickernoise/master] Video in: fix the full screen sync with settings - Xiangfu Liu
<xiangfu>
should be ok this time.
<lekernel>
wolfspraul: when you do this R4 run, please send me one of those boards right away before letting them all through SMT... I need to check that I can still run the SDRAM at 166MHz
<lekernel>
maybe I'll have easily usable test software by then though
<wolfspraul>
definitely
<wolfspraul>
as I said a few times already, I am planning a small run first, 6 or 8 board
<wolfspraul>
boards
<wolfspraul>
there are too many changes and we need to verify a little
<wolfspraul>
what do you think might affect sdram negatively? anything we should do in advance?
<lekernel>
with all the extra connected FPGA pins, I would be surprised if all the SDRAM routes were kept as is
<lekernel>
that would be the less risky option though ...
<wolfspraul>
ok, will take extra care of that
<lekernel>
that's why I'm trying to argue for the less extra FPGA pins = the better
<lekernel>
so no DDC diagnostic signals etc.
<wolfspraul>
we already agree on those
<wolfspraul>
memory performance is far more important than some small goodies
<lekernel>
wolfspraul: btw only 15 M1s left in stock now?
<lekernel>
or 23 ?
<wolfspraul>
he
<wolfspraul>
I am not counting every day
<wolfspraul>
but yes, I owe you an answer on your last mail, queued...
<wolfspraul>
I think it's around 15
<lekernel>
ha, great!
<lekernel>
xiangfu: thanks for fixing the video-in preview. I'll send new web-updates today...
<xiangfu>
lekernel, great. :)
<xiangfu>
I am working on fix: 'killing the Performance (compilation progress) window doesn't stop compilation.'
<xiangfu>
not sure if I can finish it soon.
<xiangfu>
compare to the patch editor bugs. this one is more simple :P
<lekernel>
xiangfu: just disable the close button when it's compiling... aborting the compiler cleanly and without bugs can be messy
<GitHub50>
[flickernoise] xiangfu pushed 1 new commit to master: http://git.io/eMS8mg
<GitHub50>
[flickernoise/master] performance: disable all button while compiling patches - Xiangfu Liu
rejon has joined #milkymist
<xiangfu>
for now the OSD can disaply two lines strings. how I can make it display more lines?
rejon has joined #milkymist
cladamw has joined #milkymist
rejon has joined #milkymist
rejon has joined #milkymist
<Fallenou>
15 M1 left ? how many in this run ?
<wpwrak>
rc3 run ? or r4 ?
<wolfspraul>
this run?
<wolfspraul>
there were 3 runs so far
<wolfspraul>
first run, 6 pc, all with major issues, none sold
<wolfspraul>
second run, 40 pc, about 31-33 were 100% good and sold, and the remaining ones were used up in various development/testing/design efforts
<wolfspraul>
third run, 90pc, 88 good, 8 bare boards all sold, about 65 of the other 80 full kits sold so far
<wolfspraul>
that's all :-)
<Fallenou>
wow ok :)
<Fallenou>
so 15 left, over those 88 + 40 + 6 ?
<Fallenou>
that's great isn't it ?
<Fallenou>
strange we didn't get more emails on the mailing list
<wolfspraul>
yeah but we don't have real great user demand yet
<wolfspraul>
no, not strange
<wolfspraul>
the sales are all, one by one, after massive convincing ;-)
<wolfspraul>
just think about how you got yours :-)
<Fallenou>
hehe yep
<Fallenou>
but when you get one, you MUST have questions
<wolfspraul>
for this thing to take off, our current customers have to really love the box, and recommend to their friends
<Fallenou>
about how to use it, etc
<Fallenou>
so it's really strange that we don't get more support request
<wolfspraul>
that is not happening yet, but we get there
<lekernel>
wolfspraul: didn't the CDM article help?
<wolfspraul>
no, not strange to me
<wolfspraul>
cdm? you mean peter kirn?
<wolfspraul>
definitely, yes
<lekernel>
it sold all the small amazon stock in one day ...
<lekernel>
yes
<wolfspraul>
sure
<Fallenou>
wolfspraul: I'm showing it. at work, in an association, I make pictures tweets etc ;)
<wolfspraul>
too bad it ran out of stock
<Fallenou>
to friends colleagues
<wolfspraul>
great!
<wolfspraul>
eventually this thing will take off
<Fallenou>
and they usually love the thing
<wolfspraul>
I am 100% sure
<wolfspraul>
Fallenou: thanks a lot!
<Fallenou>
I've seen a nice dmx moroted spot light on a milkymist video
<Fallenou>
motored*
<Fallenou>
how much does it cost ? :o
<wolfspraul>
the DMX items xiangfu bought were cheap, about 300 USD
<wolfspraul>
but they are also very limited
<Fallenou>
hum ok , cheap for a spot
<Fallenou>
but not that cheap :p
<wolfspraul>
I don't think there's a motor-driven spotlight among them
<Fallenou>
anyway, I have played enough with it all the week, I need to focus on mmu now :p
<Fallenou>
not buy new toys
<wolfspraul>
sure, but those are good things that won't go away
<wolfspraul>
that's why I think we can invite people to milkymist today wholeheartedly
<Fallenou>
yes
<Fallenou>
I am definitely not a VJ or DJ
<Fallenou>
and I was able to do nice things with very few efforts
<wolfspraul>
but in parallel we need to work on making the m1 experience out of the box so great that people really get hooked, tell their friends, etc.
<wolfspraul>
Fallenou: maybe you are exceptionally talented :-)
<Fallenou>
ahah no I don't think so :p
<Fallenou>
about the user experience, I can just say that any non-geek which does not care about fpga or low level stuff would say that the GUI is "slow"
<Fallenou>
meaning that if you drag windows it's kind of slow
<wpwrak>
some people will never be happy :)
<Fallenou>
personnally I don't care that much and I am more amazed about the fact that all of this runs on an FPGA, but a lambda user won't care about the FPGA miracle
<wolfspraul>
the render mode hopefully gets so good one day that most people will never need to go into the GUI
<Fallenou>
yep rendering mode works well and no lag :)
<lekernel>
funny, 1st time I hear the GUI is slow. a lot of people find it fast :p
<wpwrak>
wolfspraul: hmm, the end of "no PC needed" ?
<Fallenou>
really ?
<Fallenou>
when dragging a window over ?
<lekernel>
and I think it is, except for moving windows as you pointed out
<Fallenou>
oh yes
<Fallenou>
except that, when you click on buttons etc yes it's fast
<Fallenou>
file browsing, mouse wheel scrolling , it's all fast
<lekernel>
major software redesign should have a compositing GUI
<lekernel>
but here I just took existing code and compiled it
<lekernel>
there's no reason we can't have iOS-like interaction on the MM architecture
<wolfspraul>
Sebastien cannot work on everything, we will get more people to join.
<lekernel>
it's definitely capable of this
<Fallenou>
I guess it's a pretty good result when you take the amount of time it took to have such GUI ?
<lekernel>
(and more :)
<Fallenou>
one thing at a time anyway :)
<Fallenou>
just my feeling
<Fallenou>
oh and 3 usb ports would be awesome :'
<Fallenou>
to have keybord+mouse+midi
<Fallenou>
(midi usb)
<Fallenou>
but I've heard it's already planned
<wolfspraul>
you can try a wireless keyboard+mouse combo
<wolfspraul>
that will only occupy 1 USB port
<wpwrak>
Fallenou: M1r4 will have 4 external ports :)
<Fallenou>
yeah !
<Fallenou>
very nice
<wolfspraul>
or one of those rii mini keyboards with integrated touchpad
<Fallenou>
wolfspraul: yes I don't have this kind of combo but it's a nice idea
<wolfspraul>
you can look at amazon for 'logitech wireless combo'
<lekernel>
speaking of the GUI, how about writing all the high level UI logic code in Lua?
<wolfspraul>
and actually they may be at pretty much any store around you, quite cheap
<lekernel>
and use its object model to take care of widgets hierarchies etc.
<lekernel>
then rendering in C with some hardware acceleration
<wolfspraul>
about 20 USD
<wolfspraul>
the tiny rii remotes should come out at about 30 EUR or so, in Europe
<lekernel>
all the pesky things like manipulating strings for filenames can be done better in Lua
<roh>
wolfspraul: if you need a small number of cases just holler. i'll work something out
<wolfspraul>
great, thanks!
<wolfspraul>
not there yet, we are in the depth of design improvement right now ;-)
<roh>
for the rest of your rc3 boards. i think i also have 2 already around. in uv-red and the violett we had before
<wolfspraul>
including driving a few new requirements into mechanical, connector changes, new hole in bottom, etc.
<wolfspraul>
nice. we can use those old parts, no worries
<roh>
sure. n.p. was just thinking for the rest of the rc3 boards. or do you still have enough cases?
<wolfspraul>
I am also buying back some rc2 boards for upgrades, and so on
<roh>
ah. i think i also got a rc2.
<wolfspraul>
those one-off things need to be dealt with economically, so we have to wait for a good opportunity
<wolfspraul>
I can send you an early r4 and a design fee to update the files... one by one.
<roh>
sure. more a question of shipping opportunities or so
<Fallenou>
14:13 < wolfspraul> you can look at amazon for 'logitech wireless combo' < ok thanks for the reference, I will check this out :)
<wolfspraul>
also 'rii remote', same concept but much smaller
<wolfspraul>
go for the rii if you want something to use at an event/party/etc., during rendering
<wolfspraul>
go for the logitech wireless combo if you are in the gui a lot, editing patches
<wolfspraul>
keyboard is bigger, separate mouse
<Fallenou>
hum yep I like the separate mouse
<Fallenou>
and I don't plan on doing much parties :p
<lekernel>
he :) let's stop trolling. as I said, I'm not opposed to using OpenRISC on the basis that it technically becomes as good as LM32, which it simply isn't today.
<Fallenou>
=)
VJTachyon has joined #milkymist
lekernel_ has joined #milkymist
cozy has joined #milkymist
antgreen has joined #milkymist
rejon has joined #milkymist
<kristianpaul>
porting a simple (newlib) library to the board !
<kristianpaul>
Thats good
<kristianpaul>
I need that for milkymist ;)
<kristianpaul>
one*
<kristianpaul>
libgloss ah
<kristianpaul>
hmm lm32 have one already
<kristianpaul>
also moxie, wow !
<kristianpaul>
antgreen: :)
<antgreen>
woooooo! go moxie :) slowest project e v e r !
<kristianpaul>
:P
lekernel has joined #milkymist
Guest91557 has joined #milkymist
kilae has joined #milkymist
cozyspell has joined #milkymist
kyak has joined #milkymist
kyak has joined #milkymist
cozyspell has joined #milkymist
<lekernel>
wpwrak: does the pacman patch still work for you?
<lekernel>
hmm... works after a reboot... nice non-reproductible problem like we all love
<wpwrak>
lekernel: it's pretty tricky. even very innocent changes to the usb fw can radically change how it behaves. it sometimes feels as if there was a switch (cpu_cycles % SOME_SMALL_NUMBER) { case 0: almost_work; case 1: crash_horribly; case 2: do_something_weird; ... }
<wpwrak>
i just hope there's not really such a a clock cycle dependency ...
<wpwrak>
at least the new debug stuff under FN lets me see more clearly just how weitd it is :)
<lekernel>
mh
<wpwrak>
well, eventually, i'll figure it out. i just wish those bugs would finally learn that resistance only prolongs their suffering :)
Scopeuk has joined #milkymist
<wpwrak>
hmm, do we have a sort of official prefix for environment variables for things related to M1 on the host ? in tools/asm/pfpu, I used M1_HOST, M1_USER, and M1_PW. do they sound good ? (i'm getting tired of typing in passwords :-)