Missing characters on USART interface

Go To Last Post
22 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi,

I have a strange problem when connecting the ATMEGA16 with the USART to the
COM2 of my Compaq-Deskpro PC, Pentium-2, running Windows98.

On the PC i have a delphi application that performs a kind of Looptest with the device. The application sends a 'looptest' command to the ATMEGA16, he reply's with a specific string. In the PC application i check if the Correct string is received. If not i increment an error Counter and display the received string on the screen.

The RS232 connection works at 4800 Baud.

I see a lot of errors, >20 per 100 calls, reported by the application. Most of the time characters are missing in the string to be received !!!.

When i run the same delphi application on a portable COMPAQ Armade 1750,
with the same comport cable, it is working much better, 1 fault per 10.000 calls.

The delphi application is the only thing running on the Deskpro-PC. No virus
scanners and internet security active.

Has Someone experieced the same thing. Any suggestions are welcome,
except baying a new PC.

Regards,
Fabrizio,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How are you clocking the ATmega? If you are not using an accurate source, it could be that your baud rate is not accurate. And it could also be that your lap top is more tolerant of this.

Check the clock frequency. And baud rate settings.

Sacha.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using an 11.0592Mhz crystal has clock source.

/*Init USART */
UBRRH = 0x00; /* 11.0592Mhz crystal */
UBRRL = 0x8F; /* Baudrate 4800 */

UCSRB = ((1<<RXCIE) | (1<<RXEN) | (1<<TXEN)); Rx-Complete interrupt on
Rx & Tx enabled
UCSRC = ((1<<URSEL) | (3<<UCSZ0)); 8-data, 1 stop-bit, no parity

About the Fuse bits to select the 11.0592Mhz clock source.

CKOPT = 0 Programmed
CKSEL3..0 = 1 Unprogrammed
SUT1..0 = 1 Unprogrammed

I am not 100% certain about these bits, specially about CKOPT. But i tried with
CKOPT 0 & 1, with the same result.

fabrizio,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your settings all appear to be correct here! I presume you have verified that your clocks are all running at the correct frequency, etc? If so, the perhaps the problem is the hardware you use to connect to your PCs serial port?

It has been noticed in the past that some portable computers have not exactly stuck to the RS232 spec, tending to run at the lower end of the allowable signalling voltages. This may be another difference between your two computers. Are you using an RS232 level converter? If so, is it working properly? Check that it is within spec and that the spec is suitable for your application. Is your cable good quality? Have you tried another?

I'm afriad that we can only point you in various directions now. It's not easy to debug hardware problems like this by text. But we can always try!

Sacha.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unless the PC program can receive a stream reliably from another source, it may not be a hardware problem per se.

Besides hardware-related issues such as port setup, consider this: Fabrizio reported that the slow computer doesn't work as good as the fast computer.

--the PC app could be spending too much time processing each character
--the bufferring isn't set up correctly; the faster computer may be masking it

Try sending a text stream and displaying it with a known-good terminal emulation program.

Lee

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A very good point. I had not picked up on the fact that the laptop is running a P3.

Thanks Lee.

Sacha.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use a MAX232 for converting levels.
At RS232 side i have for on the Rx of MAX232 +9V & -9V
Tx of MAX232 +8V & -8V
At the TTL side is have 5V and 0V fot high and low level.

Some time ago i worked with AT89S8252 processor.
I made a same kind of Looptest between the PC and this device.
The same but fewer errors are present. 1 error every 1000 calls.
In this case the Baudrate is 9600.

What i will try next.
- Suggestion of Lee. I will program the device to send a defined string
X times per second. Has terminal emulator i will use Hyperterminal.

- I can also connect the ATMEGA16 to the AT89S8252 and make a looptest
between them.

Fabrizio,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have made the experience that the processing speed of a PC-program depends very much on the operating system. The newer one isn't always the better. If you can make a program, that runs under DOS, try that in DOS-mode. Even if it isn't a real solution to your problem, it could be a hint.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fabrizio,

Connect a second computer to listen to the RS232 connection using standard terminal program.

RS232 output is capable of driving 2 RS232 inputs.

Set the terminal program to capture the data.
When the error is detected just eyeball the captured data.

Peter

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fabrizio

If it does turn out that it is the PC that is losing characters, I have a reliable comms DLL and example application that uses it that you would be very welcome to.

These are written in Borland C++ Builder, so should be very easy to link in with Delphi.

Shout up if it would help you.

Andy G.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I started Hyperterminal on the PC and made a loop in the device.
The device sends 10 times per second a string of 60 Characters at 9600B
WITHOUT any problem. All strings are received and displayed correctly
by Hyperterminal.

Peter,
This proofs, to me, that there is no problem at the ATMEL side. The string
is always send correctly to the PC.

Stopbit,
Good Idee, But i don't have any dos compilers anymore.

Andy G,
I think that i have a problem in the COMPORT component that i use in DELPHI.
I use ADPCOMPORT made by ASYNC PRO. I would like to accept your
proposal and try your component, has you are friendly enough to propose it.

Fabrizio,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fabrizio

Attached is the DLL.

I will provide an example application in the next post

Andy

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And an example application.

I believe that the DLL is entirely reliable (I use it for 115 Kbaud comms to an embedded micro.)

If you have strict timing requirements, then it may need to be "breathed upon", in which case I will send you the source.

Cheers
A

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Andy,

Thank you for the Tserial.Dll
I have some difficulties including the DDL in Delphi4.
It seems that the Tserial.h, header file, has to be converted to a Delphi unit.

I will forward a question on a delphi forum to get some help on this.

regards,
fabrizio.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fabrizio

I am trying to get a Delphi header for you.

Cheers
A

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fabrizio

I'm a friend of Andy G and wrote the code on which his dll is based as a delphi (3) component.

Attached is the complete source of this component ProtoclDriver and an application using it.

The component has two modes, either an "inline" mode, where the PC is running a poll and response mode, or an autonomous mode, where messages arrive unsolicited.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dave Andy,

Thank you for the Effort.

But, this level of programming is far to difficult for me. I thought i knew something
about delphi!

I will implement an error detection on the Tx and Rx of the RS232 data, and force
retransmission in case of errors. I will keep using the Apdcomport component
of Async-pro.

fabrizio.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK Fabrizio, but it really isn't that tough.

We have an exhibition coming up next week, so have limited free bandwidth for a few days.

However, I will attempt to get my header file translated into Delphi and then all you would need to do is to _use_ the DLL, not worrying about its internals. The interface is trivial.

Then if you do decide to have another go in the future, then at least you have a choice.

Cheers
A

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Andy,

You are probably wright. The internal of the TSERIAL is to difficult for me, but the
usage should be ok.

Looking forward for the Delphi4 pas file, if you find the time.

regards,
fabrizio.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Andy,

In the meantime, via a delphi forum, someone suggested to use another proven
serial component, TSERIAL4, R2.50, written by R.J. Crowther (UK).

Although with the same problems. Still missing characters in the loopstring
coming from the device.

I have to come back on previous findings. When hyperterminal is running on the
PC i see also the same errors. Missing characters in the Incoming string.
Since hyperterminal has also lost characters the cause must be outside Delphi.

I tried the suggestion of Peter Dvorak, a few postings ago, and connected a
third PC, running hyperterminal, in parallel on the RS232 between the device and the Destop PC. Only Tx of device is connected to the third PC.
I stopped the Desktop PC, Running Delphi application, when a string error is
seen. On the third PC i can see the Last string send by the Device. This string
is Send WITHOUT errors by the Device.

I think this means characters are getting lost between the COMx port and Dephi's TSERIAL DLL.

What happens when a character is received on the UART of the PC?
- An interrupt is generated.
- Comport Driver is activated.
- What happens next ??

Do you thing this is possible. Maybe Dave, since he wrote a TSERIAL DLL,
can point me on how to find out if we loose some characters between Comx and
Delphi.

Regards,
Fabrizio.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Andy,

We found out that on the moment missing characters are detected in the
incoming loopstring, the PC USART is reporting a "Usart receiver overrun error".

The 16 bytes FIFO buffer of the PC usart is overflowing at certain point.

Instead of sending a loopstring of 40 bytes long i send a loopstring of
only 5 bytes. It runned overnight > 1 million calls with ZERO errors. This
points that we have indeed USART overrun errors.

Therefore we need to implement handshaking between PC and Device.
Handshaking is activated in the delphi comport component. However no actions
is seen on DTR or RTS pin during overrrun errors.

Delphi component input buffer length is changed from 4k to 6 Bytes.
In this case the Hardware handshaking signals is activated. DTR and RTS are
pulled low.

Question remains. Why is RTS or DTR not activated when the PC USART receiver
enters an Overrun condition?

Anyhow. I will need to build in a CRC check on data between the
device and the PC. I can ask for retransmission when errors are seen.

Kind regards,
Fabrizio,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would hesitate to use Hyperterminal for anything. We have had no end of grief with it, the character processing is so slow running on a ~500Mhz computer we could not keepup with a simple 9600 baud data stream. It was pathetic.

We bought a program called 'CRT', simple terminal program, this program rocks, have had no trouble infact can use the same 38.4 data stream on a Pentium 166 with no problems at all, unbelievable the difference between the two programs. I never would have guessed the terminal program would be the problem, but we could not keep up, and we were sending data from the terminal program to a satellite and to 2000+ receivers, therefore can't screw this up, and Hyperterminal would screw it up.

As for your actual loss of characters problem without seeing the code and exact application I could only guess, and others have done some very good guessing...

Good Luck...

admin's test signature