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’… :
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…
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?
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.
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.
Thanks guys!
your suggestions are really helpful, here’re some results so far:
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)
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)
[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?
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…
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…
Is it possible for me to write C++ code inside my project? just for doing color convertion?
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
