<kristianpaul> damn, i forgot that libc.c dont have float support for printf :-| !!!
<wpwrak> kristianpaul: you mean libbase ? :)
<kristianpaul> yes
<qi-bot> [commit] Werner Almesberger: m1/perf/sched.c: overlook compiler warnings at your own peril, grrr ... (master) http://qi-hw.com/p/wernermisc/a0abd4e
<qi-bot> [commit] Stefan Schmidt: ieee802154/at86rf230.h: Fix register names for RX_AACK_ON and TX_ARET_ON (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/43adc11
<qi-bot> [commit] Stefan Schmidt: ieee802154/at86rf230.c: Prepare driver for auto ACK support (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/d8f39e8
<stefan_schmidt> wpwrak: ping
<wpwrak> pong
<stefan_schmidt> wpwrak: I have an interesting problem iwth atusb here :)
<wpwrak> ah ? :)
<stefan_schmidt> wpwrak: I'm implementing auto ack and automatic retransmit right now
<stefan_schmidt> wpwrak: uto ack works fine already but the sending in TX_ARET mode is failing
<stefan_schmidt> wpwrak: and it seems its because no slp_tr pin is available on atusb...
<stefan_schmidt> wpwrak: From what I see it is not needed in normal tx mode but in tx_aret it is :/
<wpwrak> is it needed ?
<wpwrak> and you mean in the driver, not the hardware, correct ?
<stefan_schmidt> as in the driver yes
<stefan_schmidt> from what I found you need to toogle it shortly to 1 and back to 0 to actually start the transmitting of the frame out of the buffer
<wpwrak> that's one way to start it, yes
<wpwrak> but you should still be able to just send a command, as in basic mode
<stefan_schmidt> hmm, from what I understand I can't do this in extended mode
<wpwrak> what makes you think you can't ?
<wpwrak> page 48 has it, much like on page 33 :)
<stefan_schmidt> the contiki driver code. And my filing tests :)
<stefan_schmidt> but let me check again
<stefan_schmidt> maybe contiki uses the slp_tr approach always
<wpwrak> i wouldn't be surprised if contiki did this. in general, it should be more efficient.
<stefan_schmidt> so one either uses slp_tr _or_ send writes TX_START into TRX_STATE?
<wpwrak> but things should still work even without SLP_TR
<wpwrak> yes
<stefan_schmidt> hmm
<wpwrak> lemme push my unfinished new atusb driver ...
<qi-bot> [commit] Werner Almesberger: atusb driver for extended mode (untested and unfinished ) (ben-wpan) http://qi-hw.com/p/qi-kernel/815a0e3
<stefan_schmidt> wpwrak: maybe I'm just to tired right now but where is the TX_START done in the at86rf231 driver? I can only see the slp_tr magic in xmit
<wpwrak> rc = at86rf230_write_subreg(lp, SR_TRX_CMD, STATE_BUSY_TX)
<wpwrak> right after the slp_tr ;-)
<stefan_schmidt> wpwrak: but BUSY_TX != TX_START??
<stefan_schmidt> seems I'm running one-way street here since an hour :)
<wpwrak> check tables 7-3 and 7-4 :) (pages 45 and 46)
<wpwrak> running down one-way streets can still get you closer to your destination. it's the dead-ends you have to avoid ;-)
<stefan_schmidt> wpwrak: it actually looks like a bug to me that works by accident. Lets see:
<stefan_schmidt> STATE_BUSY_TX gets written into SR_TRX_CMD while it is an _state_ and not an command!!
<stefan_schmidt> and by accident it is also 0x02...
<wpwrak> ;-)) naw, that's intentional
<wpwrak> state and command numbers are almost always the same
<wpwrak> they did have some bugs in cases where they aren't, though
<stefan_schmidt> But TX_ARET_ON is 0x19...
<stefan_schmidt> hmm
<stefan_schmidt> same state and command
<stefan_schmidt> stops for a moment to read it all carefully
<stefan_schmidt> ok, so the problem is I write BUSY_TX_ARET there which is 0x12 and has no corresponding command
<stefan_schmidt> and page 48 shows TX_START as way to come from TX_ARET_ON to BUSY_TX_ARET
<stefan_schmidt> so command and state differ for TX_ARET here and with the logic above the state machine fails
<wpwrak> yes. if you keep the structure of a86rf230.c, you'd need an exception here
<stefan_schmidt> at leats I'm not completely blind :)
<wpwrak> i don't particularly like the way the driver constantly looks at the transceiver state. state changes are usually announced by an interrupt, too. or you can just wait a little.
<stefan_schmidt> well, I never said I like the driver. Just wanted to have another test with aack in my evaluation :)
<stefan_schmidt> wpwrak: still looking forward to your new driver and new firmware
<stefan_schmidt> wpwrak: actually after 20th october I should be able to help you with it again. (Deadline for diploma thesis)
<stefan_schmidt> wpwrak: btw, interested in the evaluation results on the IEEE 802.15.4 layer?
<wpwrak> yeah, i hope to get around to finishing it by then. got a bit sidetracked with M1 these days, sorry.
<wpwrak> sure :) particularly if they're good - or if you've found some 60 ns difference ;-)
<stefan_schmidt> wpwrak: no problem. I can do my evaluation this way. And I still have a lot to write so I son't know if I have time to test the new driver for the thesis
<stefan_schmidt> wpwrak: will prepare something and send it over tomorrow. Don't have it with me right now.
<stefan_schmidt> wpwrak: short version. _very_ stable and low packet loss even without aack but slow :)
<stefan_schmidt> wpwrak: interestingly we have some steps in the graphs for different payload lengths
<wpwrak> stable is good :) slow ... due to the USB delays, the over-the-air data rate, or perhaps protocol delays (which we generally don't implement anyway)
<wpwrak> (steps) around which kind of numbers ?
<stefan_schmidt> wpwrak: IIRC around 50 or 60 bytes. Can say for sure and show you the graphs tomorrow
<stefan_schmidt> wpwrak: I send 400 packet for each payload from 5 to 115 bytes (4 byte have been an internal header for the test)
<wpwrak> (50-60 bytes) ah, that's a little odd
<stefan_schmidt> and it is not as linear as I had expected. At least one step, maybe another, smaller, one later on
<wpwrak> hmm. interesting indeed :)
<stefan_schmidt> and max values for rtt can be way off while min is near by. That makes sense so. min is limited by hardware and max only by the linux scheduler :D
<wpwrak> yeah :)
<stefan_schmidt> muhahahaha
<stefan_schmidt> it was indeed only the state change here
<stefan_schmidt> using BUSY_TX aka 0x02 made it work for TX_ARET_ON as well :)
<wpwrak> ;-)) congratulations !
<stefan_schmidt> wpwrak: thanks for bring me back from the one-way street with slp_tr :)
<stefan_schmidt> wpwrak: thanks
<stefan_schmidt> wpwrak: btw, if you have your new driver and firmware ready for testing I might be able to sneak this into the thesis. At least if there is something until, say, 14th
<stefan_schmidt> wpwrak: if not that fine as well will test is after my thesis then
<wpwrak> (slp_tr) you're welcome :)
<wpwrak> (new driver) i'll see what i can do
<wpwrak> still have a number of other things in the pipeline, though ...
<stefan_schmidt> wpwrak: don't make any stress about it for me. I'm fine with what I have here and can evaluate it this way. Stable is more important then speed right now.
<wpwrak> no italian sports cars then ;-)
<stefan_schmidt> wpwrak: two of the atusb will stay with me after the thesis and finished studies anyway. Motivation enough to test the new driver or even help on it.
<stefan_schmidt> wpwrak: not for me. Actually since my last car broke down I share the car with my gf :)
<stefan_schmidt> wpwrak: have to wait until freelancing brings in enough for a Audi A6 now ;)
<wpwrak> ;-) subdued design then
<stefan_schmidt> wpwrak: you mean the audi or my gf's car?
<wpwrak> dunno what your gf drives :)
<wpwrak> well, or would drive if you hadn't taken possession of the car ;-)
<qi-bot> [commit] Stefan Schmidt: ieee802154/at86rf230: Add Automatic retransmit form the extended mode (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/54634de
<wpwrak> but what i mean is that most of the audis have an understated design. they often have strong engines but don't look very "sporty"
<stefan_schmidt> wpwrak: VW Polo
<stefan_schmidt> wpwrak: ah, yes. Friend of mine has an A4 as sport edition. Does more look like a family car but has enough power to have fun with it :)
<stefan_schmidt> wpwrak: and yes, I'm not to much into cars. And especially not into sport cars. If I had _to_ much money a porsche 911 would be ok thought ;)
<wpwrak> the pure sports cars are a bit inconvenient anyway. few places where you can fully enjoy them and hardly enough room for groceries, let alone anything bigger
<stefan_schmidt> wpwrak: and you feel every small bump from the street
<wpwrak> that's a feature, not a bug :)
<stefan_schmidt> yeah, like taking state instead of commands and screwing with my mind if no corresponding command is there :)
<wpwrak> that driver has indeed some peculiarities :)
<wpwrak> i don't particularly like the design. it seems to be overly cautious. better to assume that basic things like communication with the chip normally work, and have catch-all timeouts to recover from situations in which something goes wrong.
<stefan_schmidt> yeah, once one have identified this chip by reading out some regs I would assume that SPI communication is stable
<wpwrak> that may be a tad too optimistic ;-) e.g., in the case of atben, you may very well have some interruptions. but you don't need to check for them on _every_single_ state change :)