16550 Uarts vs 16650 Uarts!

16550 Uarts vs 16650 Uarts!

Post by Theodore Y. Ts' » Wed, 16 Oct 1996 04:00:00




   Date: Sat, 12 Oct 1996 07:55:31 GMT

   But 230400 and 460800 bps was already possible before that patch!
   It's only the POSIX speedsetting braindamage that disallowed that.

   I am running one line at 7812 bps and one at 76800 bps using a 460800
   baud_base.  That cannot be done using POSIX tcsetospeed even with your
   patch.  You would have to add an infinite series of Bxxxx entries to the
   silly table.

   The TIOCSSERIAL ioctl does it without pain, so I just use that.  Hopefully
   the POSIX folks wake up sometime and add a speed setting call that gets
   an integer argument that directly specifies the bitrate.

Yes, but it's much easier to get application programmers to support
230400 and 460800 if you provide a way to do it within the standard
POSIX framework.  I agree with you that the standard POSIX framework
is.... non-optimal.  However, backwards compatibility with old systems
was a extremely important for the POSIX folks, for better or for worse.

                                                - Ted

 
 
 

16550 Uarts vs 16650 Uarts!

Post by Emanuele Girland » Thu, 17 Oct 1996 04:00:00




>    Date: Sat, 12 Oct 1996 07:55:31 GMT

>    But 230400 and 460800 bps was already possible before that patch!
>    It's only the POSIX speedsetting braindamage that disallowed that.

>    I am running one line at 7812 bps and one at 76800 bps using a 460800
>    baud_base.  That cannot be done using POSIX tcsetospeed even with your
>    patch.  You would have to add an infinite series of Bxxxx entries to the
>    silly table.

>    The TIOCSSERIAL ioctl does it without pain, so I just use that.  Hopefully
>    the POSIX folks wake up sometime and add a speed setting call that gets
>    an integer argument that directly specifies the bitrate.

> Yes, but it's much easier to get application programmers to support
> 230400 and 460800 if you provide a way to do it within the standard
> POSIX framework.  I agree with you that the standard POSIX framework
> is.... non-optimal.  However, backwards compatibility with old systems
> was a extremely important for the POSIX folks, for better or for worse.

>                                                 - Ted

Are you guyes aware that the 4.4 bsd derived systems have exactly done
this? I'm almost sure that there the B* defines are

#define B38400 38400
#define B115200 115200

and so on. I don't think posix mandates that the numbers must be small
integers. And this way if the header files don't support B230400 you can
just use 230400 in your program.

        paolo zeppegno

 
 
 

1. 16550 Uarts vs 16650 Uarts!

I was going through my AST fourport compatible serial card's manual,
and was amazed to see they mentioned the card is compatible with 16650
Uarts I imeadiatly thought that was a typo and then did some poking
arround!

In the serial.c source code there are numerous reference's to a 16650
Uart which seems to be able to handle a 32 bit buffer, but it also seems
to be disabled for some reason.

Does anyone know anything about this uart and how we can ge the full
potential out of it??

Thanks!

2. Kernel change summary 1.1.80 -> 1.1.81

3. 16550 and 16650 UARTS

4. make: 1254-033 A macro cannot define itself

5. Is my modem UART 16450 or UART 16550 ?

6. named malloc error on Sparc20

7. IO Card UARTS 16550 vs 16450??

8. Linux music programs?

9. 16650 UART based boards

10. 3com Impact IQ with Lavaport-ISA 16650 UART serial

11. 16650 UART Support

12. 16650 UART support ?