Try 13,0MHz XTAL then... In fact I am using 12,288 MHz and it works fine as well. Please note 5% difference is perfectly OK in any case.Originally Posted by wtzm
Another question concerning the extif: I have read sbextif.h and sbmips.c, where the timing/delay parameters are initialized:
Does anyone (Oleg? ) know which timing parameters W0 to W3 are? This seems to be quite different from the BCM1250 (there are far more parameters described in the BCM1250 manual).Code:/* Set programmable interface timing for external uart */ tmp = CEIL(10, ns) << FW_W3_SHIFT; /* W3 = 10nS */ tmp = tmp | (CEIL(20, ns) << FW_W2_SHIFT); /* W2 = 20nS */ tmp = tmp | (CEIL(100, ns) << FW_W1_SHIFT); /* W1 = 100nS */ tmp = tmp | CEIL(120, ns); /* W0 = 120nS */ W_REG(&eir->prog_waitcount, tmp); /* 0x01020a0c for a 100Mhz clock */
The reason I'm asking this is that I want to add not only the (D)UART but maybe also other devices (i2c using a pcf8584 would be nice, some additional GPIO ports using 74ls273, etc...). To do this it is necessary to implement a simple address decoding circuit; the current one is quit inefficient - the lpt port is selected every time A4 is asserted, so it's not only available at 0xbf800010 but at 0xbf800018 as well because A3 is not checked. So if this is properly done the address range from 0xbf800018 to 0xbf80001f would be available for other purposes. The same is true for the range from 0xbf800400 to 0xbf80040f (if the chip select for the UART is only generated when A10 is low) and 0xbf800418 to 0xbf80041f. I have listed only these ranges because A10 and A4 to A0 are all easily accessible from pcb pads or pins and this method would give us 8+16+8=32 memory locations which should be enough for most applications.
I have attached a image, just in case my english wasn't intelligible.
BTW: Technik, have you any opinion whether it really is a 12,75MHz XTAL or rather 13,5MHz? (See post #41)
Try 13,0MHz XTAL then... In fact I am using 12,288 MHz and it works fine as well. Please note 5% difference is perfectly OK in any case.Originally Posted by wtzm
I've built the UART board, using a new PC16550DV (accidentely ordered it - I actually wanted a PC16552DV), 13,56MHz Crytal.
I haven't implemented my plans for this address decoding circuit yet, so simply connected /CS2 = /EIF_CS and CS0 = CS1 = Vcc (with CS0 = A3 PMON wouldn't print any startup message - apparently it only uses the UART at 0xbf800000) therefore the kernel recognizes one UART at 0xbf800000 and a second one at 0xbf800008. PMON access is working, but shell access via the serial console is somehow messed up - if I transmit certain characters (eg. 'o' '~' or 'ö') the shell acts as if I have pressed this character or <LF> a few times...
As the whole circuit isn't really shielded and the TX and RX wires are at the moment just loosely connected to my serial port, I first blamed these events on EM-interference or cosmic rays , but when I transmitted the same characters while using pmon, they just appeared/worked as they should.
I'm using minicom; 115200 bps, 8n1, no flow-control (and this should be the right settings...).
Any ideas why this is happening?
@Technik: In post #21 you wrote about similar problems, did you solve them?
UART here programmed by PMON to work with oscillator 7 times faster than in PC, so ideal crystal must be 115200x16x7 = 12.9024MHz, but +/-5% also would be Ok.Originally Posted by wtzm
13.56MHz gives you baudrate 121071 (instead of 115200), which exceed 5% margins and it's a cause of this seldom errors...
So just change your crystal to 13MHz...
Thanks the answer.
Hm... will try this; I also have a 12,75MHz ready. But I still don't understand why this error _never_ appears in PMON, but can be reproduced reliably after startup, when using the shell...
As far as I understand you, your comp always receive bytes from WL without errors ('cause PMON only send data, don't receive it), but WL sometimes "misunderstand" bytes from comp (when you try to work with shell) ?Originally Posted by wtzm
If so, maybe it depends on schematic of UART chip in your comp (how much times and at which phase it samples each received bit; - there was many different chips, and some of them doesn't perform proper majoritation on tree samples per bit).
In any case, 13.56MHz - is not a right frequency.
Not completely correct. I have communicated with PMON (if you cancel the boot with Ctrl+C) succesfully und this works - I can issue commands, etc.Originally Posted by Artie
With PMON if I send an 'o' it receives (and echoes back) an 'o'. This doesn't work on the console (after bootup). Sometimes it echoes a few 'o', or it acts as if I had transmitted a line-feed.
In the meantime I have conducted tests with my 12,75MHz Crytal. The results are the same...
By the way from where do you know that PMON expects a frequency of 7x the standard (1.8432MHz)?
I still have the opinion that 13,5MHz is the value that the linux kernel expects for serial port initialization (-> sbmips.c).
Sorry, then I have no ideas.Originally Posted by wtzm
You can try to send some characters with chess-board patterns in upper nibble (for example 0x55 - 'U' or 0xAA - 'ê') and check how they will be echoed back...
Frequency from XTAL1 pin in all UART chips (if they are 8250 compatible, of course) divided by 16-bit value of DLL/DLH register pair (and you can see this frequency at BAUDOUT' pin of your UART by scope) then divided by 16; - thus we get needed baudrate.Originally Posted by wtzm
So, to get 115200 baud with 13.5MHz crystal we must load DLL/DLH with value of 7,32421875... But this registers are integer , so we can only load either 7 or 8. - In first case we will have 120536 baud, in second - 105469. Not 115200...
Btw, my port-extender to WL500G works fine with "canonical" 1.843MHz (look at generator on second photo) - it's only needed to set PC terminal to 16457 baud. Some terminal programs doesn't know how to do this, but mine - know.
Another way to get 115200 baud with 1.843 quartz - setserial /dev/tts/0 baud_base 115200 divisor 1 spd_cust (but this will work only untill reboot, of course).
Last edited by Artie; 13-12-2005 at 19:31.
No - it seems that Kernel is not able to receive bytes from UART correctly (input - it looks like MSB is corrupted - sometimes - and incorrectly recognized as logical H). Output seems to be OK in any case. In PMON everything works fine in both directions. I did not analyze this problem deeply yet nor tried to change any serial port parameters.Originally Posted by wtzm
Update: I have just tried Bray's Terminal 1.9b (http://bray.velenje.cx/avr/terminal/) instead of Hyperterminal and set parameters to 115200, 8, space, 1, XON/XOFF. No more corrupted characters...
Last edited by Technik; 13-12-2005 at 23:29.
I have already tried enabling software flow-control and the different parity settings, but I've never tried _both_...
I will try this as soon as possible.
I have tried the same in Hyperterminal - no luck. I don't say Hyperterminal is bad but... Strange anyway. Perhaps changing default ttys0 parameters could be the right way.Originally Posted by wtzm
Hm... I was using minicom for my tests, but I don't have time at the moment to test this with parity and sw-flowcontrol.
Doesn't work for me.Originally Posted by Technik
Setting the UART type with
(it was set to a 16550A - which is AFAIK correct for a PC16550DV) and killing the currently running shell for tts/0, solved my problems, but I really don't understand why...Code:setserial /dev/tts/0 uart 16550
Can I have one of your's trx files?
Ehm... I don't have any firmware with embedded setserial - the setserial program was copied to the router using scp.Originally Posted by vlad75