From: David F. <dav...@ya...> - 2004-09-10 03:57:39
|
I reduced by bluetooth baudrate in /etc/default/bluetooth HCIATTACH_SPEED to 230400 and L2PING works better, and I can outbound connect to windows. Windows also consistenly shows Gumstix in the Bluetooth Neighborhoof. I don't see pan or rfcomm working if I enable them but I may have screwed something else up during testing. David. |
From: David F. <dav...@ya...> - 2004-09-15 01:02:54
|
At 115K baud I noticed that leading into the unknown HCI packet message I get. # vatirq14: nobody cared pc : [<c0019f9c>] lr : [<c0019f90>] Not tainted sp : c0183fb8 ip : c0183fc8 fp : c0183fc4 r10: a00156c0 r9 : 69052d06 r8 : c0184ed8 r7 : c0196edc r6 : c0196ee8 r5 : c0182000 r4 : c0019f54 r3 : 60000013 r2 : 00000000 r1 : c03b0000 r0 : 00000001 Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel Control: 397F Table: A03D8000 DAC: 0000001D handlers: [<c00d190c>] h4_recv: Unknown HCI packet type 30 h4_recv: Unknown HCI packet type 30 h4_recv: Unknown HCI packet type 30 ... h4_check_data_len: Data length is too large .... h4_recv: Unknown HCI packet type 2d etc. When this occur, the link does not die, I can still ping the network. If the network is active when this occurs, the network dies. At 921.6K Baud in a relatively short period of time I get hci_acl_txto hci0 ACL tx timeout just sitting idle. This is a fatal error that kills the network. There may be two different types of problems, I am starting to track down the first (at 115K). David. |
From: David F. <dav...@ya...> - 2004-09-15 01:35:31
|
From dmesg, IRQ14 is the BTUART (makes sense) and the nobody cared from what I see indicates multiple interrupts occur without service. David. --- David Farrell <dav...@ya...> wrote: > At 115K baud I noticed that leading into the > unknown HCI packet message I get. > > # vatirq14: nobody cared > pc : [<c0019f9c>] lr : [<c0019f90>] Not > tainted > sp : c0183fb8 ip : c0183fc8 fp : c0183fc4 > r10: a00156c0 r9 : 69052d06 r8 : c0184ed8 > r7 : c0196edc r6 : c0196ee8 r5 : c0182000 r4 > : > c0019f54 > r3 : 60000013 r2 : 00000000 r1 : c03b0000 r0 > : > 00000001 > Flags: nZCv IRQs on FIQs on Mode SVC_32 > Segment kernel > Control: 397F Table: A03D8000 DAC: 0000001D > handlers: > [<c00d190c>] > > h4_recv: Unknown HCI packet type 30 > h4_recv: Unknown HCI packet type 30 > h4_recv: Unknown HCI packet type 30 > ... > h4_check_data_len: Data length is too large > .... > h4_recv: Unknown HCI packet type 2d > etc. > > When this occur, the link does not die, I can > still ping the network. If the network is > active > when this occurs, the network dies. > > At 921.6K Baud in a relatively short period of > time I get hci_acl_txto hci0 ACL tx timeout > just sitting idle. This is a fatal error that > kills the network. > > There may be two different types of problems, I > am starting to track down the first (at 115K). > > David. > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: thawte's > Crypto Challenge Vl > Crack the code and win a Sony DCRHC40 MiniDV > Digital Handycam > Camcorder. More prizes in the weekly Lunch Hour > Challenge. > Sign up NOW > http://ad.doubleclick.net/clk;10740251;10262165;m > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: David F. <dav...@ya...> - 2004-09-15 01:53:55
|
This is the last of these notes, I'll combine them in the future. cat /proc/tty/driver/"PXA serial" indicates that while doing "nothing" basically no tx events occur, but every 3 seconds or so I get 3482 rx events. David. --- David Farrell <dav...@ya...> wrote: > From dmesg, IRQ14 is the BTUART (makes sense) > and the nobody cared from what I see indicates > multiple interrupts occur without service. > David. > --- David Farrell <dav...@ya...> > wrote: > > > At 115K baud I noticed that leading into the > > unknown HCI packet message I get. > > > > # vatirq14: nobody cared > > pc : [<c0019f9c>] lr : [<c0019f90>] Not > > tainted > > sp : c0183fb8 ip : c0183fc8 fp : c0183fc4 > > r10: a00156c0 r9 : 69052d06 r8 : c0184ed8 > > r7 : c0196edc r6 : c0196ee8 r5 : c0182000 > r4 > > : > > c0019f54 > > r3 : 60000013 r2 : 00000000 r1 : c03b0000 > r0 > > : > > 00000001 > > Flags: nZCv IRQs on FIQs on Mode SVC_32 > > Segment kernel > > Control: 397F Table: A03D8000 DAC: 0000001D > > handlers: > > [<c00d190c>] > > > > h4_recv: Unknown HCI packet type 30 > > h4_recv: Unknown HCI packet type 30 > > h4_recv: Unknown HCI packet type 30 > > ... > > h4_check_data_len: Data length is too large > > .... > > h4_recv: Unknown HCI packet type 2d > > etc. > > > > When this occur, the link does not die, I can > > still ping the network. If the network is > > active > > when this occurs, the network dies. > > > > At 921.6K Baud in a relatively short period > of > > time I get hci_acl_txto hci0 ACL tx timeout > > just sitting idle. This is a fatal error > that > > kills the network. > > > > There may be two different types of problems, > I > > am starting to track down the first (at > 115K). > > > > David. > > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: thawte's > > Crypto Challenge Vl > > Crack the code and win a Sony DCRHC40 MiniDV > > Digital Handycam > > Camcorder. More prizes in the weekly Lunch > Hour > > Challenge. > > Sign up NOW > > > http://ad.doubleclick.net/clk;10740251;10262165;m > > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: thawte's > Crypto Challenge Vl > Crack the code and win a Sony DCRHC40 MiniDV > Digital Handycam > Camcorder. More prizes in the weekly Lunch Hour > Challenge. > Sign up NOW > http://ad.doubleclick.net/clk;10740251;10262165;m > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: David F. <dav...@ya...> - 2004-09-15 02:50:18
|
I changed my mind, From the cat proc sequence below I get 1: uart:BTUART mmio:0x40200000 irq:14 tx:3196 rx:1372836 oe:36 RTS|CTS|DTR|DSR|CD The oe is overrun error. I get this when the bluetooth is set to HCIATTACH_SPEED=115200. If I let the link sit and do dothing (ifconfig and ping shows a valid bnep0 connection) periodically I will get the previously reported "Unknown HCI packet type 30" if I cat proc.. before and after this I see OE increase by 4 or 5 events. I can't understand how you get overruns with a 64 byte fifo at this rate. I started reviewing the pxa.c serial code, its going to take a while. Do people really use udelay(1) if a loop 10000 or 100000 times? It seems to be the bluetooth problem is a serial driver problem. It may be better to use the HWUART to diagnose the problem, it looks like the same driver, and I can better control a stimulation source. David. (Time to go to bed...) --- David Farrell <dav...@ya...> wrote: > This is the last of these notes, I'll combine > them in the future. > > cat /proc/tty/driver/"PXA serial" indicates > that > while doing "nothing" basically no tx events > occur, but every 3 seconds or so I get 3482 rx > events. > > David. > > --- David Farrell <dav...@ya...> > wrote: > > > From dmesg, IRQ14 is the BTUART (makes sense) > > and the nobody cared from what I see > indicates > > multiple interrupts occur without service. > > David. > > --- David Farrell <dav...@ya...> > > wrote: > > > > > At 115K baud I noticed that leading into > the > > > unknown HCI packet message I get. > > > > > > # vatirq14: nobody cared > > > pc : [<c0019f9c>] lr : [<c0019f90>] > Not > > > tainted > > > sp : c0183fb8 ip : c0183fc8 fp : c0183fc4 > > > r10: a00156c0 r9 : 69052d06 r8 : c0184ed8 > > > r7 : c0196edc r6 : c0196ee8 r5 : c0182000 > > > r4 > > > : > > > c0019f54 > > > r3 : 60000013 r2 : 00000000 r1 : c03b0000 > > > r0 > > > : > > > 00000001 > > > Flags: nZCv IRQs on FIQs on Mode SVC_32 > > > Segment kernel > > > Control: 397F Table: A03D8000 DAC: > 0000001D > > > handlers: > > > [<c00d190c>] > > > > > > h4_recv: Unknown HCI packet type 30 > > > h4_recv: Unknown HCI packet type 30 > > > h4_recv: Unknown HCI packet type 30 > > > ... > > > h4_check_data_len: Data length is too large > > > .... > > > h4_recv: Unknown HCI packet type 2d > > > etc. > > > > > > When this occur, the link does not die, I > can > > > still ping the network. If the network is > > > active > > > when this occurs, the network dies. > > > > > > At 921.6K Baud in a relatively short > period > > of > > > time I get hci_acl_txto hci0 ACL tx timeout > > > just sitting idle. This is a fatal error > > that > > > kills the network. > > > > > > There may be two different types of > problems, > > I > > > am starting to track down the first (at > > 115K). > > > > > > David. > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by: thawte's > > > Crypto Challenge Vl > > > Crack the code and win a Sony DCRHC40 > MiniDV > > > Digital Handycam > > > Camcorder. More prizes in the weekly Lunch > > Hour > > > Challenge. > > > Sign up NOW > > > > > > http://ad.doubleclick.net/clk;10740251;10262165;m > > > > > > _______________________________________________ > > > gumstix-users mailing list > > > gum...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: thawte's > > Crypto Challenge Vl > > Crack the code and win a Sony DCRHC40 MiniDV > > Digital Handycam > > Camcorder. More prizes in the weekly Lunch > Hour > > Challenge. > > Sign up NOW > > > http://ad.doubleclick.net/clk;10740251;10262165;m > > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: thawte's > Crypto Challenge Vl > Crack the code and win a Sony DCRHC40 MiniDV > Digital Handycam > Camcorder. More prizes in the weekly Lunch Hour > Challenge. > Sign up NOW > http://ad.doubleclick.net/clk;10740251;10262165;m > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2004-09-15 23:43:14
|
I just checked an update into SVN which set the BTUART FIFO length to 256 instead of 64. Might resolve that part of the b2 problem. In testing with the 256 buffer though, I'm still getting disconnects happening from time to time. C On Sep 14, 2004, at 7:50 PM, David Farrell wrote: > > It seems to be the bluetooth problem is a serial > driver problem. It may be better to use the > HWUART to diagnose the problem, it looks like the > same driver, and I can better control a > stimulation source. |
From: David F. <dav...@ya...> - 2004-09-16 00:50:57
|
You lost me. Are you talking about some FIFO other than the hw one in the PXA. Where are you getting 256 from? I was thinking the IRQ trigger point should be lower to allow for longer latency, I got sidetracked during this. I am trying to finds stuff on the 2.6 kernel regarding metrics related to latency. I noticed some comments about hcidump have you done anything with that yet? Do you know of any way in linux to tee off the serial device? It would be nice to capture some of the offending packets and play them back to the bluetooth driver. David. --- Craig Hughes <cr...@hu...> wrote: > I just checked an update into SVN which set the > BTUART FIFO length to > 256 instead of 64. Might resolve that part of > the b2 problem. In > testing with the 256 buffer though, I'm still > getting disconnects > happening from time to time. > > C > > On Sep 14, 2004, at 7:50 PM, David Farrell > wrote: > > > > > It seems to be the bluetooth problem is a > serial > > driver problem. It may be better to use the > > HWUART to diagnose the problem, it looks like > the > > same driver, and I can better control a > > stimulation source. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: thawte's > Crypto Challenge Vl > Crack the code and win a Sony DCRHC40 MiniDV > Digital Handycam > Camcorder. More prizes in the weekly Lunch Hour > Challenge. > Sign up NOW > http://ad.doubleclick.net/clk;10740251;10262165;m > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2004-09-16 01:32:24
|
The serial port FIFO in the linux kernel, as defined in drivers/serial/pxa.c in the serial_pxa_ports[] array. bluez-hcidump is now a valid TARGET in the buildroot. Once compiled, you can copy it to the gumstix. I've tried doing some stuff with it, but it doesn't look like HCI level stuff going wrong -- right now I'm suspecting a combination of the buffer problem and radio problems in my office causing disconnections which are real disconnections. More time needed to recreate more failures, to be able to track it down better. Not sure if there's a way to record from the tty -- could probably hack the kernel a bit to do so. C On Sep 15, 2004, at 5:50 PM, David Farrell wrote: > You lost me. Are you talking about some FIFO > other than the hw one in the PXA. Where are you > getting 256 from? I was thinking the IRQ > trigger point should be lower to allow for longer > latency, I got sidetracked during this. I am > trying to finds stuff on the 2.6 kernel regarding > metrics related to latency. > > I noticed some comments about hcidump have you > done anything with that yet? > > Do you know of any way in linux to tee off the > serial device? It would be nice to capture some > of the offending packets and play them back to > the bluetooth driver. > > David. > > --- Craig Hughes <cr...@hu...> wrote: > >> I just checked an update into SVN which set the >> BTUART FIFO length to >> 256 instead of 64. Might resolve that part of >> the b2 problem. In >> testing with the 256 buffer though, I'm still >> getting disconnects >> happening from time to time. >> >> C >> >> On Sep 14, 2004, at 7:50 PM, David Farrell >> wrote: >> >>> >>> It seems to be the bluetooth problem is a >> serial >>> driver problem. It may be better to use the >>> HWUART to diagnose the problem, it looks like >> the >>> same driver, and I can better control a >>> stimulation source. >> >> >> >> > ------------------------------------------------------- >> This SF.Net email is sponsored by: thawte's >> Crypto Challenge Vl >> Crack the code and win a Sony DCRHC40 MiniDV >> Digital Handycam >> Camcorder. More prizes in the weekly Lunch Hour >> Challenge. >> Sign up NOW >> > http://ad.doubleclick.net/clk;10740251;10262165;m >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: David F. <dav...@ya...> - 2004-09-16 01:58:20
|
--- Craig Hughes <cr...@hu...> wrote: > The serial port FIFO in the linux kernel, as > defined in > drivers/serial/pxa.c in the serial_pxa_ports[] > array. I saw that, you said fifo to 256, the pxa255 only has 64 bytes. I did see (line 504) that the trigger point is 8 bytes for baud > 2400. We could try 16 or 32 but I would rather understand why before doing. > bluez-hcidump is now a valid TARGET in the > buildroot. Once compiled, > you can copy it to the gumstix. I've tried > doing some stuff with it, > but it doesn't look like HCI level stuff going > wrong -- right now I'm I tend to agree. > suspecting a combination of the buffer problem > and radio problems in my > office causing disconnections which are real I am not so sure. My iPAQ runs fine ransferring large files even with my 2.4G Spread Spect phone going and gumstix bluetooth pinging. > disconnections. More time > needed to recreate more failures, to be able to > track it down better. Do you guys have an eval board to hook up the bt module via RS232 to a pc? If not maybe you can populate a bare gumstix board with only the module to bring out the serial lines so you can watch the HCI_H4 traffic. I would expect the most tested BlueZ stuff is on a pc. David. |
From: David F. <dav...@ya...> - 2004-09-16 11:25:42
|
My initial thoughts on the pxa.c serial driver with all due respect to the author. FIFOs work best by doing two things. Reducing the frequency of interrupts and minimizing the time spent in an interrupt revice routine. The pxa.c driver does the former, not the latter. The way the former works is obvious, the latter works by knowing you that you can burst read x number of bytes without checking anything else. This complicates the design a bit. You have to check for timeout interrupts and process the fifo differently. The user space buffer should be aligned to the fifo trigger size. The easiest fix for now may be to not loop for (at most) 256 bytes from the fifo but only read the number specified by the trigger point size. I next plan on toggling a gpio at entry and exit of the read routing to measure the effect of this change on timing. David. --- David Farrell <dav...@ya...> wrote: > --- Craig Hughes <cr...@hu...> > wrote: > > > The serial port FIFO in the linux kernel, as > > defined in > > drivers/serial/pxa.c in the > serial_pxa_ports[] > > array. > > I saw that, you said fifo to 256, the pxa255 > only > has 64 bytes. I did see (line 504) that the > trigger point is 8 bytes for baud > 2400. > We could try 16 or 32 but I would rather > understand why before doing. > > > bluez-hcidump is now a valid TARGET in the > > buildroot. Once compiled, > > you can copy it to the gumstix. I've tried > > doing some stuff with it, > > but it doesn't look like HCI level stuff > going > > wrong -- right now I'm > I tend to agree. > > suspecting a combination of the buffer > problem > > and radio problems in my > > office causing disconnections which are real > I am not so sure. My iPAQ runs fine > ransferring > large files even with my 2.4G Spread Spect > phone > going and gumstix bluetooth pinging. > > disconnections. More time > > needed to recreate more failures, to be able > to > > track it down better. > > Do you guys have an eval board to hook up the > bt > module via RS232 to a pc? If not maybe you can > populate a bare gumstix board with only the > module to bring out the serial lines so you can > watch the HCI_H4 traffic. I would expect the > most tested BlueZ stuff is on a pc. > > David. |
From: Edward W. <Edward.Wei@Dartmouth.EDU> - 2004-09-30 20:05:57
|
What is the status of bluetooth now? Has any progress been made? I tried running both rctest and l2test out of the bluez package. For rctest, the gumstix is able to receive indefinitely, but only send a few packets before stalling with the message "hci_cmd_task: hci0 command tx timeout". For l2test, the gumstix can receive fine for a while, then I get "h4_recv: Unknown HCI packet type 7f" messages. The gumstix also can't send under l2test. If this is a problem with my own setup, I'll provide the hcidump and ask on the bluez mailing list. Ed David Farrell wrote: >My initial thoughts on the pxa.c serial driver >with all due respect to the author. >FIFOs work best by doing two things. Reducing >the frequency of interrupts and minimizing the >time spent in an interrupt revice routine. The >pxa.c driver does the former, not the latter. The >way the former works is obvious, the latter works >by knowing you that you can burst read x number >of bytes without checking anything else. >This complicates the design a bit. You have to >check for timeout interrupts and process the fifo >differently. The user space buffer should be >aligned to the fifo trigger size. The easiest >fix for now may be to not loop for (at most) 256 >bytes from the fifo but only read the number >specified by the trigger point size. I next plan >on toggling a gpio at entry and exit of the read >routing to measure the effect of this change on >timing. > >David. > >--- David Farrell <dav...@ya...> wrote: > > > >>--- Craig Hughes <cr...@hu...> >>wrote: >> >> >> >>>The serial port FIFO in the linux kernel, as >>>defined in >>>drivers/serial/pxa.c in the >>> >>> >>serial_pxa_ports[] >> >> >>>array. >>> >>> >>I saw that, you said fifo to 256, the pxa255 >>only >>has 64 bytes. I did see (line 504) that the >>trigger point is 8 bytes for baud > 2400. >>We could try 16 or 32 but I would rather >>understand why before doing. >> >> >> >>>bluez-hcidump is now a valid TARGET in the >>>buildroot. Once compiled, >>>you can copy it to the gumstix. I've tried >>>doing some stuff with it, >>>but it doesn't look like HCI level stuff >>> >>> >>going >> >> >>>wrong -- right now I'm >>> >>> >>I tend to agree. >> >> >>>suspecting a combination of the buffer >>> >>> >>problem >> >> >>>and radio problems in my >>>office causing disconnections which are real >>> >>> >>I am not so sure. My iPAQ runs fine >>ransferring >>large files even with my 2.4G Spread Spect >>phone >>going and gumstix bluetooth pinging. >> >> >>>disconnections. More time >>>needed to recreate more failures, to be able >>> >>> >>to >> >> >>>track it down better. >>> >>> >>Do you guys have an eval board to hook up the >>bt >>module via RS232 to a pc? If not maybe you can >>populate a bare gumstix board with only the >>module to bring out the serial lines so you can >>watch the HCI_H4 traffic. I would expect the >>most tested BlueZ stuff is on a pc. >> >>David. >> >> > > > >------------------------------------------------------- >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >Project Admins to receive an Apple iPod Mini FREE for your judgement on >who ports your project to Linux PPC the best. Sponsored by IBM. >Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >_______________________________________________ >gumstix-users mailing list >gum...@li... >https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: Kaan E. <ka...@12...> - 2004-09-15 13:08:06
Attachments:
sample.jpg
|
Hi all, Is there anyone who attached an TFT LCD to gumstix-f succesfully? Actually, I am looking for a daughter board solution for hirose connector to use LCD, serial port, power input, and audio output. This may be (if it is possible) just cable based solution (I attached an image to the mail, you can see a cable solution sample which marked with red pen. source: http://www.hirose-connectors.com/products/DF1_5.htm ). Waysmall does not present a tft lcd support. And, we have not enough know-how to design a daughter board customly for our project. Thanks... Kaan Erdemir |
From: Craig H. <cr...@hu...> - 2004-09-15 20:32:45
|
I think that's bytes, not events C On Sep 14, 2004, at 6:53 PM, David Farrell wrote: > cat /proc/tty/driver/"PXA serial" indicates that > while doing "nothing" basically no tx events > occur, but every 3 seconds or so I get 3482 rx > events. |
From: Craig H. <cr...@hu...> - 2004-09-15 20:33:37
|
No, my bad -- it is events C On Sep 14, 2004, at 6:53 PM, David Farrell wrote: > cat /proc/tty/driver/"PXA serial" indicates that > while doing "nothing" basically no tx events > occur, but every 3 seconds or so I get 3482 rx > events. |
From: David F. <dav...@ya...> - 2004-09-15 23:39:09
|
I called them events to be ambiguous enough until I read the code more carefully. I am just starting to sit down to do that. I am restricting my initial effort to low speed, low throughput related errors. I get the errors doing nothing on the gumstix, just the belkin nap announcing stuff, every 3 seconds of about 3K bytes. Only rx events. I find is strange that the PXA can't keep the fifo empty. In a possibly related issue, I see occassional extra characters on the console, I beleive it is the same driver. David. --- Craig Hughes <cr...@hu...> wrote: > No, my bad -- it is events > > C > > On Sep 14, 2004, at 6:53 PM, David Farrell > wrote: > > > cat /proc/tty/driver/"PXA serial" indicates > that > > while doing "nothing" basically no tx events > > occur, but every 3 seconds or so I get 3482 > rx > > events. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: thawte's > Crypto Challenge Vl > Crack the code and win a Sony DCRHC40 MiniDV > Digital Handycam > Camcorder. More prizes in the weekly Lunch Hour > Challenge. > Sign up NOW > http://ad.doubleclick.net/clk;10740251;10262165;m > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2004-09-15 20:31:34
|
So possibly we just need to make the event queue a bit longer or something; could be that the PXA is falling behind on processing interrupts from the b2 module if there's heavy traffic. C On Sep 14, 2004, at 6:35 PM, David Farrell wrote: > From dmesg, IRQ14 is the BTUART (makes sense) > and the nobody cared from what I see indicates > multiple interrupts occur without service. |
From: Bouwens / M. <bou...@bl...> - 2004-09-15 20:45:42
|
Hi, I'm not shure, but today I did some filetranfers using my new linksys wireless router. Average throughput was low, need to figure out if we have some sort of interference between bluetooth and the wireless box. If you have something to test, pls let me know. Robert > -----Original Message----- > From: gum...@li... > [mailto:gum...@li...]On Behalf Of Craig > Hughes > Sent: Mittwoch, 15. September 2004 22:31 > To: gum...@li... > Subject: Re: [Gumstix-users] Bluetooth > > > So possibly we just need to make the event queue a bit longer or > something; could be that the PXA is falling behind on processing > interrupts from the b2 module if there's heavy traffic. > > C > > On Sep 14, 2004, at 6:35 PM, David Farrell wrote: > > > From dmesg, IRQ14 is the BTUART (makes sense) > > and the nobody cared from what I see indicates > > multiple interrupts occur without service. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: thawte's Crypto Challenge Vl > Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam > Camcorder. More prizes in the weekly Lunch Hour Challenge. > Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: J.p. L. <jl...@ne...> - 2006-08-25 21:30:16
|
I'd like to use bluetooth to pull files off my gumstix. I've never messed with bluetooth before, but thanks to this list and the wiki, I now have ssh and rfcomm access working. I've tried copying a file (/boot/uImage was my test) back to my PC using scp (simplest way I could think of), and I'm getting about 10KB/s. Is this typical? Is there a way to increase the throughput? I have the Infineon module, BTW. I also tried to access the 'stix over HTTP, but it doesn't respond. netstat says boa is listening on port *:80, so I'm not sure what the problem is with that. Has anyone else tried to use boa over bluetooth? Lastly if anyone has any better suggestions about how to grab one's data over bt, I'd appreciate them. Thanks, J.p. Lien |
From: Jay P. <ja...@bl...> - 2006-08-25 21:46:07
|
If you have ssh working then you should be able to use SFTP I believe. -Jay On Aug 25, 2006, at 5:16 PM, J.p.Lien wrote: > I'd like to use bluetooth to pull files off my gumstix. I've never > messed with > bluetooth before, but thanks to this list and the wiki, I now have > ssh and > rfcomm access working. > > I've tried copying a file (/boot/uImage was my test) back to my PC > using scp > (simplest way I could think of), and I'm getting about 10KB/s. Is > this typical? > Is there a way to increase the throughput? I have the Infineon > module, BTW. > > I also tried to access the 'stix over HTTP, but it doesn't > respond. netstat > says boa is listening on port *:80, so I'm not sure what the > problem is with > that. Has anyone else tried to use boa over bluetooth? > > Lastly if anyone has any better suggestions about how to grab one's > data over > bt, I'd appreciate them. > > Thanks, > J.p. Lien > > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Evan <me...@gm...> - 2006-08-25 22:51:26
|
I initialy acived a fsast blutooth spee dbut it rapidly decreased to 10kb/s or less. The http web server worked perfectly fine fo me (i believe it was bluetooth, it may have been usb). On 8/25/06, J. p. Lien <jl...@ne...> wrote: > > I'd like to use bluetooth to pull files off my gumstix. I've never messed > with > bluetooth before, but thanks to this list and the wiki, I now have ssh and > rfcomm access working. > > I've tried copying a file (/boot/uImage was my test) back to my PC using > scp > (simplest way I could think of), and I'm getting about 10KB/s. Is this > typical? > Is there a way to increase the throughput? I have the Infineon module, > BTW. > > I also tried to access the 'stix over HTTP, but it doesn't > respond. netstat > says boa is listening on port *:80, so I'm not sure what the problem is > with > that. Has anyone else tried to use boa over bluetooth? > > Lastly if anyone has any better suggestions about how to grab one's data > over > bt, I'd appreciate them. > > Thanks, > J.p. Lien > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Black, M. <Michael.Black@EssexCorp.com> - 2006-10-18 16:56:28
|
I'd like add a usb Bluetooth interface to a gumstix 400xm. Has anybody done this? Recommend a model? How does it plug into the B-female connector on the 400xm? =20 ___________________ Michael D. Black Essex Corporation bl...@es... =20 =20 =20 =20 =20 =20 =20 This electronic message and any files transmitted with it contain = information which may be privileged and/or proprietary. The information = is intended for use solely by the intended recipient(s). If you are not = the intended recipient, be aware that any disclosure, copying, = distribution or use of this information is prohibited. If you have = received this electronic message in error, please advise the sender by = reply email or by telephone (301-939-7000) and delete the message. |
From: Matthew F C. <mc...@ua...> - 2006-10-18 17:13:19
|
That USB connection is client only. In order to use any USB devices you'll have to get CF USB host card.=20 -Matt ________________________________ From: gum...@li... on behalf of Black, Michael Sent: Wed 10/18/2006 11:56 AM To: General mailing list for gumstix users. Subject: [Gumstix-users] Bluetooth I'd like add a usb Bluetooth interface to a gumstix 400xm. Has anybody done this? Recommend a model? How does it plug into the B-female connector on the 400xm? =20 ___________________ Michael D. Black Essex Corporation bl...@es... =20 =20 =20 =20 =20 =20 =20 =20 This electronic message and any files transmitted with it contain information which may be privileged and/or proprietary. The information is intended for use solely by the intended recipient(s). If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this information is prohibited. If you have received this electronic message in error, please advise the sender by reply email or by telephone (301-939-7000) and delete the message.=20 |
From: David K. <dk...@sh...> - 2006-10-18 18:08:20
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Black, Michael wrote: > I=E2=80=99d like add a usb Bluetooth interface to a gumstix 400xm. >=20 > Has anybody done this? >=20 > Recommend a model? >=20 > How does it plug into the B-female connector on the 400xm? >=20 Soon there will be bluetooth on almost all the gumstix motherboards. There's a page on their wiki about it, but basically there waiting on the RoHS compliant bluetooth chips from the manufacturer. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iQGVAwUBRTZtt8nf+vRw63ObAQqk8Qv8C5CZHI7llm16nb/94Q8ecPbyufb2wUvw 8f5yXCgsmWBk4ZnaYRYlz+qP27YY6iWcuP90jVKxufD9lsk6L8jYrGPR+wAjT002 MxASqhSHL1AL2tciQQtK750mC+BLFp4/yBH+Ivr9HVdoIHtIF5Tbm58b9NkJQ3x9 UEOW7BKky9hmcDkD29Td5fwnRkRlRskKlK9EZT4qqISvSalK1De67sj+P4clE10G cyq84dRDy2emlf8INbjtw0ZY+NZgBsRNNDJtVQtmBMBTSE6TEC0EfAtR5dhQGgvQ jmy7Pna5yIGrMZLPwqGZPDk8xNC6pj5eVlcrt8132UdHJCNlKGc6RkPKCc6U1+3L uOAiKTXXLJ2NbPxgS27yUzvYuMcsTVrSiGSrCjtfZXxE7lxrQ2h3DAx9KSV6In/1 tDCIegUdNBy3DllydUy1qux5eueJDRNdYBiihQUgc08seLJ+a3YiYmnS/x8Olaue dYkY3PxxqMwgaHpn728g4UDuUVxDlNCl =3DDi6C -----END PGP SIGNATURE----- |
From: Jesse W. <jes...@gm...> - 2006-10-18 18:42:10
|
short out line of what you can do: get a serial bluetooth module from http://www.sparkfun.com/commerce/categories.php?cPath=16_115m add the bluez stack and configure it to point to use whichever serial you hook up the module to. maybe Craig or Dave could coment on the specifics? -- -Jesse W. |
From: Brad M. <bmi...@xm...> - 2006-10-19 14:57:42
|
Jesse > get a serial bluetooth module from > http://www.sparkfun.com/commerce/categories.php?cPath=16_115m > add the bluez stack and configure it to point to use whichever serial > you hook up the module to. The sparkfun modules have the wrong firmware so bluez can't talk to them. A better bet is the bluegiga wt11-a-hci or wt12-a-hci from semiconductorstore.com I bought a couple of them and did some reading to figure out how to connect it up but haven't done it yet. see http://bluetooth-alsa.sourceforge.net/embedv1.html Brad |