On Oct 1, 8:19=A0am, Anony Mous <anony.mous...@yahoo.com> wrote:> On 9/30/2011 12:56 PM, linnix wrote: > > > I am pumping data from PIC24/Max3232 to PC at 115000 baud. > > Does the PC that you are using have a "true" serial port or are you > working through a USB-to-RS232 converter? =A0If the latter, who's USB > driver are you using? =A0I've experienced a similar "hanging" or > "stalling" problem with both an older FTDI driver and a Prolific driver. > =A0 Update to the latest FTDI drive fixed the problem. =A0I switch to avo=id> the Prolific driver. =A0In my scenario the RS232 port was still up, but > communications stalled.True PC com port. USB-RS232 converter can't handle the speed.
Serial port throughput
Started by ●September 30, 2011
Reply by ●October 1, 20112011-10-01
Reply by ●October 1, 20112011-10-01
On 30/09/11 23:57, Claude wrote:> In article<504aad6c-3911-425c-be0f-ff047b65fd22 > @q26g2000vby.googlegroups.com>, me@linnix.info-for.us says... >> >>> >>> I have come across non Maxim 232 parts that fall over at 115200 baud.... >>> I think you need a scope on it or some debug equipment.... >> >> Yes, it's a TI clone. Perhaps i need to check out others. My guess >> is that the charge pump is not suppling enough voltage for the >> transmitter. > > That's unlikely, first of all because if that were the case, the correct > function would resume after a brief pause to allow the caps to recharge. > But you say that only a reset enables TX again. >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.> That's usually a clear indication that something's wrong with the code. > > I'm not familiar with the 24, have you checked the possible failure > modes for the USART module? > Does your code check there is enough space in the USART TX buffer before > placing a new byte? > Does you code clear any fault bit? > > Claudio
Reply by ●October 1, 20112011-10-01
On 01/10/11 17:29, linnix wrote:> On Oct 1, 8:19 am, Anony Mous<anony.mous...@yahoo.com> wrote: >> On 9/30/2011 12:56 PM, linnix wrote: >> >>> I am pumping data from PIC24/Max3232 to PC at 115000 baud. >> >> Does the PC that you are using have a "true" serial port or are you >> working through a USB-to-RS232 converter? If the latter, who's USB >> driver are you using? I've experienced a similar "hanging" or >> "stalling" problem with both an older FTDI driver and a Prolific driver. >> Update to the latest FTDI drive fixed the problem. I switch to avoid >> the Prolific driver. In my scenario the RS232 port was still up, but >> communications stalled. > > True PC com port. USB-RS232 converter can't handle the speed.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.
Reply by ●October 2, 20112011-10-02
On Oct 2, 4:29=A0am, linnix <m...@linnix.info-for.us> wrote:> > True PC com port. =A0USB-RS232 converter can't handle the 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).
Reply by ●October 2, 20112011-10-02
On Oct 1, 9:59=A0pm, Jim Granville <j.m.granvi...@gmail.com> wrote:> On Oct 2, 4:29=A0am, linnix <m...@linnix.info-for.us> wrote: > > > > > True PC com port. =A0USB-RS232 converter can't handle the speed. > > Did you mean turn-around agility ?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.
Reply by ●October 3, 20112011-10-03
> I am pumping data from PIC24/Max3232 to PC at 115000 baud. It works > in burst of 4K blocks. However, after 10K to 30K of data, the > transmitter shutdown momentally. The serial link is still up. I can > issue a micro reset from the serial link, which is the fastest way to > restart the transmission. The average throughput is around 15000 bps > (bits), including the shutdown/reset cycle. Without the reset cycle, > i can probably get up to 25000 bps. > > I am not sure if this is a logic (PIC24) or signal (Max3232) problem. > My guess is that the transmitter is overwhelming the Max3232 charge > pump, which is running at 5V with 10uF cap on VCC and 1uF cap charge > storages. Would increasing caps help?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
Reply by ●October 3, 20112011-10-03
On Oct 3, 4:36=A0am, "Meindert Sprang" <m...@NOJUNKcustomORSPAMware.nl> wrote:> > I am pumping data from PIC24/Max3232 to PC at 115000 baud. =A0It works > > in burst of 4K blocks. =A0However, after 10K to 30K of data, the > > transmitter shutdown momentally. =A0The serial link is still up. =A0I c=an> > issue a micro reset from the serial link, which is the fastest way to > > restart the transmission. =A0The average throughput is around 15000 bps > > (bits), including the shutdown/reset cycle. =A0Without the reset cycle, > > i can probably get up to 25000 bps. > > > I am not sure if this is a logic (PIC24) or signal (Max3232) problem. > > My guess is that the transmitter is overwhelming the Max3232 charge > > pump, which is running at 5V with 10uF cap on VCC and 1uF cap charge > > storages. =A0Would increasing caps help? > > 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 period=s> 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, y=ou> end up with sync problems. > > MeindertI 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.
Reply by ●October 3, 20112011-10-03
On 2011-10-03, linnix <me@linnix.info-for.us> wrote:> > 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
Reply by ●October 3, 20112011-10-03
On Oct 3, 10:24=A0am, Simon Clubley <clubley@remove_me.eisner.decus.org- Earth.UFP> wrote:> On 2011-10-03, linnix <m...@linnix.info-for.us> wrote: > > > > > I am clocking with 12MHz crystal, 96MHz PLL and 32MHz CPU, so timing > > should be OK. =A0I have to insert turn around delay, =A0"put char" -> > > delay -> "get char". > > as well as transmitter empty checking: > > "put char" -> "check transmitter empty" =A0(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 ? >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);
Reply by ●October 4, 20112011-10-04
On Mon, 3 Oct 2011 09:31:04 -0700 (PDT), linnix <me@linnix.info-for.us> wrote:>On Oct 3, 4:36=A0am, "Meindert Sprang" <m...@NOJUNKcustomORSPAMware.nl> >wrote: >> > I am pumping data from PIC24/Max3232 to PC at 115000 baud. =A0It =works>> > in burst of 4K blocks. =A0However, after 10K to 30K of data, the >> > transmitter shutdown momentally. =A0The serial link is still up. ==A0I can>> > issue a micro reset from the serial link, which is the fastest way =to>> > restart the transmission. =A0The average throughput is around 15000 =bps>> > (bits), including the shutdown/reset cycle. =A0Without the reset =cycle,>> > i can probably get up to 25000 bps. >> >> > I am not sure if this is a logic (PIC24) or signal (Max3232) =problem.>> > My guess is that the transmitter is overwhelming the Max3232 charge >> > pump, which is running at 5V with 10uF cap on VCC and 1uF cap charge >> > storages. =A0Would increasing caps help? >> >> 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 > >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.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 <local>$10. Pidgin special cheap advice. ?-)
