ASM51

Alguem tem usado as rotinas _delay_ms e _delay_us que tem no arquivo .h ?

Tem algo estranho, quando dou _delay_ms(1000), da o dobro de tempo...

Eu setei certinho no MAKEFILE para 2000000 o cristal e comentei F_CPU dentro do .H

TCPIPCHIP

Estando correto os sets por SW e sendo cristal é estranho. Será que está dividindo devido algum fuse ligado ao clock? Algum fuse que tenha que ser setado a parte?

As rotinas de temporização foram as primeiras que mexi, como estas do sistema estavam consumindo muito espaço de memória para pouca coisa, resolvi escrever as minhas.

Não é nenhum bicho de sete cabeças, porem tem o inconveniente de sempre que reajustar o clock ter de recalibrar a de uS.

A calibração do tempo tbem pode ser feita pelo cronometro do debuguer.

/* Rotinas de DELAY * Parametro maximo que pode ser utilizado em qualquer escala é 255 */
// uso: delay_us(100);
void delay_us(uint8_t us) // *** Os calculos de tempo começam na rotina de "ms" ***
{ uint8_t r; // Para saber o valor por pulso dividir 1000uS pela contagem
for(r = 0; r < us; r++); // total para saber o tempo por pulso (1000/648=1,54us)
}

void delay_ms(uint8_t ms) // Ajustando tempo: Cronometrar 10s com VSWPro, fazer media
{ uint8_t p, q; // de três leituras, considerar os 4 digitos (10.69 = 1069)
for(p = 0; p < ms; p++) // multiplicar indices do laço obtendo contagem total (7 x
for(q =0; q < 8; q++) // 100 = 700), dividir tempo pela contagem total obtendo
delay_us(81); // tempo por pulso, calc. inteiros para obter contagem ideal
}

void delay_s(uint8_t s)
{ uint8_t i, n;
for(i = 0; i < s; i++)
for(n =0; n < 10; n++)
delay_ms(100);
}

brasilma escreveu:As rotinas de temporização foram as primeiras que mexi...

Eu tb! Só que as primeiras coisas que eu fiz no AVR, foi conhecer o funcionamento dos timers!!

Brasilma arrebentando no C!!

Yesssssss!!! eheheheheheheheheh

[]'s

Pelo o que entendí o problema do tcpipchip não está na função usada.
No caso acima o problema está nos fuses, supondo que não haja erro de SW.
Como está dando a metade do tempo, deve estar sendo usado um chip da família ATmega32 ou 64 e deve estar com o fuse CKOPT desaprogramado dando a metade de Fck.
Se fosse em um ATmega48, 88, 168 a frequencia estaria 8x menor devido a um bit similar nos fuses com outro nome.

estou usando o ATMEGA8515L...
tem algum esquema de FUSE nele que nao sei ?

Não, eu errei. Ví como 20Mhz e não como 2Mhz.

O fuse é o mesmo mas a função dele é até 8Mhz CKOPT = 1 (desprogramado) e acima de 8 até 16Mhz CKOPT = 0 (programado) o que aumenta a amplitude do oscilador e consumo do mesmo, ou seja, um cristal acima de 8Mhz pode o oscilador não manter ou partir sem mudar esse fuse. Não é o seu caso. Poderia até ser se estivesse pegando o segundo harmônico. Mas esse não é o caso pois a F está Fcristal/2.

Verificar:
Verifique se CKSEL 1..3 o divisor de frequência deve estar setado para 1, por programa. Veja se em algum ponto do seu programa está setando esse registro com outro valor.

Com certeza foi modificado o valor para 2000000, na área descomentada, dentro do delay.h.

Tá muito estranho...no ATMEGA168 consigo manda dados para a PS/2 do PC...

No ATMEGA8515 nao vai....
Vou ter que ficar com o ATMEGA168 mesmo

A diferença é que no ATmega168 a frequência Fck/io é setada por programa no registro CLKPR nos bits <CLKSEL3..0> = 0 divisão por 1, ou seja, clock iqual ao do cristal.
Há um fuse de nome CKDIV8 que divide o cristal por 8, além do prescaler em CLKPR, por programa.
Nesta família, mesmo com um cristal, pode-se mudar Fck/io durante o funcionamento através do registro CLKPR.

Já no ATmega 8515, que eu não conheço bem, os bits CLKPR são fuses e não são modificados por programa como nos ATmega48,88,168 .
Para um cristal de 2Mhz CKOPT=1 e< CLKSEL 3..1> =110 . Mas pelo o que entendo, isso deveria mexer somente com a performance do oscilador e não com a frequência.
Já a frequencia do oscilador interno é totalmente dependente de CLKPR (bits CLKSEL).
O oscilador interno vem setado para 1Mhz.
Há possibilidade de no 8515 estar setado para uso do oscilador interno ?
Pois com 1Mhz dará o dobro do tempo no seu delay.

Eu setei certinho no MAKEFILE para 2000000 o cristal e comentei F_CPU dentro do .H

Se acima em lugar de "cristal" seria clock, estou raciocinando como um oscilador a cristal, desde o início.
Caso esteja usando oscilador interno, seu problema são os fuses CKSEL do 8515 que tem que ser setado para 2Mhz na mão.

Na família AT48,88,168 e novas estes fuses são setados por programa e inclusive podem ser alterado em runtime.

Se seu oscilador é relamente a cristal, e não oscilador interno, penso que só há a possibilidade: de não estar setado para uso com cristal, no caso do 8515 e está atuando o oscilador interno com 1Mhz, por default, o que lhe dá o dobro do delay programado.