AVR-Chat

Hey Guys,

Would this work as well?



static unsigned char array1[100];


[Non-text portions of this message have been removed]

Below, do you mean that the array would be zero'd once each time the
program runs (such as after a reset) ?  The K&R C standard and most
run-time initialization programs do for sure zero static storage once. 

In my experience, it's rather rare to have to repeatedly zero out an
array, from a programming technique and algorithm viewpoint. You might
agree that zeroing an array implies you are later going to read
elements of the array that have never been assigned a computed value.
This is usually poor design.

--- In AVR-Chat@yahoogroups.com, David Appleton <englsprogeny@...> wrote:

>
> Hey Guys,
> 
> Would this work as well?
> 
> 
> 
> static unsigned char array1[100];
> 
> 
> [Non-text portions of this message have been removed]
>

In this application, the arrays represent individual LEDS on the led
nameboard. These run as 8 * 8 modules from 4 * 16 bit Constant current
shift registers. Similar to 74HC494, but with Constant Current Drivers.

I need to clear the arrays everytime I change the display, I found it
faster clearing the arrays then just incrementing the indexes that
have LEDS that are to be on. I I were to assign either a 1 or 0 to
each one instead of just incrementing the ones that are on, it would
take longer than just clearing the arrays to start off with.

Hope that explains it a bit, from the different methods I tried, the
one where I clear the arrays first seems to compile to the smallest size. 

I was really just looking for a faster way to do this, I figured
someone may have come across a clever way using pointers.

Thanks for all the replies !

Cheers
Hein B
Auckland, New Zealand

--- In AVR-Chat@yahoogroups.com, "stevech11" <stevech@...> wrote:

>
> Below, do you mean that the array would be zero'd once each time the
> program runs (such as after a reset) ?  The K&R C standard and most
> run-time initialization programs do for sure zero static storage once. 
> 
> In my experience, it's rather rare to have to repeatedly zero out an
> array, from a programming technique and algorithm viewpoint. You might
> agree that zeroing an array implies you are later going to read
> elements of the array that have never been assigned a computed value.
> This is usually poor design.
> 
> --- In AVR-Chat@yahoogroups.com, David Appleton <englsprogeny@> wrote:
> >
> > Hey Guys,
> > 
> > Would this work as well?
> > 
> > 
> > 
> > static unsigned char array1[100];
> > 
> > 
> > [Non-text portions of this message have been removed]
> >
>

Ah so. Well in that cast, no doubt the fastest way to clear the array
is to call memset() since it's probably optimized asm code, as said
earlier in this thread.

--- In AVR-Chat@yahoogroups.com, "kernels_nz" <kernels@...> wrote:
>
> In this application, the arrays represent individual LEDS on the led
> nameboard. These run as 8 * 8 modules from 4 * 16 bit Constant current
> shift registers. Similar to 74HC494, but with Constant Current Drivers.
> 
> I need to clear the arrays everytime I change the display, I found it
> faster clearing the arrays then just incrementing the indexes that
> have LEDS that are to be on. I I were to assign either a 1 or 0 to
> each one instead of just incrementing the ones that are on, it would
> take longer than just clearing the arrays to start off with.
> 
> Hope that explains it a bit, from the different methods I tried, the
> one where I clear the arrays first seems to compile to the smallest
size. 

> 
> I was really just looking for a faster way to do this, I figured
> someone may have come across a clever way using pointers.
> 
> Thanks for all the replies !
> 
> Cheers
> Hein B
> Auckland, New Zealand
>

Sorry, I'm too late always, but:

as you know AVR is an 8 bits micro which means each 
transaction to memory allowed only in 8 bits at one
time. but filling memory unlike 80x86 CPU's is not
an embedded instruction, safest way is to use memset
function but, if speed is most important factor,
memset could be optimized also. (by now i dont know
the real implementation of memset function in C
runtime library), consider to folowing sources:

//////// an optimized version of memset function
_memset:	//p:(r25,r24),n(r22),size(r21,r20)
	movw	ZL,r24
	movw	r24,r20
	sbiw	r24,0
	breq	.no_fill
	sbrs	r24,1
	rjmp	.word_fill
	st	Z+,r22
	sbiw	r24,1
	breq	.no_fill
.word_fill:
	st	Z+,r22
	st	Z+,r23
	sbiw	r24,1
	brne	.word_fill
.no_fill:
	ret

//////// an optimized version to fill words instead of
bytes
_memsetw:
	movw	ZL,r24
	movw	r24,r20
	sbiw	r24,0
	breq	.no_fill
.word_fill:
	st	Z+,r22
	st	Z+,r23
	sbiw	r24,1
	brne	.word_fill
	ret

//////// I hope memset be implemented like this in C
runtime library

memset:
	movw	ZL,r24
	movw	r24,r20
	sbiw	r24,0
	breq	.no_fill
.byte_fill:
	st	Z+,r22
	sbiw	r24,1
	brne	.byte_fill
	ret

execution time for 100 bytes (or generally n bytes)
	memset:		504 cycles (4+n*5)
	_memsetw:	354 cycles (4+((n/2)*7)
	_memset:	357 cycles (7+((n/2)*7)

these functions use a safe and fast enough code to
fill
memory bytes or words.

sample usage:

  unsigned char array1[100];

1-  memset( array1, 0, sizeof(array1));   
2-  _memset( array1, 0, sizeof(array1));
3-  _memsetw( array1, 0, sizeof(array1)/2); //count of
words!

but consider some important points:

if either you code's size or execution time is not
good enough, at least of problems exist:

1- your code needs optimization. so optimize it. to do
this, divide your code in time critical parts, and
generic logical parts. all time critical parts should
be implemented in assembly, but other codes may be
written in C or assembly, on your choice.

2- your job is too large (time/size) for selected
micro-controller. select another one, or increase 
micro-controller work speed.

but anyway, i wrote such a program for somebody, which
had more than 50 complex effects, data entry with AT
keyboard, works on an array of up to 32 blocks of 8x8
LED's each (using upto 256 bytes of memory). by using
an ATmega163 working at 8MHz it works very well. maybe
your hardware design is somehow simple, but not
effective.

as a suggestion, you may shift bits one by one to
shift registers, but try to shift out one byte at a
time by paralleling eight channels and clock all 8
rows in one cycle, like this:

for(i=0; i<sizeof(image); i++)
{
    OUTPUT_PORT = image[i];
    shift_register_common_clock = 1;
    shift_register_common_clock = 0;
}

it works perfect and fast enough.

in my project in most cases I needed to waste time to
synchronize LEDs with humen eyes.

good luck;

--- stevech11 <stevech@san.rr.com> wrote:

> Ah so. Well in that cast, no doubt the fastest way
> to clear the array
> is to call memset() since it's probably optimized
> asm code, as said
> earlier in this thread.
> 
> --- In AVR-Chat@yahoogroups.com, "kernels_nz"
> <kernels@...> wrote:
> >
> > In this application, the arrays represent
> individual LEDS on the led
> > nameboard. These run as 8 * 8 modules from 4 * 16
> bit Constant current
> > shift registers. Similar to 74HC494, but with
> Constant Current Drivers.
> > 
> > I need to clear the arrays everytime I change the
> display, I found it
> > faster clearing the arrays then just incrementing
> the indexes that
> > have LEDS that are to be on. I I were to assign
> either a 1 or 0 to
> > each one instead of just incrementing the ones
> that are on, it would
> > take longer than just clearing the arrays to start
> off with.
> > 
> > Hope that explains it a bit, from the different
> methods I tried, the
> > one where I clear the arrays first seems to
> compile to the smallest
> size. 
> > 
> > I was really just looking for a faster way to do
> this, I figured
> > someone may have come across a clever way using
> pointers.
> > 
> > Thanks for all the replies !
> > 
> > Cheers
> > Hein B
> > Auckland, New Zealand
> > 
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com