Is there a way to get rid of these Spin loops?

Patrick1ab

These lines of Spin code (especially the repeats) of the attached program are the bottleneck while loading a Windows Bitmap file:

if buf[28] == 24
        repeat h from y+height-1 to y
          sdfat.pread(@line,3*width)
          lcd.lcd_drawrow(h,width, @line)

          if pad
            repeat until pad == 0
              sdfat.pread(@dummy, 1)
              pad--

      elseif buf[28] == 32
        repeat h from y+height-1 to y
          repeat temp from 0 to width-1
            sdfat.pread(@line[temp*3], 3)
            sdfat.pread(@dummy, 1)
          lcd.lcd_drawrow(h,width, @line)

          if pad
            repeat until pad == 0
              sdfat.pread(@dummy, 1)
              pad--

Loading a 24 bit color file could be faster, but for me it's okay: ~0.8 seconds
but when it comes to loading a 32 bit color bitmap it takes more than 20 seconds.

Is there a more elegant / efficient way?
Best thing would be to translate this to Pasm, but I don't think thats possible, is it?

lonesock

The more data you request at once, the faster the SD access will be (and it would be best if your line buffer was long-aligned, assuming FSRW, but most likely true of Kye's code as well).

So, reading in an entire scan line at once is probably the best compromise for speed vs RAM usage. That would include reading in the padding at the end of the line.

Then, the most elegant solution would probably be adding in a method to the lcd code to do a drawrow with 32-bit values in (what object are you using? I'm betting it's in PASM, so you may have to get your hands dirty ;-).

Jonathan

Bobb Fwed

Patrick1ab wrote: »

Best thing would be to translate this to Pasm, but I don't think thats possible, is it?

SPIN is an interpreted language. It is interpreted and executed by PASM. So anything that can be done in SPIN can most definitely be done in PASM. And usually dedicated PASM code runs about 300 to 800 times faster than similar SPIN.

Patrick1ab

Hi everyone. Thanks for your replies.

lonesock wrote:

The more data you request at once, the faster the SD access will be (and it would be best if your line buffer was long-aligned, assuming FSRW, but most likely true of Kye's code as well).

So, reading in an entire scan line at once is probably the best compromise for speed vs RAM usage. That would include reading in the padding at the end of the line.

I'm working on a new version, where I use a long-aligned line buffer:

long line[40]       ' 40 longs needed for a maximum of 32 bit color depth
                      ' 30 longs for 24 bit color depth
                      ' 20 longs for 16 bit color depth
                      ' and 10 longs for 8 bit color depth

It's bigger than the old one, because I want it to be able to hold one line of a 32 bit Bitmap (although only 24 bits are used; empty bytes... yuck... Microsoft invention I guess)

lonesock wrote:

Then, the most elegant solution would probably be adding in a method to the lcd code to do a drawrow with 32-bit values in (what object are you using? I'm betting it's in PASM, so you may have to get your hands dirty ;-).

The object I use is a display driver I'm currently working on.
See my other thread: http://forums.parallax.com/showthread.php?t=126432

I started creating an experimental version of this driver yesterday, which should be even faster (less hub operations) and which is intended to support also 16 and 32 bit color depth. The constant problem is that I need to convert the format of the bitstream.
For example:

needed by the LCD (262K color mode): rrrrrr gggggg bbbbbb

Windows bitmap (32 bit): bbbbbbbb gggggggg rrrrrrrr 00000000 (one pixel; 8 bits unused)
Windows bitmap (24 bit): bbbbbbbb gggggggg rrrrrrrr bbbbbbbb (one pixel and beginning of the second one)
Windows bitmap (16 bit): bbbbbggg ggrrrrr0 bbbbbggg ggrrrrr0 (two pixels and one bit/ pixel unused)

The plan is to use a "rdlong" for the 32 bit mode, a "rdword" + "rdbyte" for the 24 bit color mode and maybe a "rdlong" again for the 16 bit mode. This should simplify the cut-out masks aswell.
Afterwards I'm going to put it together again with the "movi" instruction I just found yesterday while reading the manual.
I only hope that I won't mix up the different modes while writing the code ;-)

Bobb Fwed wrote:

SPIN is an interpreted language. It is interpreted and executed by PASM. So anything that can be done in SPIN can most definitely be done in PASM. And usually dedicated PASM code runs about 300 to 800 times faster than similar SPIN.

Okay, but how do you call an external object from Pasm? How to pass the parameters? The repeat loop with "djnz" for example wouldn't be the problem.