<stefan_schmidt>
wpwrak: I bet its some function that contains random() and hours modulo
<stefan_schmidt>
wpwrak: anyway, hacking on the atusb driver now
<stefan_schmidt>
added correct printout for 231 (id 3) and ignoring interface 1 so far
<stefan_schmidt>
without ignoring the interface or driver gets probed two times. One for each interface. And if I get it correctly 1 is only for DFU?
<stefan_schmidt>
at least ignoring it does no harm as I can still talk to the chip
<wpwrak>
stefan_schmidt: heh, cool. how do you structure it ?
<stefan_schmidt>
wpwrak: well, strcuture...., well the branch is called atusb-bastard :)
<wpwrak>
;-))
<stefan_schmidt>
but maybe I should not do it to dirty
<wpwrak>
is it an spi host, a fork of at86rf230.c, ... ?
<stefan_schmidt>
I wonder how much my work will clash with the work from Richard
<stefan_schmidt>
wpwrak: I was thinking about getting all usefull logic/function from at86rf230.c and gluing usb logic to it
<wpwrak>
yeah, if you get anything to work, you should sync with him
<stefan_schmidt>
but on the other hand I want to use it long term
<stefan_schmidt>
he is in charge for the usb part and you for the transport split?
<wpwrak>
well, i changed my plan a little: no big transport split but just make it an SPI host
<stefan_schmidt>
hmm
<wpwrak>
a very specialized one ;-)
<stefan_schmidt>
wpwrak: --verbose?
<wpwrak>
it can figure out what to do by looking at the structure of the requests
<wpwrak>
did yuo see that i added three new requests, ATUSB_SPI_WRITE, ATUSB_SPI_READ1, and ATUSB_SPI_READ1 ?
<stefan_schmidt>
wpwrak: ive seen your commits but could not make out much of it
<wpwrak>
they map to register read/write, frame buffer read/write, and - in case we use it - SRAM read/write
<stefan_schmidt>
it seemed the interrupt work is done
<stefan_schmidt>
ok, mapping calls sounds easy
<wpwrak>
the interrupt work is a bit trouble
<stefan_schmidt>
so we just have some functions abstracting real spi and usb-spi?
<wpwrak>
i haven't figured out how to efficiently synchronize control transfers and interrupts
<wpwrak>
atusb could just be an SPI driver that knows a few magic tricks
<wpwrak>
if you send it requests it doesn't understand, it would just complain
<stefan_schmidt>
hmm
<stefan_schmidt>
thinks about it
<wpwrak>
what worries me is the interrupt synchronization
<stefan_schmidt>
it shuffles the work away from the transport split to writing a spi driver
<stefan_schmidt>
how are interrupts handled over USB anyway in the kernel?
<wpwrak>
if the interrupt synchronization can't be hidden cleanly and reasonably efficiently in the SPI driver layer, the whole SPI host idea may not fly after all
<wpwrak>
i think you just enqueue an URB and get it when it has been served. but i don't think there are sequence guaranteed
<wpwrak>
s/guaranteed/guarantees/
<wpwrak>
but .. i'm not an expert of the USB subsystem
<stefan_schmidt>
I haven't seen much that we could use for int from the spi framework
<wpwrak>
there may also be a problem with the firmware using edge-triggered interrupts. not sure if the avt re-arms them when entering or when leaving the ISR. in the latter case, we may lose interrupts. but that can be fixed.
<wpwrak>
(int) you have to create a "fake" interrupt, then pass its number to at86rf230.c
<stefan_schmidt>
wpwrak: but the drivers gets the interrupt from the platform data and not from spi?!
<wpwrak>
the spi driver picks it up from the platform data and then passes it on. so you can fake all that :)
<stefan_schmidt>
what I like about the transport split is that it is straight forward to implement (int aside)
<stefan_schmidt>
what I like about the spi way is that it abstracts it nicely and we don't have to touch the main driver
<stefan_schmidt>
(spi) ah, thats possible to hook in there then
<wpwrak>
yeah, and we want the spi split for atben, too. spi_gpio must be pretty slow.
<wpwrak>
also, the transport split is easy at the top (the transfer functions) but gets messy at the bottom (driver registration, removal, etc.)
<stefan_schmidt>
I actually would expect some more bottlenecks on the way from the chip to the flash :)
<stefan_schmidt>
wpwrak: so how would we best work together on this? (Also including Richard of course)
<wpwrak>
(chip to flash) flash ?
<wpwrak>
you should let richard know that you're hacking on it, so that he can sync with you when he has time (or if he's done anything already, update you)
<stefan_schmidt>
(bottleneck) I meant the whole system performance from getting data from atben to the actual nand flash for storage. Nor sure if spi_gpio is the bottleneck there
<wpwrak>
regarding the overall architecture, i'm not quite sure yet what to do about the interrupt problem. several approaches come to mind. all of them suck in one way or another:
<stefan_schmidt>
letting him know as in sending patches to the ml?
<wpwrak>
1) stop handling control transfers while there's a pending interrupt. that would require the user of atusb to have an asynchronous bulk/interrupt read pending all the time, or it'll hang. okay the kernel, messy for user space.
<wpwrak>
(letting know) more polite to warn him before sending patches :)
<stefan_schmidt>
I will put the politeness in the cover letter :P I'm fine with the patches getting thrown away if he has somehting better already
<stefan_schmidt>
Just want to get started with it
<wpwrak>
2) keep the current approach but make some means to explicitly sync after register accesses where we actually care about the interrupt situation. that would be the ones that need the interrupt/worker synchronization ritual.
<wpwrak>
3) convert everything to use bulk transfers, so that all the data flows in the same stream.
<wpwrak>
suckiness of 1): would either complicate user space or require a sync/async mode switch. also, not sure if blocking control transfers is such a nice idea.
<wpwrak>
suckiness of 2): at86rf230.c needs to know about this
<stefan_schmidt>
I would avoid making user space more complicated. Its the kernel job to make it easy (INHO)
<wpwrak>
suckiness of 3): parsing of messages in a stream is harder than just getting handed a nice message in the form of a control transfer.
<wpwrak>
(user space) i mean the user space only tools. they don't use the kernel code.
<stefan_schmidt>
ah, the tools/ section
<wpwrak>
yup
<stefan_schmidt>
not much of an opinion here. They all have benefits...
<wpwrak>
right now i use a bulk EP, not an interrupt EP, but it seems they're very similar
<stefan_schmidt>
I have some more days working on this. So it would make sense to pput our effort together instead of me going off in one direction due to time pressure
<wpwrak>
will be easier to change once i've split the firmware build into boot and app usb stack
<stefan_schmidt>
given that you know hardware, firmware and drivers the architecture decision should be in your hands
<stefan_schmidt>
I'm happy to help coding it though
<wpwrak>
yeah. i need to read a bit more about usb. see if there are any useful hints about the interrupt model
<stefan_schmidt>
3:30 am here. I think I call it a day.
<stefan_schmidt>
Will send my small mini patches to the list and Richard to let him know what I'm doing
<wpwrak>
the at86rf230/1 is a bit nasty when it comes to interrupt synchronization, due to the shared interrupt bit and the shared buffer, but it's still not *that* outlandish
<stefan_schmidt>
So he can decide what to do with it
<stefan_schmidt>
oh, its one frame buffer for both tx and rx?
<wpwrak>
alright. i think for now, i don't have any clear recommendation about what to do.
<wpwrak>
yup
<stefan_schmidt>
oh, the cc2420 has one for each direction
<wpwrak>
must have saved a lot of precious gates :-(
<wpwrak>
i know ...
<stefan_schmidt>
but no re-submit in hardware
<wpwrak>
seems that someone at atmel really liked the old 3c501
<stefan_schmidt>
heh
<stefan_schmidt>
(recommendation) seems so :P
<stefan_schmidt>
I will be back here tomorrow to discuss this further. Or ml both fine with me.
<wpwrak>
alright. meanwhile, i'll ponder the interrupt situation a bit more.
<stefan_schmidt>
great
<wpwrak>
hmm. one aproach may be to not read the interrupt status and just send a zero byte instead of the status. that may get rid of some trouble.
<wpwrak>
the interrupt may still be late/weird, but at least IRQ_STATUS would be correct
<stefan_schmidt>
wpwrak: mails are out. Hopefully polite enough. :)
<stefan_schmidt>
time to move my body into the bed
<stefan_schmidt>
night all
<qwebirc62324>
A question... stupid question..  Is the USB port on the NN fully functional?
<rjeffries>
Nanonote USB is a device port, not host
<qwebirc62324>
What does that mean?
<qwebirc62324>
"Devices" as in like flash drives... or..?
<rjeffries>
good analogy. Nanonote can NOT attach to e.g. USB drives, or a USB WiFi stick, ora USB Flash drive. it has the same type of connection as those other devices
<qwebirc62324>
So, what could the USB port be used for?
<qwebirc62324>
I don't claim to be an expert.
<rjeffries>
it can be used with Linux Ethergadter s/w to provide a connection to a Linux PC, and thence to the internet
<qwebirc62324>
Ok. I knew that.. but wasn't sure if it could actually do more.
<qwebirc62324>
Thanks.
<kristianpaul>
oh, cool, deaddrops.com for the offline lovers :-)
<kristianpaul>
wpwrak: about sige, i think i was confuse because i forgot this chip  (SE4162) have complex output, not real ! as before ones and others IC's like the one from maxin
<kristianpaul>
he, i was doubing but namuru core implement tracking for I and Q already ;-)
<kristianpaul>
so.. from a sample at least i should implement two correlators
<wpwrak>
(buddha) nice plastic. how do you make vertical walls with bumps ?
<wpwrak>
ah, the bumbs are wheels. no bumps in the plastic then.
<wpwrak>
pity that the battery cover isn't shown fully. i'm rather curious whether is has any parts that fold back on itself. that's a problem i'be been trying to solve for about a year or so - how to make a battery cover if all you have is a mill with 3 degrees of freedom (for making the part or a mold)
<dvdk>
hmm, cannot push after xiangfu's renaming of the branch
<dvdk>
git push origin master
<dvdk>
-> To prevent you from losing history, non-fast-forward updates were rejected
<dvdk>
git pull --rebase origin master
<dvdk>
-> Current branch trunk is up to date.
<dvdk>
any ideas?
<wolfspraul>
ouch, and xiangfu is MIA today...
<kyak>
dvdk: we just rebased yesterday
<dvdk>
i could just try a 'git pull' but that's going to mess with the logs?
<dvdk>
how can i retrieve a diff for the stuff already committed?
<kyak>
so you need to git reset --hard origin/master (save your commits first)
<dvdk>
sve cmomits how?
<kyak>
save commits via git format-patch
<kyak>
save uncommited via git stash
<dvdk>
shows empty
<kyak>
do you have commits to save?
<dvdk>
i already committed, just didn't push
<dvdk>
yup
<dvdk>
just a diff against remote head. Â
<dvdk>
how?
<kyak>
i just checked, git format-patch -n should work
<dvdk>
doesn't do anything
<dvdk>
git log --branches shows my commit
<dvdk>
now i just need to extract it
<kyak>
how do you do it? (format-patch)
<dvdk>
format-patch -n
<kyak>
huh?
<kyak>
you should at leasst supply a range
<dvdk>
you mean two revs
<kyak>
yes
<kyak>
you could also use a log with -p
<kyak>
and reapply your patches after reset
<dvdk>
git log -p --branches does the job
<kyak>
great
<dvdk>
extremely large file (>50MB) going to cut out my changes
<kyak>
something is wrong
<kyak>
the patch should be small, only contain your changes
<dvdk>
git log -p --branches is a full log of not only my changes
<dvdk>
btw i still cannot push
<dvdk>
error: failed to push some refs to 'git@projects.qi-hardware.com:openwrt-xburst.git'
<dvdk>
do i need to run 'git pull' ?
<kyak>
you need to: 1) save your changes, this way or another
<jow_laptop>
kyak, dvdk: I added gfortran and the sjlj option
<wpwrak>
stefan_schmidt: (postman) you should be ahppy you heard him ;-)
<kyak>
jow_laptop: hey, cool! seems we can drop at least two of our patches
<kyak>
thanks!
<stefan_schmidt>
wpwrak: only packages for my gf :)
<stefan_schmidt>
wpwrak: I'm moving my patches over to qi-kernel now and should have a new set with maybe some mor epatches later today
<wpwrak>
larsc: okay to give stefan commit access for qi-kernel, so that he can work on the ben-wpan branch ?
<stefan_schmidt>
wpwrak: the IRQ race is tough when we are just trying to pass it from spi to usb I fear
<kyak>
jow_laptop: btw, i've managed to make Ctrl+r (reverse-search) work somehow in busybox's ash, here is the first draft: http://downloads.qi-hardware.com/people/kyak/tmp/busybox.patch . I'll try to polish it and make it configurable. Let's see if it get's accepted then by busybox upstream :)
<stefan_schmidt>
but emulating two irqs and two frame buffer is problematic as well. To much logic in the firmware
<dvdk>
jow_laptop: cool
<wpwrak>
stefan_schmidt: yeah, i wouldn't go as far a trying to emulate something wildly different
<stefan_schmidt>
wpwrak: ok, firmware is your part :D
<dvdk>
about the mtd-utils problem (missing ubiattach)
<dvdk>
just did feeds/install mtd-utils
<dvdk>
but looking at the makefiles i don't find any utilities that were split out
<stefan_schmidt>
wpwrak: I'm going to plug in the driver into the ieee802154 driver layer
<dvdk>
is the build-server using a different feeds.conf?  because the one that is in nanonote-files does source an old version of mtd-utils without the splitting of tools
<wpwrak>
stefan_schmidt: alright. that gives you the maximum flexibility
<kyak>
dvdk: grep mtd-utils .config
<kyak>
dvdk: and you'll see all of them :)
<dvdk>
not here
<dvdk>
CONFIG_PACKAGE_mtd-utils=m
<kyak>
ah
<kyak>
of course, you need to enable it
<dvdk>
enabled it no more options here
<kyak>
to see the submenu items
<dvdk>
my feeds.conf: src-svn packages svn://svn.openwrt.org/openwrt/packages@25513
<dvdk>
@25513 is the problem?
<kyak>
probably
<stefan_schmidt>
wpwrak: and it keeps the userspace API over sockets my other code bases on :)
<dvdk>
but where does the build server take his feeds.conf?  im using the one from nanonote-files
<kyak>
dvdk: why are you even pinning the revision, if you are playing with trunk?
<kyak>
we are all on master now, there is no trunk
<dvdk>
ah, well
<kyak>
backfire is done :)
<dvdk>
but there must still be a deterministic, pinned feeds.conf, no?
<kyak>
in nanonote-files?
<dvdk>
yes
<kyak>
so yes
<dvdk>
used by the build server, so that build results do not change over time
<dvdk>
(without _us_ hacking anything)
<kyak>
huh?
<kyak>
this is the purpose of build server
<kyak>
to build the latest
<kyak>
not to build the same
<dvdk>
i mean, if we don't change our git repos, then build shouldn't have different results
<dvdk>
i thought the latest of _our_ stuff, not uncontrollable (and not easily patchable) openwrt upstream
<kyak>
there is always latest feeds on build server. After the images is built, which is considered to be a release, then feeds can be pinned to reproduce it
<kyak>
mtd-utils is a submenu in which mtd-utils-* reside, not the real package. During build it is set to =y (even if mtd-utils-* are =m), so such dependency doesn't appear
<kyak>
this is a completely legal case to use --force-depends :)
<dvdk>
doesn't want to know any more details :)
<jow_laptop>
meh, there's a dependecy on a not existing mtd-utils ?
<dvdk>
jow_laptop: looks like it, don't like it, too
<dvdk>
kyak: btw our libfreetype seems to do subpixel aliasing, ASE fonts look a little nicer now
<stefan_schmidt>
6: wpan0: <BROADCAST,NOARP> mtu 127 qdisc noop state DOWN qlen 10
<stefan_schmidt>
    link/ieee802.15.4 de:ad:be:af:ca:fe:ba:be brd ff:ff:ff:ff:ff:ff:ff:ff
<stefan_schmidt>
wpwrak: ^^ ieee802154 registration is working
<stefan_schmidt>
only stub functions so far
<xMff>
hail the caffeebabe ;)
<stefan_schmidt>
wpwrak: Next is a small xmit function following the atrf-rxtx style
<wpwrak>
stefan_schmidt: nice ! :)
<wpwrak>
xMff: bee2 bee2 ! ;-)
<mstevens>
can one get these atusb things with a case on?
<wpwrak>
mstevens: for now, you have to get the case on :)
<qi-bot>
[commit] jow: [toolchain] introduce option to enable setjump()/longjump() based C++ exceptions (#9185, patch from David Kuehling via Qi hardware) http://qi-hw.com/p/openwrt-xburst/814de68
<wpwrak>
stefan_schmidt: now we have a deadline - friday evening, us west cost time ;-)
<wpwrak>
mstevens: tuxbrain has ben experimenting with using sugru as a cover, but the results are inconclusive this far
<mstevens>
interesting
<stefan_schmidt>
wpwrak: Where does the deadline come from?
<wpwrak>
stefan_schmidt: richard powering up friday evening ;-)
<stefan_schmidt>
wpwrak: heh
<RichardSharpe>
Hey stefan_schmidt ...
<stefan_schmidt>
hi RichardSharpe
<stefan_schmidt>
wpwrak: atrf_reg_write(dsc, REG_PHY_CC_CCA, (1 << CCA_MODE_SHIFT) | channel) is all I need to set the channel?
<stefan_schmidt>
RichardSharpe: The driver is plugged into the ieee802154 layer now. We can see it in ip and set and address, etc
<qi-bot>
[commit] Werner Almesberger: atusb/fw/board_app.c: do not read and accumulate IRQs; flash LED when EP1 busy http://qi-hw.com/p/ben-wpan/23c5922
<qi-bot>
[commit] Werner Almesberger: tools/lib/atusb-common.c: updated for new interrupt handling in firmware http://qi-hw.com/p/ben-wpan/8a2d80a
<qi-bot>
[commit] Werner Almesberger: tools/lib/misctxrx.c (wait_for_interrupt): enforce a minimum timeout of 10 ms http://qi-hw.com/p/ben-wpan/d8363d8
<qi-bot>
[commit] Werner Almesberger: tools/atrf-xmit/atrf-xmit.c: cleaned up timeouts and interrupt polling http://qi-hw.com/p/ben-wpan/7c12bf0
<wpwrak>
hi RichardSharpe !
<wpwrak>
stefan_schmidt: yes, and wait a little for the PLL to lock again
<wpwrak>
(commits) new interrupt mechanism, new luck ;-)
<stefan_schmidt>
wpwrak: for basic xmit should I look into atrf xmit or atrf-txrx?
<wpwrak>
stefan_schmidt: atrf-txrx. atrf-xmit is a little weird :)
<stefan_schmidt>
wpwrak: oki
<stefan_schmidt>
but tx has to wait now. Need to do something else first.
<stefan_schmidt>
Will send out the patches I have until now
<RichardSharpe>
stefan_schmidt: THanks & will look at this tomorrow etc ...
<wpwrak>
stefan_schmidt: hmm, maybe just queue them up in the ben-wpan branch for now
<stefan_schmidt>
RichardSharpe: sure. The first one will need a SOB from you anyway. Its your driver skeleton and I set you as author but can 't sign off for you :)
<stefan_schmidt>
wpwrak: should I have access?
<wpwrak>
larsc: okay to add stefan_schmidt as a committer for qi-kernel ?
<wpwrak>
stefan_schmidt: so far, only locally :)
<wpwrak>
stefan_schmidt: btw, what's you user name on projects.qi-hardware.com ?
<stefan_schmidt>
wpwrak: that I have already done :)
<stefan_schmidt>
wpwrak: not sure I have a user there :P
<stefan_schmidt>
creating one...
<stefan_schmidt>
should be stefan
<stefan_schmidt>
wpwrak: done, user is stefan
<wpwrak>
RichardSharpe, stefan_schmidt: i've added you both to ben-wpan, in case you need to commit anything there
<stefan_schmidt>
wpwrak: I guess I have to upload my ssh key there?
<wpwrak>
stefan_schmidt: to commit, you'll a ... yes :)
<wpwrak>
stefan_schmidt: clock on your name (afyer Welcome), then on "update your account"
<stefan_schmidt>
wpwrak: I will push it into my patches into a ben-wpan-stefan branch to review before merge into the main branch
<wpwrak>
stefan_schmidt: sounds good
<stefan_schmidt>
wpwrak: hmm, does the ssh uri is different from the normal one? besides git@...
<stefan_schmidt>
wpwrak: what do you have in your .git/config for origin?
<stefan_schmidt>
Repository write access denied.
<stefan_schmidt>
fatal: The remote end hung up unexpectedly
<bartbes>
I didn't mean complex numbers, I meant complicated math, bit of a language fail on my part ;)
<kristianpaul>
octave is not  CAS, so for octave you need to put stuff in some particular way
<kristianpaul>
but seems mathomatic is for that
<whitequark>
wpwrak: kind of. sadly it won't include qi hardware things, through :/
<bartbes>
have you guys heard of termbox?
<whitequark>
bartbes: the library?
<bartbes>
yeah
<bartbes>
I guess that's a yes ;)
<bartbes>
I was wondering whether it had been ported
<qi-bot>
[commit] jow: [package] hotplug2: make libbsd depend on "not uclibc" for now, the conditional depdendency handling needs fixes http://qi-hw.com/p/openwrt-xburst/b6b061e
<xMff>
kyak: maybe rebase again, I jsut committed an important fix to the depdency handling
<kyak>
ok, since i'm already making noise here :)
<qi-bot>
[commit] jow: [scripts] metadata.pl: fix handling of multiple conditional depends that reference the same package (exposed by previous hotplug2 changes), also kill duplicate dependency specs while we're at it http://qi-hw.com/p/openwrt-xburst/8d14610