<aisa>
I'm not fishing for new tasks right now, my NanoNote backlog is still full.
<aisa>
but I intend to work on some of the deeper issues we're experiencing on the NanoNote, so I share my skillset so as I'm ready to work on these you know what I can and can't do.
<wolfspraul>
most important I think is steady progress over time, not run like crazy at the beginning, then be exhausted after x weeks :-)
<aisa>
excellent advice!
<aisa>
ok, I'm off for tonight.  I'll file that ticket tomorrow.
<wolfspraul>
DocScrutinizer: we have pretty nice and automatic schematics histories up :-)
<wolfspraul>
this is driven directly after commits of KiCad files into git
<wolfspraul>
thanks to some magic scripts by Werner...
<wpwrak>
wolfspraul: congratulations on getting schhist up and running !
<wolfspraul>
wpwrak: ah, it's all your work
<wolfspraul>
but yes I'm happy it's running
<wolfspraul>
next time there is a KiCad commit we have to see how it holds up
<wpwrak>
what could possibly go wrong ? ;-)
<wolfspraul>
we could also automatically create visualizations of mechanical/3D files :-)
<wpwrak>
hmm, 3D is already as automated as it can get :) the tricky bit is finding an orientation that looks good
<wolfspraul>
animated gif that rotates the object :-)
<wpwrak>
layouts will be fun, though. the plot function is much more complex than the one for schematics. and there is talk about changing the board format, so just doing the plot without involving pcbnew wouldn't be a future-proof  idea.
<wolfspraul>
actually you were right about the AVT2 work, it does look quite nice
<wolfspraul>
funny I always thought it was a big mess, but now that things are nicely visible we can all see that Carlos did a pretty clean job back then
<wolfspraul>
wpwrak: understood. there is no rush I think.
<wolfspraul>
for me, it's much much more important that things are maintainable, that we are communicating everything properly, etc.
<wpwrak>
(animated) i was thinking of making a "ben factory" clip with pov-ray. after all, there's little difference in having one or 100 cases in an image :)
<wolfspraul>
even the schematics diffs/visualizations we have now provide ample opportunities to improve the process
<wolfspraul>
but it needs time, need to explain, etc.
<wpwrak>
yeah, caching ...
<wolfspraul>
yeah, great!
<wpwrak>
ah, the user's process :)
<wolfspraul>
I think we share the same view that in any open hardware project, the process & tools is what matters. so the more we can integrate/document/automate that on the mechanical side, the better
<wolfspraul>
next on my server list are a few additional mediawiki extensions and updates
<wpwrak>
yup. the more computers take care of the boring repetitive things, the better
<wolfspraul>
and some smaller things like openwrt source mirror for packages from openwrt-packages
<wolfspraul>
the usb id updates are not reflected in the usb.ids download file yet, although they do show up in the web interface
<wpwrak>
btw, don't you want to shut down the forum ? it seems to serve more as a trap than a useful place for communication
<wolfspraul>
he :-)
<wolfspraul>
steter tropfen hoehlt den stein
<wolfspraul>
no I don't want to shut it down, but you are right it needs more love
<wpwrak>
(usb ids) cool. i think they don't create the file very often
<wpwrak>
;-)
<qi-bot>
[commit] Werner Almesberger: ben-pcb-comp2: 1 mm and 100 um scans are done. Reusing old ben-pcb-comp-500um. http://qi-hw.com/p/ben-scans/d0d1c5c
<wolfspraul>
I want to improve a few things on the communication/blog side, then I also need to get back to talk a bit more about the project again.
<wpwrak>
what would be great is a forum that connects to the mailing list. but that may be a lot of work
<wpwrak>
yup. plans for ya :)
<wolfspraul>
I gave up on those ideas, not everything should be connected together.
<wpwrak>
(forum/list) the thing is that they both serve exactly the same purpose
<wolfspraul>
I think there is almost no overlap nowadays in the 'mailing list audience' and the 'forum audience'
<wolfspraul>
just two worls
<wolfspraul>
worlds
<wpwrak>
so you create two disjoint groups. best case is that one group will eventually discover the other and realize that the other place is better
<wolfspraul>
the mailing lists have their function, their audience that knows how they work, appreciates it, etc.
<wolfspraul>
the forum is another group of people
<wpwrak>
i don't know. there are many very technical places that are fine with fora. likewise, most people who use mailing lists seem to be happy with them.
<wpwrak>
mailing lists are more efficient, that's for sure
<wpwrak>
a forum always has this hint that you don't quite want the user to really have all that data
<wolfspraul>
which data?
<wpwrak>
the content of the forum, the messages
<wpwrak>
in a mailing list, you get a copy of everything. in the forum things live inside the forum but usually without a useful means to download them (may even be prohibited by the usage rules)
<wolfspraul>
fair enough
<wolfspraul>
I would be that 99.9% of forum users wouldn't even have the thought that they should download all forum content...
<wolfspraul>
they just have some problems/issues, and are looking for help
<wolfspraul>
or they find old forum messages after searching, either in the forum search function or via google
<wpwrak>
sure. i'm just saying that this is one common limitation of fora
<wpwrak>
by the way, google searches mailing list archives as well :) the important thing there is that you also have a way to quickly get to the answer
<wolfspraul>
do you think the KiCad developers would be interested in seeing the schhist running?
<wolfspraul>
I don't know anybody there and the Yahoo forums really do turn me off...
<wolfspraul>
I tried to post a few times but there always was this or that problem, then I gave up.
<wolfspraul>
I think schhist is a pretty nice example of what is possible with good free EDA tools
<wpwrak>
developers are now on launchpad, including the list. users are still on yahoo, though
<wpwrak>
and yes, yahoo sucks horribly, i agree
<wpwrak>
it looks more like a users thing than a developers thing. i mean, there's no way this could ever be part of kicad itself.
<wolfspraul>
launchpad, ok
<wolfspraul>
maybe I should email them about the /schhist link? do you think they are interested?
<wolfspraul>
I guess they know you by now, since several of your patches were already accepted.
<wpwrak>
yeah, they do. recently, i haven't been very successful getting stuff there, though. i mean, even --plot has been sitting there for more than a year ...
<wolfspraul>
hmm
<wolfspraul>
is it still an active project?
<wolfspraul>
maybe they just don't like your patches, or what is the reason?
<wpwrak>
kicad ? yes, it's active
<wolfspraul>
of course with you being a C purist, and they try to 'use every possible C++ feature' (quote from their website), I can imagine some issues :-)
<wolfspraul>
trying to use every possible C++ feature is a really really stupid idea though, I hope they fail on that
<wpwrak>
the --plot patch wasn't clean enough. and they didn't want to accept it as a temporary solution either. of course, the big infrastructure cleanup that would allow it to be done cleanly hasn't happened so far.
<wpwrak>
(c vs. c++) yeah :)
<wpwrak>
often there's also a schedule problem. i have something that needs solving, but they don't have the time to deal with it. so after a bit of discussion, things get postponed indefinitely.
<wpwrak>
meanwhile, i find a work-around, so then i don't have an itch to scratch either
<viric>
As there are some nand experts here... :)
<viric>
tuxbrain told me how to make an ubifs image
<viric>
But can I make any 'nand' file for the qemu '-mtdblock' command then, from that ubifs image? I think I have to prepare a full mtd layout, with the three uboot-kernel-ubifs with proper memory addresses.
<viric>
Any idea?
<viric>
and, NAND in devices is usually mapped to physical addresses like RAM, right?
<viric>
(If anyone knows of a document that would tell me about this, please give a link. I simply could not find all this meanwhile)
<rafa>
viric: do you need to use qemu with mtdblock or you just want to test the image?.. if you dont care if you want to use mtdblock then maybe you just could make a image disk file with an ext2 FS and the userland rootfs inside (so you would boot the system with qemu like if you would have a disk)
<mth>
viric: NAND access is via a controller, it's not mapped directly into memory
<mth>
rafa: how would the guest machine load from the disk then? afaik that's done via IDE emulation, but the NN does not have an IDE controller
<rafa>
mth: if you build a nanonote kernel with ide controller it should work.. or qemu just can emulate the nn hardware only? it not is just arch?
<viric>
rafa: I'd like to learn about both
<viric>
rafa: and I want to test specifically the ubifs, whether it boots or not
<viric>
mth: via controller? But... for the CPU, is not all mapped to physical ram?
<viric>
I would not emulate the nn hardware in qemu.
<viric>
I'll use any other mips32
<mth>
the mainline qemu does not emulate the NN afaik,  but there is the qemu-jz that at least emulates the JZ4740, although not exactly the NN specs
<mth>
viric: it's not hard though to add a machine to qemu, if the components are already supported
<viric>
I don't mind much about the jz specific details. Any other mips32 will do, to test the userland
<wolfspraul>
wpwrak: from the 3 ben-wpan variants, the most recent microSD one is atusd, right?
<viric>
Any mips32 will do to test the userland. I wanted to use their default 'malta' system
<viric>
All my trouble is in the mtdblock
<viric>
mth, rafa: the mtdblock access does not need any kernel support, other than telling the kernel 'what addresses map to what mtdblocks', isn't it?
<mth>
see hw/mips_dingoo.c
<rafa>
mth: I mean.. if viric just want to run the userland.. he could (if qemu supports the cpu/arch) to boot with qemu using whatever hw emulation qemu supports
<viric>
rafa: yes, that is what I plan. The kernel boots fine
<viric>
rafa: I only need to tell qemu "use this mtdblock", and I have to prepare the mtdblock file, which I don't know how to do.
<viric>
I read the pages around ubifs (mtdtools, all that...)
<viric>
and all those tools come without manpages, so I barely know what to do with them
<viric>
ok - time for lunch here
<viric>
I'll come later. Thank you
<mth>
viric: I guess there are only two likely formats: either an image containing only the data or an image containing data + oob
<mth>
since it will be presented as a block device, data-only would be my first guess
<mth>
but I have no proof for that assumption
<mth>
viric: actually, doesn't qemu have a mode where it translates API calls between architectures?
<wpwrak>
wolfspraul: atusd is the latest one i'm working on, yes. but i'll update atusb too. cntr is something else - it's an arbitrary-precision frequency counter.
<mth>
in that case you wouldn't need an image at all
<mth>
system calls, I mean
<wpwrak>
wolfspraul: i built it to measure the clock accuracy. none of my instruments is precise enough to do that correctly.
<viric>
mth: image of what, you mean?
<viric>
'mtdblocks' will be shown as an mtd device, not a block device
<mth>
a NAND image: a file containing the data used for emulating a NAND
<viric>
Ah
<viric>
Yes, this is what I want
<viric>
I did not understand what you meant about that 'mode that translates....'
<mth>
note that if you compile the tools on an x86-64 machine, you have to patch them (see comment I added on the qemu-jz page)
<viric>
But I'm not looking for any specific jz-things
<viric>
Isn't openwrt doing something like this? I could read the openwrt code...
<mth>
the patch is because of a bug that occurs only on 64-bit systems, it's not JZ related
<viric>
but maybe that is outdated?
<viric>
I am not using qemu-jz
<wolfspraul>
wpwrak: hmm, OK. but atusd is what might/will become the 802.15.4 module for the Ben and future devices?
<mth>
it's a patch for the image build tool download linked from the qemu-jz page
<wolfspraul>
(sorry I need to simplify a bit, just to get the story...)
<mth>
if you can find a more recent version of that tool, it might be patched
<viric>
ok
<wpwrak>
wolfspraul: yes. atusb is the one that goes into the pc.
<wpwrak>
wolfspraul: regarding future devices, if one is to be built into the nanonote, then it would be based closely on the atusd. with a few more signals and some emi filters, though.
<wolfspraul>
ok, we get to that then... thanks I have the rough 'big picture' clear now
<viric>
The 'nanddump' command outputs in what format?
<viric>
bin+oob?
<qmasterrr>
hi
<viric>
I'm trying to use nandsim to get something close to the nanonote nand
<aisa>
It should be User:Alanpost/Notebook, which also exists.
<aisa>
Anyone with wiki-admin privileges around to delete a page for me?
<aisa>
woohoo!  I could not boot my NanoNote off a single 16gb microSD partition, but reformatting to a 2gb partition works.
<aisa>
Yay!  I have reflashed my Ben.  I have been fighting to find a block of time to devote to this.
<aisa>
I've been afraid of bricking the thing, and I use it for actually things.  :-)
<tuxbrain>
congrats alsa, the first flashing is always special :)
<aisa>
I realize in doing it, as well, that being able to boot off a microSD is very nice for testing.
<bartbes>
I wonder
<aisa>
I can write all sorts of junk to that card just to see what it does, without affecting my regular environment.
<bartbes>
where does it look for the kernel?
<aisa>
/boot/uImage
<aisa>
which is to say, you write the same kernel you have at /dev/mtd1
<aisa>
s/you write/you read/
<aisa>
that still didn't make sense.
<aisa>
I'm trying to say it boots a kernel off the microSD.  And that kernel is bit-for-bit the same as if it were on the Ben.
<aisa>
oh good, I resynced my data and vim loads.  I'm at least at the same point I was at.  I've been afraid I'd boot into a system I couldn't actually use.
<kristianpaul>
heating the printer
<wpwrak>
ducks
<kristianpaul>
heh 3minutes printing, seems this is really small this time
<wpwrak>
i'm amazed by how quickly your printing goes
<kristianpaul>
:D
<kristianpaul>
It is FDM fault
<kristianpaul>
an inacurcay of the open source sofware :p
<kristianpaul>
why i never pad enought atention to this thing ;)
<kristianpaul>
pad/paid
<kristianpaul>
you milled all the counterweights?
<wpwrak>
i made a wooden mold. then i cast them.
<kristianpaul>
ohh
<kristianpaul>
wich of this scripts is loaded usign heeks python?
<kristianpaul>
i dont see import from HeeksCad...
<kristianpaul>
it directly mills?
<wpwrak>
you run it in the console. import cw
<kristianpaul>
ahh heekscad dvd
<kristianpaul>
cnc
<wpwrak>
or reload(cw)
<wpwrak>
(first time it's import, then reload)
<kristianpaul>
i dont use heekscad cnc for obvious reasons :)
<kristianpaul>
i was trying heekspython the other day no more..
<wpwrak>
the script doesn't set up the mill. that has to be done manually (unfortunately)
<kristianpaul>
but it draws using the cnc heekscad engine if wen call it like that?
<wpwrak>
yes
<kristianpaul>
i see
<wpwrak>
i found some pictures. lemme clean them up a bit ..
<ebaus>
hi out there I've installed debian succesfully but can't make sound work I'm using mp3blaster
<kristianpaul>
hi
<ebaus>
any suggestions?
<kristianpaul>
sorry i dont use debian on the ben afaik
<kristianpaul>
but i think i saw that issue in the mail lists
<kristianpaul>
wolfspraul: hi
<ebaus>
just by change do you know if there's a sound device defined in openwrt /dev ?
<kristianpaul>
wolfspraul: i friend ask me about a device with two xbusrt chips, and also about if this techonology is proven to work on industrial enviroments, do you have comments about it?
<wpwrak>
hmm. the 0.5 mm of space below the pcb. is it really empty ?
<wpwrak>
this looks more like a lot of empty space above the pcb, but none below
<kristianpaul>
well PCB space is 1mm actually
<wpwrak>
so how tall is the hole ?
<wpwrak>
1 mm, no ?
<kristianpaul>
~
<wpwrak>
that's not quite enough. there has to be 0.5 mm of air above the "floor". then there's the pcb (0.8 mm)
<kristianpaul>
hmm
<wpwrak>
maybe it's time to switch to openscad, so that all the adjustments are quicker to make ;)
<kristianpaul>
:)
<kristianpaul>
i'll do if you found how to do parametric fillet
<wpwrak>
that's actually what i hate about most interactive cad programs - when you need to experiment and tweak things, it gets quite hellish with lots and lots of manual repetitions
<kristianpaul>
indeed
<wpwrak>
seems that there's no built-in fillet/chamfer
<kristianpaul>
wait
<kristianpaul>
you dont
<wpwrak>
you could of course construct it "manually" ...
<kristianpaul>
can you do that in SVG or QCAD?
<kristianpaul>
and is just matter of extrude
<wpwrak>
no idea :)
<kristianpaul>
:p
<wpwrak>
i tried qcad once. after a few frustrating hours, i hurled into a corner, virtually speaking, and drew the damn thing in fped :)
<kristianpaul>
lol
<kristianpaul>
can you draw something like a filled in fped?
<kristianpaul>
or inkscape...
<kristianpaul>
what a mess ;)
<kristianpaul>
i need re-think my prefered cad sofware indeed