From: Benny S. <ben...@ma...> - 2005-02-26 20:16:19
|
Hi I have to use both serial ports on the waysmall so I'm still trying to ge= t=20 the BT module working on the BTUART instead of the HWUART. Someone from the list did send me a data sheet for the ROK 104101 module,= =20 but in that data sheet I can't find any specific things about the UART=20 except from the fact that UART 1 has a 128 bytes FIFO, but nothing regard= ing=20 how many bytes it will accept after setting RTS low. The data sheet is marked: ------------------------------- Preliminary Data Sheet EN/LZT 146 130 R1C =A9 Ericsson Microelectronics AB, May 2002 ------------------------------- If someone should have another datasheet for the module and did not sign = a=20 NDA then please send it to me. Until now I have tried different things with limited success. I have amon= g=20 other things tried to limit the use of the TX FIFO to one byte (I will fi= rst=20 insert a new byte when the previous has been send). With this approach a=20 change on CTS should prevent further bytes to be transmitted (normally up= to=20 64 bytes could be transmitted after the BT module say "stop"). It does work better, but still I see the BT crash occasionally. Another r= eal=20 "funny" thing is that CTS on the gumstix change state every time I send j= ust=20 one byte to the BT module. I thought it was an error in the serial driver= ,=20 but when I use the HWUART on the waysmall it seems to behave as expected. Suggestion to what to do (and or a datasheet which might explain the funn= y=20 behaviour of the flow ctrl signals) will be appreciated. BR Benny=20 |
From: David F. <dav...@ya...> - 2005-02-26 21:50:02
|
The lost serial port is a problem for me too. I have other things to worry about. When everything is perfect (right), I'll give up the console. I would leave the fifo's as big as they can. Handshake disables the transmit, it doesn't matter the size of the fifo. Slow the baud rate down to as low as you can. The handshake response latency relative to character times is what matters. The longer the character time, the sooner the handshake appears to happen. I had better luck reducing the rx loop from 256 bytes to 32. The way I look at it this limits the latency. Although less than 256 chars will always exit the loop, the sooner you exit the loop the soone you can service other things. My patch does not do this since I wanted to change as few things as possible. So far I have had a week of solid bluetooth performace on the HWUART (excluding the boot time issue). I assume you had things running ok on the HWUART? David. --- Benny Simonsen <ben...@ma...> wrote: > Hi > > I have to use both serial ports on the waysmall > so I'm still trying to get > the BT module working on the BTUART instead of > the HWUART. > Someone from the list did send me a data sheet > for the ROK 104101 module, > but in that data sheet I can't find any > specific things about the UART > except from the fact that UART 1 has a 128 > bytes FIFO, but nothing regarding > how many bytes it will accept after setting RTS > low. > > > > The data sheet is marked: > > ------------------------------- > > Preliminary Data Sheet > EN/LZT 146 130 R1C > © Ericsson Microelectronics AB, May 2002 > > ------------------------------- > > If someone should have another datasheet for > the module and did not sign a > NDA then please send it to me. > > > > Until now I have tried different things with > limited success. I have among > other things tried to limit the use of the TX > FIFO to one byte (I will first > insert a new byte when the previous has been > send). With this approach a > change on CTS should prevent further bytes to > be transmitted (normally up to > 64 bytes could be transmitted after the BT > module say "stop"). > > It does work better, but still I see the BT > crash occasionally. Another real > "funny" thing is that CTS on the gumstix change > state every time I send just > one byte to the BT module. I thought it was an > error in the serial driver, > but when I use the HWUART on the waysmall it > seems to behave as expected. > > > > Suggestion to what to do (and or a datasheet > which might explain the funny > behaviour of the flow ctrl signals) will be > appreciated. > > > > > > BR > > Benny > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_ide95&alloc_id396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Tim A. <ti...@ut...> - 2005-02-28 08:52:55
|
On 26 Feb 2005, at 21:49, David Farrell wrote: > The lost serial port is a problem for me too. I > have other things to worry about. When > everything is perfect (right), I'll give up the > console. There may not be any more hardware serial ports, but there are plenty of GPIOs. With the oomph of the PXA255 I wouldn't have thought bit-banging serial using the GPIOs would be a prohibitive overhead. I'm confident that the hardware is up to the task, but I'm no Linux kernel hacker, so there may be a world of stuff I'm missing there. Just a matter of software :D Tim |
From: Benny S. <ben...@ma...> - 2005-02-28 11:58:48
|
Hi Tim You can't use bit-banging to create an asynchrone serial port on Linux. That will require two timers which can trig a read or write precisely for every bit period. You can't do that on Linux because drivers are able to disable interrupts and when they do that the timers you use for serial bit-banging can't tell that it is time for reading or writing a new bit from a GPIO. However you can create your own synchrone serial master with bit-banging (e.g SPI) BR Benny ----- Original Message ----- From: "Tim Auton" <ti...@ut...> To: <gum...@li...> Sent: Monday, February 28, 2005 9:52 AM Subject: Re: [Gumstix-users] BT on BTUART > On 26 Feb 2005, at 21:49, David Farrell wrote: > >> The lost serial port is a problem for me too. I >> have other things to worry about. When >> everything is perfect (right), I'll give up the >> console. > > There may not be any more hardware serial ports, but there are plenty of > GPIOs. With the oomph of the PXA255 I wouldn't have thought bit-banging > serial using the GPIOs would be a prohibitive overhead. I'm confident that > the hardware is up to the task, but I'm no Linux kernel hacker, so there > may be a world of stuff I'm missing there. > > Just a matter of software :D > > > Tim |
From: David F. <dav...@ya...> - 2005-02-28 13:41:06
|
There is a possibility of using bit banging with RS232 (or the syncronous serial port) See the MAX3100 family of SPI interfaced uarts. http://www.maxim-ic.com David. --- Benny Simonsen <ben...@ma...> wrote: > Hi Tim > > You can't use bit-banging to create an > asynchrone serial port on Linux. > That will require two timers which can trig a > read or write precisely for > every bit period. > You can't do that on Linux because drivers are > able to disable interrupts > and when they do that the timers you use for > serial bit-banging can't tell > that it is time for reading or writing a new > bit from a GPIO. > However you can create your own synchrone > serial master with bit-banging > (e.g SPI) > > BR > Benny > > ----- Original Message ----- > From: "Tim Auton" <ti...@ut...> > To: <gum...@li...> > Sent: Monday, February 28, 2005 9:52 AM > Subject: Re: [Gumstix-users] BT on BTUART > > > > On 26 Feb 2005, at 21:49, David Farrell > wrote: > > > >> The lost serial port is a problem for me > too. I > >> have other things to worry about. When > >> everything is perfect (right), I'll give up > the > >> console. > > > > There may not be any more hardware serial > ports, but there are plenty of > > GPIOs. With the oomph of the PXA255 I > wouldn't have thought bit-banging > > serial using the GPIOs would be a prohibitive > overhead. I'm confident that > > the hardware is up to the task, but I'm no > Linux kernel hacker, so there > > may be a world of stuff I'm missing there. > > > > Just a matter of software :D > > > > > > Tim > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2005-02-28 16:29:50
|
On Feb 28, 2005, at 12:52 AM, Tim Auton wrote: > There may not be any more hardware serial ports, but there are plenty > of GPIOs. With the oomph of the PXA255 I wouldn't have thought > bit-banging serial using the GPIOs would be a prohibitive overhead. > I'm confident that the hardware is up to the task, but I'm no Linux > kernel hacker, so there may be a world of stuff I'm missing there. I think as has been pointed out that bit-banging a new "UART" on GPIOs would be difficult if not impossible in practice at any reasonable baud rate. However, creating a "super serial" buddy board with 2, 4, 8, however many UARTs you want, linked to the PXA over SPI would work fine, and likely be pretty easy to implement, > Just a matter of software :D Make that hardware and software ;P C |
From: Philip T. <ph...@te...> - 2005-02-28 16:39:46
|
On Mon, 2005-02-28 at 08:30 -0800, Craig Hughes wrote: > I think as has been pointed out that bit-banging a new "UART" on GPIOs > would be difficult if not impossible in practice at any reasonable baud > rate. However, creating a "super serial" buddy board with 2, 4, 8, > however many UARTs you want, linked to the PXA over SPI would work > fine, and likely be pretty easy to implement, > Would it be slightly easier to use an 820 compatible Quad or Octal UART mapped at a memory address which would then be used on a Gumstix Connex? This way you could use the 820 serial support already built in to the kernel. Although, I did read on my monthly trawl through the ARM kernel mailing list that the 820 driver and the PXA serial driver conflict on port naming issues. Craig, if you write the drivers, I'll design the hardware :) > Make that hardware and software ;P > > C Phil |
From: David F. <dav...@ya...> - 2005-02-28 16:50:49
|
How about a board with a Xilinx Spartan 3? Craig does the software, Phil the hardware and I'll write the VHDL (for uarts initially). David. --- Philip Trickett <ph...@te...> wrote: > On Mon, 2005-02-28 at 08:30 -0800, Craig Hughes > wrote: > > > I think as has been pointed out that > bit-banging a new "UART" on GPIOs > > would be difficult if not impossible in > practice at any reasonable baud > > rate. However, creating a "super serial" > buddy board with 2, 4, 8, > > however many UARTs you want, linked to the > PXA over SPI would work > > fine, and likely be pretty easy to implement, > > > Would it be slightly easier to use an 820 > compatible Quad or Octal UART > mapped at a memory address which would then be > used on a Gumstix Connex? > > This way you could use the 820 serial support > already built in to the > kernel. Although, I did read on my monthly > trawl through the ARM kernel > mailing list that the 820 driver and the PXA > serial driver conflict on > port naming issues. > > Craig, if you write the drivers, I'll design > the hardware :) > > > > Make that hardware and software ;P > > > > C > > Phil > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Philip T. <ph...@te...> - 2005-02-28 17:04:00
|
On Mon, 2005-02-28 at 08:50 -0800, David Farrell wrote: > How about a board with a Xilinx Spartan 3? > Craig does the software, Phil the hardware and > I'll write the VHDL (for uarts initially). > > David. > OK, As long as we start with a board that gives us 8 UARTS ;) Phil |
From: Philip T. <ph...@te...> - 2005-02-28 17:11:12
|
On Mon, 2005-02-28 at 17:03 +0000, Philip Trickett wrote: > On Mon, 2005-02-28 at 08:50 -0800, David Farrell wrote: > > How about a board with a Xilinx Spartan 3? > > Craig does the software, Phil the hardware and > > I'll write the VHDL (for uarts initially). > > > > David. > > > OK, > > As long as we start with a board that gives us 8 UARTS ;) > > Phil > Thinking about it, how about a board that is opencores compatible? http://opencores.org/ Phil |
From: David F. <dav...@ya...> - 2005-02-28 17:18:58
|
Opencores would work, either way we are sticking Craig with the software :) David. --- Philip Trickett <ph...@te...> wrote: > On Mon, 2005-02-28 at 17:03 +0000, Philip > Trickett wrote: > > On Mon, 2005-02-28 at 08:50 -0800, David > Farrell wrote: > > > How about a board with a Xilinx Spartan 3? > > > Craig does the software, Phil the hardware > and > > > I'll write the VHDL (for uarts initially). > > > > > > David. > > > > > OK, > > > > As long as we start with a board that gives > us 8 UARTS ;) > > > > Phil > > > Thinking about it, how about a board that is > opencores compatible? > > http://opencores.org/ > > Phil > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2005-02-28 18:14:49
|
On Feb 28, 2005, at 8:39 AM, Philip Trickett wrote: > This way you could use the 820 serial support already built in to the > kernel. Although, I did read on my monthly trawl through the ARM kernel > mailing list that the 820 driver and the PXA serial driver conflict on > port naming issues. Yes, the 8250 driver conflicts with the PXA serial driver -- which is why CF serial cards will have trouble working too. In other words, it's really a Problem Which Needs Solving anyway. From reading RMK's postings on the linux-arm mailing list, it sounds like really the way the PXA driver does things is bad and wrong, and can't really be properly resolved in the "correct" way with ease. But I've never been averse to implementing the pragmatic when the ideal is unreasonable. Probably just hijacking some major/minor device numbers for something we'll never reasonably see on a PXA device for the PXA serial ports (such as say char-major-11) would work reasonably well. I'll take a look. C |
From: Philip T. <ph...@te...> - 2005-02-28 18:30:24
|
On Mon, 2005-02-28 at 10:15 -0800, Craig Hughes wrote: > Yes, the 8250 driver conflicts with the PXA serial driver -- which is > why CF serial cards will have trouble working too. In other words, > it's really a Problem Which Needs Solving anyway. From reading RMK's > postings on the linux-arm mailing list, it sounds like really the way > the PXA driver does things is bad and wrong, and can't really be > properly resolved in the "correct" way with ease. But I've never been > averse to implementing the pragmatic when the ideal is unreasonable. > Probably just hijacking some major/minor device numbers for something > we'll never reasonably see on a PXA device for the PXA serial ports > (such as say char-major-11) would work reasonably well. I'll take a > look. > Right, I'll start looking for a quad or Octal UART then... :) Phil |
From: David F. <dav...@ya...> - 2005-02-28 18:46:32
|
Can it be predefined that these new uarts are never console ports. It would makes things much easier, right? Does Phil need additional consoles? David. --- Craig Hughes <cr...@hu...> wrote: > On Feb 28, 2005, at 8:39 AM, Philip Trickett > wrote: > > > This way you could use the 820 serial support > already built in to the > > kernel. Although, I did read on my monthly > trawl through the ARM kernel > > mailing list that the 820 driver and the PXA > serial driver conflict on > > port naming issues. > > Yes, the 8250 driver conflicts with the PXA > serial driver -- which is > why CF serial cards will have trouble working > too. In other words, > it's really a Problem Which Needs Solving > anyway. From reading RMK's > postings on the linux-arm mailing list, it > sounds like really the way > the PXA driver does things is bad and wrong, > and can't really be > properly resolved in the "correct" way with > ease. But I've never been > averse to implementing the pragmatic when the > ideal is unreasonable. > Probably just hijacking some major/minor device > numbers for something > we'll never reasonably see on a PXA device for > the PXA serial ports > (such as say char-major-11) would work > reasonably well. I'll take a > look. > > C > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT > Products from real users. > Discover which products truly live up to the > hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Philip T. <ph...@te...> - 2005-02-28 18:57:15
|
On Mon, 2005-02-28 at 10:46 -0800, David Farrell wrote: > Can it be predefined that these new uarts are > never console ports. It would makes things > much easier, right? Does Phil need additional > consoles? > > David. Would be nice. Yu could have a BBS run by a gumstix.... Nah, I think that having them for general serial use would be preferable. Would this be good for the robotics people as well? (Thinking multi limbed mechanical creatures requiring lots of MCU's here...) Phil |