Main Site Documentation

FEZ Cobra with 130x130 SPI Screen - why sooo slooowww


#1

hi guys i got my cobra today and started development of a project… with a 130x130 SPI screen.
The screen supports a ‘write-mode’ which allows me push a double-buffered byte[] directly to the screen so there’s nearly no lag with the transmission process.

What bothers me is time consumed by filling that buffer… the buffer size is 130x130, and it’s ushort[],
i tried using for(…)loop to fill that buffer (clear screen) or using Array.Copy to make it a bit faster…

But those didnt help, it’s still like 1FPS… why is there such a bit difference between using ‘native’ screen with that screen connecter to applying the ‘external small SPI screen’… ::slight_smile:

Any suggestion will be helpful!

Thanks ;D


#2

welcome to the forums.

you do of course realise that “native” screens are parallel, and an SPI screen is serial, right? So even if you wrote to the device at the same rate, you’d take much longer to write the the whole data out in SPI.

But your problem is more a data copy issue. There are some other threads here on array handling optimisation, but you might have to either wait for one of the original contributors to see your post or go try search…


#3

thanksss for your quick reply =v= gonna do some search though, it’s really an array-handling problem and i wonder if i can write some native code there, while using stuff like ‘LargeBuffer’ to link those stuff together…

And i’m also curious in the way the ‘official graphic lib’ make things get rendered fast…
Can I use the lib while using SPI screen?


#4

There is a huge difference in native screen and SPI screen.

A native screen gets updated by hardware without software interaction. The software just sees a large array of pixel data in memory, if you change a pixel in that memory, it is directly reflected on the screen by the hardware.

With SPI you have the software that needs to transmit the pixel data to the screen over a slower serial bus.


#5

If we are discussing a speed problem, then we must be quantitative. Saying something is slow without backup numbers is not enough.

You think the problem is with the array copy, but are you sure?

Please write a program which contains only your code snippet, and execute the method 1000 times. Messure how long it takes. We will then know if this method is your problem.

Please give us some numbers…


#6

Are you sure it’s filling array consuming your time? Or it’s SPI communication (actualy initialization)?

[quote]Please give us some numbers…
[/quote]


#7

You need ot use Bitmap class for everything including clearing the screen. When you are ready to flush then you can transfer over SPI.

Of course this is documented on the wiki like everything else :slight_smile:
See this please http://wiki.tinyclr.com/index.php?title=Displays#Native-support_on_non-standard_display

We come to the community.


#8

Thanks guys!
your suggestions are really helpful, here’re some results so far:

  1. Request of ‘The Number’:
    Filling an Array (132x132 USHORT) :
    00:00:02.2146174
    00:00:02.2183432
    00:00:02.2067382
    00:00:02.4182268
    00:00:02.2064584
    00:00:02.2168089
    Code is just do a ‘for’ loop and set value to each item of the array without ANY calculation inside.

    While another test result:
    Using Bitmap class and GetBytes() method, draw a line on to the bitmap, write them directly through SPI (speed=40000)

00:00:00.1397776
00:00:00.1395407
00:00:00.1398297
00:00:00.1395117
00:00:00.1396907
00:00:00.1395185
00:00:00.1397155

that’s a big suprise for me…

  1. a new problem…
    my screen is 16bit color driven (RGB565) so I need to do a convertion again - with Arrays…
    or is there any possibility of me to write the convertion part in C or C++?
    seems native means fast (array part)

Thanks again!! ;D


#9

[quote]my screen is 16bit color driven (RGB565) so I need to do a convertion again - with Arrays…
or is there any possibility of me to write the convertion part in C or C++?
seems native means fast (array part)[/quote]

Did you see my reply? It doesn’t do what you need?


#10

Your reply was reallly helpful, ;D and as I posted, I’ve tested performance using Bitmap class and it’s all good… but the only problem is Bitmap class generates 0XFFFFFF color, but most of the ‘small’ screens are 0XFFFF which is 16bit color driven… :stuck_out_tongue:

I wonder if there’s any way for dev using small screens to convert 24bit-color to 16bit Natively, if I do it by using CLR+Array it will be as slow as what i tried before…

:slight_smile:

Is it possible for me to write C++ code inside my project? just for doing color convertion?


#11

Please read the link from my reply :slight_smile: You have everything you need provided by GHI!


#12

Util helps!

it’s a ‘WOW’ on performance… what a great product with such nice community support

THANKS SO MUCH!!

:slight_smile:


#13

I like this, you first post is about it being slow and you now it is wow on performance :slight_smile:

You just had to know how to do it right :slight_smile:


#14

That’s something you come to understand quickly working with these sorts of resource-constrained devices… they’re a whole lot less forgiving of brute-force and a whole lot more rewarding of cleverness :slight_smile: