Serial port throughput

I have come across non-Maxim parts that locked up if too much current is taken from the charge pump voltages. We had a card once that "borrowed" the V+ voltages for a additional signal. It worked fine with the Maxim

232 parts, but failed with an alternative part. If we drew too much current from the charge pump, it shut down and had to be power-cycled to get it working again.

Of course, that shouldn't happen when running at the rated baud rates - unless for some reason there is more load on your RX line than there should be.

I've run 2 MBaud continuously on two channels through an FTDI2232 device. Drivers can be an issue with FTDI, but if you get them right there the chips run fine at high speed.

Did you mean turn-around agility ?

For speed, 115200 is easy for most std USB ports I've tested, but they can have issues with ping-pong type direction changes. Allow about 1ms for those.

They do start to 'fall off' from the saturated byte rates, above around 500kbd, and give little gain at all going from 1Mb to 2Mbd

The HS FT2232H shifts the goal posts, and with packets larger than

296 bytes, I've had that show 6.000112MHz on a counter sending 'U's, (which means it is at full saturates rates).

Yes, and it needs to have enough local bufferings. I was testing it with a 1K AVR (programmed as USB-RS232), which limits my block size to around 800 bytes.

First of all: check the signal on the output of the MAX3232 if that shuts down. Probably not. Is your baudrate exactly 115200? If not, you HAVE to insert silent periods of at least one byte time to let the receiver resync on an idle state. If you send data over an async line and the baudrates don't match exactly, you end up with sync problems.

Meindert

an

s

ou

I am clocking with 12MHz crystal, 96MHz PLL and 32MHz CPU, so timing should be OK. I have to insert turn around delay, "put char" ->

delay -> "get char". as well as transmitter empty checking: "put char" -> "check transmitter empty" (reverse order will not work) to get it to work.

So, something is stopping it from running full duplex at full speed.

Have you checked yet to make sure that the MCU transmitter is not been stopped by the MCU's UART CTS flow control logic ?

If you are having problems sending data at full speed, the peer may be trying to regulate the flow of data by raising CTS to stop transmission and thereby stopping the MCU UART if it's running in flow control mode.

Everything you are saying is consistant with this scenario so it may be worth your while to make sure this is not the problem.

In other words, are you running the MCU UART in flow control mode without you realising it and are you also seeing flow control signal changes from the peer without you realising it ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

)

The flow control lines are not assigned to any pins, so they should be off by default. I just added the line to disable flow control, but make no difference.

PIC24: #define BAUDRATE2 115200UL #define BRG_DIV2 4 #define BRGH2 1 #define BAUDRATEREG2 (((GetSystemClock()/2)+ (BRG_DIV2/2*BAUDRATE2))/BRG_DIV2/BAUDRATE2-1) U1BRG =3D BAUDRATEREG2; U1MODE =3D 0; U1MODEbits.BRGH =3D BRGH2; U1STA =3D 0; U1MODEbits.RTSMD=3D 1; // disable flow control U1MODEbits.UARTEN =3D 1; U1STAbits.UTXEN =3D 1; IFS0bits.U1RXIF =3D 0;

PC: GetCommState(serial, &m_dcb); m_dcb.BaudRate =3D 115200; m_dcb.ByteSize =3D 8; m_dcb.Parity =3D NOPARITY; m_dcb.StopBits =3D ONESTOPBIT; m_dcb.fAbortOnError =3D TRUE; SetCommState(serial, &m_dcb); SetupComm(serial, 4096, 4096); COMMTIMEOUTS comTimeOut; comTimeOut.ReadIntervalTimeout =3D 3; comTimeOut.ReadTotalTimeoutMultiplier =3D 3; comTimeOut.ReadTotalTimeoutConstant =3D 2; comTimeOut.WriteTotalTimeoutMultiplier =3D 3; comTimeOut.WriteTotalTimeoutConstant =3D 2; SetCommTimeouts(serial,&comTimeOut);

works

=A0I can

to

bps

cycle,

problem.

shuts

periods

If

exactly, you

Me suspects you never get to the problem without a scope. Hunt places like Craigs list, eprey, yard sales, surplus outlets for minimal scopes = to do the job, maybe real cheap 'bout $10.

Pidgin special cheap advice.

?-)

ks

I can

o

bps

le,

.

uts

iods

If

, you

o

More like $100 to $200, and another piece of junk, according to my wife.

Yes, we would need to scope it piror to productions. The production shops should have the equipments to do so.

For now, just looking for easy fix. I am going to try the Max232 (upto 250Kbps) rather than the Max3232 (up to 120Kpbs). We just change the VCC from 3.3V to 5V, so we don't need the Max3232 anyway.

You have already lost more time and effort in this mess than a cheap scope costs.

In its own weird way, it is interesting to follow how long the guesswork will still last.

Methinks that you should start with putting the transmitter empty test before writing to the UART, to put the horse before the cart and not the other way round.

--

Tauno Voipio, and old and grumpy MSEE

It stops all output immediately. There might be a reason why Microchip's sample code test it after writing, not before.

I am entirely ignorant of Microchip devices... but this suggests a "stupid" question: are you sure that your "transmitter empty" test is using the correct logic sense, and is not a "transmitter not empty" test?

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Yes, by flattering (coping) Microchip directly. For PIC32, there is even a NOP before testing. My quess is that they don't want some registers to be touched while transmitting.

you

I recently picked up a free scope on Freecycle, along with a lot of other electronics.

--
You can't have a sense of humor, if you have no sense.

Is some output received? Or is there no output at all?

I wouldn't call that "being sure"... rather, "being trusting". It is not unknown for example code to have bugs.

If you test UART register status after writing, and your test is really "is the register full", it will usually work, because you have just written to the register, so it is full. Your code then fetches the next byte to be sent, from wherever it is stored, and if that usually takes longer than the time the UART needs to transmit a byte, the register will have cleared in time, the next byte will go off correctly, and it will all seem to work.

The fact is, your app does not work; so there is an error somewhere (but of course perhaps not in the SW). The fact that your app works differently when you test UART register emptiness before writing to the register, and after writing to the register, is fishy. I would make very sure that the check for register emptiness is done correctly, and is not inverted.

HTH,

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

On a sunny day (Tue, 4 Oct 2011 11:12:23 -0700 (PDT)) it happened linnix wrote in :

There is no guarantee that the Microchip examples are correct. I know of at least 2 cases where they are not. And have read of one case that cost somebody a lot of money as they had to bring in a consultant to fix it. There is not even a guarantee the datasheets are correct or complete (examples exist) and no guarantee the hardware is correct, see silicon updates. Never assume, but measure, read those dataheets over and over again... Write test code.

No output at all. The chip seems to lock up.

U1TXREG =3D ch; Nop(); while(U1STAbits.TRMT =3D=3D 0);

bit 8 TRMT: Transmit Shift Register Empty

0 =3D Transmit Shift Register is not empty, a transmission is in progress or queued.

unless the spec and sample codes are both wrong.

I'll try reversing the test and see what happens.

t y t

The chip lock up if I reverse the test. So, the existing spec and code should be correct.