<aw>
0x30: U7's input signal from fpga is very good, it's ouput pin 4 is not 5V pulse, then I re-soldering U7 pins again then still no output well. so I decided to replace a new one later.
<wpwrak_>
aw: but pin 5 (of U7) is a clean 5V ?
<aw>
wpwrak_, yeah...much clean 5V
<wpwrak_>
aw: sounds nasty then.
<aw>
R56 220 ohm also good
<wpwrak_>
aw: have you measured U7.4 to ground resistance (when unpowered) ?
<aw>
don't know, just soldered new one. ;-) let's test. :)
<aw>
hmm...good idea. No.
<aw>
good..now PASS. ;-)
<wolfspraul>
aw: you record the U7 findings and exchange in the test results spreadsheet, right?
<wolfspraul>
we did pretty well on the rc2 run, with the 'notes' column remembering all actions, so we should do that again
<aw>
wolfspraul, recording now. ;-) also will add another test logs. ;-)
<wolfspraul>
great
<wolfspraul>
then on to 0x31 :-)
<wolfspraul>
so we have the first full-function board with 0x30 ?
<wolfspraul>
probably 0x2F had too many reworks and we consider it internal/Adam use only
<wolfspraul>
correct?
<aw>
btw, we need to tell xiangfu that when we test only like MIDI from menu selection, after i press "h", test tool should tell me a "h" selected. ;-)
<wolfspraul>
maybe you can also take a picture of 0x30 on both sides to document the wire...
<aw>
yes, let's let 0x2F to delievered by Adam firstly..
<wolfspraul>
but 0x30 looks perfect now, right?
<aw>
yes, take pictures later
<aw>
yes
<wolfspraul>
maybe you can leave 0x30 rendering for 24h or so
<wolfspraul>
just plug in the power, boot, let it sit somewhere
<wolfspraul>
"24h rendering test" is a good benchmark, a 'full day'
<wolfspraul>
man we could invent so many more tests. temperature cycles for example.
<wolfspraul>
or drop tests (with case assembled of course)
<wolfspraul>
or or or
<wolfspraul>
temperature cycles would be quite interesting actually, I think. but very time consuming so maybe later...
<wolfspraul>
aw: I am not proposing this for rc3, but what do you think about the value of testing real temperature cycles?
<wolfspraul>
like 20 times up to 60 degree, down to 0 or less, back up, etc.
<aw>
no no, i added a newer test on the bottom
<wolfspraul>
I think most OEMs are doing temperature cycle testing, do they?
<aw>
yes, why not! they indeedly do that.
<wolfspraul>
we have never done it, and we don't have programmable cases either to heat and cool in cycles
<wolfspraul>
yes I know :-) but we never did
<wolfspraul>
so I don't even know what interesting or uninteresting results one could find
<wolfspraul>
but since everybody is doing that, there must be something valuable there...
<wolfspraul>
anyway
<wolfspraul>
not in rc3!!!
<wolfspraul>
too time consuming
<aw>
but I can only to use a heat air to rise temperature to 60 degree, then blow cool air down...cycling
<wolfspraul>
and we don't have the equipment either for controlled heating and cooling
<wolfspraul>
no no
<wolfspraul>
:-)
<wolfspraul>
I said: not for rc3
<aw>
yes,
<wolfspraul>
I'm just saying that's one big test area that Sharism Ltd. has never actually done right
<aw>
or go find a labortory to do test after thic rc3.
<aw>
s/thic/this
<wolfspraul>
I think a small case that can do programmed heating/cooling shouldn't be too expensive
<wolfspraul>
someone can build one with a few Arduinos :-)
<wolfspraul>
(I am joking Adam, please don't start working on this...)
<wolfspraul>
we keep that for later when we are Apple sized
<aw>
oah~yeah...i saw Make magzine had have someone did such things before with a small box alike.
<wolfspraul>
there you go
<wolfspraul>
:-)
<aw>
well...time to record and check 0x31
<wolfspraul>
I am wondering what kind of value one can get from temperature cycle testing.
<wolfspraul>
that would be the first thing I would want to understand. need to talk to someone at a large OEM.
<wolfspraul>
you can get a lot of data, OK. but why is the data valuable? What kind of decisions do you make based on that data?
<aw>
sure sure temperature test chamber can verify design
<wolfspraul>
you change certain components?
<wolfspraul>
you can measure/predict the life expectancy of a board, do the temperature cycles imitate aging? etc. etc.
<wpwrak_>
wolfspraul: one thing you'd find are parts with incorrect tolerances, be it by design or by manufacturing
<wolfspraul>
probably you could also throw humidity tests in there...
<aw>
and also capture which part is not on best balanced value, like wpwrak_Â Â did very well on checking C238's value for lower bound or upper bound validation.
<wpwrak_>
wolfspraul: not sure what temperature changes will find. could be just temperature gradients (e.g., no all parts heat/cool at the same speed), could be thermal stress. you'd need a lot of cycles for the latter, though.
<aw>
and with them can know also parts tolerance if took well consideration while designing... ;-)
<wolfspraul>
I just know that all OEMs do temperature cycle testing quite consistently, and we don't.
<aw>
yeah..."thermal stress" to figure/verify design
<wpwrak_>
aw: heh, you did the low/high tests. i merely suggested values :)
<wolfspraul>
but it's very time consuming, that's for sure
<wolfspraul>
and needs a lot of boards
<wolfspraul>
and it will generate a lot of data that then needs to be analyzed, not discarded
<wolfspraul>
we cannot do it now
<wpwrak_>
wolfspraul: i think it would be good to have tests at the ends of the allowed/expected temperature range as soon as possible. see if the board still works on a hot day. see if it still works if you bring it in from the cold.
<aw>
wpwrak_, well we are not close and/or big company, but with your tools or design's parameters all taken into considerations then design goes better. ;-)
<wpwrak_>
wolfspraul: M1 should be subjected to rough use, so such things matter much more than to, say, a desktop PC that sits in a nice 20-30 C all day long
<wolfspraul>
I think it matters for all consumer electronics.
<wpwrak_>
wolfspraul: it does. but more for some than for others :)
<wolfspraul>
but I do not have the resources now to go into that, maybe we can do some very simple tests like you said with 'hot day', but most likely the results will be inconclusive then.
<wolfspraul>
I think the only way to tackle it is to make the cycles reproducible, with a controlled heating to a controlled temperature, several boards (at least) for comparison, etc.
<wolfspraul>
otherwise you will look at noise
<wpwrak_>
wolfspraul: M1 is aimed at people who move around, encounter unknown and non-ideal working conditions, may have time pressure, have very embarrassing failure scenarios, etc.
<wolfspraul>
so they have to buy 2!
<wpwrak_>
that helps if one flat out fails. but what if there's a design problem that breaks it in general < 10 C ?
<wpwrak_>
and you're VJ'ing a christmas party in moscow ? arrived late, because of too many drunk drivers in the streets
<wpwrak_>
and yes, you can't do much more than simple tests for now. still, you should do them :)
<wolfspraul>
there will be no systematic temperature cycle testing for the rc3 run
<wolfspraul>
but I have an eye on it, for sure. first would like to understand the value, i.e. how many good feedback to expect. and the setup and execution needs to be in a controlled way.
<wolfspraul>
not random, then we will only look at noise
<wpwrak_>
for cycle testing, you'd first have to find out what to look for, yes
<wolfspraul>
I do have extensive experience in how _NOT_ to do temperature cycle testing :-)
<wolfspraul>
so I know there is something to discover there, but need to be careful the first time around to really extract value
<wpwrak_>
but you should be able to, say, put a M1 in the fridge and see how it likes that. or take a hair dryer to it
<wpwrak_>
ah, what was the negative experience ?
<wolfspraul>
yes, we can try. but I'm telling you the results may be inconclusive.
<wolfspraul>
because we don't really know the temperature some part of the board were cooled/heated to or not
<wolfspraul>
in the end we will ignore the results, whatever they are
<wolfspraul>
not good
<wolfspraul>
so the fridge/hair dryer idea, don't know. fridge maybe better than hair dryer.
<wpwrak_>
(ignore results) there's that risk :)
<wpwrak_>
fridge is easier and more controlled :)
<wolfspraul>
it has to be reproducible, and you most likely want to subject several boards at once to the same test
<wolfspraul>
this being so time consuming, you easily get lost in noise, or too much data points
<wpwrak_>
for getting a first feeling, i'd say one board would be enough. you'd only want to go into more extensive tests is there are problems
<aw>
btw, last time we had have good repeated MIDI test image to test. so i just used that to see signals, that's good tool. so while signals always sending then I can keep on eye on circuit.
<wolfspraul>
too easy to discover noise
<wolfspraul>
so first we need an approach that we believe masks the noise
<aw>
hope later DMX or other accessory can have such great tool to debug. ;-)
<wolfspraul>
then do the test
<wpwrak_>
e.g., if you say the minimum operating temperature should be 10 C, test it at 0 C. that'll take care of most variations.
<wpwrak_>
(noise) only if your tolerance margins are too small
<wolfspraul>
at our former employer (that's where my only limited experience comes from), temperature cycle testing was a joke
<wpwrak_>
the expected outcome should be 0 problems, with any board that passes QC
<wolfspraul>
people knew they had to do it, but nobody knew what to do with the results :-)
<wolfspraul>
so we need to avoid that
<wolfspraul>
anyway, it won't happen for rc3
<wolfspraul>
if we can sell the rc3 run and go for rc4, maybe we can do some more investments along those lines
<wpwrak_>
well, those phones hardly worked even if you didn't stress them at all ;-)
<wpwrak_>
remember #1024 ? (-:C
<wolfspraul>
it would be cool for sure, also to establish a quality standard, certain standardized cycles
<wolfspraul>
but those cycles must relate to actual user problems, not be some random number
<wolfspraul>
it must correlate with actual life expectancy of the boards...
<wolfspraul>
that's the tricky part, I think testing and collecting results is relatively easy.
<wolfspraul>
so we need someone with experience to tell us which cycles to test in order to verify the design, the life expectancy, how to mimick aging, etc.
<wolfspraul>
just my thinking...
<wolfspraul>
the famous 80/20 rule surely applies to that subject as well
<wpwrak_>
again, cycle testing != probing the operating range. cycle testing is much more advanced. but if you get complaints that M1 crashes in the middle of a show on a hot night or doesn't boot, etc., your VJ customers will not like to hear that you never tested it beyond 28 C
<larsc>
'put device into fridge for 30 minutes before operation'
<wpwrak_>
"operate between 20 and 25 C. maximum humidity 50%."
<wpwrak_>
reminds me of those labels on clothes. something made of cotton, "hand-wash cold. do not dry."
<wpwrak_>
in the old days, those labels told you what the fabric and the color were designed to survive. nowadays, it's what the bloody lawyers think will cover the company's ass.
<wpwrak_>
i find those most interesting that specify a maximum temperature that's well below normal body temperature. "warning: actually wearing will ruin it" ? or maybe it's their line for zombies and other corpses.
<wolfspraul>
aw: can you find a wire with black insulation?
<wolfspraul>
would probably look a little better...
<wolfspraul>
also I'm not sure about the tape, maybe some drops of silicone or so are better along the way? or not?
<aw>
oah~ yeah...you're right. ;-)
<wolfspraul>
but small drops, only to fixate the wire
<aw>
need to buy black insulation one. ;-)
<wolfspraul>
yes
<wolfspraul>
looks better
<wolfspraul>
and how about small drops of silicone instead of tape?
<aw>
yes, that picture haven't used silicon, seems that I'ven't assembled them into case. so not glue them yet. ;-)
<aw>
will do glue after I confirm m1 board fit with case well then. ;-)
<aw>
after 0x31, i assemble them.
<aw>
0x30 now let it rendering to 24 hour test
<wpwrak_>
larsc: on the inside .. like on my body, below a jacket (in winter) ? yeah :) besides, ambient temperature around here can easily exceed 30 C (in summer, occasionally even in winter - global warming is fun :)
<larsc>
wpwrak_: i meant on the iside of your body ;)
<lekernel>
aw, so you had a defective midi optoisolator?
<wolfspraul>
no, I think it was a schmitt-trigger
<wolfspraul>
anyway, 0x30 is in perfect condition now and doing a 24h rendering test
<lekernel>
ok
<lekernel>
and what about the 0.7A board?
<wolfspraul>
he's working on that now (that's 0x31)
<wolfspraul>
also I think he had an idea how to improve the DMX test, I didn't fully understand it but improved test is always good. hopefully xiangfu can help on that one.
<wolfspraul>
xiangfu: did you see adam's comment about the midi & dmx test above?
<wolfspraul>
adam wrote "btw, we need to tell xiangfu that when we test only like MIDI from menu selection, after i press "h", test tool should tell me a "h" selected."
<wolfspraul>
and also "last time we had have good repeated MIDI test image to test. so i just used that to see signals, that's good tool. so while signals always sending  then I can keep on eye on circuit.
<wolfspraul>
"
<wolfspraul>
so maybe the midi and dmx tests can continue to go in circles, until a button is pressed? then we could just have one test image and it can be used to look at signals as well, if needed.
<xiangfu>
ok. I will look into ti
<xiangfu>
it
<wolfspraul>
basically you run the test, if it fails you print FAIL and finish. if it succeeds, you print "PASSED (retrying until button press)" and continue to run the test again
<wolfspraul>
that way the same test image can be used to measure signals if needed, and if not needed it's just one more button press
<wolfspraul>
I don't understand what Adam meant with the "press 'h'" comment, maybe it's clear to you?
<wolfspraul>
that retrying thing should be done for midi & dmx for now
<xiangfu>
not sure. I can talk with Adam
<wolfspraul>
ok, but the retrying until button press is clear?
<wolfspraul>
only print it once, so it doesn't clutter the log, but keep retrying indefinitely until button press
<wolfspraul>
sorry I mean 'key press' (on the keyboard)
<xiangfu>
I will working on those 1 hours later. a little bit tied
<wolfspraul>
sure, it's not urgent I think. just an idea for improvement.
<wolfspraul>
oh I think I understand Adam's comment with the 'h selected' now. Maybe he means that when he presses 'h', there is no record of that in the log (=on screen). So it just needs to add a printf to document that 'h' was in fact pressed. That's my understanding.
<aw>
wolfspraul, yes, so that i know what item I selected. ;-)
<aw>
print that item again like "h ->" or somethings
<aw>
1. foreign matter on fpga's top body, that one I not sure if it's like burned inside when high currents was happened on my first time power on.
<GitHub168>
[extras-m1/master] added shadow to text 'Live' - Yi Zhang
<aw>
2. now try to use Eliminates the law thus I'd like to disconnect L7 to cut off 3V3 (which is the most power sources in m1 ), if now high current occurs, might be some where short about 3.3V circuits (including fpga's supplies)
<aw>
3. if no high current occurs, then narrow potential failure area though. ;-)
<aw>
for 1) if this to be true, cant see bga solderabilities condition under fpga unless a X-ray took. ;-)
<wolfspraul>
aw: you think that 'foreign matter' comes from inside the fpga?
<aw>
not sure now, i just took picture
<wolfspraul>
doesn't look like it. let's see what the L7 test shows...
<aw>
No
<aw>
just spot somethings now. ;-)
<wpwrak_>
(foreign matter) could be a scratch
<wolfspraul>
aw: I don't remember we had this type of problem in rc2, let's hope it's not something bigger in the whole rc3 run...
<wolfspraul>
but one by one, now they are all soldered already anyway
<wolfspraul>
two boards were good
<aw>
just measured C98 (3V3)Â Â to ground resistance (when unpowered) then is 30 ohm, which is not correct to 0x30( 1M ohm )
<aw>
surely I disconnected L7, and now I can very surely impendance 3V3 to ground (unpowered )is very BAD. :(
<aw>
now keep using  Eliminates the law. if someone has new idea, let me know. ;-)
<wpwrak_>
30 ohm would be just 100 mA :)
<wpwrak_>
is this a two-wire or four-wire measurement ?
<aw>
yeah...so any steps on power on again needed to be solid judgement first
<aw>
two-wire
<wpwrak_>
one test would be to just power the board and probe for the component that gets hot. of course, if you're not sure that the board is already nearly dead, that's no a nice test
<wpwrak_>
a thermal imager would help. wish they were affordable ...
<wpwrak_>
(2 wire) okay, so it's anything between 0-30 Ohm :)
<aw>
but 0x30 has at least 1 M ohm . ;-)
<aw>
so I don't want to power L7 again... could be immediately damage some where . ;-)
<aw>
unpowered , i can just measure quickly somewhere. ;-)
<wpwrak_>
1 M is nice. but i wonder how reliable that is. but yes, the difference 1 M vs. 30 Ohm (or whatever) is striking
<aw>
yeah...1M vs. 30 ohm already..damn
<lekernel_>
what happens when you power that board with L7 removed? no more overcurrent I'd guess?
<lekernel_>
this just looks like some short circuit or bad chip ...
<aw>
i guess too. but before power on again....i am looking more..hope spot some else
<lekernel_>
if all else fails, you can use the brutal technique: apply power without current limitation, and see where the smoke comes off
<aw>
ha~see directly some chip burned. ;-) also a good idea though. ;-)
<lekernel_>
there's a risk to burn PCB traces, though
<aw>
no... ;-) I don't like smoke air though. ;-)
<lekernel_>
so i'd keep this technique as 'last resort' ;)
<aw>
ha
<wolfspraul>
normally would be x-ray now, if we cannot compartmentalize more with L7 on
<lekernel_>
or you can use an intermediate - use current limitation and power on the 3.3V rail directly... it must get hot somewhere
<wpwrak_>
do all chips have the right orientation ? :)
<wolfspraul>
too late for xray today, hmm. can't we remove some other parts of the circuit after l7?
<wolfspraul>
the 'check where it gets hot or burns' technique is a little unusual I'd say :-)
<wolfspraul>
also, Adam may get more boards soon. it's a huge difference whether this is an isolated case on 2-3 boards across the run, or affects 50% of the run (for example)
<wolfspraul>
so if he looks at the next 5 boards and they are all ok, he would normally postpone looking at 0x31 now
<wolfspraul>
but if we get another 1-2 like that in the next 5 -> big problem :-)
<wolfspraul>
so... aw - when do you get more boards? does minbo have xray? can we remove some other parts after l7?
<wolfspraul>
those are my ideas
<wpwrak_>
(check where it's hot - unusual) naw, that's actually about the first one you learn ;-)
<wolfspraul>
no factory works like that
<wolfspraul>
xray
<wpwrak_>
no, hopefully not the factory ;-))
<aw>
from now on, every board before I tested. I'd like to quickly measure (unpowered) impedances on TP1 ~4
<wolfspraul>
good idea
<wolfspraul>
how to continue on 0x31 now?
<aw>
0x31 , even I get good condition without L7, this cant help me restore 0x31 now.
<aw>
so let's not do any more on this 0x31 now
<lekernel_>
no, but you know there are no further problems on the power supply
<aw>
when after finish all batches rc3, then back to see this board...
<wolfspraul>
well, that's assuming it's an isolated case
<wolfspraul>
a bit risky after seeing 3 boards
<aw>
lekernel_, sure , i agreed. but I have other things to do not just this board . ;-)
<wolfspraul>
aw: when do you get more boards?
<wpwrak_>
wolfspraul: do you suspect it's a through-hole problem ? if not, knowing now or later wouldn't make much of a difference
<aw>
they said to me yesterday at fast on this Friday. at last on Saturday.
<aw>
wpwrak_, hup?
<wolfspraul>
no idea, can be lots of things
<wolfspraul>
it's just an economic problem, not technical. is this 1 board of 80, or 40 of 80? we don't know
<wolfspraul>
that's the #1 thing to know now
<wpwrak_>
actually, can a board without through-hole do anything useful ? (such as blink some leds)
<wolfspraul>
if it's 1 of 80, we may never investigate further
<wolfspraul>
ever
<wolfspraul>
:-)
<aw>
okay...i can still quickly to know if other circuit caused that, when disconnected L7, not big deal. ;-)
<wolfspraul>
we use the board as a spare part lab supply
<wpwrak_>
aw: if it was a through-hole problem, then identifying the problem may provide useful feedback for the fab (because they haven't done through-hole yet). if it's something else, the damage is already done.
<wolfspraul>
too late for feedback
<lekernel_>
there's almost nothing through-hole on those boards
<lekernel_>
it's merely the connectors
<aw>
actually i'd like to jump to assemble case with m1 to settle how/where i must to glue.
<wolfspraul>
that's what the test of the first board provides
<aw>
though hole problems?
<wpwrak_>
lekernel_: so would it make sense to do a power-up test (with current measurement) on boards after SMT, before TH ? (during production)
<lekernel_>
no
<wolfspraul>
nah come on, it's a short somewhere. this is normal. biggest problem is that adam cannot quickly look at some more boards, then we wouldn't even discuss this.
<aw>
well...rc1 & rc2 went through a real through hole reflow process before. will it suddently happened strange thing on rc3?
<wolfspraul>
so we don't know how rare/common the 0x31 problem is across the run
<wolfspraul>
it's a bit unsettling to me, with us only seeing 3 :-)
<wolfspraul>
but well
<wolfspraul>
no risk no fun
<aw>
i bed something if need to damage this board. probably my soldering skill will be the number one to kill it. ;-)
<lekernel_>
btw, does the AOI work this time?
<lekernel_>
I remember seeing an horror picture with capacitors on run2 that the AOI didn't spot
<aw>
the remaining boards I didn't bring back. I still request them to do AOI. since this time they said the qty is enough to collect hard data to train machine.
<wpwrak_>
(aoi) cool !
<aw>
i could only say these firstly three boards haven't been scanned by AOI and soldered through hole parts by myself. :(
<wolfspraul>
lekernel_: AOI is also a matter of how much time is invested to make it find things
<wolfspraul>
you can always let boards run through the AOI machine, but how useful that actually is is another matter
<aw>
now, without L7: 0.38A only as we guessed, not big deal...since I compared to 0x2f on TP1~Tp4. ;-)
<wolfspraul>
aw: which parts are powered by L7 ?
<wolfspraul>
or behind L7
<aw>
for other 3V3 circuits, it will spend more times to eliminate. ;-)
<aw>
phel....fpga, ethernet,flash, usb transciver, vga encoder, ...
<lekernel_>
do all chips have the right orientation?
<wolfspraul>
ok
<wolfspraul>
maybe put this board aside and see what the next 3-5 look like
<wolfspraul>
or xray
<wolfspraul>
probably faster and better than soldering around
<aw>
yes,
<wolfspraul>
aw: does minbo have an xray machine?
<aw>
you can imagine those boards are pass through smt machine..so they should be all on the same directions excepts the fisrt panel they starts to mount. ;-)
<aw>
wolfspraul, no
<aw>
last time the jtag rc2 that smt vendor also don't have xray machine.
<aw>
so I'd like ti investigate this 0x31 after we finish all batch...then if more boards like this, I bring them to do x-ray scan.
<aw>
s/ti/to
<wolfspraul>
yes, sounds good
<wolfspraul>
you are right, even if we want to do xray, we pool together with other boards first, that's much more economical
<aw>
i think i now to try assemble a case with 0x2F. ;-)
<wolfspraul>
yes
<lekernel_>
wow there are so many M1 production and other pictures on the qi hardware wiki
<lekernel_>
we should print big panels and posters with all of them ;)
<wpwrak_>
pin them on the chinese wall ;-)
<aw_>
the original version of case's 3 buttons  is composed of three parts, and not easy to stick together, so currently button is going to be composed of chemistry process?
<aw_>
last time I assembled case skipped those three buttons. ;-)
<aw_>
now need to feel how those buttons assembled together though.
<wolfspraul>
aw_: the buttons are made of three parts, but you will get them assembled
<wolfspraul>
if you only have unassembled buttons right now, you can try with some glue to get them together :-)
<wolfspraul>
there are three parts, from inside to outside like this: 1) a little bigger thin part 2) smaller thin part 3) smaller thick part, same color as case
<wolfspraul>
you can try any glue you have, but it's really terrible to put them together and make them fit through the hole, let alone keep it all clean
<wolfspraul>
first you have to peel off the white film from the 3 pieces
<aw_>
can i use Instantaneous rubber to glue those three parts together?
<wolfspraul>
then you need to glue 2 times, between 1/2 and 2/3
<aw_>
yes, peel off already
<wolfspraul>
you can try any glue
<wolfspraul>
it will be a mess anyway ;-)
<wolfspraul>
just try to get them together in _any way_ that works, no hesitation. it's very hard to do it well.
<wolfspraul>
you may also need to remove some glue leftover with a knife, because the tolerances of getting the button through the hole are small, and the button can easily get stuck
<wolfspraul>
just experiment, and no worries
<aw_>
yes,, i notice that condition.
<lekernel>
cyanoacrylate glue applied in small quantity at the right spot isn't that much of a mess
<lekernel>
but if you do it wrong, it does become quite a mess indeed
<lekernel>
e.g. if you put too much glue, some of it leaks from the sides and blocks or glues other things
<aw_>
umm..good that at least have 1.5mm space between front case and board, so no problems on shape up an ellipse on a 30awg wire.
<wolfspraul>
correct
<wolfspraul>
the wire will be safe
<aw_>
yes..i put a little & thin then slippery few glue on inner of circumference. ;-)
<aw_>
now just wait few times to let them stuck well.
<aw_>
btw, tomorrow I need bring two case to find someone help me drill two holes: one is microphone , the other is the upper case for usb cable. ;-)
<wolfspraul>
hmm
<wolfspraul>
why do you need a mic hole?
<wolfspraul>
for the jtag cable, if you do holes, I suggest you make a hole into the backpanel, near the power plug
<wolfspraul>
and use a regular usb cable
<wolfspraul>
the upward pointing usb cable is meant to be used with the top acrylic completely removed. of course you can also make a hole into that one if you like :-)
<aw_>
since need to drill a jtab usb hole, so accompany a mic hole. ;-)
<aw_>
lekernel, yes, i used 3M cyanoacrylate glue. :-)
<lekernel>
(I have not checked what is new... diff it if you want)
<wolfspraul>
oh nice, I didn't think lm32 was even actively maintained anymore
<wolfspraul>
I should contact them and try to sell them an m1 :-)
<lekernel>
I don't know if they changed anything
<lekernel>
in the March version, there was nothing new in the processor core itself
<wolfspraul>
sure, but I'm serious. Once I have units I will fire an email in their direction, to marketing or so, telling them to buy it to see a good use of their core.
<lekernel>
also, it seems they have used the open source license for LM8 as well
<wolfspraul>
yes, that's another reason to contact them
<kristianpaul>
LM8 have GCC support as well?
<kristianpaul>
i never undertood that..
<wolfspraul>
once I have established contact with someone, I can bringup the issue of the unfortunate licensing/legal maze, see whether they want to improve it
<wolfspraul>
but I need a product so I have something to talk to them about
<mwalle>
kristianpaul: iirc there was a press announcement about gcc support for the lm8
<mwalle>
lekernel: where do you have the information about the lm8 license from?
<wolfspraul>
they emailed him I think :-)
<wolfspraul>
Lattice's way to execute and communicate licensing decisions is messed up
<wolfspraul>
just look at the lm32, same thing. first you have to register to download a free as in beer software, then generate source files from it, then some of those source files fall under an open source clause in a difficult to read license
<wolfspraul>
and the headers of those source files are even unfortunately written with "confidential and proprietary" standing right next to the reference that will eventually explain that it is actually open source
<wolfspraul>
argh
<wolfspraul>
I wish they cut put one source tarball for download, without registration, and the licensing headers and information in that tarball would be crystal clear
<wolfspraul>
but I doubt it will happen, at least not soon
<wolfspraul>
maybe someone will read all the fine print in the new arrangement, but it definitely looks better than before
<mwalle>
+// Version 3.8
<mwalle>
+// 1. Feature: Support for dynamically switching EBA to DEBA via a GPIO.
<mwalle>
+// 2. Bug: EA now reports instruction that caused the data abort, rather than
<mwalle>
+//Â Â Â Â next instruction.
<mwalle>
+//
<mwalle>
for lm32_cpu
<wpwrak_>
wolfspraul: so that's on the files that had a nasty copyright notice before ?
<kristianpaul>
yeah, better than beffor indeed
<wpwrak_>
kewl. so maybe the rants were useful :-)
<kristianpaul>
also, the link sebastien posted, saids [R] wich is not true, cause as soon you click on it download start, no registration required
<kristianpaul>
s/saids/point a
<kristianpaul>
"LatticeMico System 1.3 on Linux" right?
<wolfspraul>
kristianpaul: I think you may have registered in the past.
<kristianpaul>
yes,
<wolfspraul>
wpwrak_: I don't know exactly which files it applies to etc and won't dig in there now. I want for another guy like that crazy dude, then I do it ;-)
<wolfspraul>
the actual intention and meaning was and is clear since 2006, for anybody who acts in good faith
<kristianpaul>
(good faith) yeah :)
<wpwrak_>
wolfspraul: yeah, but it's good to have it in writing
<mwalle>
wpwrak_: yes all files, i'll post a patch to the ML later
<wolfspraul>
sometimes it's really enough. it's as if we ask people to pray 5 times daily in front of the temple of rms, just to be sure they are really serious.
<wolfspraul>
I'm more interested to find someone at Lattice for a marketing cooperation. That's be harder though since they have this idea that the open core helps them promote their proprietary peripherals :-)
<wolfspraul>
the Milkymist strategy doesn't quite fit into that plan...
<wpwrak_>
wolfspraul: (enough) the problem is that you're putting yourself in the position of (supposedly) authoritatively interpreting and representing their license. this is simply not a place you should be, for all sorts of reasons.
<wpwrak_>
(marketing) well, once you get their attention, word may spread :)
<kristianpaul>
what's that er1?
<kristianpaul>
ah, nv jtag related..
<kristianpaul>
ok, there is lm8-elf-gcc now where is the source...