include some assembler

Hey all,

I know it is possible to integrate some assembler code in Avrco. But I know nothing about assembler and need a very short piece of assembler to optimize for speed. Can someone help and take a look?

I try to multiplex a small RGB display with a xmega256A3u. I have a pointer to ram where the data is located, I have a free output port D and a free clock pin on a different port.
The assembler only need to get the ram byte at the pointer, increment the pointer, and place the data on the output port. Than it needs to set the clock pin high and low again.

I've a example from internet in C but like mentioned, I never used assembler in avrco or with the AVR so it's chinese for me Seems they do it in just 5 ticks :confused2:

Example:

// A tiny bit of inline assembly is used; compiler doesn't pick
// up on opportunity for post-increment addressing mode.
// 5 instruction ticks per 'pew' = 160 ticks total
#define pew asm volatile(
"ld __tmp_reg__, %a[ptr]+" "nt"
"out %[data] , __tmp_reg__" "nt"
"out %[clk] , %[tick]" "nt"
"out %[clk] , %[tock]" "n"
:: [ptr] "e" (ptr),
[data] "I" (_SFR_IO_ADDR(DATAPORT)),
[clk] "I" (_SFR_IO_ADDR(SCLKPORT)),
[tick] "r" (tick),
[tock] "r" (tock));

// Loop is unrolled for speed:
pew pew pew pew pew pew pew pew
pew pew pew pew pew pew pew pew
pew pew pew pew pew pew pew pew
pew pew pew pew pew pew pew pew

Thanks all for any help and information :thumbright:

Thnx Merlin.

Multiplexing an RGB display is time consuming because of the number of leds.
The display I have is 32x64. This results in 32*64*3RGB=6144 leds. To create several colors I want to give every led 16 intensity levels. So 16R*16G*16B=4096 several colors.
Using SPI is not possible: the display clocks two lines at once with R,G and B data (R0,G0,B0 for line 0 and R1,G1,B1 for line 16). I take port D for it and don't use D6 and D7. A whole byte works faster.

The code look like:

var
RgbClk[@PortF,7] : bit; //Clock pin
RgbData[@PortD] : byte; //port to send out the data arranged as xxR0G0B0R1G1B1
RgbDataArr : array[0..1023] of byte; //graphic data
RgbLine : byte; //from 0..15
MyPntr : pointer;
ii : byte;
idx : word;
begin
idx:=(word(RgbLine and $0F))shl 6; //Calculate the index in the array
MyPntr:=@RgbDataArr[idx]; //Set pointer
for ii:=0 to 63 do //Do for panel length
RgbData:=byte(MyPntr^++); //Get data
incl(RgbClk);nop;excl(RgbClk); //Clock data
endfor;

On a xmega256@32MHz, above code to clock RGB data for example line 0 and line16 is taken 85µsec not optimized. Optimized it still takes about 58µsec. If I see the internet assembler code, they do it in 64x5ticks=320ticks or 10µSec, almost 6 times faster.
To have an idea:
Let's take I do it not with assembler, just optimized. With some overhead I need 60µsec for two lines. For the whole screen I will need x16 = 960µsec. I will have to this 4 times to create a 16 level intensity so x4 = almost 4msec just communication. To create a smooth image with good color and no flickering you need a refresh rate of about 200 frames. That means my avr is almost full occupied with communication between the display.
I'm aware that it is time consuming and therfore I want to use 1 AVR as host. That one is for display tasks communicating over SPI to another avr as slave that does the display multiplexing.

Thnx;)

Thanks Thomas.

At the moment I still try to find out if the whole concept is good and feasible : will I have enough runtime, will it not be too complicated and is this the right way to make a big scoreboard? Because it is for commercial use, I also need to check some other things: beside budget and development time, are those RGB panels reliable and can I pass EMC testing with all those multiplexing …

So still some issues to check before I have a go;)

Thanks again Thomas, I will try it out;)

Hi,

the IN/OUT and SBI/CBI statement only work in a small memory area, $20..$3F
I think. Above that these statements can´t be used instead use LDS and STS.

rolf