<Jay7> news item for march - OE have support of NN in vanilla kernel recipes now
<Jay7> i.e. you may build now .37
<Jay7> thanks to Andrea Adami :)
<Jay7> we are trying to bring kexec to usable state now..
<wpwrak> .37 is great news !!
<qi-bot> [commit] Werner Almesberger: sal/: primitive USRP2-based spectrum analyzer http://qi-hw.com/p/wernermisc/e6f62bc
<wpwrak> phew. finally found a way to un-GL the darn usrp2_fft
<wpwrak> it's actually easy. just two lines to change.
<wolfspraul> roh: you there? I'm sitting here with Xiangfu and we try to assemble two cases :-)
<wolfspraul> I am a little lost with the 3 buttons.
<wolfspraul> are we supposed to add glue? the 3 pieces don't seem to glue...
<larsc> yes
<wolfspraul> man cool. survival Xiangfu has a glue gun in his backpack!!!
<wolfspraul> larsc: thanks a lot, we are back on track...
<wolfspraul> always good to carry some glue with you, just in case...
<kristianpaul> recovers from a power failure
<kyak> < wolfspraul> always good to carry some glue with you, just in case... <-- this has made my morning :)))
<qi-bot> [commit] Xiangfu Liu: update usbboot version http://qi-hw.com/p/xburst-tools/86d8824
<qi-bot> [commit] Xiangfu Liu: update changelog, INSTALL http://qi-hw.com/p/xburst-tools/8170afb
<qi-bot> [commit] Xiangfu Liu: update debian changelog http://qi-hw.com/p/xburst-tools/51b7b51
<kyak> guys
<kyak> i just connected to Ben via serial
<kyak> a do echo 32 > /dev/ttyS0 on Ben, and receive it in my terminal emulator on PC
<kyak> i have ttyS0::askfirst:/bin/ash --login in /etc/inittab
<kyak> but i don't see any command prompt in serial console
<kyak> what's the problem?
<xiangfu> kyak: the baud rate is 57600.
<xiangfu> what app you using in PC?
<kyak> yep, i got it right.. otherwise i won't receive the test string
<kyak> putty
<kyak> so whatever i send to /dev/ttyS0 from Ben, i receive it on my PC
<kyak> i can't TX back to Ben it seems.. i don't know if tail -f /dev/ttyS0 would work to test it
<xiangfu> kyak: this should work: while : ; do cat /dev/ttyS0 ; done
<kyak> ok
<xiangfu> tail -f not
<kyak> i rebooted Ben
<kyak> and i see output in serial
<xiangfu> wait.
<kyak> but i can't type in -\
<xiangfu> you must press "S" when power on. for make the serial full work.
<kyak> ah!
<xiangfu> (the serial under battery)
<kyak> yes
<kyak> under the batery
<kyak> HAHA
<kyak> this is great
<kyak> xiangfu: thanks a lot :)
<wpwrak> someone is celebrating :)
<kyak> yea! i found the damn cable, and it was free.. Then i didn't solder it right (TX<->RX), but now it's working  :)
<wpwrak> kyak: if possible, i think it would be better to connect to the other serial pins: no conflict with the keyboard
<kyak> wpwrak: i'm thinkinh about it. But, if i'm connected via serial, i don't usually need Ben's keyboard
<wpwrak> kyak: and you shouldn't need to press S for the other pins either (at least i never had to so far)
<kyak> ah.. that's good
<kyak> another thing
<kyak> i can't insert battery with these wires
<kyak> under the battery
<wpwrak> use thinner wires ;-)
<kyak> they end up with a connector
<kyak> anyway
<kyak> wpwrak: you don't even imagine the ugliness of my solder work
<kyak> there is tin everywhere under the battery now
<wpwrak> kyak: well, you managed this. so you'll also be fine with UBB :)
<kyak> ok, i will try to explore the second posibility now...
<xiangfu> upload the new version xburst-tools. support 'reset' command.
<kyak> ehehe
<kyak> stupid kexec
<kyak> showing interesting things to me
<kyak> in serial console
<kyak> now it's not just "Bye"
<wpwrak> ;-)
<kyak> hm, i wonder, how can i boot "S" and "M" at the same time? :)
<kyak> i.e. serial console, take kernel from SD card
<xiangfu> kyak: yes. you can press BOTH "S" and "M" . you will see the u-boot output in serial .
<xiangfu> the "U" is very first check. then check if "S" pressed. then "M/F1/F2/F3/F4"
<kyak> xiangfu: thnkas
<xiangfu> NAND Boot
<xiangfu> Starting U-Boot ...
<xiangfu> [S] pressed, enable UART0
<xiangfu> [M] pressed, boot from sd card
<xiangfu> kyak: ^
<xiangfu> when you press "S" . the u-boot will delay 3 seconds.
<xiangfu> for you active the u-boot console.
<xiangfu> if there is no input in serial. u-boot will load kernel.
<kyak> xiangfu: now i'm able to go deeper for udnerstanding of kexec problem :)
<kyak> everything > line 154 was not visible before
<kyak> wpwrak: "Incorrect memory mapping !!!
<kyak> wpwrak: "Incorrect memory mapping !!!" - do you have any ideas?
<wpwrak> this doesn't look too bad. no, don't know what this is. looks like something architecture-specific.
<kyak> hm, ok
<kyak> btw, i re-soldered it
<kyak> with thinner wires
<kyak> i still have the connector that plugges to USB-UART cable
<kyak> so when i'm finished, i'll solder it all off :)
<jow_laptop> I wonder why the jz4750 does no add_memory_region() in its setup code
<jow_laptop> looks like that would solve the kexec error
<kyak> jz4740?
<jow_laptop> the prom setub for the xburst/nn
<jow_laptop> *setup
<qi-bot> [commit] Xiangfu Liu: new package: avrdude, for programming Atmel AVR Microcontrollers http://qi-hw.com/p/openwrt-packages/27512b3
<xiangfu> tuxbrain_away: wpwrak ^ , avrdude added in openwrt-packages.git. just don't know how to test if avrdude works fine.
<tuxbrain_away> xiangfu: including wpwrak patches?
<kyak> jow_laptop: sorry, i don't understand...
<xiangfu> tuxbrain_away: forget that patches. adding now. thanks
<kyak> xiangfu: will it overwrite the avrdude from openwrt-feeds?
<jow_laptop> kyak: the panic message after kexec happens if no boot_mem_map exists
<jow_laptop> kyak: this map is populated by calls to "add_memory_region()", other mips boards have such calls in their setup code, but the ingenic soc code has not
<tuxbrain_away> xiangfu: kyak is right until patches are really finished I think we have to mantain it as some kind of fork
<jow_laptop> kyak: other boards do this in prom init: add_memory_region(0x0, memsz, BOOT_MEM_RAM);
<kyak> jow_laptop: hmm, ok! do you think we could just take it?
<jow_laptop> I have no idea how to determine the ram size from within there
<jow_laptop> but for testing ruposes you could just stick it in with a hardcoded value
<kyak> add_memory_region(0x0, 33554432, BOOT_MEM_RAM); - like this?
<kyak> i.e. hardcoded 32Mb
<jow_laptop> I think the second arg is mb
<kyak> ah ok
<jow_laptop> no wait
<jow_laptop> bytes
<xiangfu> tuxbrain_away: add the aurdude in openwrt-xburst.git . if define NANONOTE. applied werner's patch.
<xiangfu> tuxbrain_away: kyak then I will try to send patch to upstream. then remove it from openwrt-xburst.git :)
<kyak> jow_laptop: http://pastebin.com/r6TaFZYt
<kyak> moving on :))
<tuxbrain_away> cool xianfu, then instead of my compiled arvdude I will use this to test :)
<xMff> kyak: hmm, no idea about the console
<qi-bot> [commit] Xiangfu Liu: avrdude add patch for nanonote from werner http://qi-hw.com/p/openwrt-packages/c5dd13f
<xiangfu> not finish yet. work on that later.
<xMff> xiangfu: " (cd $(PKG_BUILD_DIR); aclocal; automake) " should be replaced with PKG_FIXUP:=autoreconf
<kyak> xMff: it's fine, it's working :) just need to pass the correc cmdline now
<kyak> xMff: thanks a lot! need to ask larsc to make the patch for prom.c more clean and nice
<kyak> xMff: now, seems that kernel cmdline can't be passed via kexec
<kyak> what does CONFIG_IMAGE_CMDLINE_HACK do?
<xMff> kyak: it sets the commandline to a specific pattern ("CMDLINE: ") which is substituted in the final binary
<kyak> substituted by what?
<xMff> by whatever is set in menuconfig
<kyak> ok, so it's not exactly what i need...
<xMff> well
<xMff> it relates to what you need
<xMff> iirc it disables the normal processing of the cmdline
<kyak> the cmdline is always empty, no matter what i set in kexec
<kyak> it means that i won't be able to kexec the same kernel i'm booting
<xMff> not with the cmdline hack in place
<kyak> beacuse in one case (botting via uboot) i don't need the cmdline
<kyak> but in another case (booting via kexec) i do need this hack
<kristianpaul> kyak: you solved tx problem?
<kyak> hm, besides, IMAGE_CMDLINE_HACK is bool...
<kyak> kristianpaul: yep, just needed to boot with "S"
<kristianpaul> ah, nv (read backlog)
<kristianpaul> kyak: i'm think you may get garbage some times as that pin i shared
<kyak> all is good so far :)
<kyak> i'm not using the keyboard
<kyak> Ben's keyboard
<kristianpaul> good
<kristianpaul> larsc: You think using serial port for debugging linux can tell me something about the suspend crashing...
<kristianpaul> Or i can activate some debug flag for RTC?..
<Jay7> kyak: btw, where do you find right cable? :)
<kyak> Jay7: from a colleague of mine :)
<Jay7> lucky you :)
<kyak> yes, it was pretty random
<wpwrak> kyak: congratulations ! you're almost there
<wpwrak> kyak: line 27 shows you what you need at line 168. so if you put this into CONFIG_CMDLINE of the kernel you're building, you should be fine
<kyak> F7=CD@N $B2 5@HK HK F@D5 H 2IBM5 FDB5 5I 2I )
<kyak> damn
<kyak> wpwrak: yeah, and this is what i don't want to do
<kyak> i dont't want to hardcode the CONFIG_CMDLINE
<kyak> right now it is passed by u-boot. I fairly enough expect kexec to be able to do the same
<kyak> wpwrak: sorry, i forgot to mention here that even if i do kexec -l .. --append="$(cat /proc/cmdline)", the "Kernel command line: " is still empty
<kyak> the other guy on #kexecboot suggested putting some printf in kexec-tools, and we see that the cmdline is actually formed there.. But somehow it is not received by kernel
<wpwrak> kyak: (pass cmdline in the kernel) i mean while testing. to see if anything else is missing
<wpwrak> kyak: yeah, the kernel's low-level code may simply implement a different convention for accepting the command line. you have to look at the code on both ends.
<kyak> i agree, i'll test now if the hardcoded cmdline would work..
<kyak> i'm salmost sure it will
<wpwrak> famous last words ;-)
<kyak> in fact, i was sure without "almost" before you said "if anything else is missing" :)
<kyak> so now i'm in doubt, too
<wpwrak> ;-))
<wpwrak> potential problems include drivers that leave things in a state where they can't restart it
<xMff> yes, ar71xx in openwrt has such an issue with the on-flash board data
<xMff> can't find mac addresses after kexec
<wpwrak> xMff: debugging kexec is fun :) people at IBM did quite a lot of work there, when they made kdump
<kyak> wpwrak: so you only solve problems to find bigger problems behind it :)
<wpwrak> alas, each driver can exhibit some surprise
<xMff> kyak: regarding the memory size, I suppose parsing the mem= argument from the cmdline and falling back to 32mb is the way to go
<xMff> I do not know whether it is possible to probe the memory
<kyak> xMff: i really hope that larsc would come up with a nice and clean solution for this... After all, he's the one who did prom.c :)
<B_Lizzard> Hmm, just booted Muffinman with 2.6.37 and my screen colors are all fudged up
<B_Lizzard> larsc, an issue with my defconfig?
<B_Lizzard> This is vanilla + the modifier keys patch
<kyak> xMff: wpwrak: http://pastebin.com/xvvTLRvZ CMDLINE hardcoded - works like a charm :)
<xMff> great
<kyak> but to make it work with cmdline supplied by kexec - this is the question...
<xMff> is the cmdline hack actually needed?
<kyak> nope
<xMff> it is usually only used for boards with known faulty bootloaders
<kyak> i onyl set CONFIG_CMDLINE_BOOL and CONFIG_CMDLINE
<wpwrak> kyak: congratulations ! does the display work, too ?
<xMff> why is the hack enabled in the normal Qi builds?
<kyak> wpwrak: sometimes yes, sometimes no :)
<kyak> xMff: it is disabled in 2.6.37. But what is trange to me, is that 2.6.32 is actually rellocatable kernel
<kyak> seems that CMDLINES is overwritten by uboot
<kyak> wpwrak: hmm, i disabled the serial console , all seem to work fine
<kyak> just did a fast boot from 2.6.32 to 2.6.37 with switching of rootfs
<kyak> :)
<kyak> i'm about to see how it would work for gmenu2x
<kyak> not changing the rootfs in this case
<kyak> it just works :)(
<B_Lizzard> Also, the screen blanks to white
<kyak> not quite "just". Something wrong with dropbear or network. This is minor, passing the cmdline is major
<tuxbrain_away> congrats kyak , then I supose the graphical dinamic multiboot is near isn't it?
<kyak> tuxbrain_away: you should ask Jay7 about it, i'm just helping out :)
<Jay7> kexecboot is just working :)
<Jay7> we need working kexec
<kyak> yup
<tuxbrain_away> Rusian powa!
<Jay7> :))
<kristianpaul> :-)
<tuxbrain_away> UBB had just arrived :) they look great :)
<wpwrak> tuxbrain_away: wheee !! do they fit well ?
<kyak> xMff: hm......
<kyak> i'm confused
<kyak> there is add_memory_region() in qi-kernel git. But it didn't got into the kernel??
<xMff> kyak: maybe due to quality
<xMff> hardcoded etc.
<kyak> could be..
<kyak> well, i wonder if i should take prom_init_cmdline(); now it will solve other problems
<kyak> it's strange, cause i specifically asked lars about the difference between openwrt-trunk and qi-kernel kernels. He said it is openwrt logo :)
<larsc> B_Lizzard: you are missing the display driver
<tuxbrain_away> wpwrak: fits like a glove dude :) uploading pics to wiki
<wpwrak> tuxbrain_away: excellent. congratulations !!
<wpwrak> tuxbrain_away: seems that your pcb fab is a keeper :)
<wpwrak> tuxbrain_away: (pics to wiki) and more importantly, to the shop, getting rid of my ugly hand-crafted board :)
<tuxbrain_away> wpwrak: will do don't worry and of course it will deserve a post :)
<dvdk> tuxbrain_away (UBB arrived): BTW what about the extra AVR ICs?
<dvdk> tuxbrain_away: can you add them to the order and tell me how much i owe you?
<wpwrak> tuxbrain_away: (post) even better :)
<B_Lizzard> larsc, were these patches never merged?
<tuxbrain_away> sadly I don't have IC , due the stock breack of trough hole I only have Arduino UNO smd editon , but programing sould work due you atact directly to the chip on SPI, (and comunication should also work) even with the 5-3V3 voltage diference.... at least directly serial from NN to Arduion board does.
<dvdk> tuxbrain_away: ok.  you mean if i hook the arduino UNO smd up to the 3.3V of the UBB, it should still work?
<tuxbrain_away> yep, yu should power the Arduino externaly with a bat or somthing like that and at least on serial works with NN
<dvdk> tuxbrain_away: so i need an external battery?  just UBB+NN+Arduino won't do?
<dvdk> hmm.
<tuxbrain_away> no it will not. you need a 5V source to USB or 7-12V on Vinn
<tuxbrain_away> tipicall a 9V batt
<larsc> B_Lizzard: the driver isn't ready for upstream yet
<dvdk> tuxbrain_away: thanks for the clarification. Maybe then arduino is not the right thing for me.  I'm searching for something that could work "sandalone" with UBB+NN+NanoNote, powered via the UBB.
<dvdk> s/sandalone/standalone
<tuxbrain_away> then you sould look for an naked Atmega chip
<dvdk> tuxbrain_away: just looking (reichelt.de) :)
<dvdk> just not very economical.  cheap IC, expensive shipping :(
<tuxbrain_away> or for a Arduino Mini 3v3 edition... (I don't have this one yet)
<wpwrak> pretty much any "naked" avr should do. even the weird ones that come with their clock fuse set to "external" will work ... soonish ;-)
<wpwrak> dvdk: don't you have any walk-in electronics shop where you live ? they may have some avrs
<dvdk> wpwrak: no time to "walk-in" :)
<wpwrak> dvdk: ;-)
<dvdk> wpwrak: Berlin is such a big city.  And our public transport is somewhat broken currently ;)
<wpwrak> dvdk: (public transport) ah, we really have a lot of people in berlin. winter still strong ? if you need to find a shop, roh can probably tell you where they have avrs
<B_Lizzard> larsc, yeah, sorry
<B_Lizzard> Couldn't remember if we had that applied in our tree or if it was vanilla
<B_Lizzard> I don't see some bugfixes either
<B_Lizzard> The bug fix in the battery driver
<B_Lizzard> The mutex thing
<dvdk> wpwrak: i'm actually tempted to try the cheap EVB R8C13, however looks like it cannot be flashed synchronously via UBB :/  http://www.reichelt.de/?;ACTION=3;ARTICLE=69672
<B_Lizzard> So, everything here that has to do with the Nanonote should be applied in our tree?
<dvdk> tuxbrain_away: wow, impressive images, maybe more people will buy, once seeing this :)
<wpwrak> tuxbrain_away: hmm, your shipping is pricy indeed ... btw, your shop should mention which carrier gets used
<B_Lizzard> At least the last few stuff
<dvdk> tuxbrain_away: ok, then my order stays like it is, no extra arduino added.
<wpwrak> dvdk: (r8c13) you'd have to find out how this chip is programmed, then check on the schematics if the pins needed for this are connected. some chips have more than one choices.
<tuxbrain_away> Is not the UPS shied showed?
<tuxbrain_away> wpwrak: how do you make the graphics on NN they where "online" or reading a file?
<wpwrak> tuxbrain_away: nice picture. a gazillion of boards ;-))
<dvdk> wpwrak: already had one pass at the datasheets and didn't found anything (it has two async modes, two-wire+ground and one-wire+ground).
<wpwrak> tuxbrain_away: (ups) oooh, right. now i see the tiny logo ;-)
<kyak> wpwrak: a question: can UBB be used as a serial console interface?
<dvdk> kyak: would solve many problems, if it could.  but looks like it can't.
<wpwrak> tuxbrain_away: (graphics) hmm, i don't understand the question. which graphics ?
<tuxbrain_away> you should ad a microcontroler for this kyak
<tuxbrain_away> the ones you do for signal analisys on NN
<wpwrak> kyak: (serial console) not easily. you could probably make a driver that bit-bangs serial. but it would be inefficient. should be okayish for tx-only, though.
<tuxbrain_away> you use gnuplot isn't it?
<kyak> i see, thanks )
<wpwrak> kyak: you could add some interface circuit that translates some more friendly protocol to uart (or anything more convenient, such as usb device)
<wpwrak> tuxbrain_away: i use gnuplot a lot, yes. what i used in any specific case would depend on the case. if you tell me which image, i can probably tell you what i used :)
<tuxbrain_away> I think gnuplot can draw "live" values , isn't it? would be a really cool to do demo for example reading analog values on arduino and show how the graphic varies on NN moving a potentiometer
<kyak> wpwrak: i have an old nokia phone, which has these service pin-outs (and then it's UART, if i'm not mistaken). I thought i could use UBB to connect Ben to it. Can I?
<tuxbrain_away> even a simple bar or line moving up and down could fit
<kyak> just trying to understand why i need this IC.. Why can't Ben act as one?
<wpwrak> tuxbrain_away: (live values) hmm, never tried to do that. i think it would be hackish. i've seen xplot being used for live plots
<wpwrak> kyak: then ben act as uart tx, but you'll have to busy-wait during the transmission (unless your bit rate is very very slow - then you could use timers)
<wpwrak> kyak: for rx, you'd either have to busy-loop to wait for the start bit or use an interrupt. the problem with the interrupt is interrupt latency. if interrupt latency is too large, then your uart driver would be too late to catch subsequent bits
<wpwrak> kyak: also, interrupt latency is variable. so an interrupt-driven driver may catch, say, 99% of all bytes, but then miss one
<kyak> wpwrak: ok, i understood that the hardware chip would be better, right?
<wpwrak> kyak: and interrupt latency varies with kernel activity. so you may be able to use soft-serial well enough when the ben is idle, but RX may be unusable if it's, say, copying files
<wpwrak> kyak: a dedicated chip can just busy-loop all the time (or even use dedicated uart hardware), and will thus have no problem meeting deadlines
<wpwrak> tuxbrain_away: (ubb) they scrwed up a little on the points of attachment, but okay, that can be solved with a knife/file/sand paper
<kyak> wpwrak: how does it all work with SD card on the same lines? it also requires low latencies and interrupts/
<B_Lizzard> larsc, sorry for the ball-busting
<B_Lizzard> Do I apply anything from "POWER: jz4740-battery: Protect against concurrent battery readings" and above in here http://projects.qi-hardware.com/index.php/p/qi-kernel/source/changes/jz-2.6.37/ ?
<wpwrak> tuxbrain_away: i made the order. i wonder if it really got through - i ended up on a page offering/demanding "verified by visa", which i declined, and then it showed up as authorized. so i'm not sure if verified by visa was just politely offered for my consideration or if the transaction wasn't really cleared yet. you may want to have an eye on this.
<B_Lizzard> That stuff seems newer
<tuxbrain_away> wpwrak: yeah I know I have to polish them prior shipping
<larsc> B_Lizzard: the mutex patch is in 2.6.37.1
<larsc> the battery mutex patch
<B_Lizzard> The suspend fix?
<wpwrak> kyak: for SD, there is a controller in the jz4720 that implement the lowest-level protocol in hardware. just like the ben's uart does the bit-level timing and exchanged only entire bytes with the cpu
<kyak> wpwrak: i'm asking because i know that some pins (GPIO) of my router can be used interchangebly as LEDs/serial console/SD card mod. So i thought it is possible in Ben. Can we utilize these lowest-level capabilities?
<wpwrak> kyak: if you have a chip that does spi slave to whatever conversion, like it's intended for my uart board, then this chip a) uses only a communication with very relaxed timing for the host (the host chooses the clock, etc.), and b) can even do some local buffering. so very long latency on the host (ben) side is acceptable.
<wpwrak> kyak: for serial, i explained the limitations above. for sd host, yes, you can of course use the existing sd/mmc host controller
<wpwrak> kyak: sd device would have limitations similar to uart rx. only that the timing would be even more demanding.
<kyak> ok, is it _only_ sd/mmc host controller, or can it do other things? Can it time the uart communication for us?
<wpwrak> kyak: you have sd/mmc host controller and bit-banging. with big-banging, you do whatever you please, but you should choose carefully what protocols you use :)
<kyak> wpwrak: ok: ) thanks for explanations!
<wpwrak> tuxbrain_away: if the card transaction didn't get through, i'll just do an interbank transfer. there's no rush anyway.
<B_Lizzard> I mean, is the suspend fix upstream or is it in that list?
<B_Lizzard> Otherwise I'll just apply the display driver and the blanking issue
<wpwrak> kyak: one gotcha: before connecting anything via UBB (that isn't an SD/SDIO device), make sure to
<tuxbrain_away> seems the transaction from my part has been accecpted
<wpwrak> kyak: echo jz4740-mmc.0 >/sys/bus/platform/drivers/jz4740-mmc/unbind
<larsc> suspend fix?
<wpwrak> kyak: this will turn off the SD/SDIO/MMC driver in the kernel and also ensure the kernel doesn't try to power up your circuit
<kyak> wpwrak: so do i understand correctly that "mmc_over_gpio" driver (like seen here for example: http://www.dd-wrt.com/wiki/index.php/Linksys_WRT54G-TM_SD/MMC_mod) is working in bit-banging mode?
<kyak> wpwrak: thanks for th hint
<B_Lizzard> You mentioned that the kernel crash when suspended has been fixed in 2.6.37
<B_Lizzard> Something about wakeups
<larsc> i don't think so
<wpwrak> kyak: power up often requires some "precharging", to avoid an excessive inrush current (if the inrush current it too large, the ben's 3.3 V rail will drop, the ben hangs, and needs to be reset)
<larsc> i said that you can workaround it in sw
<B_Lizzard> Ah, OK
<wpwrak> kyak: (precharing) the exact process depends on the board. this can usually be done by driving all output high or by just putting a little delay between card insertion and power up. if you start the communication manually, then the delay is nornmally implicit.
<B_Lizzard> OK, I'll just add the display driver and the blanking fix then
<B_Lizzard> Thanks for the help, larsc
<larsc> np
<larsc> you might also want to add the gpio-charger driver
<larsc> it reports whether the battery is currently being charged
<wpwrak> kyak: (mmc over gpio) yes, looks that way. sd/sdio/mmc host is okay for bit-banging, because the host controls the clock and there are no tight timing requirements on the clock (if there is any lower bound for the clock at all, don't know :)
<kyak> ok, so i got the general idea :) whatever is tx'ed from Ben, or controlled by Ben, is OK :)
<wpwrak> tuxbrain_away: (transaction) cool. then i'll have some ubb fun next week, too ;-) btw, got any more orders after the first rush ?
<wpwrak> tuxbrain_away: (rt plot) nice. so "replot" does the trick.
<wpwrak> kyak: (controlled by ben) yes, that's the point. even rx is okay (e.g., in SPI host, SD/MMC host, etc.), as long as the ben gets to dictate the timing.
<kyak> wpwrak: all right. I'll have that in mind when thinking about possible uses of UBB for me
<wpwrak> kyak: also, fast synchronous protocols are better than asynchronous or slow synchronous, because you need to wait a minimum (slow sync) or even exact (async) amount of time for those. for fast synchronous, you just set up the data bits, bang the clock, and you're done.
<wpwrak> kyak: luckily, spi master (and all its derivatives) is one of the fast synchronous ones :)
<kyak> hmm, okay, so the less is the delay between data bits, the better. The best case is no delay between them? :)
<wpwrak> kyak: the best is if the minimum delay = the maximum frequency is larger than what the ben can output when bit-banging. that way, you never have to worry about going "too fast"
<wpwrak> kyak: in practice, the frequency will also be limited by characteristics of your transmission line. e.g., if you have a long cable, you'll need to slow down a little. but that's all doable with a few short delay loops. no rocket science.
<kyak> ok, i understand. Need to try it on practice :)
<wpwrak> kyak: what's bad are low bounds for maximum delays. if they're short, you can also just loop a few times and hope no interrupt interferes. (i do this when programming my c8051f326 chips. programming thus fails every now and then, but it's not really worth the trouble to fix it. failures are reported reliably, and you can just retry)
<kristianpaul> tuxbrain_away: nice looking boards, i may order one but by UPS no sr.. (i can take risk for postal mail)
<kristianpaul> one pack* or whatever mimimal quatity
<kristianpaul> UBB + CPLD.. UBB + RFM12B.. UBB + :-)
<wpwrak> ups is 43 EUR to argentina. that's a bit less than USD 60. created a bit of phantom pain in my wallet, but i've had worse
<kyak> wpwrak: thanks for this much of information! i really hope i will remember it, when i'll have to do something like this: )
<wpwrak> kyak: the irc log is your friend ;-)
<kristianpaul> (irc log) indeed
<kyak> yeah, irclogs is one of the most visited pages on qi by me :)
<wpwrak> kyak: we'll also have to write up all this stuff at some point in time. there are still a few loose ends, though. e.g., i need to complete the system-clock-provided-by-ben for avr programming (uart will need this), see if i can get my libbb to work, look at uio, and also put some firmer numbers on the power-up process
<kyak> wpwrak: at the moment, is there any driver/user mode tool that can help one work with UBB?
<kristianpaul> kyak: i think some  libs in the werner misc can help..
<kristianpaul> or just try poke
<kristianpaul> or blinkelights code
<kyak> so it can control CPU pins?
<wpwrak> kyak: well, depends on what you want to do. i already use the 8:10 card interface at many places (blinkenlights,  avrdude/uart, avrdude/atusb-pgm, f326, atben). the i/o is open-coded, though.
<wpwrak> kyak: then there's the rmf12 (sp?) module and tuxbrain has some blinkenlights, too
<kyak> oh, that blinkenlights can be used to light up the keyboard :)
<wpwrak> kristianpaul: the lib isn't tested yet. it needs a kernel >= .36 (i know for sure that it doesn't work with kernels < .36, so some negative testing has been done ;-)
<kristianpaul> wpwrak: oh ok
<wpwrak> kristianpaul: and yes, poke works, too ;-)
<kristianpaul> kyak: i dunno if the gpio linux module can be ported for UBB
<kristianpaul> I read about that once..
<kristianpaul> hey, now tuxbrain_away can sell accesories for UBB like the missing SPI to Ethernet board ;)
<wpwrak> kristianpaul: such a board would even make sense. the ribbon cable on UBB is flexible and not too "heavy". so there's less risk of accidently ripping it out or mechanically breaking something.
<wpwrak> kristianpaul: alas, since UBB doesn't really get locked inside the ben, it can be pulled out by accident. but i guess we just have to live with this. there's a little mechanism in the 8:10 card holder that supposedly holds the card, but it doesn't seem to work too well. okay, maybe it's also that my ubbs have a slightly incorrect form, due to machining tolerances. tuxbrain's should be more precise.
<kristianpaul> I like this one http://ur1.ca/3dpu2
<kristianpaul> linux module is already made for that
<kristianpaul> But is not copyleft..
<kristianpaul> I can be home made.. but no, i need focus on gps-sdr thing for now
<wpwrak> kristianpaul: you can probably even make it smaller ;-)
<kristianpaul> wpwrak: yup i want, and learn kicad in the mean time
<methril_work> kristianpaul, you cant, the connector is as big as this
<wpwrak> methril_work: there's still a lot of pcb space behind the connector :)
<wpwrak> methril_work: also, big 100 mil headers are lame :)
<methril_work> i don`t like the headers too
<methril_work> wpwrak, but it`s not going to be sooo small
<wpwrak> methril_work: the chip exists in a 28qfn package, which is more compact than the ssop. so if you place a ribbon cable landing zone on the top, get rig of the header, and put all the electronics on the bottom, you should be able to make the whole thing a bit smaller
<wpwrak> methril_work: every micron counts ;-)
<methril_work> wpwrak, ;)
<kristianpaul> hmm, qfn seems to the best choice for DIY tiny stuff
<wpwrak> aye. qfn that doesn't depend on the center pad to be reliably soldered.
<kristianpaul> Now i wonder if xilinx sells fpga in that package. let see
<wpwrak> they should have a few small cplds
<kristianpaul> i guess at least
<wpwrak> kristianpaul: that doesn't really look like qfn ... do you have a package drawing somewhere ?
<kristianpaul> let me find
<kristianpaul> he, i just looked for qfn on their shop
<kristianpaul> yeah, seems more dfn
<tuxbrain_away> wpwrak: I have just tested in a brand new NN a knifed border clean UBB and I thing it offers enough resistance to avoid accidental disconections, of course is not thihgt looked and surelly abuse will end with that resistance, so I might says yes mine board are better than yours :P
<wpwrak> tuxbrain_away: great ! i was hoping that ;-)
<wpwrak> tuxbrain_away: i think the nominal dimensions of my 8:10 card design are quite accurate (the scan i derived them from should have given me something like 10 um accuracy)
<wpwrak> tuxbrain_away: and a "real" 8:10 card should lock a little. i also modified some of my UBB to lock a little better. so the more accurate industrially made UBB ought to be better at locking, too. nice to see that this worked !
<tuxbrain_away> I must say that NN locking mechanism is a little shitty, my olds NN (the non charging and my uart soldered, are now totally non locking anithing, and the new one as I said offer some resistance but moving a little side to side and appling a non very heavy pull and it also out.
<tuxbrain_away> but for example in my movile phone is guest tied as glue
<viric> locking?
<tuxbrain_away> guest->get
<tuxbrain_away> of the 8:10 cards
<viric> Do you mean that... "ballen"?
<tuxbrain_away> viric: ballen? me refiero al cierre (el pequeño click) que hace las uSD para asegurar la tarjeta, en el NN pues es un poco ... debil
<viric> hm
<tuxbrain_away> en otros dispositivos es mucho mas fuerte y seguro
<viric> aquella molla?  no sé com va.
<viric> no sabia que hagués de quedar trabada.
<kristianpaul> hagues?
<viric> tuviese
<tuxbrain_away> exacte  la molleta :), si en pricipi es la seva funcio pero clar , standard 8:10 cards doen't expose too much out to be a real thread , you have to had long nails or some toll to force to pull it out locked. but with UBB and the other 8:10 we will have thing getting out of the 8:10 bay so is more easy to try to pull it out even if locked
<tuxbrain_away> kristianpaul: catalan lenguage :)
<wpwrak> tuxbrain_away: (lock in ben) wolfgang once mentioned that he wasn't happy with the quality of the 8:10 card receptacle
<viric> as I understod there are no 3d cad drawings for the NN
<tuxbrain_away> wpwrak: I just agree with his appreciation
<wpwrak> viric: my stuff is still in the same state as a few months ago. still have to combine the meshes i already have, and scan a few more items
<viric> I mean *reference* drawings
<wpwrak> if there were, my scans wouldn't have made much sense :)
<tuxbrain_away> wow, my nokia phone makes me sweet to pull it out locked.. for Ya I would like to have this 8:10 bay
<wpwrak> kristianpaul: pity. well, you don't want to hand-solder a very large qfn anyway
<kristianpaul> wpwrak: yeah, i pass
<viric> wpwrak: but how does someone manufacture new cases? Qi simply owns the molds?
<tuxbrain_away> kristianpaul: I will send you a proforma over the weekend for 10 UBB+postal shipping.
<kristianpaul> tuxbrain_away: thanks :-)
<wpwrak> viric: wolfgang asks the company that makes the bens for him to make more. think they produce the complete ben, not just parts
<viric> and they don't have the drawings?
<tuxbrain_away> viric: I confirm wpwrak words
<tuxbrain_away> viric: I think the have jus buy the case to someone els
<tuxbrain_away> I think they just buy the case to someone else
<viric> this means 'unreachable drawings'?
<kristianpaul> bingo :_)
<tuxbrain_away> I think wolfgang has tried hard , so yes
<tuxbrain_away> the only chance is trhoug wpwrak scanings
<viric> hm ok
<kristianpaul> or some molding reverse eng tecnique
<kristianpaul> if exists**
<viric> I didn't know wpwrak scanned *that much* already :)
<wpwrak> the proper process would probably be to make a design from scratch, and use the scans for dimensions to "see if things fit" in the cad system
<tuxbrain_away> kristianpaul: well paleontologist do that all the time isn't ? _P
<viric> wpwrak: I agree.
<viric> I'm trying to package freecad to nios
<viric> nixos
<wpwrak> that's basically how i made the counterweight. afterwards, i made the mold with the data, cast two pieces with wax, checked the dimensions and made some small corrections (there's always something you overlook), then proceeded to lead
<viric> ok
<viric> wpwrak: we got some improvements in the 3D scanner. Maybe I could try to scan some ben piece...
<viric> although it's meant to scan smaller pieces than the ben
<viric> wpwrak: what is the precision of your scanner? (I know only the resolution)
<wpwrak> i don't know exactly. i would think in the range of the resolution
<viric> :)
<viric> what scanner is it?
<viric> maybe the manufacturer claims some precision
<viric> (which may be not the best source to trust)
<wpwrak> it's a roland "modela" mdx-15
<wpwrak> (mill/scanner)
<viric> precision until "0,02mm" I read
<tuxbrain_away> Is a pain! I will recieve the ribon cables this night, my blood is claim for hot tin and flux smell but I have tons of other work to do! aaargh I wish I have employess to order do that booring stuff aargh!, I must keep that UBB out of my sight until the weekend
<viric> that's quite good
<wpwrak> tuxbrain_away: seems that you need a lot more coffee ;-)
<methril_work> thinks that tuxbrain_away miss me ;)
<tuxbrain_away> wpwrak: no I need a cloning machine... but I guess will end on a angry discussion on who of my me(s) will grab the iron
<tuxbrain_away> methril_work: no man, if you where here you sure will solder five meanwhile my me(s) were fighting
<tuxbrain_away> btw methril_work we must talk I have news to talk about
<methril_work> tuxbrain_away, nice!!
<methril_work> tuxbrain_away, i`m at work now
<wpwrak> tuxbrain_away: the tuxbrain clone wars :)
<tuxbrain_away> jane shoud do an Ascii comic about that
<methril_work> tuxbrain_away, i`ll catch you in 2/3 hours heere?
<viric> wpwrak: how do you earn money, if I may ask? :)
<viric> wpwrak: you look like a 100% for-qi worker :)
<tuxbrain_away> methril_work: yes I will wait for you unitl 3AM if needed today
<viric> Do you have a 'mecenas'?
<methril_work> tuxbrain_away, i`ll try to arrive earlier
<tuxbrain_away> going for the ribbon cable return in 10 mins
<wpwrak> viric: i have dwindling savings :)
<viric> aah :)
<viric> you really look like enjoying your days :)
<wpwrak> viric: oh yes, i am ;-) alas, the problem of earning money will become acute before very long :-(
<viric> before very long?
<wpwrak> i should get some regular income around mid-year. so this means that i shouldn't delay looking for something much more than a month from now
<kristianpaul> wpwrak: what is you regular income ? i mean work
<kristianpaul> lecture profesor, linux developer, paid developer..
<kristianpaul> Well i guess you dont work in argentina...
<tuxbrain_away> wpwrak: I can also confirm that the ribon cable fits like a glove with terminations..... can you hear that?.... is my soul aging for feel the heat of the iron :(
<wpwrak> tuxbrain_away: (terminations) i expected nothing less ;-)
<wpwrak> kristianpaul: linux kernel developer/consultant. yes, teleworking
<larsc> wpwrak: can you recommend any software to convert the ubb gerber files to gcode?
<larsc> or the kicad brd file
<kristianpaul> heekscad?
<wpwrak> larsc: hmm, isn't gerber more or less equivalent to gcode ?
<wpwrak> larsc: kicad can also output dxf, in case this helps
<wpwrak> larsc: if you're thinking of making your own, it's probably much more efficient to get a few from tuxbrain, either directly or via dvdk
<larsc> well, i'm sitting right next to a cnc mill
<larsc> dxf should work
<larsc> thanks
<roh> larsc: check the metalab wiki
<roh> there are some utils linked they use for outline milling (pcbs)
<wpwrak> larsc: the milling is fun. it's the etching that takes time :) well, if you have one that can also mill the traces, you could do that. but then be careful about the stuff between the traces inside the receptacle. if there's copper, it may short pins
<tuxbrain_away> larsc:  I you succesfull finish doing one, please add to the wiki pics and so an publish it any place, the much noise we make with that the better :)