What the UART is!!

Why, from that description I would conclude that you're having a typical day trying to make a UART work.

Yes, it's possible that your code is driving the UART into some erroneous state. More likely the UART is getting into some state where it wants some hand-holding that you're not providing. Check all of the error conditions, and see if any of them have to be corrected by some action from the processor.

Just a note: "Famous UART (TI/Philips...)" doesn't give anyone sufficient information to figure out what UART you are using. If you want to give the specific part then post the part number. If it's a Philips designed UART then strange states are the order of the day (they've enhanced it over other UARTs that way).

If you can't get help here this is the kind of topic that would get you lots of interest on comp.embedded, although many of the microprocessor-oriented folks on this group can also be found on that one.

Nothing specific -- it just seems that Philips takes a wacky approach to all their interface chips, UARTs included.

Boy, a failure after 20 days -- that must be fun to try to replicate and hunt down!

Hi, I am back, show you what I learn...

S T F U !

XDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD

Best repeat. Boki.

"Boki" schreef in bericht news: snipped-for-privacy@g43g2000cwa.googlegroups.com...

Er... There are a couple of thousends - maybe even tens of thousends - types of UARTs out there. Even if you stick to the 8250 and it's successors you have some tens. So what micro are you using to control what UART?

petrus bitbyter

Boki,first try to learn something. Than come back here and ask questions.:))

And pause briefly between characters when doing this. Sending the same byte repeatedly back-to-back can be easily sync'd on the wrong transition and come out as the wrong character. Leads to some head-scratching. A brief pause causes the receiver to sync on the real start bit.

Richard

Check baud rate, clock, divider, stop bits, parity, word length.

Check that the data is right way up.

Run the UART as simply as possible- write a routine that just polls the data ready bit, reads it, clears it and prints the character received. No interrupts, don't try to chaw before you've cut your teeth. Then extend it to include frame/overrun error etc. if you want it.

Write another routine that just waits for UART empty then outputs one character. Does it come through OK?

Then write the ISR one step at a time.

Paul Burke

Hi Tim, do you have any information on the "strange states" of philips uarts? I use a philips SC28L198 octal UART which likes to fail after 20 days of perfect operation.

Ross

Boki - Is it possible that all your quizzical posts to this newsgroup are due to this malfunctioning UART? Dropped characters would explain a lot of stuff that shows up on the news server...

Did you ever find that "what kind of modulator do we need for next technology life?" And did your Amazon book ever get there? I think the UART must've dropped a few characters off the shipping address...

Tim.

Polling can be exactly the right way to handle asynchronous inputs. Systems that must have extremely high reliability (such as fly-by-wire) use a design technique that calls for _no_ processor interrupts -- all processing must happen in rigidly defined timeslices, and no process can overrun its timeslice. They tend to be a bitch and a half to design (or modify), but the path to proving that they'll be very reliable is considerably shortened.

The idea of using interrupts, and even multi-tasking, is making inroads in these areas, but very slowly.

One question.

Are you using a proper interrupt routine to service the UART ?

I mean *proper* as in hardware driven. I got a shock many years ago when I discovered that software writers think polling is adequate to handle interrupts.

Graham

Long time no see, thanks a lot, I will check comp.embedded.:)

Best regards, F.Y.

Hey, Come on, I am not droper :) quite busy here sorry.

Because I didn't find the answer I can try but I didn't try on my UART problem.

I am EE background, so I like to post here to ask most of my questions. :)

Is that ok?

Thanks.

Boki.

Now, we are using 1 byte interrupt, we use TI or philips 16 byte FIFO uart to receive bluetooth data for our dsp.

We already design all timing meet the spec, but still happen byte error ( or lost )

Dear Graham, Good point, but I we alraedy deal with this point.... but still no lucky....

Best regards, Boki.

A DSP that can decode multimedia files, RISC, about 100MHz.

From stuff that Boki has previously posted I suspect that the UART is running at a rather more pedestrian data rate.

Hiwever without a fuller overview of what he has it's very hard to comment meaningfully.

Graham

"Boki" schreef in bericht news: snipped-for-privacy@g47g2000cwa.googlegroups.com...

So a DSP running at 100MHz. Even if you don't run that UART on 100MHz as well, first thing you have to do is slowing down the input pins with an RC-filter. A proc that fast can react on disturbances of 1ns and the next fly passing by may cause such a disturbance. For the same reason your connections (p.e. solderjoints) should be perfect. Even much slower UARTS may be constantly triggered causing interrupts by bad joints and other hard to find disturbances on the line.

petrus bitbyter

Hi, Good point, but we already do this..... still got wrong data (bytes) @@

Besr regards, Boki.