Atmel AVR, too slow encoder tics counting

"Umpa" schreef in bericht news:c7ffsi$hj2$ snipped-for-privacy@atlantis.news.tpi.pl...

32 bits integers are very time consuming on 8 bit uP's. Perhaps you can use an 8 bit, and use that to adjust a 32 bit value in your main code.

main() { while(1) { cli() 32bitlicz += 8bitlicz; 8bitlicz = 0; sei() .......... } }

Well, something like that. I'm not in favor of using interrupts for encoder inputs. There are dedicated encoder frontend chips, such as HCTL2000 etcetera, which would be my preference for reading encoders at this speed. For reading hand turned encoders, such as digital pots, a timer interrupt does pretty well.

The risk with this all-software method, and the speeds you have, is loosing/gaining a few steps perhaps. Imagine the encoder/shaft is stopped, but vibrates. You can get nasty bursts of pulses in such situations, as the encoder is actually going back and forth. Of course, in many systems it may not matter much if a few steps are missed.

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)

Hello,

My code (I posted above) counts correctly -- I know about problem of "vibrating encoder shaft", and prepared correct code.

Umpa.

[snip]

I couldn't read it (Acrobat 5.0 under Linux)

-frank

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,

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.

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.

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.

fuses. Look at the datasheet!

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