Page 4 of 5 FirstFirst ... 2345 LastLast
Results 46 to 60 of 74

Thread: Make an expansion board with a serial port(s) for WL-500b/g

  1. #46
    Join Date
    Sep 2004
    Location
    Austria
    Posts
    125
    Another question concerning the extif: I have read sbextif.h and sbmips.c, where the timing/delay parameters are initialized:
    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 */
    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).
    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)
    Attached Images Attached Images  

  2. #47
    Join Date
    Dec 2003
    Location
    Czech Republic
    Posts
    270
    Quote Originally Posted by wtzm
    ...
    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.

  3. #48
    Join Date
    Sep 2004
    Location
    Austria
    Posts
    125
    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?

  4. #49
    Join Date
    Dec 2005
    Location
    Moscow, Russia
    Posts
    3
    Quote 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...
    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.
    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...

  5. #50
    Join Date
    Sep 2004
    Location
    Austria
    Posts
    125
    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...

  6. #51
    Join Date
    Dec 2005
    Location
    Moscow, Russia
    Posts
    3
    Quote Originally Posted by wtzm

    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) ?
    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.

  7. #52
    Join Date
    Sep 2004
    Location
    Austria
    Posts
    125
    Quote Originally Posted by Artie
    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) ?
    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.
    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).

  8. #53
    Join Date
    Dec 2005
    Location
    Moscow, Russia
    Posts
    3
    Quote Originally Posted by wtzm
    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.
    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...
    Sorry, then I have no ideas.

    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...

    Quote Originally Posted by wtzm
    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).
    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.
    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).
    Attached Images Attached Images     
    Last edited by Artie; 13-12-2005 at 20:31.

  9. #54
    Join Date
    Dec 2003
    Location
    Czech Republic
    Posts
    270
    Quote Originally Posted by wtzm

    @Technik: In post #21 you wrote about similar problems, did you solve them?
    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.

    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; 14-12-2005 at 00:29.

  10. #55
    Join Date
    Sep 2004
    Location
    Austria
    Posts
    125
    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.

  11. #56
    Join Date
    Dec 2003
    Location
    Czech Republic
    Posts
    270
    Quote Originally Posted by wtzm
    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.

  12. #57
    Join Date
    Sep 2004
    Location
    Austria
    Posts
    125
    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.

  13. #58
    Join Date
    Sep 2004
    Location
    Austria
    Posts
    125
    Quote Originally Posted by Technik
    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...
    Doesn't work for me.
    Setting the UART type with
    Code:
    setserial /dev/tts/0 uart 16550
    (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...

  14. #59
    Can I have one of your's trx files?

  15. #60
    Join Date
    Sep 2004
    Location
    Austria
    Posts
    125
    Quote Originally Posted by vlad75
    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.

Page 4 of 5 FirstFirst ... 2345 LastLast

Similar Threads

  1. Howto add serial port to WL-500gx/gp
    By Josephus in forum WL-500g/WL-500gx Tutorials
    Replies: 50
    Last Post: 05-11-2012, 12:32
  2. Use an USB-serial port converter
    By Technik in forum WL-500g/WL-500gx Tutorials
    Replies: 39
    Last Post: 24-04-2012, 11:54
  3. Serial port for WL-500g
    By sveasoft in forum WL-500g Pics & Specs
    Replies: 6
    Last Post: 08-03-2005, 22:39

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •