Sign in

username:

password:



Not a member?

Search Comp.Arch.Embedded



Search tips

embedded by Keywords

68HC11 | 68HC12 | 8051 | 8052 | ARM | ARM7 | Asic | AT91 | AT91RM9200 | Atmel | AVR | AVRStudio | Bootloader | CFP | CompactFlash | Cygnal | Cypress | Dataflash | DSP | eCos | EEPROM | Embedded Linux | Emulator | Endian | Ethernet | Firewire | FPGA | Freescale | GCC | GNUARM | GSM | H8 | HDLC | I2C | Infineon | Interrupts | Java | JTAG | LCD | LED | LPC2000 | MCU | Microchip | MMC | MPLAB | MSP430 | PC104 | PCB | PCI | PCMCIA | PowerPC | Rabbit | RS232 | RS485 | RTOS | SBC | SDRAM | Sensor | SPI | STK500 | UART | UML | USART | USB | Verilog | VHDL | VxWorks | Xilinx

Ads

Discussion Groups

Discussion Groups | Comp.Arch.Embedded | 20 bit UART for 5912OSK

There are 14 messages in this thread.

You are currently looking at messages 10 to 14.

Re: 20 bit UART for 5912OSK - Rocky - 10:28 15-01-06

Chuck F.  wrote:
<SNIP>
> That phasing problem is why most UARTs use a 16x clock signal.
> They need at least a 2x signal, and that can be very hairy.
>

It is interesting the odd clock multiples actually give better all
round performance than the next higher even multiple. Note that a 2x
sampling rate is not actually usable due to the uncertainty when
sampling the start bit.

Sampling at 3 times the bit rate gives better performance than 4 times.

Regards
Rocky




Re: 20 bit UART for 5912OSK - Chuck F. - 11:08 15-01-06

Rocky wrote:
> Chuck F.  wrote: 
 >
<SNIP>
> 
>> That phasing problem is why most UARTs use a 16x clock signal.
>> They need at least a 2x signal, and that can be very hairy.
>> 
> It is interesting the odd clock multiples actually give better
> all round performance than the next higher even multiple. Note
> that a 2x sampling rate is not actually usable due to the
> uncertainty when sampling the start bit.
> 
> Sampling at 3 times the bit rate gives better performance than 4
> times.

That really devolves into where the error budget is applied.  The 
2x situation requires that the receiver be clocked faster than the 
sender.  When two such communicate one will fail.

-- 
"If you want to post a followup via groups.google.com, don't use
  the broken "Reply" link at the bottom of the article.  Click on
  "show options" at the top of the article, then click on the
  "Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>;

Re: 20 bit UART for 5912OSK - Chuck F. - 11:18 15-01-06

Sillycar wrote:
> Chuck F.  wrote:
> 
... snip ...
>>
>> The reason for the UART bit length limitation is that both ends
>> have to agree on the actual baud rate.  The result must sample the
>> final stop bit correctly.  For 10 total bits (8 data, plus start
>> and stop) this means the frequencies must agree within at least 5%,
>> assuming exact accuracy in locating the start bit.  Things only get
>> worse from there.  For 20 or so bits that number is about 2%, and
>> the initial sampling accuracy will probably not let it work at all.
> 
> Hi Chuck, I gather from your post that it is not advisable to use the
> UART protocol then? Thanks for the reply.

Exactly. You might investigate various self-clocking techniques.

Congratulations on learning to use the google interface correctly, 
and thence how to post correctly.  Now you also need to learn to 
snip the quoted portions that are not germane to your reply, and 
you will be a first class netizen.

-- 
"If you want to post a followup via groups.google.com, don't use
  the broken "Reply" link at the bottom of the article.  Click on
  "show options" at the top of the article, then click on the
  "Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>;

Re: 20 bit UART for 5912OSK - Roberto Waltman - 12:25 15-01-06

<s...@gmail.com> wrote:
( Latest post on how to use an OMAP processor's
UART to exchange 20bit messages )

>I don't have a choice. My project requires me to use the OMAP. Thanks
>for the reply.
>
>Lincoln

As others have pointed out, it is not possible to use
a UART the way you need.
( I am surprised at the implicit agreement in previous
posts in this thread that there is a UART "protocol". )

The solution is, of course, to design and implement
a protocol on top of the UART basic 7-to-9 bits word
format to deliver 20 bit messages.
(I'll use the term "word" here to refer to the basic
7/8/9 bit data units delivered by a traditional UART)

Using 8-bit words, a trivial implementation could be
to encode each 20 bit message as 3-UART-words messages,
with 7 bits transmitted in the least significant
positions of the 2 first words and 6 in last word.
Use the most significant bit as a framing bit, i.e.,
set it to '1' in the first word of each triplet
and '0' in the last two, to identify the beginning
of a message.
(Some UARTS can be programmed to a 9-bit mode with the
fist bit generating a receive interrupt when set. This
could simplify your logic, if available)

This will sole the OP problems, and also open a
Pandora box of how to deal with, and recover from,
communication errors.
(For example, you may have to extend the message size
to include a CRC, or to keep time stamps on when
each word was received, to be able to differentiate
between the tree words belonging to a valid message,
and a first word from one message +2nd and 3rd from
a latter message, with the intermediate ones lost)

I would suggest checking a good book on networking
and communication protocols.


Roberto Waltman

[ Please reply to the group,
  return address is invalid ]

previous | 1 | 2