<wpwrak>
kristianpaul: i think parametric is the way to go. (stable version) hopefully soon. well, over the last week, i already thought three times i had the final version ... one even progressed to the point of having boards cut, etched, and via-ed. and then i realized it still had some features i'd rather not have there :-(
<kristianpaul>
wpwrak: development hell trap? :p
<kristianpaul>
argg i give up, no more tries of printing the buttons..
<kristianpaul>
i'll make work what i alredy printed
<wpwrak>
kristianpaul: well, #1 was me realizing that i could make quite a dramatic improvement to the layout. #2 was me realizing that some things in the layout where too tight (also discovering some new traps in how kicad handles zones). #3 was me overlooking one flaw. now, i allowed me one extra day to review #4. let's hope this was time well spent, and that it works now ;-)
<kristianpaul>
phew, finally it fits and i be pressed
<wolfspraul>
bartbes: hi
<bartbes>
woah
<bartbes>
delayed response
<wolfspraul>
kristianpaul: this is absolutely awesome!!!
<wolfspraul>
can you do a blog post, or mail, or even just a few lines here describing the steps it took you to make the case?
<wolfspraul>
like how did you find your local acrylic supplier, how did you find the laser shop?
<kristianpaul>
sure sure
<wolfspraul>
how long did it take you, what did it cost, which difficulties did you run into (tolerances, etc)
<wolfspraul>
how about screws and spacers, other small parts?
<kristianpaul>
good point
<kristianpaul>
I had printed my own buttons, is not the _perfect_ thing but it works
<kristianpaul>
(find your local acrylic supplier, how did you find the laser shop) is same shop
<kristianpaul>
I just send case, pay, choose color and thats it
<wolfspraul>
can you upload some of those pics (or maybe just all) to the wiki? it should be a news item in our community news
<kristianpaul>
sure
<kristianpaul>
difficulties so far, are missing small parts, mostly the spacers that came with the mm1 are not compaible with the case, so i have a slight un-aligned
<kristianpaul>
I do not have plans of buy screws
<kristianpaul>
I already made my own hole for let jtag-serial cable to go inside case (i used it most of the time)
<kristianpaul>
I'll blog later, an upload pics to wiki, righ now i'm wiring sige board to mm1, and i need to see how handle the ribbon cable there..
<kristianpaul>
cost: 10usd material and cut process + 5 usd shipping to my home
<wpwrak>
kristianpaul: soon you'll need another case - a presentable one, without all the extra holes ;-)
<kristianpaul>
wpwrak: hmm, may be, also i can try green color ;-)
<wpwrak>
the "smoke" looks very nice
<kristianpaul>
wolfspraul: i just send cad file as it is on repo plus a pic from a already made case then i got the quote
<kristianpaul>
I got the link to this company as a guy have a reprap machine told me about then
<kristianpaul>
I think tolerances in general will be good with the right small parts..
<kristianpaul>
buttons are really tricky
<kristianpaul>
wpwrak: smoke is nice indeed,  i'm planning also put may be some smalls blue leds in two sides to get a nice effect, (for future events)
<kristianpaul>
wolfspraul: thats  it !
<kristianpaul>
at least now mm1 is easy to handle :-)
<wolfspraul>
kristianpaul: ok, maybe write a little 'how I made my own m1 case' story somewhere
<wolfspraul>
and you know how it is, it's either done fast or never. now you still remember the details :-) If you don't get to it, I understand. So many things. But it would be a great story I think.
<kristianpaul>
wolfspraul:Â Â (story) sure
<wolfspraul>
rejon: did you see this? kristianpaul made his own m1 case, totally independently in Colombia!
<wolfspraul>
they need to disable anonymous edits asap
<kristianpaul>
or add catcha..
<wolfspraul>
first disable anonymous edits, immediately
<wolfspraul>
the spam bots are ripping their beautiful wiki apart right now
<wolfspraul>
from the last 500 edits it looks like 50% or more are spam
<wpwrak>
still better than mail :)
<kristianpaul>
hmm, 10Mhz, 3V3, 15pf load per pin, i should not extend this so much..
<kristianpaul>
wolfspraul: What you think about ARM clones? i mean use it on real products
<wolfspraul>
don't understand your question
<kristianpaul>
I mean arm is getting popular, soon or later it may get implemented on fpga and described with some HDL language and use it somwhere
<kristianpaul>
Non couting the already linux adn gcc  support it make interest for developers
<wolfspraul>
you need to ask Sebastien, I would think ARM will vigorously protect their IP
<kristianpaul>
oh sure
<kristianpaul>
but clones will appear one next to other
<wolfspraul>
so if you just ask me, I can see arm cores inside ASICs, and they can be great for us
<wolfspraul>
when it comes to an integrated IC design, I believe in the Milkymist/LM32 path, which we can only implement in fpgas right now
<wolfspraul>
what do you mean with 'clones will appear'?
<kristianpaul>
implentarios of arm-like cores compatible with gcc/linux
<wpwrak>
wolfspraul: how about the pre-FPGA nanonote line ? would a ya with, say, a Marvell PXA be something you'd consider ?
<wolfspraul>
I don't see that at all right now for myself, so the question is very hypothetical.
<kristianpaul>
sure ;-)
<wolfspraul>
putting that aside, what's the difference between a Marvell PXA and an Ingenic chip? None I think.
<wolfspraul>
just comes down to features
<wolfspraul>
but given all the things we did to bring the NanoNote alive, I would try to protect our software investments above everything else first.
<wolfspraul>
same with Milkymist, as we improve the tools around it
<wpwrak>
wolfspraul: yeah, i mean if the feature set would be more attractive
<wolfspraul>
bottom line: someone else needs to make that Marvell NanoNote :-)
<wolfspraul>
yes, and if the NanoNote would not have been started, then yes, sure
<wolfspraul>
the Marvell chip may be more expensive and harder to source
<wolfspraul>
and Marvell would be far less flexible than Ingenic
<wpwrak>
using the same core has of course the advantage of a more-or-less binary-compatible user space
<wolfspraul>
no hopes of ever installing a server behind the Marvell firewall that will do a nightly rsync to shuffle some sources out :-)
<wpwrak>
;-)))
<wolfspraul>
I like working with Ingenic, even if it's dormant RIGHT NOW.
<wolfspraul>
a large Ingenic customer contacted us recently because they saw what we did on the NanoNote.
<wolfspraul>
I don't expect any big business opportunity there, but that's how things grow if you do solid work in some place, rather than jumping around and building random boards with random chips, and nothing ever works well.
<wolfspraul>
kristianpaul: my main worry about ARM 'clones' would be patents, and the way ARM will defend their IP.
<kristianpaul>
wolfspraul: indeed
<wolfspraul>
you need to ask Sebastien about this, I trust and follow his judgment. Milkymist is just starting...
<kristianpaul>
sure
<wpwrak>
wolfspraul: (jumping around) yeah, agreed. continuity is good.
<kristianpaul>
hey andres-calderon
<wolfspraul>
but I am not 'against' ARM cores, that would be so stupid I think. we are trying to build great copyleft hw, fast, that really works, and has great features/specs.
<wpwrak>
wolfspraul: just wanted to know your general opinion with respect to ARM, apart from OMAP overengineering
<wolfspraul>
sure but there can be several 'back stories' to this
<wolfspraul>
1) they exist because they operate and sell in places where ARM does not have judicial reach
<wolfspraul>
2) they exist because they are small, and ARM is better off letting them grow first, then apply their tax
<wolfspraul>
3) they exist because ARM is actually not vigorously patenting and defending their IP, maybe (theoretically) because they even support such clones?
<wolfspraul>
4) they exist because they already have a licensing agreement with ARM
<wolfspraul>
those are the 4 options that come to my mind right now
<larsc>
i meant opensource designs
<wolfspraul>
you mean a gpl licensed hdl source code?
<larsc>
yes
<wolfspraul>
if an implementation infringes ARM patents, that changes nothing
<wolfspraul>
5) they exist because it is an open source software design that no company would ever dare to manufacture or sell because of ARM patent infringement
<wolfspraul>
I added that one :-)
<kristianpaul>
wolfspraul: You care about US export laws about lattice mico32?
<larsc>
i'm not arguing about that. just wanted to point out that there _are_ ARM compatible designs, because kristianpaul said there _will_ be.
<kristianpaul>
larsc: yep
<wpwrak>
up to ARM6 may be free from patents or close to it (~1-2 years), as far as the 20 years limit applies
<wolfspraul>
that concept never worked for MIPS
<wpwrak>
yeah, but who knows why ...
<wolfspraul>
kristianpaul: I care, but that's an entirely different subject and typically outside of scope for free projects. There are a lot of embargoes...
<wpwrak>
maybe MIPS paid them to stop claiming it was free from patents ;-)
<wolfspraul>
wpwrak: oh I know why. because MIPS is doing very aggressive lobbying and very aggressive legal actions.
<wolfspraul>
I spoke in person with the people running it on both sides.
<wpwrak>
wolfspraul: ah, so it's the sue-to-lose-but-kill-the-enemy-anyway approach
<wolfspraul>
if you think you can make a MIPS-clone under the 'patents are expired' idea, you can go try, and MIPS Inc. will be your enemy
<wolfspraul>
the Chinese government tried, and failed!
<wolfspraul>
if that is not enough proof for you, MIPS will gladly take on Werner Inc. next
<Fusin>
wb /me ;)
<wpwrak>
wolfspraul: lemme first rig some laws my way :)
<wolfspraul>
ARM is in the UK, they could use less leverage via their government. But not that much less, UK is still someone...
<Fusin>
my ben still doesn't boot :(
<wolfspraul>
I think it's simple. If you believe in ARM clones, get a written statement from ARM Inc. that your theory is OK and they acknowledge that what you do is legal.
<wolfspraul>
once you have that, we can move
<kristianpaul>
Fusin: you we're flashing it? or tryin boot?
<Fusin>
I reflashed
<Fusin>
but still doesnt boot
<kristianpaul>
ormris: Did you get usbboot to work finally?
<wolfspraul>
you ran reflash_ben.sh ?
<Fusin>
yep
<kristianpaul>
Fusin: what it said on screen?
<Fusin>
screen is black
<wolfspraul>
after reflashing, unplug the USB cable, take out the battery, wait 20 seconds
<kristianpaul>
lsusb show something?
<wolfspraul>
Fusin: then battery back in, then press power-on button for a solid 5 seconds
<Fusin>
Bus 001 Device 009: ID 0525:a4a1 Netchip Technology, Inc. Linux-USB Ethernet Gadget
<wolfspraul>
let's try that first. maybe the reflash was successful and you just didnt' reset/reboot yet.
<Fusin>
ok i try power off
<larsc>
that looks as if the kernel is actually booted
<kristianpaul>
may it be lcm bus unpluged?
<kristianpaul>
Fusin: it just happen? it was working well before?
<wolfspraul>
that would be bad, but not very likely that it happens in conjunction with a reflash
<Fusin>
no did not work before
<kristianpaul>
hmm..
<Fusin>
i wait 20 secs ;)
<wolfspraul>
Fusin: when did you get your Nano? did you ever see it boot/turn on the screen?
<Fusin>
never saw it running
<Fusin>
new buy, got it yesterday
<Fusin>
connected to laptop for charging
<Fusin>
waited until led light goes off
<larsc>
looks like your nanonote screen is broken/not connected
<Fusin>
then tried boot
<wolfspraul>
too bad, could be that your LCM cable/connection is bad and you need to return/replace the device
<wolfspraul>
you did Ctrl-Alt-F2? and then <enter>?
<kristianpaul>
fusin@?
<wolfspraul>
just try again with Ctrl-Alt-F3 :-)
<kristianpaul>
root@..
<Fusin>
oops
<wolfspraul>
ah good point!
<Fusin>
fusin is my username on mint..
<Fusin>
redo as root
<kristianpaul>
is not on ben :-)
<Fusin>
root@192.168.254.101's password:    BusyBox v1.15.3 (2010-12-14 14:36:17 CET) built-in shell (ash) Enter 'help' for a list of built-in commands.  root@BenNanoNote:~# i'm in :D
<Fusin>
I'm in the ben
<kristianpaul>
wolfspraul: do you have a extra set of "small parts" s for a mm1 perhaps?
<Fusin>
but screen is still black
<Fusin>
so i guess ribbon is faulty, eh?
<kristianpaul>
just in case.. gmenu2x
<kristianpaul>
Fusin: ribbon may be, but that part need to be checked visually
<kristianpaul>
at lest linux can diagnostice that  part, larsc ?
<Fusin>
top said gmenu is running
<kristianpaul>
ah ok :-)
<wolfspraul>
Fusin: yes, I am really sorry but you need to return/replace the device, that's the easiest way.
<wolfspraul>
we've had 5-10 cases like this so far, in about 1100 nanos.
<kristianpaul>
wolfspraul: all fo the just disconnected lcm bus?
<kristianpaul>
s/fo/of
<Fusin>
that's bad for me :(
<Fusin>
return nano and wait new one takes time...
<larsc>
Fusin: where are you from?
<wolfspraul>
where did you buy it?
<Fusin>
I usualy work approx 200 - 500km from home
<Fusin>
so it take weeks before I'm back home...
<Fusin>
<- Nürnberg Germany
<wolfspraul>
where did you buy it? maybe the replacement can be sent there?
<Fusin>
oh, i will
<Fusin>
it's from Pulster
<Fusin>
also sold me my Freerunner ;)
<wolfspraul>
he. welcome to the NanoNote club then, even though you are having a hard first time...
<Fusin>
reminds me my first Linux :D
<wolfspraul>
kristianpaul: there seems to be a variety of causes 'around' the LCM cable
<Fusin>
Softlanding System 0.99pl6 :D
<wolfspraul>
the connector on the mainboard side, the connector on the LCM board side, the cable itself
<Fusin>
tooks days to install on an 386 :D
<Fusin>
took also one week to get X11 working in greyscale
<kristianpaul>
wolfspraul: oh, really?.. getting fun with hardware then :-)
<Fusin>
but i survived :P
<wolfspraul>
Fusin: one sec let's try another thing, just for fun (you can still replace)
<Fusin>
listens
<wolfspraul>
the LCM cable goes through the hinge on the right side
<wolfspraul>
where the 'mic' hole is
<wolfspraul>
press your thumb on that area (keep the Ben running), see whether the LCM comes on
<wolfspraul>
you can try the same on the other side (the LCM), roughly where 'qi-hardware' is printed
<Fusin>
hmm, how do I quit gmu?? *g*
<Fusin>
with key commands?
<kristianpaul>
alt + enter
<wolfspraul>
or just kill it in ssh :-)
<Fusin>
thx
<wolfspraul>
Fusin: when you press on those places, does the LCM turn on?
<Fusin>
nada :(
<Fusin>
means : no
<wolfspraul>
you can press quite hard, just not so much as to break the plastic
<wolfspraul>
ok, was a long shot anyway
<wolfspraul>
I think there were 1-2 people who said pressing there helped
<wolfspraul>
(of course the devices were exchanged still)
<kristianpaul>
or try open screeen to max then close again.. and see
<Fusin>
ok, thx for help
<Fusin>
i goto bed now, it's 4 o'clock in the morning :)
<wolfspraul>
sorry again for the LCM problem
<wolfspraul>
keep us posted how your exchange is going
<Fusin>
ok
<Fusin>
n8 guys
<kristianpaul>
nite
<kristianpaul>
wolfspraul: You do stress test on nanonote lcm before leave?
<kristianpaul>
I mean let said, 50 open and close, or vibration tests..
<kristianpaul>
hehe, just dreaming :-)
<wpwrak>
kristianpaul: i guess soon he will :)
<wpwrak>
wolfspraul: i think if the connection is really hosed, the LCM will miss the initialization sequence, so pushing later wouldn't do much
<kristianpaul>
I remenber when my laptop failed, lemote said we tested the power suply 50 times to make sure it will came back OK
<wolfspraul>
kristianpaul: not every device is stress-tested, and I'm not sure that would help.
<wpwrak>
wolfspraul: i have one problem LCM, too (developed after a while - didn't examine it yet), and there the contact was intermittent. so the LCM came up, but then the contact failed. in this case, it could be brought back with pressure once.
<wolfspraul>
the LCM connection is definitely the weakest spot in the hw design
<kristianpaul>
agree
<wpwrak>
yup. very fragile.
<kristianpaul>
well i damaged my self lcm connector too
<kristianpaul>
is kinday weak... i think, i dint aplied too much force i remenber
<wpwrak>
i suspect the cable can just develop hairline cracks anywhere. i don't think the receptacle is nearly as likely to fail.
<wpwrak>
flexible cables are just one of these troubled technologies. i'm sure wolfgang has vivid memories of that from his openmoko days, too :)
<kristianpaul>
but freerunner dint have mobile parts..
<wpwrak>
the cable between mainboard and (fixed) lcm worked quite well. i never heard of problems there.
<wpwrak>
but then it also had the debug board. that connected with a long FPC to the main unit. endless fun has been had with this one ...
<wpwrak>
a particularly nice moment was when we took an OEM project under our wings. that one was loosely based on the freerunner technology. they had a horrible contraption for their debug board, though. so we suggested to replace this with the openmoko debug board.
<wpwrak>
so we made the design changes. then, the plan was to ship something like ten or twenty debug boards with cables to our customer (in the US). so i got the items and did a quick test to make sure everything was alright ... much later that night, after beginning to seriously doubt my sanity, i knew that about 10% of the whole batch really worked.
<wpwrak>
the rest had all sorts of issues. also, many worked sometimes and then not. turned out that our previous FPC supplier had vanished and we had to order cables from a new source. that new source had not made them with the necessary accuracy. so basically the whole production run had to go back (well, or into the trash. don't know where they ended up.)
<kristianpaul>
:-/
<wpwrak>
one of the issues was that many cables were not wide enough. so you could shift them a little. if you *just* hit the right spot, they would work. if not, some pins wouldn't connect. so you may get serial but no jtag. during one of those nights, i figured out the failure pattern and learned how to position the critters.
<wpwrak>
basically, insert it, then gently move to the left until you hit the border. then to the right, until you hit that border. then move back half the distance (a few dozen micron). then lock the thing and test. if it doesn't pass, repeat.
<wpwrak>
the next day, we verified the scratch marks on the contacts with a microscope. and yes, they were all over the place.
<wpwrak>
another batch of these cables was too wide. so you could 1) try to force them in anyway, or 2) try to cut them down to the right size. 1) would sometimes work, sometimes not. 2) was a game of chance.
<wpwrak>
and then these cables developed hairline fissures quite easily. so when you bent it one way, it may give contact. bend it the other way, and it's gone. and again, this usually just affected one signal out of more than a dozen. so you never quite knew if a cable didn't have some defect that you just hadn't looked for yet.
<wpwrak>
oh yes, i learned to love those FPCs ;-)
<wpwrak>
eventually, i was sufficiently fed up with that mess that i made idbg. that solved the problem for good - at least for me :)
<kristianpaul>
fdti was not so popular in that time?
<wpwrak>
ftdi is ancient :) we had an ftdi on the debug board. i picked the silabs chip for idbg because it's more flexible and needs less space than the ftdi chips (they didn't have a crystal-less solution back then)
<wpwrak>
ftdi documentation also sucks. lots of secrecy that's just plain annoying.
<wolfspraul>
ftdi is surprisingly unpopular among people who really tried to use it, and push to the limits
<wpwrak>
and what's documented still leaves lots of things unclear
<wpwrak>
i'm not surprised at all ;-)
<wolfspraul>
their brand is strong though, so I guess it gets selected by 'managerial decision' into many places still, whether the engineers are complaining or not
<wpwrak>
of course, i'm one of them. if "try anything but dumb serial" already counts as "push to the limits"Â Â :)
<kristianpaul>
so what you recomend instead of fdti?
<wpwrak>
a microcontroller
<kristianpaul>
:-)
<wolfspraul>
well but you are demanding on the details, you demand clear documentation, etc.
<wpwrak>
wolfspraul: is it demanding when you want to know which bits in their EEPROM you have to set to enable bit-banging on the "C" bus ? the manual just tells you that this needs to be configured, but doesn't tell you how.
<wolfspraul>
the ft2232hq on the m1 jtag-serial board seems to fulfill its purpose well though
<wpwrak>
wolfspraul: also, due to the poor documentation, there are all sorts of bugs in the drivers
<wolfspraul>
maybe the problem is just that people try to use the ftdi chip it all sorts of diverse environments, and then it fails
<wpwrak>
naw, the issue is that they somehow feel they shouldn't tell you what you need to know. this is very different from the usual incompleteness you find in documentation.
<wpwrak>
there are also obscure bugs that manuals don't warn you about. like data being lost apparently at the byte level.
<kristianpaul>
stick on his trusty or well know microchip for me pic18
<wpwrak>
the ft2232 has a special engine for things like jtag. the simpler chips don't have that engine. but their documentation claims capabilities that would make it perfectly feasible to accomplish the same, only perhaps less efficiently
<wpwrak>
but eventually you realize that you probably won't even get something like SPI to work reliably
<kristianpaul>
thats shame
<kristianpaul>
anyway for me fdti was just usb2ttl and now jtag with mm1
<wpwrak>
and amoong the two or three possibilities for implementing it the manual suggests exist, you'll find that at least one is not accessible because of incomplete documentation
<wolfspraul>
ok but I think for the very specific purpose that the ft2232hq is hard-wired on the m1 jtag-serial board, it's a good choice and the problem is solved
<wolfspraul>
that's not to say that I don't hear the type of feedback we hear from you now many times already
<wpwrak>
and so on. i tried to make one of the ftdi critters work for programming the c8051f32x chips, but eventually gave up after trying for one or two weeks.
<wolfspraul>
I would be very careful to see the ftdi chips as some sort of debug-board-swiss-army-knife. for sure they are not.
<wpwrak>
yes, if you have a use case that someone else already validated and you don't to anything else but exactly that, then you're probably fine
<wpwrak>
it's kinda like the stories you tell of OMAP :-)
<wpwrak>
well, one good thing came out of all this - in the end, i used the ben for programming my c8051f32x chips, with a predecessor of ubb :-)
<wpwrak>
btw, also the ft2232 has its bugs. if you use its regular big-banging mode, it can also "swallow" commands. i saw when making a remote reset tool for the openmoko debug board. hadn't realized the context back then, though.
<wolfspraul>
can we run into those bugs with the m1 jtag-serial board?
<wpwrak>
if all you do are jtag and serial, then i think you should be fine
<wolfspraul>
good
<wolfspraul>
:-)
<wpwrak>
if you control anything else, e.g., a led or so, you may have to send the command several times before it "takes"
<wpwrak>
i don't know if these are really reliable, though. dbgrst should be pretty good, because i used it in scripted tests and would have noticed a failure rate > 10% or so. norwp never saw such intense testing.
<qwebirc39061>
.
<kyak>
mirko: hey, are you there?
<kyak>
mirko: the top Makefile is also not quite OK. eg. it has staging_dir/toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/include/QtGui in INCPATH. But this is not correct, must be staging_dir/target-mipsel_uClibc-0.9.30.1/usr/include/QtGui
<kyak>
mirko: but then you are right that further Makefiles have even more problems (for example, empty CC)
<kyak>
mirko: i'm trying it with "Tile" application, which is quite simple and has only one Makefile
<wpwrak>
kyak: btw, speaking of the openwrt build: after the discussion on build time, i tried to see how long it would take to run it on my pc. one thing i noticed is that the "jikes" dependency seems to be an anachronism that cannot be satisfied with any recent ubuntu. (the build failed subsequently somewhere in gcc, which is when i dropped the idea)
<kyak>
wpwrak: $ rpmquery -a |grep jikes returns nothing. Why do you have this dependency?
<wpwrak>
kyak: it's listed on xiangfu's page about the build process
<kyak>
btw, at takes ~2.5 hours to build from scratch here. I don't build all the packages, maybe only half of them (my rootfs size was 256 Mb)
<kyak>
so i guess full build would take 5-6 hours
<kyak>
wpwrak: you should ask xiangfu then
<kyak>
i don\t have jikes installed on my build
<kyak>
wpwrak: i want to disassemble my Ben :)
<kyak>
need to clean behind the LCD glass
<kyak>
there is some dust and particles these
<kyak>
how i can do this? is the top case disassemlable?
<wpwrak>
the plastic is easy to remove. but you may scratch it in the process.
<wpwrak>
the plastic sheet is just glued. you can lift it off with a knife.
<kyak>
oh. then i would need to prepare a glue to glue it back?
<wolfspraul>
kyak: I very much recommend you not to try this.
<wolfspraul>
I'd say chances are 90% or more that after you are finished, it will look worse.
<wolfspraul>
the piece above the LCM module is called 'PC sheet', it's plastic
<kyak>
that's bad.. this dust behind the LCD is bothering me
<wolfspraul>
it has black paint on the back side, if you try to lift it off (it is glued), you have to be extremely careful to not scratch off that black paint from behind
<wolfspraul>
you mean behind the PC sheet? on top of the LCM module probably
<wolfspraul>
well you can try, but here are 2 things you really need to watch big time
<wolfspraul>
first of all - the PC sheet is glued and you need some thing razor-like instrument to lift it off on the sides
<wolfspraul>
and when doing that, you have to be super careful to not exert pressure from below onto the PC sheet, because you will scratch off the black paint otherwise
<kyak>
it seems that these particles are on both PC sheet and LCM module
<wolfspraul>
assuming you are able to lift off the PC sheet without damaging it, you then need to be able to clean both sides (the top side of the LCM module and the bottom side of the PC sheet) so that it is cleaner than right now
<wolfspraul>
most likely that will only work with some sort of air gun
<wpwrak>
maybe alcohol would work, too. "pressurized" air (in cans) is actually not air. it's some other inert gas.
<wolfspraul>
yes it may work, but I have never tried and from similar experiments I am careful to not overestimate my cleaning ability.
<wolfspraul>
it's amazing what small particle you see once it is pressed right in front of the bright backlight coming out of the LCM module
<wpwrak>
;-) yeah, i wouldn't recommend cleaning attempts if it's just for appearance. if the dirt is so thick that you can't see though it anymore, that would be different.
<wolfspraul>
correct, fully agree
<kyak>
wolfspraul: ok, i give up. Seems there is no easy way to do that. From my previous experience, this could end badly :)
<wolfspraul>
you would need a few Bens to play with before you are really good at this
<wolfspraul>
I could send you a replacement PC sheet, I think I have some flying around somewhere, but that may not even fix your (much bigger) problems anymore once you have too much dirt there and no way to clean it properly.
<wolfspraul>
I suggest you wait until it gets really bad and you get into the needed 'what the heck' mood.
<kyak>
hehe, ok :)
<wolfspraul>
such as 'worst case, I continue to use my Ben without the PC sheet, then I can always easily swipe directly over the LCM module'
<wolfspraul>
once you are there, I'd say you are ready
<wolfspraul>
xiangfu's personal Ben was like that for a while. plastic on top of the keyboard missing, keyboard held down with tape. pc sheet missing.
<wolfspraul>
couple other parts missing or 'hacked'
<kyak>
this must look cool
<mirko>
kyak: i think i've a solution :)
<mirko>
kyak: the issue is: the actual qmake command gets the (more or less) correct environment variables passed
<mirko>
however the created Makefile again calls qmake to create further Makefiles - this call isn't prefixed with proper variables..
<kristianpaul>
wpwrak: from you experience whats the max long to extend a bus with logic signals around 10Mhz and 15pf of load per pin
<kristianpaul>
I'm about cut ribbon cable for mm1 <-> sige comunication but it should be a bit longer as the exp connector is not in the edge of the board.
<kristianpaul>
I can test signal anyway with scope (yay!)
<kristianpaul>
but may be you already had experience to share abou this topic :-)
<wpwrak>
hmm, 10 MHz ... very very short :)
<wpwrak>
will you have ground between signals ?
<kristianpaul>
yes
<kristianpaul>
sige is powered from mm1
<kristianpaul>
(very very short) damn i know :/ i think i'll end fiting sige inside the mm1
<kristianpaul>
may be i can find a place for it next to the jtag-serial board..
<wpwrak>
(ground) i mean: are signal traces separated by ground traces ? or will you have crosstalk between signals ? also, do you have termination ?
<wpwrak>
inside the box would definitely be an advantage. a properly designed cable can go for maybe 1 m. a not so properly designed one probably just a few cm.
<kristianpaul>
wpwrak: separated by ground traces, yes
<kristianpaul>
wpwrak: termination, prone to interference..
<wpwrak>
(termination) so is this a yes or a no ? :)
<kristianpaul>
yes
<wpwrak>
okay, then it's probably safe to have a few tens of centimeters
<wpwrak>
if you consider IDE PATA cables, they also go quite fast and they're relatively long
<kristianpaul>
hmm, good point
<kristianpaul>
I already bougt ribon cable, but i'll take better my bus from a IDE PATA one
<wpwrak>
the cable material is probably very similar
<kristianpaul>
IDE wires look thin than the colored-ribbon i have
<kristianpaul>
ah, but connector differ so i'll use the colored-ribbon
<r-wos>
Hi everybody! Quick question: has anyone successfully compiled ScummVM for the NanoNote yet?
<r-wos>
I tried to compile it directly on the NanoNote (mad, I know) - and it works up to the final link, which dies with a signal 10, bus error...
<wpwrak>
wow, bus error is a misalignment. these have gotten rare in recent years
<mirko>
wpwrak: you didn't use macosx recently did you? ;)
<r-wos>
no, but I did a quick search for "bus error", too ;-)
<wpwrak>
mirko: where's the crucifix and the garlic ?
<kyak>
r-wos: compiling it on Ben might be a bad idea, better set up the openwrt build environment and take over the broken scummvm packages from qi-openwrt-feeds
<r-wos>
kyak: yeah, that's probably better... Hm, I thought I could get away without this cross-compile-juggling...
<mirko>
wpwrak: wp
<wpwrak>
mirko: 0x007f 0x007f ... ? what's that ? :)
<kyak>
mirko: it seems that qt4 is appending QtCore/QtGui/etc (whatever is needed) to the last directory in TARGET_INCDIRS
<kyak>
so it didn't work when toolchain dir was at the end.
<kyak>
mirko: it seems that QMAKE_INCDIR_QT is not designed to hold multiple directories
<kyak>
by default, it is $$[QT_INSTALL_HEADERS] which is a single directory
<kyak>
mirko: maybe it is correct to have $(STAGING_DIR)/usr/lib only in TARGET_INCDIRS (which goes into QMAKE_INCDIR_QT and then gets appended by QtGui/QtCore etc)
<kyak>
and then use QMAKE_INCLUDEPATH to add other directories that currently live in TARGET_INCDIRS
<kyak>
(btw, i think those other dirs are not really necessary)
<kristianpaul>
steve|m: hey
<kristianpaul>
steve|m: Do you know if the osl support vcd output?
<kristianpaul>
ah, wait
<kristianpaul>
neat it does :-)
<kristianpaul>
amazing i can record ~2ms of data at 10Mhz
<kristianpaul>
but nothing trusty, 50mhz should be ok