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