ASM51

Pessoal.
Olhando neste minuto, observei que as seriais do 2478 possuem um hw dedicado para time out.
Por exemplo, eu abilito a interrupção de time out.
Configuro para 6mS.

Dentro de 6mS se não houver interrupção por recepção de char, um contador estoura, e gera uma interrupção.
Ao haver esta interrupção, eu entro no _IRQ, faço a performance de teste de flgs, até descobrir que a int é por time out. Desta forma eu uso este artificio para sincronizar frame de dados.

Alguém ja conseguiu entender como usar isso corretamente!? Me deu um nó na mente, mais não consegui entender bulhufas de pitibiriba!!!

Tipo, para que serve sim, entendi, como usa?! nem a pau juvenal !!!

Fabim,

Não entendi se você entendeu ou não pra que serve ou se não entendeu como usar.

Eu uso recurso parecido por software em alguns projetos pra saber se já chegou o fim de um recepção.

Exemplo: A partir do instante em que começa uma recepção se eu não receber um novo byte em 1ms eu considero que já recebi tudo e inicío o tratamento dos dados.

Até mais.

Abuda, assim.

Eu li no user manual sobre time out, na serial, e li em algum lugar no user manual, sobre time out byte. Sei bem pra que serve, e como usar.
O que eu não entendi foi, tem como eu configurar isso no hW da serial do arm ???? Tipo, a serial possui um registrador configuravel para time out ?

Abraços, e obrigado.

Fabim,

Dei um "bisu" no datasheet aqui e não achei timeout nas seriais(UART) o que tem nas UART é um timeout da rotina de AutoBaud das mesmas.

Corrigindo acabei de achar:

É disso que você está falando?

Minimum of one character in the Rx
FIFO and no character input or removed
during a time period depending on how
many characters are in FIFO and what
the trigger level is set at (3.5 to 4.5
character times).
The exact time will be:
[(word length) × 7 - 2] × 8 + [(trigger level
- number of characters) × 8 + 1] RCLKs

foi isso mesmo que eu li, e não entendi %@%# nenhuma!!!

Isso aí é quando você está usando o fifo depth maior que 1. A uart tem 16 bytes de fifo, e existem algumas configurações possíveis (1, 4, 8 ... 14, 16; dependendo da implementação, não lembro qual a nxp usa).

O que ocorre é que quando o fifo depth é maior que um, os caracteres vão sendo armazenados no buffer mas a interrupção só ocorre nos seguintes casos:

1) Quando recebendo uma sequencia contínua de dados, quando o depth é alcançado. Se for 8, por exemplo, a irq de recepção só será acionada quando ao menos 8 bytes estiverem no buffer. Assim ao invés de ter 8 interrupções, você trata uma só.

2) Quando ao menos um byte é recebido, mas o fluxo de dados para por um tempo igual aquele indicado na fórmula, antes de chegar a atingir o depth. Isto ocorre pra que a tua rotina possa tratar os dados remanescentes de uma recepção, que não sejam múltiplos do depth escolhido.


Este mecanismo é pra aliviar o trabalho da cpu em atender interrupções, não pra tratar timeouts, pra isto o sugerido é usar um dos timers da cpu, fazendo a programação dele no início de um ponto e parando ou dando reset nesse caso o evento esperado ocorra antes do timeout. Mas isto não tem nada a ver com o hardware da serial, embora você talvez queira sincronizar com as condições de buffer de envio vazio ou ainda shift register de envio vazio, dependendo exatamente do que vc quer fazer, por exemplo, se ao enviar um comando pela serial, vc precisa de uma resposta dentro de um tempo, ou algo.

blz, polesapart, agora entendi. Mas beleza, da pra fazer com os math do timer 0 de boa.
O que esta me matando mesmo, é as fuck interrupções. hehehe
Cara, por isso não gosto de pic, nem arm7. CM3 é tudo tão mais direto.

Hehehehe, é, o setup de irqs nos lpc2xxx ñ é exatamente amigável.

No CM3 também não existe essa função para Timeout. É preciso usar um timer da CPU.
Ou você está falando das INT que ainda não conseguiu domar?

Nightcrawler escreveu:No CM3 também não existe essa função para Timeout. É preciso usar um timer da CPU.
Ou você está falando das INT que ainda não conseguiu domar?

INTS

Bom pra não abrir outra thread vou usar esta mesmo.
Depois de me descabelar bastante achando que não tinha intendido nada sobre o PLL e interrupções, mudei de ares, e descobri que tava tudo funfando direitinho, e que o problema estava na configuração da serial.
Um amigo me passou que.

int Clock_Div;
#define BaudRate 9600

Clock_Div = (36000000)/(16 * BaudRate);
// Define divisor p/ o BaudRate desejado (PCLK = 72MHz)
U3LCR = 0x83;
// Define 8 bits, sem paridade, 1 Stop bit, e habilita
// acesso aos divisores U0DLL e U0DLM (DLAB=1)
U3DLM = (Clock_Div / 256);
// Define valor do divisor p/ Baudrate desejado (MSB)
U3DLL = (Clock_Div % 256);
// Define valor do divisor p/ Baudrate desejado (LSB)
U3LCR &= 0x7F;
// Desabilita acesso aos divisores U0DLL e U0DLM (DLAB=0)

Utilizando a lógica acima,
Clock_Div = 36kk/(16*9600) = 234.375
U3DLM = 234.375/256 = 0;
U3DLL = 234.375%256 = 0;
........

li o datasheet e não entendi direito...

Pelo que eu pude entender, se resultado do primeiro calculo < que 256, então valor é colocado em U3DLL, se igual ou maior que 256 então resultado / 256 e colocado em U3DLM, e resultado %256 e colocado em U3DLL.

Se entendi certo, porque não quer funcionar ? hehehe

Fabim,

Pra facilitar tua vida: http://www.4shared.com/file/vbihFRyX/BAUDCALC.html

nigth, obrigado.
Cara como eu odeio modulos OEM carissimos, e com documentação vagabunda, e que você não entende corretamente como funciona.

Cara, a forma de funcionamento do modulo é selecionado através de um resistor pull down, que dentro de 3 valores, fala para o módulo como ele vai funcionar. Eu nem vi isso, só tentei ler o formato 1, depois de prativamente reinventar todas as rotinas de interrupção e serial, e timer´s. Eu parei pra tomar um coff, comecei a ler o datasheet novamente, e pimba!!! Tinha que jogar a porcaria do pino para o GND!!! Soldei um fiosinho, liguei o oem e pumba, alá os valores perfeitos, perfeitos, perfeito, sem nenhum erro de frame.. hehehehe

Obrigado pessoal, pelo menos agora sei como funciona as ints no arm7, e a forma de configurar a serial do arm7 é igualzim do cm3, só mudando os nomes.

HEHEHEHEHEHEHE

fabim escreveu: Cara como eu odeio modulos OEM carissimos, e com documentação vagabunda, e que você não entende corretamente como funciona.

Cara, a forma de funcionamento do modulo é selecionado através de um resistor pull down, que dentro de 3 valores, fala para o módulo como ele vai funcionar. Eu nem vi isso, só tentei ler o formato 1, depois de prativamente reinventar todas as rotinas de interrupção e serial, e timer´s. Eu parei pra tomar um coff, comecei a ler o datasheet novamente, e pimba!!! Tinha que jogar a porcaria do pino para o GND!!! Soldei um fiosinho, liguei o oem e pumba, alá os valores perfeitos, perfeitos, perfeito, sem nenhum erro de frame.. hehehehe

Cara, o que tinha no café que tu tomou?? Hehehe.
Explica melhor do que tu tava apanhando...

eu simplesmente estava esperando um tipo de protocolo que vinha com X bytes. Só que a porqueira do módulo estava mandando valores loucos totalmente fora do que deveria ser. Foi quando eu li o datasheet com muita atenção, e percebi que o tipo de protocolo, que são 3 tipos, é selecionado através de um resistor de pull down, que eu devo colocar, entre 3 valores pré determinados.

Fiz o dito, e pumba, na hora ja resolveu!!! hehehe