Hi folks,
Has anybody tried to use differential drivers for this purpose ...???
You might get better result with that.
kb
----- Original Message -----
From: Arie de Muynck
To: l...
Sent: Sunday, August 20, 2006 6:58 AM
Subject: Re: [lpc2000] Re: UART1 problem receiving but ok transmitt
From: "Tom Walsh"
> Yes, I have used that in an 8051 design. The thing to remember about
> RS485 is that you are working with inductance + capacitance of the wires
> interconnecting the devices. That will affect the data rate at which
> you can send, the longer the distance, the lower the baudrate.
> Typically, 9600 baud will only go maybe several hundred feet before
> distortion occurs due to the complex filter charactoristics the wire
> presents itself at. Termination of both ends of the wire with
> 300..600ohms does help, but it is not a cureall.
An RS485 is meant to be used with transmission lines: twisted pair,
terminated at BOTH ends with 100..120 Ohms (depending on the wire
characteristic impedance). A ground wire must be used to. If the receiver
cannot stand noise in the idle state biasing should be added on one
position
of the cable.
If properly connected 100 kbps should be useable over 1000 meters.
> BTW, as unbelievable as this may sound, there was one installation for a
> school district in New Jersey where we discovered that the TelCo BA
> lines between two points was 14miles! That data link worked solid with
> no errors at 1200 baud!
Certainly attainable if a shielded cable is used with the shield connecting
the commons of the RS485 transceivers and at least one side is galvanically
isolated. If not isolated, any lightning strike in the vicinity will
introduce enough common mode voltage to destroy drivers or receivers. The
line should be used unterminated (or with an AC termination), the DC
resistance of the wire would probably be too high to use a 120 Ohm far end
termination, and the damping of the reflected wave in 14 mile is high
enough
to live without terminators anyway.
Regards,
Arie de Muijnck
------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/418 - Release Date: 8/14/2006
From: "Tom Walsh" > Yes, I have used that in an 8051 design. The thing
to remember about
> RS485 is that you are working with inductance + capacitance of the wires
> interconnecting the devices. That will affect the data rate at which
> you can send, the longer the distance, the lower the baudrate.
> Typically, 9600 baud will only go maybe several hundred feet before
> distortion occurs due to the complex filter charactoristics the wire
> presents itself at. Termination of both ends of the wire with
> 300..600ohms does help, but it is not a cureall.
An RS485 is meant to be used with transmission lines: twisted pair,
terminated at BOTH ends with 100..120 Ohms (depending on the wire
characteristic impedance). A ground wire must be used to. If the receiver
cannot stand noise in the idle state biasing should be added on one position
of the cable.
If properly connected 100 kbps should be useable over 1000 meters.
> BTW, as unbelievable as this may sound, there was one
installation for a
> school district in New Jersey where we discovered that the TelCo BA
> lines between two points was 14miles! That data link worked solid with
> no errors at 1200 baud!
Certainly attainable if a shielded cable is used with the shield connecting
the commons of the RS485 transceivers and at least one side is galvanically
isolated. If not isolated, any lightning strike in the vicinity will
introduce enough common mode voltage to destroy drivers or receivers. The
line should be used unterminated (or with an AC termination), the DC
resistance of the wire would probably be too high to use a 120 Ohm far end
termination, and the damping of the reflected wave in 14 mile is high enough
to live without terminators anyway.
Regards,
Arie de Muijnck
Reply by Tom Walsh●August 19, 20062006-08-19
fredrikssonjohan wrote:
> Hi All,
>
> Some comments back on my own post.
>
> I have tried with blinking a led every time I'm supposed to received a
> char and that LED is blinking rock solid (even if it doesn't say if
> it's a correct received char ;-) ).
>
> Second, I tested against a RS-232 chip instead and it was rock solid
> echoing of the char I sent to it so I presume, once again, that the
> actual code for receiving and sending is ok and it's something with
> timing or simular that makes it go wrong when using the RS485 chip.
>
> As I can send without any problem it looks like, and I have verified
> the schema/pcb many times now, the connections between LPC2106 and the
> MAXIM circuit should be fine.
>
> So, doing a test with interrupt handling on the comms RX part could be
> worth it. Shall have a look at the errata also.
>
> Someone here that have worked with the MAX1480B chip?
> Yes, I have used that in an 8051 design. The thing to remember about
RS485 is that you are working with inductance + capacitance of the wires
interconnecting the devices. That will affect the data rate at which
you can send, the longer the distance, the lower the baudrate.
Typically, 9600 baud will only go maybe several hundred feet before
distortion occurs due to the complex filter charactoristics the wire
presents itself at. Termination of both ends of the wire with
300..600ohms does help, but it is not a cureall.
Typically all our stuff is 1200baud, nine bit data (start+9bits+stop,
essentially "stick parity").
The other thing that you have to consider when doing half duplex: when
you have both ends in RX mode, then set one side to TX, there is a
finite time interval in which you are "charging the lines". Usually
20..50ms precharge (front porch) is sufficient before you actually start
sending data out. Then, when the last bit of the last char is sent, you
have to hold the line (back porch) for about 10..15ms to allow a nice
idle interval to exist, the drop the carrier.
As to the MAX1480, I know that it can run full duplex, I've never used
it that way as a lot of the equipment I design is targeted towards
installation in older buildings. Most times you can only find a pair of
wires to use, customers hate to be told that they have to run all new
cable just so we can have full-duplex operation! Typically, you can
find that single wire pair to use.
BTW, as unbelievable as this may sound, there was one installation for a
school district in New Jersey where we discovered that the TelCo BA
lines between two points was 14miles! That data link worked solid with
no errors at 1200 baud!
OK,
Disabling the DC-DC Converter of MAX1480:
- Measure Voltage of PIN 26
- Disconnect PIN1 & PIN2 (May be PIN 8 also) from VCC
- Inject same measured voltage to PIN26, attach
a bigger decoupling capacitor. Take note of capacitor
should be connecting to that RS485 floating ground.
=> Pls don't blame me if your MAX1480/LPC2106 burnt
=> Have fun... and good luck..
BTW: May be you should short your LPC2106 ground to the
RS485 Isolated ground first. Remove possiblity of some
components not conected to the correct ground...
Regards
--- In l..., "unity0724" wrote: >
> Hi,
> For pull up, I use 20KR if there are heavy loading of 32x
> devices (Sometimes actually overloading up to >50 ...out
> of spec), and 3.3KR if only point to point. All these
> were done on SN75176, not MAX1480.
>
> It might help your debugging if you could remove that
> MAX1480 and wire a simple SN75176 to get software
> working first. The opto-coupler Hi-V isolation should
> be "fully transparent" to your software. If it works on a
> simple SN75176, it should work on MAX1480.
>
> For MAX1480 debugging, could you find some way to
> disable that DC-DC isolated supply converter.... :)
> and inject some regulated power supply first.
>
> Sorry, Cannot think of anything else.... :)
>
> I was thinking of using ADM2483 instead of MAX1480.
> DigiKey is unable to ship any Maxim or LinearTech parts
> to Singapore here (...sales boundary...) and having some
> problem with prototyping qty. ADM2483 is cheaper
> (after external DC-DC Converter included), looks very much
> like a SN75176, plus I also do not really like that MAX1480.
>
> Have not read the MAX1480 in detail. Let me do that later
> and see if I can provide you some debugging aids...
>
> ...Have fun.. and good luck... :)
> Regards
>
> --- In l..., "fredrikssonjohan" wrote:
> >
> > Hi Unity0724 and others,
> >
> > Well, running out of things to try, it's only pulling A hi and B
> low
> > that is left to test for now. What values would you recommend? I've > > never had any need to so before.
> >
> > I must say that I've never had this much hard work with normal
> RS485
> > ic's from maxim. And getting the TX to work perfect but not the RX > is
> > very frustrating!
> >
> > It's one of the the few fully isolated RS485 circuits around so
> there
> > wasn't much to choose from! Might need to look for alternatives... > >
> > Back to testing...
> >
> > Cheers
> > Johan
> >
> >
> > --- In l..., "unity0724" wrote:
> > >
> > > For RS485...
> > >
> > > - Make sure you pull up A/'+' signal and Pull down
B/'-' signal > on
> > > the RS485 bus
> > > - Make sure you use TEMT to disable your RS485 driver. Do NOT
> > > disable the RS485 driver immediately after you write the
> > > character to UART. That character will be slowly shifted out > > > and only completed shifting out of the UART
when TEMT is set.
> > > - RS485 is half-duplex, if you do not disable the RS485 receiver > > > when transmitting, there will be character
echo-ed back to UART > > > receiver every time you transmit a character
> > > - For some RS485 interface parts, there might be "glitches" on
> the
> > > bus signal when you disable the RS485 driver (but this normally > > > get filtered off by the UART receiver)
> > >
> > > Sorry, cannot think of anything else... and Good Luck
> > > Regards
> > >
> > > BTW: I was actually happen to use that MAX1480 in the planning.
> > > Please give some info of the problem after all this... :)
> > >
> > >
> > >
> > > --- In l..., "fredrikssonjohan"
> wrote:
> > > >
> > > > Hi All,
> > > >
> > > > Some comments back on my own post.
> > > >
> > > > I have tried with blinking a led every time I'm supposed to
> > > received a
> > > > char and that LED is blinking rock solid (even if it doesn't
> say if
> > > > it's a correct received char ;-) ).
> > > >
> > > > Second, I tested against a RS-232 chip instead and it was rock > > > solid
> > > > echoing of the char I sent to it so I presume, once again,
> that the
> > > > actual code for receiving and sending is ok and it's something > with
> > > > timing or simular that makes it go wrong when using the RS485 > chip.
> > > >
> > > > As I can send without any problem it looks like, and I have
> > > verified
> > > > the schema/pcb many times now, the connections between LPC2106 > and
> > > the
> > > > MAXIM circuit should be fine.
> > > >
> > > > So, doing a test with interrupt handling on the comms RX part > > > could be
> > > > worth it. Shall have a look at the errata also.
> > > >
> > > > Someone here that have worked with the MAX1480B chip?
> > > >
> > > > Thanks for all the input and comments so far. Anything more of > > > ideas
> > > > or thoughts are, as before, very very welcome.
> > > >
> > > > Cheers
> > > > /Johan
> > > >
> > > > --- In l..., "fredrikssonjohan"
> wrote:
> > > > >
> > > > > Hi!
> > > > >
> > > > > I'm stucked with this and can't figure out why it will not
> work.
> > > > > Anyone seeing the obvious or have any friendly ideas of what > > > might be
> > > > > wrong?
> > > > >
> > > > > OK. I'll try to give an as good description as possible of
> what
> > > I have
> > > > > and try do. The first problem is that if I send, as a test, > > > 8 "A" I
> > > > > will get 4 or 5 "A"s in return and then one or two non ascii > > > visible
> > > > > chars and mostly a FF as end. I would say the successrate is > 3-4
> > > per
> > > > > 20 sent blocks of 8 "A". So there is my problem. No clean RX > on
> > > the
> > > > > LPC2106 with this MAX1480B.
> > > > >
> > > > > There is a LPC2106 connected via a 74HC86 and finally the
> Maxim
> > > > > MAX1480B opto/power isolated circuit. This is all connected > as
> > > per
> > > > > MAXIMSs datasheet and work 100% when sending data. Never
> miss a
> > > single
> > > > > bit.
> > > > > As I never have any TX problem I figure that the init part
> of
> > > the port
> > > > > should be OK.
> > > > >
> > > > > As a stripped down testing routine I do the following:
> > > > > while (1)
> > > > > {
> > > > > cbuff[icnt] = wait_and_receive();
> > > > > icnt++;
> > > > >
> > > > > if (icnt == 8)
> > > > > {
> > > > > icnt = 0;
> > > > > IOSET = (1<
> > > > > pause(TWO_MS);
> > > > > for (int j = 0; j < 8; j++)
> > > > > uart1Putch(cbuff[j]);
> > > > >
> > > > > // Back to RX mode again
> > > > > IOCLR = (1<
> > > > > pause(TWO_MS);
> > > > > }
> > > > > }
> > > > >
> > > > > Im just waiting for any char in the RX buffer and switch to > > > RS486 TX
> > > > > mode and send it back. Added a small delay after switching
> mode
> > > on the
> > > > > RS485 line just to be sure.
> > > > >
> > > > > Using this bit just for pool until there is a char available > > > > > int wait_and_receive(void)
> > > > > {
> > > > > int ch;
> > > > >
> > > > > while((ch = uart1Getch()) == -1) {
> > > > > ;
> > > > > }
> > > > > return ch;
> > > > > }
> > > > >
> > > > > And this is the actual code checking if the is a char
> available.
> > > > > The uart1Getch(...) loooks like this:
> > > > > if (U1LSR & ULSR_RDR) // check if character is available
> > > > > return U1RBR; // return character
> > > > > return -1;
> > > > >
> > > > > The init is done by this and works perfect for TX
> > > > > void uart1Init(uint16_t baud, uint8_t mode, uint8_t fmode)
> > > > > {
> > > > > // set port pins for UART1
> > > > > PINSEL0 = (PINSEL0 & ~U1_PINMASK) | U1_PINSEL;
> > > > >
> > > > > U1IER = 0x00; // disable all
> interrupts
> > > > > U1IIR; // clear interrupt ID > > > > > U1RBR; //
clear receive
> register
> > > > > U1LSR; // clear line status > > > register
> > > > >
> > > > > // set the baudrate
> > > > > U1LCR = ULCR_DLAB_ENABLE; // select divisor
> > > latches
> > > > > U1DLL = (uint8_t)baud; // set for baud low > byte
> > > > > U1DLM = (uint8_t)(baud >> 8); // set for baud high > byte
> > > > > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > > > > U1FCR = fmode;
> > > > > }
> > > > >
> > > > > Wow, sorry for the long message and code, but otherwise I
> guess
> > > > > someone is asking how that and that is done so I include it > from
> > > the
> > > > > start.
> > > > >
> > > > > If anyone have a clue or idea I would be very happy guy!
> > > > >
> > > > > Cheers
> > > > > Johan
> > > > >
> > > >
> > >
>
Reply by unity0724●August 19, 20062006-08-19
Hi,
For pull up, I use 20KR if there are heavy loading of 32x
devices (Sometimes actually overloading up to >50 ...out
of spec), and 3.3KR if only point to point. All these
were done on SN75176, not MAX1480.
It might help your debugging if you could remove that
MAX1480 and wire a simple SN75176 to get software
working first. The opto-coupler Hi-V isolation should
be "fully transparent" to your software. If it works on a
simple SN75176, it should work on MAX1480.
For MAX1480 debugging, could you find some way to
disable that DC-DC isolated supply converter.... :)
and inject some regulated power supply first.
Sorry, Cannot think of anything else.... :)
I was thinking of using ADM2483 instead of MAX1480.
DigiKey is unable to ship any Maxim or LinearTech parts
to Singapore here (...sales boundary...) and having some
problem with prototyping qty. ADM2483 is cheaper
(after external DC-DC Converter included), looks very much
like a SN75176, plus I also do not really like that MAX1480.
Have not read the MAX1480 in detail. Let me do that later
and see if I can provide you some debugging aids...
...Have fun.. and good luck... :)
Regards
--- In l..., "fredrikssonjohan" wrote: >
> Hi Unity0724 and others,
>
> Well, running out of things to try, it's only pulling A hi and B low > that is left to test for now. What values would you
recommend? I've
> never had any need to so before.
>
> I must say that I've never had this much hard work with normal RS485 > ic's from maxim. And getting the TX to work
perfect but not the RX is > very frustrating!
>
> It's one of the the few fully isolated RS485 circuits around so there > wasn't much to choose from! Might need to look
for alternatives...
>
> Back to testing...
>
> Cheers
> Johan
> --- In l..., "unity0724" wrote:
> >
> > For RS485...
> >
> > - Make sure you pull up A/'+' signal and Pull down B/'-'
signal on > > the RS485 bus
> > - Make sure you use TEMT to disable your RS485 driver. Do NOT
> > disable the RS485 driver immediately after you write the
> > character to UART. That character will be slowly shifted out
> > and only completed shifting out of the UART when TEMT is set.
> > - RS485 is half-duplex, if you do not disable the RS485 receiver
> > when transmitting, there will be character echo-ed back to UART
> > receiver every time you transmit a character
> > - For some RS485 interface parts, there might be "glitches" on the > > bus signal when you disable the RS485 driver (but
this normally
> > get filtered off by the UART receiver)
> >
> > Sorry, cannot think of anything else... and Good Luck
> > Regards
> >
> > BTW: I was actually happen to use that MAX1480 in the planning.
> > Please give some info of the problem after all this... :)
> >
> >
> >
> > --- In l..., "fredrikssonjohan" wrote: > > >
> > > Hi All,
> > >
> > > Some comments back on my own post.
> > >
> > > I have tried with blinking a led every time I'm supposed to
> > received a
> > > char and that LED is blinking rock solid (even if it doesn't say if > > > it's a correct received char ;-) ).
> > >
> > > Second, I tested against a RS-232 chip instead and it was rock
> > solid
> > > echoing of the char I sent to it so I presume, once again, that the > > > actual code for receiving and sending is ok and
it's something with > > > timing or simular that makes it go wrong when
using the RS485 chip. > > >
> > > As I can send without any problem it looks like, and I have
> > verified
> > > the schema/pcb many times now, the connections between LPC2106 and > > the
> > > MAXIM circuit should be fine.
> > >
> > > So, doing a test with interrupt handling on the comms RX part
> > could be
> > > worth it. Shall have a look at the errata also.
> > >
> > > Someone here that have worked with the MAX1480B chip?
> > >
> > > Thanks for all the input and comments so far. Anything more of
> > ideas
> > > or thoughts are, as before, very very welcome.
> > >
> > > Cheers
> > > /Johan
> > >
> > > --- In l..., "fredrikssonjohan" wrote: > > > >
> > > > Hi!
> > > >
> > > > I'm stucked with this and can't figure out why it will not work. > > > > Anyone seeing the obvious or have any friendly
ideas of what
> > might be
> > > > wrong?
> > > >
> > > > OK. I'll try to give an as good description as possible of what > > I have
> > > > and try do. The first problem is that if I send, as a test,
> > 8 "A" I
> > > > will get 4 or 5 "A"s in return and then one or two non ascii
> > visible
> > > > chars and mostly a FF as end. I would say the successrate is 3-4 > > per
> > > > 20 sent blocks of 8 "A". So there is my problem. No clean RX on > > the
> > > > LPC2106 with this MAX1480B.
> > > >
> > > > There is a LPC2106 connected via a 74HC86 and finally the Maxim > > > > MAX1480B opto/power isolated circuit. This is
all connected as > > per
> > > > MAXIMSs datasheet and work 100% when sending data. Never miss a > > single
> > > > bit.
> > > > As I never have any TX problem I figure that the init part of > > the port
> > > > should be OK.
> > > >
> > > > As a stripped down testing routine I do the following:
> > > > while (1)
> > > > {
> > > > cbuff[icnt] = wait_and_receive();
> > > > icnt++;
> > > >
> > > > if (icnt == 8)
> > > > {
> > > > icnt = 0;
> > > > IOSET = (1<
> > > > pause(TWO_MS);
> > > > for (int j = 0; j < 8; j++)
> > > > uart1Putch(cbuff[j]);
> > > >
> > > > // Back to RX mode again
> > > > IOCLR = (1<
> > > > pause(TWO_MS);
> > > > }
> > > > }
> > > >
> > > > Im just waiting for any char in the RX buffer and switch to
> > RS486 TX
> > > > mode and send it back. Added a small delay after switching mode > > on the
> > > > RS485 line just to be sure.
> > > >
> > > > Using this bit just for pool until there is a char available
> > > > int wait_and_receive(void)
> > > > {
> > > > int ch;
> > > >
> > > > while((ch = uart1Getch()) == -1) {
> > > > ;
> > > > }
> > > > return ch;
> > > > }
> > > >
> > > > And this is the actual code checking if the is a char available. > > > > The uart1Getch(...) loooks like this:
> > > > if (U1LSR & ULSR_RDR) // check if character is available
> > > > return U1RBR; // return character
> > > > return -1;
> > > >
> > > > The init is done by this and works perfect for TX
> > > > void uart1Init(uint16_t baud, uint8_t mode, uint8_t fmode)
> > > > {
> > > > // set port pins for UART1
> > > > PINSEL0 = (PINSEL0 & ~U1_PINMASK) | U1_PINSEL;
> > > >
> > > > U1IER = 0x00; // disable all interrupts > > > > U1IIR; //
clear interrupt ID
> > > > U1RBR; // clear receive register > > > > U1LSR; //
clear line status
> > register
> > > >
> > > > // set the baudrate
> > > > U1LCR = ULCR_DLAB_ENABLE; // select divisor
> > latches
> > > > U1DLL = (uint8_t)baud; // set for baud low byte > > > > U1DLM = (uint8_t)(baud >> 8); // set
for baud high byte > > > > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > > > U1FCR = fmode;
> > > > }
> > > >
> > > > Wow, sorry for the long message and code, but otherwise I guess > > > > someone is asking how that and that is done so
I include it from > > the
> > > > start.
> > > >
> > > > If anyone have a clue or idea I would be very happy guy!
> > > >
> > > > Cheers
> > > > Johan
> > > >
> > >
>
Reply by fredrikssonjohan●August 19, 20062006-08-19
Hi Unity0724 and others,
Well, running out of things to try, it's only pulling A hi and B low
that is left to test for now. What values would you recommend? I've
never had any need to so before.
I must say that I've never had this much hard work with normal RS485
ic's from maxim. And getting the TX to work perfect but not the RX is
very frustrating!
It's one of the the few fully isolated RS485 circuits around so there
wasn't much to choose from! Might need to look for alternatives...
Back to testing...
Cheers
Johan
--- In l..., "unity0724" wrote: >
> For RS485...
>
> - Make sure you pull up A/'+' signal and Pull down B/'-'
signal on
> the RS485 bus
> - Make sure you use TEMT to disable your RS485 driver. Do NOT
> disable the RS485 driver immediately after you write the
> character to UART. That character will be slowly shifted out
> and only completed shifting out of the UART when TEMT is set.
> - RS485 is half-duplex, if you do not disable the RS485 receiver
> when transmitting, there will be character echo-ed back to UART
> receiver every time you transmit a character
> - For some RS485 interface parts, there might be "glitches" on the
> bus signal when you disable the RS485 driver (but this normally
> get filtered off by the UART receiver)
>
> Sorry, cannot think of anything else... and Good Luck
> Regards
>
> BTW: I was actually happen to use that MAX1480 in the planning.
> Please give some info of the problem after all this... :)
>
> --- In l..., "fredrikssonjohan" wrote:
> >
> > Hi All,
> >
> > Some comments back on my own post.
> >
> > I have tried with blinking a led every time I'm supposed to
> received a
> > char and that LED is blinking rock solid (even if it doesn't say if
> > it's a correct received char ;-) ).
> >
> > Second, I tested against a RS-232 chip instead and it was rock
> solid
> > echoing of the char I sent to it so I presume, once again, that the
> > actual code for receiving and sending is ok and it's something with
> > timing or simular that makes it go wrong when using the RS485 chip.
> >
> > As I can send without any problem it looks like, and I have
> verified
> > the schema/pcb many times now, the connections between LPC2106 and
> the
> > MAXIM circuit should be fine.
> >
> > So, doing a test with interrupt handling on the comms RX part
> could be
> > worth it. Shall have a look at the errata also.
> >
> > Someone here that have worked with the MAX1480B chip?
> >
> > Thanks for all the input and comments so far. Anything more of
> ideas
> > or thoughts are, as before, very very welcome.
> >
> > Cheers
> > /Johan
> >
> > --- In l..., "fredrikssonjohan" wrote:
> > >
> > > Hi!
> > >
> > > I'm stucked with this and can't figure out why it will not
work.
> > > Anyone seeing the obvious or have any friendly ideas of what
> might be
> > > wrong?
> > >
> > > OK. I'll try to give an as good description as possible of what
> I have
> > > and try do. The first problem is that if I send, as a test,
> 8 "A" I
> > > will get 4 or 5 "A"s in return and then one or two non ascii
> visible
> > > chars and mostly a FF as end. I would say the successrate is 3-4
> per
> > > 20 sent blocks of 8 "A". So there is my problem. No clean RX on
> the
> > > LPC2106 with this MAX1480B.
> > >
> > > There is a LPC2106 connected via a 74HC86 and finally the Maxim
> > > MAX1480B opto/power isolated circuit. This is all connected as
> per
> > > MAXIMSs datasheet and work 100% when sending data. Never miss a
> single
> > > bit.
> > > As I never have any TX problem I figure that the init part of
> the port
> > > should be OK.
> > >
> > > As a stripped down testing routine I do the following:
> > > while (1)
> > > {
> > > cbuff[icnt] = wait_and_receive();
> > > icnt++;
> > >
> > > if (icnt == 8)
> > > {
> > > icnt = 0;
> > > IOSET = (1<
> > > pause(TWO_MS);
> > > for (int j = 0; j < 8; j++)
> > > uart1Putch(cbuff[j]);
> > >
> > > // Back to RX mode again
> > > IOCLR = (1<
> > > pause(TWO_MS);
> > > }
> > > }
> > >
> > > Im just waiting for any char in the RX buffer and switch to
> RS486 TX
> > > mode and send it back. Added a small delay after switching mode
> on the
> > > RS485 line just to be sure.
> > >
> > > Using this bit just for pool until there is a char available
> > > int wait_and_receive(void)
> > > {
> > > int ch;
> > >
> > > while((ch = uart1Getch()) == -1) {
> > > ;
> > > }
> > > return ch;
> > > }
> > >
> > > And this is the actual code checking if the is a char available.
> > > The uart1Getch(...) loooks like this:
> > > if (U1LSR & ULSR_RDR) // check if character is available
> > > return U1RBR; // return character
> > > return -1;
> > >
> > > The init is done by this and works perfect for TX
> > > void uart1Init(uint16_t baud, uint8_t mode, uint8_t fmode)
> > > {
> > > // set port pins for UART1
> > > PINSEL0 = (PINSEL0 & ~U1_PINMASK) | U1_PINSEL;
> > >
> > > U1IER = 0x00; // disable all interrupts
> > > U1IIR; // clear interrupt ID
> > > U1RBR; // clear receive register
> > > U1LSR; // clear line status
> register
> > >
> > > // set the baudrate
> > > U1LCR = ULCR_DLAB_ENABLE; // select divisor
> latches
> > > U1DLL = (uint8_t)baud; // set for baud low byte
> > > U1DLM = (uint8_t)(baud >> 8); // set for baud high byte
> > > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > > U1FCR = fmode;
> > > }
> > >
> > > Wow, sorry for the long message and code, but otherwise I guess
> > > someone is asking how that and that is done so I include it from
> the
> > > start.
> > >
> > > If anyone have a clue or idea I would be very happy guy!
> > >
> > > Cheers
> > > Johan
> > >
>
Reply by jayasooriah●August 18, 20062006-08-18
--- In l..., "John Heenan" wrote:
> This is not helpful. I believe Brendan made an honest
attempt and has
> come to the conclusion your results are not repeatable within the
> parameters you state or imply.
Perhaps Brendan's attempts are as honest as your comments are helpful :)
> I wonder what "independent verfification" means here?
Some
> university students in a hurry plagirising results?
I find students these days have much better things to do!!!
On a more serious note, the people who pay me to solve such problems,
this problem in particular, have verified my findings and moved on.
I thought it would be useful to document it for the benefit of others
who may find themselves in a similar situation.
I certainly did not mean it to be an exercise for Brendan to see if
can stimulate the LPC and create the race conditions as I and others
have been able to.
Jaya
Reply by John Heenan●August 18, 20062006-08-18
--- In l..., "jayasooriah" wrote: >
> --- In l..., "Brendan Murphy"
> wrote:
> >
> > --- In l..., "jayasooriah" wrote: > > > No argument here. You should not be surprised
you are not able to > > > repeat my results if you do not have the right
equipment or if you do > > > not design the test to look for the particular
fact you want
> > verified.
> > >
> >
> > Eh?
> >
> > I was trying to verify your claim the UART dropped characters at low > > bit rates when there are no gaps between the
received characters. I > > verified these conditions, as I described in the
test results. If your > > tests needed some special equipment or other
condition, maybe you
> > should have shared this information before presenting the claim?
>
> Look Brendan. Call it whatever you want. I have presented tests and
> the results. It is on public record.
>
> Others have independently verified my findings. There is little point > making endless requests for more information.
>
This is not helpful. I believe Brendan made an honest attempt and has
come to the conclusion your results are not repeatable within the
parameters you state or imply.
I wonder what "independent verfification" means here? Some university
students in a hurry plagirising results?
John Heenan
> Have a nice day.
>
> Jaya
>
Reply by jayasooriah●August 18, 20062006-08-18
--- In l..., "Andrew Berney" wrote: >
> Errrm not wishing to prolong this conversation but who has independantly
> verified this? I've not seen a post from anyone who has actually verified > that the UART does indeed have the issue you claim -
did I miss something?. > It appears to be working fine for the 2129 I tested
it on.
>
> Andy
Andy,
My information is the this problem is readily replicated using the
image I provided on other (A version) variants besides the 2292/0510
on which I conducted the tests when FT232BM based dongle is used.
What is the date codes on your FT232BM and LPC2129 chips, and what
crystals frequencies are you using on these?
Jaya
Reply by unity0724●August 18, 20062006-08-18
For RS485...
- Make sure you pull up A/'+' signal and Pull down B/'-'
signal on
the RS485 bus
- Make sure you use TEMT to disable your RS485 driver. Do NOT
disable the RS485 driver immediately after you write the
character to UART. That character will be slowly shifted out
and only completed shifting out of the UART when TEMT is set.
- RS485 is half-duplex, if you do not disable the RS485 receiver
when transmitting, there will be character echo-ed back to UART
receiver every time you transmit a character
- For some RS485 interface parts, there might be "glitches" on the
bus signal when you disable the RS485 driver (but this normally
get filtered off by the UART receiver)
Sorry, cannot think of anything else... and Good Luck
Regards
BTW: I was actually happen to use that MAX1480 in the planning.
Please give some info of the problem after all this... :)
--- In l..., "fredrikssonjohan" wrote: >
> Hi All,
>
> Some comments back on my own post.
>
> I have tried with blinking a led every time I'm supposed to received a > char and that LED is blinking rock solid (even if it
doesn't say if
> it's a correct received char ;-) ).
>
> Second, I tested against a RS-232 chip instead and it was rock solid > echoing of the char I sent to it so I presume, once
again, that the
> actual code for receiving and sending is ok and it's something with
> timing or simular that makes it go wrong when using the RS485 chip.
>
> As I can send without any problem it looks like, and I have verified > the schema/pcb many times now, the connections
between LPC2106 and the > MAXIM circuit should be fine.
>
> So, doing a test with interrupt handling on the comms RX part could be > worth it. Shall have a look at the errata also.
>
> Someone here that have worked with the MAX1480B chip?
>
> Thanks for all the input and comments so far. Anything more of ideas > or thoughts are, as before, very very welcome.
>
> Cheers
> /Johan
>
> --- In l..., "fredrikssonjohan" wrote:
> >
> > Hi!
> >
> > I'm stucked with this and can't figure out why it will not
work.
> > Anyone seeing the obvious or have any friendly ideas of what might be > > wrong?
> >
> > OK. I'll try to give an as good description as possible of what I have > > and try do. The first problem is that if I send, as
a test, 8 "A" I > > will get 4 or 5 "A"s in return and then one or two
non ascii visible > > chars and mostly a FF as end. I would say the
successrate is 3-4 per > > 20 sent blocks of 8 "A". So there is my problem. No
clean RX on the > > LPC2106 with this MAX1480B.
> >
> > There is a LPC2106 connected via a 74HC86 and finally the Maxim
> > MAX1480B opto/power isolated circuit. This is all connected as per > > MAXIMSs datasheet and work 100% when sending data.
Never miss a single > > bit.
> > As I never have any TX problem I figure that the init part of the port > > should be OK.
> >
> > As a stripped down testing routine I do the following:
> > while (1)
> > {
> > cbuff[icnt] = wait_and_receive();
> > icnt++;
> >
> > if (icnt == 8)
> > {
> > icnt = 0;
> > IOSET = (1<
> > pause(TWO_MS);
> > for (int j = 0; j < 8; j++)
> > uart1Putch(cbuff[j]);
> >
> > // Back to RX mode again
> > IOCLR = (1<
> > pause(TWO_MS);
> > }
> > }
> >
> > Im just waiting for any char in the RX buffer and switch to RS486 TX > > mode and send it back. Added a small delay after
switching mode on the > > RS485 line just to be sure.
> >
> > Using this bit just for pool until there is a char available
> > int wait_and_receive(void)
> > {
> > int ch;
> >
> > while((ch = uart1Getch()) == -1) {
> > ;
> > }
> > return ch;
> > }
> >
> > And this is the actual code checking if the is a char available.
> > The uart1Getch(...) loooks like this:
> > if (U1LSR & ULSR_RDR) // check if character is available
> > return U1RBR; // return character
> > return -1;
> >
> > The init is done by this and works perfect for TX
> > void uart1Init(uint16_t baud, uint8_t mode, uint8_t fmode)
> > {
> > // set port pins for UART1
> > PINSEL0 = (PINSEL0 & ~U1_PINMASK) | U1_PINSEL;
> >
> > U1IER = 0x00; // disable all interrupts
> > U1IIR; // clear interrupt ID
> > U1RBR; // clear receive register
> > U1LSR; // clear line status register > >
> > // set the baudrate
> > U1LCR = ULCR_DLAB_ENABLE; // select divisor latches > > U1DLL = (uint8_t)baud; // set for
baud low byte
> > U1DLM = (uint8_t)(baud >> 8); // set for baud high byte
> > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > U1FCR = fmode;
> > }
> >
> > Wow, sorry for the long message and code, but otherwise I guess
> > someone is asking how that and that is done so I include it from the > > start.
> >
> > If anyone have a clue or idea I would be very happy guy!
> >
> > Cheers
> > Johan
>
