Hi,
Thanks for pointing out reply issue, I didn't notice. I'm not sure what do you
mean about PROGMEM, I have declarations
volatile uint8_t CurrLed;
volatile uint8_t Leds[MAX_LEDS];
maybe I am wrong but volatile declaration shouldn't tell the compiler to fetch
value each time it's access it?
I think you are right about second statement, the interrupt uses too much time
and the execution of the next instruction never happens. Placing a CLI does not
stop the display. I think I have to rewrite the interrupt to match the HCT 161
transitions.
Regarding previous advice about dropping character generation at the runtime,
it is necesary, because the CPU will do just led display, nothing else. Data
comes via TWI and it's not formatted, format is position and then value, for
example 0, 0 means first digit must display 0, hence need adjustement to
diplay that value as led digits. If you have a better proposal I'll be glad to
hear it.
Cornel
----- Original Message ----
From: Philipp Burch <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, January 15, 2008 10:41:58 PM
Subject: Re: [avr-gcc-list] altering array variable and interrupts
Hi,
ok, if you need to modify the characters, then you can just declare the
mentioned array volatile and not PROGMEM.
What do you mean with "I don't think this really completely stops
execution"? Have you tested it, or are you just guessing? What's the
interval of the interrupt, how is F_CPU defined and do you use
optimization? There's an easy way to check if the program continues:
Place a cli(); instruction right before your mainloop. If it doesn't
hang in the interrupt, the program should then just run inside the
infinite loop and hence not do anything with the controllers pins, so
you can easy check.
btw: You should reply to "[email protected]", or I'm the only
recipient of the mail.
Philipp
> Hi,
>
> Thanks for reply. I do want to modify that array of char not to
> prevent changing them. Basicaly each time interrupt occurs it should
> read the array and output values, and I will change values often. I
> know delay inside interrupt is not a good tactic but I just didn't
> have time to compute the right low-to-high transaction time in CPU
> clocks to match the 74hc161 4-bit counter logical diagaram I clock
> from interrupt; hence I used a delay. I don't think this really
> completely stops execution of the program so the value never change.
>
> Cornel
>
> ----- Original Message ----
> From: Philipp Burch <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Tuesday, January 15, 2008 8:24:17 PM
> Subject: Re: [avr-gcc-list] altering array variable and interrupts
>
> Hi,
>
> I guess, your ISR takes too long. Delayloops in ISRs are very, very bad
> style, because they block the whole CPU. I suppose, the Interrupt comes
> more often than every 3ms, so there is no way for the AVR to execute any
> code outside the ISR. You should rewrite the complete program, there are
> many unnecessary things, such as character generation at runtime. Just
> declare a PROGMEM array with all your digits and read from it with
> pgm_read_byte() (From avr/pgmspace.h, check the manual of avr-libc),
> that saves RAM and initialization work. And it prevents the characters
> from getting modified (Or do you really need this "feature"?).
>
> Philipp
> > sorry I forgot to put url: http://rafb.net/p/fxrljj42.html
> >
> >
_______________________________________________
AVR-GCC-list mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping_______________________________________________
AVR-GCC-list mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
