Atmel AVR, too slow encoder tics counting - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Atmel AVR, too slow encoder tics counting
Quoted text here. Click to load it

10 kHz would be enough.
But, above two people have said that
my ATmega16 works with 1MHz
frequency, and I need to attach
cristal. I think, it solves my problem.

Umpa.



Re: Atmel AVR, too slow encoder tics counting
Umpa schrieb:
Quoted text here. Click to load it

You can set up your internal RC to 8 or 16MHz by progamming the corrseponding
fuses. Look at the datasheet!

Alexander


Re: Atmel AVR, too slow encoder tics counting
Quoted text here. Click to load it
fuses. Look at the datasheet!


The device is shipped with 1MHZ internal RC clock. Internal RC clock can
be set to 1,2,4,8 Mhz, NOT 16Mhz. Using an simple external 16Mhz crystal
gives 16Mhz clock rate.

best regards,

--
Bernhard Roessmann

Re: Atmel AVR, too slow encoder tics counting
On Fri, 7 May 2004 14:20:41 +0200, "Alexander Peter"

Quoted text here. Click to load it
fuses. Look at the datasheet!
Quoted text here. Click to load it

Internal RC can be set to 1MHz (Defult), 2,4 and 8 MHz. If you want
higher than that you need to use one of the other clock options.
With the 8MHz clock, you can probably handle up to 38.4kbaud.


Regards
   Anton Erasmus




Re: Atmel AVR, too slow encoder tics counting
Quoted text here. Click to load it

That needs a "volatile".

Re: Atmel AVR, too slow encoder tics counting


Quoted text here. Click to load it


The above most definitely needs to be 'volatile' to keep the optimizer
from caching the value in registers since it has no idea it might be
updated out of band in the interrupt routine.

Quoted text here. Click to load it

Hmmm ... these are probably OK as is.

-Brian
---
Brian Dean
http://www.bdmicro.com /

Re: Atmel AVR, too slow encoder tics counting
Quoted text here. Click to load it

In my opinion, your programm waste time in cursorHome() function because
1 or 2ms is needed by lcd controller to achieve this operation, but it
depend of how this function is implented. Possibly you may invoke
cursorHome when you really need to showString... something on LCD

Cheers,


Re: Atmel AVR, too slow encoder tics counting
Quoted text here. Click to load it
You are right. cursorHome() isn`t the fastest function in the world ;)
But, counting encoder`s ticks are realized by interrupt-driven
function. So, cursorHome() can be interrupted when
system calls SIG_INTERRUPT0 or 1.

Umpa.



Re: Atmel AVR, too slow encoder tics counting
Quoted text here. Click to load it

Okay that's right Umpa, ticks increment or decrement prior to normal AVR
code execution in that case. I thought about licr overflow or underflow,
in fact time waisted in cursorHome() before showString() anything on LCD
that might be misinterpret the results on LCD ... but i realized that
licr variable is long int (32 bits !!!) so no problem !

Tell me how you fixed that bug (hard or soft prob ?)

Habib.


Re: Atmel AVR, too slow encoder tics counting
Quoted text here. Click to load it
I did two things:
-- now my program uses only one interrupt - it made
my program faster, but only a little bit,
-- I changed internal frequency rate - default it is 1MHz,
I changed it to 8MHz and my program runs 8 times
faster ;)

Umpa.



Site Timeline