OpenWrt Forum Archive

Topic: Speed of WRT54G V2 serial port

The content of this topic has been archived on 14 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi,

I want to use the serial port of my WRT54G V2 with some hardware that requires a speed of 460800(=115200 * 4) Baud. Can this be achieved with the WRT54G?

If not I'll have to add a litte microcontroller to translate between the two baudrates and that would just slow down everyting.

Thanks in advance,
Tobias Schneider

root@Boone:~# setserial /dev/tts/0 baud_base 11980800
root@Boone:~# cat /proc/tty/driver/serial
serinfo:1.0 driver:5.05c revision:2001-07-08
0: uart:16550A port:B8000300 irq:3 baud:460800 tx:257 rx:0 RTS|DTR
1: uart:16550A port:B8000400 irq:3 baud:4800 tx:437140 rx:422914 brk:3 RTS|CTS|DTR|DSR|CD

So it looks like I can set that baud rate... but does it actually work?

I have no idea and I don't think I've got anything handy to test it with that'll go that fast.

(Last edited by Boone on 23 Apr 2006, 05:48)

Tobias:

What baud_base does setserial currently report for you? If it's 460800 or a multiple of it, you're in luck. If not, you'll need to change the crystal that your UART uses to a multiple of 16 times 460800 (like the 7.3728MHz I mention below) - I haven't seen a v2 WRT54G board, so I don't know how hard this mod will be (probably quite easy if you're good at soldering). Then you will probably need to use setserial (or recompile your kernel) to tell linux what the the new baud_base is.

If you're using RS232 level convertors rather than plain TTL, you may be in trouble there too - the MAX223 convertors that I'm going to be using (because they fit on the v1.0 board) are only specced up to 120kbaud. You may need to check what speed your convertors are rated for.

Boone:

Where are you getting that baud_base of 11980800 from? The baud_base should be set to the highest baud rate the UART can support, which on the 16550 and similar UARTs is one sixteenth the oscillator frequency the hardware supplies to the UART. Does your UART have a 191.692800MHz crystal or oscillator? Any of the datasheets I've looked at for the 16550, 16552, 162552, 16652 etc (D)UARTs seem to suggest that the highest frequency they can support is 24MHz or in some cases 48MHz, giving a baud_base of 1500000 or 3000000.

All:

I'm going to fit two serial ports to my v1.0 WRT54G (see http://cjb.ie/reveng.txt for the excruciating details) but I'm trying to figure out what crystal frequency to fit (it's currently unpopulated). A lot of WRT54G hackers seem to mention 12.75MHz with a divisor of 7, which close to (16*)115200, but a couple of percent off. 12.9MHz/7 would give a pretty accurate 16*115200. I have some 7.3728MHz oscillators, which are exactly 4*16*115200 (and would make the basebaud exactly 460800); but I'm trying to find out how (or if) the kernel will detect this automatically, or if it assumes a baud_base of 796875 (which is correct for a 12.75MHz crystal).

Anyway, if anyone knows why WRT54G hackers are using 12.75MHz for UARTs, I'd love to hear about it. Thanks!

Christian

Hi,
I've located a 48MHz crystal on my V2.0 board which I easily could replace with a 7.3728MHz crystal. The current crystal gives the 3MBaud mentioned by you.
Is the UART the only unit of the router which uses the crystal? If not I'll propably have to recompile the kernel to match. I belive, that the CPU uses this clock to generate its main clock. With a 7.3Mhz crystal this clock would be 1/7th compared to 48Mhz.

Anyway I'll take a look at the source code to see if i can get some informations out of it smile

As I'm going to use the 3.3V signalas of the port directly I'll have no problems with level converters.
Many thanks for your information! I'll report my results.

Tobias

minus1:  My attempt was a completely uneducated attempt.  I just basically played with the numbers and a calculator to get /proc/tty/driver/serial to spit out the correct baud rate smile

Thanks for your insightful post however, much appreciated!

Tobias:

I'm not familiar with the v2 board - are there any other crystals on it? I took a look at http://www.linksysinfo.org/modules.php? … =6#wrt54g2 but the pictures there are not detailed enough for me to get a good "feel" for the board. Can you take high resolution pictures?

Can you follow the tracks from the 48MHz crystal to find out where it goes? If the 48MHz is used elsewhere on the board, you really only want to change the frequency going to the UART; the circuit board layout will decide if this is easy. Can you find the UART on the board and figure out where its clock signal comes from?

If the 48MHz goes everywhere - don't forget that any multiple of 7.3728MHz will do nicely for the UART. To take an example, 4*7372800 is 29491200; if you got a 29.5MHz crystal, that would give you a baud_base of 1843750bps, and you could divide that by 4 to get 460937, which is a deviation of less than 0.03% from the baud rate you want (given 8N1 asynchronous communication, baud rates of sender and receiver can differ by several % without any problem). Compared to 48MHz, other components would run about 85% slower on 7.3728MHz - less than one sixth of original speed - or about 40% slower on 29.5MHz - a little over half the original speed.

Have you much experience of kernel hacking? I've tried reading 8250.c to figure out whether it autodetects the UART baud_base in some way, or just uses a value it gets some other way, perhaps some default compiled in. If you can figure that out for me I'd be very grateful - I'm still trying to figure out why pages like http://wiki.openwrt.org/OpenWrtDocs/Cus … 5717c211f5 recommend a strange frequency of 12.75MHz giving an even stranger baud_base of almost (but not quite) 7*115200; UART datasheets almost invariably recommend frequencies that are a power of two times 16*115200.

Edit:

I note from http://www.linksysinfo.org/modules.php? … id=6#table that the v1 and v2 boards have a different MCU (v1: BCM4072KPB; v2: BCM4712KPB); I can't see a separate UART on the v2 board, so it may be integrated into the BCM4712. I can't find a proper datasheet online for the 4712, but it probably uses that 48MHz to run lots of other integrated peripherals - including things like generating radio or ethernet data rates - so changing the crystal will probably break everything.

So... where to go from here? Here are the options that I can see, listed in order of increasing pain/messiness:

1. If the device you're connecting to is running its serial port well within spec or a bit slow, talking to it at 428571bps /may/ work (divisor set to 7). This is about 7% slow, but the total budget for speed difference on 8N1 asynchronous links is close to 10%. If the other device comes anywhere close to saturating the 460800bps link, even briefly, you're likely to see lots of framing errors; if you can configure it to send an extra stop bit, that should fix that.

2. If the device you're connecting to runs its serial port a bit fast, you could try talking to it at 500000bps (divisor set to 6); this is about 8.5% fast. Set your stop bits to 2. Some (maybe all?) 16550 clones will only require 1 receive stop bit even when sending 2, which will help a lot.

3. Change the crystal to 29.5 or 44.2 and hope this doesn't break everything else on board.

4. Get a v1.0 board, and fit a UART and a 7.3728MHz crystal (or a multiple). This will give you exactly the right baud rate, and full hardware handshaking too if you want it. The easiest way to get TTL serial connections is probably by soldering straight onto the PLCC44.

5. Put a PIC or similar in between the two devices to interface between two baud rates, as you suggested earlier. I wouldn't fancy this, though, given the lack of hardware handshaking on the v2 serial port - what happens if the PIC gets an overrun? It will need to signal this somehow; or your protocol on the WRT54G will need to be very resilient to characters that go missing without generating an error condition.

Boone:

No worries, for a moment you had me hoping there were WRT54G's out there with the UART fed by a programmable frequency generator :)

Christian

(Last edited by minus1 on 27 Apr 2006, 08:35)

The discussion might have continued from here.