qi-bot | The build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-09232011-2040/ | 00:45 |
---|---|---|
kristianpaul | damn, i forgot that libc.c dont have float support for printf :-| !!! | 01:36 |
wpwrak | kristianpaul: you mean libbase ? :) | 04:48 |
kristianpaul | yes | 04:52 |
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 | 09:01 |
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 | 10:02 |
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 | 10:02 |
stefan_schmidt | wpwrak: ping | 19:03 |
wpwrak | pong | 19:03 |
stefan_schmidt | wpwrak: I have an interesting problem iwth atusb here :) | 19:03 |
wpwrak | ah ? :) | 19:03 |
stefan_schmidt | wpwrak: I'm implementing auto ack and automatic retransmit right now | 19:04 |
stefan_schmidt | wpwrak: uto ack works fine already but the sending in TX_ARET mode is failing | 19:04 |
stefan_schmidt | wpwrak: and it seems its because no slp_tr pin is available on atusb... | 19:04 |
stefan_schmidt | wpwrak: From what I see it is not needed in normal tx mode but in tx_aret it is :/ | 19:05 |
wpwrak | is it needed ? | 19:05 |
wpwrak | and you mean in the driver, not the hardware, correct ? | 19:06 |
stefan_schmidt | as in the driver yes | 19:06 |
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 | 19:06 |
wpwrak | that's one way to start it, yes | 19:07 |
wpwrak | but you should still be able to just send a command, as in basic mode | 19:07 |
stefan_schmidt | hmm, from what I understand I can't do this in extended mode | 19:07 |
wpwrak | what makes you think you can't ? | 19:08 |
wpwrak | page 48 has it, much like on page 33 :) | 19:08 |
stefan_schmidt | the contiki driver code. And my filing tests :) | 19:09 |
stefan_schmidt | but let me check again | 19:09 |
stefan_schmidt | maybe contiki uses the slp_tr approach always | 19:09 |
wpwrak | i wouldn't be surprised if contiki did this. in general, it should be more efficient. | 19:10 |
stefan_schmidt | so one either uses slp_tr _or_ send writes TX_START into TRX_STATE? | 19:10 |
wpwrak | but things should still work even without SLP_TR | 19:10 |
wpwrak | yes | 19:10 |
stefan_schmidt | hmm | 19:10 |
wpwrak | lemme push my unfinished new atusb driver ... | 19:11 |
qi-bot | [commit] Werner Almesberger: atusb driver for extended mode (untested and unfinished ) (ben-wpan) http://qi-hw.com/p/qi-kernel/815a0e3 | 19:12 |
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 | 19:13 |
wpwrak | rc = at86rf230_write_subreg(lp, SR_TRX_CMD, STATE_BUSY_TX) | 19:14 |
wpwrak | right after the slp_tr ;-) | 19:14 |
stefan_schmidt | wpwrak: but BUSY_TX != TX_START?? | 19:14 |
stefan_schmidt | seems I'm running one-way street here since an hour :) | 19:15 |
wpwrak | check tables 7-3 and 7-4 :) (pages 45 and 46) | 19:16 |
wpwrak | running down one-way streets can still get you closer to your destination. it's the dead-ends you have to avoid ;-) | 19:18 |
stefan_schmidt | wpwrak: it actually looks like a bug to me that works by accident. Lets see: | 19:21 |
stefan_schmidt | STATE_BUSY_TX gets written into SR_TRX_CMD while it is an _state_ and not an command!! | 19:21 |
stefan_schmidt | and by accident it is also 0x02... | 19:22 |
wpwrak | ;-)) naw, that's intentional | 19:22 |
wpwrak | state and command numbers are almost always the same | 19:22 |
wpwrak | they did have some bugs in cases where they aren't, though | 19:22 |
stefan_schmidt | But TX_ARET_ON is 0x19... | 19:22 |
stefan_schmidt | hmm | 19:23 |
stefan_schmidt | same state and command | 19:23 |
Action: stefan_schmidt stops for a moment to read it all carefully | 19:23 | |
stefan_schmidt | ok, so the problem is I write BUSY_TX_ARET there which is 0x12 and has no corresponding command | 19:25 |
stefan_schmidt | and page 48 shows TX_START as way to come from TX_ARET_ON to BUSY_TX_ARET | 19:25 |
stefan_schmidt | so command and state differ for TX_ARET here and with the logic above the state machine fails | 19:26 |
wpwrak | yes. if you keep the structure of a86rf230.c, you'd need an exception here | 19:26 |
stefan_schmidt | at leats I'm not completely blind :) | 19:27 |
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. | 19:27 |
stefan_schmidt | well, I never said I like the driver. Just wanted to have another test with aack in my evaluation :) | 19:27 |
stefan_schmidt | wpwrak: still looking forward to your new driver and new firmware | 19:28 |
stefan_schmidt | wpwrak: actually after 20th october I should be able to help you with it again. (Deadline for diploma thesis) | 19:28 |
stefan_schmidt | wpwrak: btw, interested in the evaluation results on the IEEE 802.15.4 layer? | 19:29 |
wpwrak | yeah, i hope to get around to finishing it by then. got a bit sidetracked with M1 these days, sorry. | 19:29 |
wpwrak | sure :) particularly if they're good - or if you've found some 60 ns difference ;-) | 19:29 |
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 | 19:30 |
stefan_schmidt | wpwrak: will prepare something and send it over tomorrow. Don't have it with me right now. | 19:31 |
stefan_schmidt | wpwrak: short version. _very_ stable and low packet loss even without aack but slow :) | 19:31 |
stefan_schmidt | wpwrak: interestingly we have some steps in the graphs for different payload lengths | 19:31 |
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) | 19:33 |
wpwrak | (steps) around which kind of numbers ? | 19:33 |
stefan_schmidt | wpwrak: IIRC around 50 or 60 bytes. Can say for sure and show you the graphs tomorrow | 19:34 |
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) | 19:35 |
wpwrak | (50-60 bytes) ah, that's a little odd | 19:36 |
stefan_schmidt | and it is not as linear as I had expected. At least one step, maybe another, smaller, one later on | 19:36 |
wpwrak | hmm. interesting indeed :) | 19:36 |
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 | 19:37 |
wpwrak | yeah :) | 19:39 |
stefan_schmidt | muhahahaha | 19:41 |
stefan_schmidt | it was indeed only the state change here | 19:41 |
stefan_schmidt | using BUSY_TX aka 0x02 made it work for TX_ARET_ON as well :) | 19:41 |
wpwrak | ;-)) congratulations ! | 19:41 |
stefan_schmidt | wpwrak: thanks for bring me back from the one-way street with slp_tr :) | 19:42 |
stefan_schmidt | wpwrak: thanks | 19:42 |
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 | 19:43 |
stefan_schmidt | wpwrak: if not that fine as well will test is after my thesis then | 19:43 |
wpwrak | (slp_tr) you're welcome :) | 19:45 |
wpwrak | (new driver) i'll see what i can do | 19:46 |
wpwrak | still have a number of other things in the pipeline, though ... | 19:47 |
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. | 19:50 |
wpwrak | no italian sports cars then ;-) | 19:51 |
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. | 19:51 |
stefan_schmidt | wpwrak: not for me. Actually since my last car broke down I share the car with my gf :) | 19:51 |
stefan_schmidt | wpwrak: have to wait until freelancing brings in enough for a Audi A6 now ;) | 19:52 |
wpwrak | ;-) subdued design then | 19:55 |
stefan_schmidt | wpwrak: you mean the audi or my gf's car? | 19:56 |
wpwrak | dunno what your gf drives :) | 19:57 |
wpwrak | well, or would drive if you hadn't taken possession of the car ;-) | 19:58 |
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 | 19:59 |
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" | 19:59 |
stefan_schmidt | wpwrak: VW Polo | 19:59 |
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 :) | 20:00 |
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 ;) | 20:01 |
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 | 20:02 |
stefan_schmidt | wpwrak: and you feel every small bump from the street | 20:04 |
wpwrak | that's a feature, not a bug :) | 20:05 |
stefan_schmidt | yeah, like taking state instead of commands and screwing with my mind if no corresponding command is there :) | 20:06 |
wpwrak | that driver has indeed some peculiarities :) | 20:09 |
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. | 20:10 |
stefan_schmidt | yeah, once one have identified this chip by reading out some regs I would assume that SPI communication is stable | 20:14 |
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 :) | 20:17 |
--- Mon Sep 26 2011 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!