Quão críticas são as frequências UART?


17

Vou usar um cristal de 8 MHz para executar meu microcontrolador a 16 MIPS (instruções PLL 4x, 2 ciclos). No entanto, 8 MHz não se dividem em nenhuma frequência UART AFAIK ... então, quão críticas são essas frequências? Eu pretendo usar 115.200 baud.

O UART pode ser executado dentro de ± 1%? Se isso não funcionar, qual frequência devo usar? (Gostaria de chegar o mais próximo possível dos 16 MIPS, para obter a velocidade máxima de processamento.) Se isso importa, estou usando um PIC24FJ64GA004.

Respostas:


13

Se você estiver dentro de 1%, você deve estar bem.

Suponha que o seu UART use um relógio de oversampling de 16x, por exemplo, você pode configurá-lo entre 1.843.200 Hz e 16x de 115.500 bps. (uma amostragem excessiva como essa é bastante comum) Isso permite que o UART conte 8 overclocks da borda de queda do bit inicial, para localizar o centro das células do bit dentro de +/- um período do overclock, após que conta 16 períodos do overclock para determinar quando coletar dados.

Se você presumir que ele pode atingir o centro do bit inicial, para manter a amostragem de dados seriais nas células de bits corretas em 8 bits de dados, a frequência do relógio deve permanecer entre (8-0,5) / 8 e (8 + 0,5 ) / 8 ou +/- 6,25% da taxa de bits pretendida. Um overclock mais alto aproxima-se da condição ideal de atingir o centro do bit inicial, mas 8x ou 16x geralmente estão próximos o suficiente para que você possa supor que uma incompatibilidade de 5% funcionará.

No entanto, você não pode contar com o outro lado perfeitamente na frequência. Se você conectar um dispositivo 4% mais rápido a um dispositivo 4% mais lento, terá um problema. Encontrei pelo menos um caso em que um PC estava um pouco lento, e um dispositivo um pouco rápido, e os dois só conseguiam se comunicar marginalmente, embora o mesmo dispositivo funcionasse bem com outros PCs e o PC funcionasse com outros dispositivos. (O escopo é de aproximadamente 112kbps e 119kbps). Por esse motivo, é bom tentar atingir a frequência nominal o mais próximo possível. Eu nunca vi nada dentro de 2% da nominal ter um problema.

O usual é usar uma taxa de clock mestre que forneça um número inteiro múltiplo da taxa de sobre-amostragem UART pretendida vezes a taxa de transmissão. Por exemplo, se você deseja uma CPU rodando a cerca de 8 MHz, use um oscilador de 7,3728 MHz, que pode ser dividido por 4 para obter 1,8432 MHz, que é exatamente 16 vezes 115200.


8 MHz pode ser dividido por 69 para obter 115.942, o que está bem dentro de ± 1%. Gostaria de saber se o PIC suporta esse tipo de divisão para seu gerador de taxa de transmissão. Espero que sim, mas acho que não.
Thomas O

O PIC possui um gerador de taxa de transmissão. Funcionaria bem, mas apenas para uma transmissão mais baixa como 9600, não funcionaria para uma transmissão alta como 115.200, torna-se muito impreciso.
Thomas O

Você acha que eu poderia usar um cristal de 7,3728 MHz? (Não vou usar o oscilador interno de 7,37 MHz porque gostaria de precisão.) Ele me permite dividir por 64 para obter uma frequência UART de 115.200. É o mais rápido que consigo com alta tolerância.
Thomas O

1
se o seu UART o suportar, é preferível fazer um overclock (como 16x) para que ele possa sobre-amostrar o bit inicial e encontrar o centro da célula de bits, mas obter um 16x para 115K dentro de 1% pode ser um desafio, a menos que você usa um cristal baud múltiplo.
JustJeff

4

As menções de 1% @JustJeff não são necessárias. A maioria dos UARTs permite um erro de meio bit no último bit. Na maioria das vezes, um quadro consiste em 1 bit de início, 8 bancos de dados e 1 bit de parada, para um total de 10 bits. Meio bit em 10 bits é de 5% (os 6,25% de JustJeff não levam em consideração o bit inicial e o final).


1
não me cite mal; re "1%", minha afirmação era de que isso poderia ser difícil de alcançar. Os "6,25%" supunham que você atingisse o centro do bit de início e seria a diferença máxima permitida nas taxas de clock do receptor contra o transmissor nessas condições.
JustJeff

1

JustJeff esqueceu o bit de início, mas Stevenh adicionou o bit de parada. Assumindo o protocolo comum de 8 bits de dados, 1 bit de início e sem bit de paridade (o número de bits de parada não importa), há tempos de 8 1/2 bits desde a borda principal do bit de início até o centro do último bit de dados. Geralmente, você deseja que o receptor experimente esse último bit dentro de 1/4 de tempo. Observe que 1/2 bit é o limite garantido para falhar. Qualquer coisa lá perto se torna irrealizável, pois sempre há algum ruído elétrico e instabilidade.

1/4 dividido por 8 1/2 = 2,94%.

Como JustJeff mencionou, a maioria das implementações de UART realmente mostra os dados recebidos com um relógio 16x assíncrono. Isso adiciona outra incerteza de tempo de 1/16 bits, já que esse é o erro com o qual a borda principal do bit inicial pode ser medida. O tempo de 1/16 bits em 8 1/2 bits é outro 0,74%. Isso sai do orçamento de erro calculado anteriormente. Você acaba com uma diferença de 2,2% permitida no relógio para que o receptor experimente o último bit dentro do tempo de 1/4 de bit do centro.

Como outros já disseram, usar um cristal de 7,3728 MHz é uma prática comum quando é necessária uma taxa de transmissão precisa. Geralmente, você pode executar a CPU perto da sua taxa máxima enquanto atinge a taxa de transmissão UART dentro de um erro de cristal.


Não concordo que os bits de parada não importem. Em esta pergunta comunicação falhou porque o bit de parada foi erroneamente definido para um nível baixo.
stevenvh

O bit de parada deve estar presente para que a comunicação geral funcione, mas não entra no cálculo do orçamento de erros para a maioria dos UARTs. Os UARTs exigirão algum tempo mínimo após o último bit de dados antes da próxima borda principal do próximo bit de início. É para isso que serve o tempo de parada. Quando esse tempo não é cumprido, você recebe um "erro de enquadramento". Talvez isso seja amostrado como um bit de dados, mas eu sei de casos em que ele foi tratado de maneira diferente. Os teletipos antigos precisavam de 2 bits de parada para dar tempo ao mecanismo mecânico para estar pronto para pegar o próximo personagem.
precisa

Eu me referi ao começo pouco três vezes, não foi?
JustJeff

@OlinLathrop: O bit de parada é necessária para garantir que quando o envio de um byte cujos MSB é zero não vai ser uma borda de descida para a próxima bit de início. Dispositivos diferentes se comportam de maneira diferente nos casos em que a linha de dados fica baixa antes do esperado, mas se não houvesse um bit de parada, uma sequência transmitida de zero bytes não conteria informações de tempo úteis. Esse requisito pode ser atendido por outros meios com uma sobrecarga de estrutura fixa inferior a 25%, mas não conheço ninguém que o faça.
Supercat

1

Um ponto ainda não mencionado é que alguns dispositivos esperam transmitir um byte de dados para cada byte de dados que recebem. Se um dispositivo desse tipo alimenta dados continuamente, sua taxa de transmissão é até 0,1% mais lenta que a do dispositivo transmissor e não tem capacidade de enviar bits de parada ligeiramente encolhidos, sua saída ficará um byte atrasado a cada 1000 consecutivos bytes recebidos. Se o dispositivo estiver limitado a 16 bytes de buffer, ele eliminará um byte de dados após passar aproximadamente 16.000 e cairá aproximadamente um byte por mil a partir de então. Vale a pena notar que os chamados modems "1200 baud" realmente operam a uma taxa ligeiramente superior a 1200 bits / segundo (acho que é cerca de 1202) exatamente por esse motivo (de modo que, mesmo que o transmissor seja 0,15% mais rápido do que deveria) estar,

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.