did you have seen driver done ago for .net mf
Vecc.Netduino.Drivers.Ili9341
1 Like
No I didn’t. But in our NETMF implementation it’s a native driver 
Because of speed and because of the graphics primitives that already exist in NETMF that we don’t have to recode.
Here, with TinyCLR, we mainly have to provide the init sequence and a transfer method for the graphics buffer (at least for SPI displays), so it’s much more simple.
1 Like
And it supports fonts and UI. You are welcome 
1 Like
and you’re welcome for the updates to properly support orientation changes and display issues And thanks for @taylorza way back when too ! 
2 Likes
Does your driver keep switching color between yellow and purples even we don’t change any color?
Known why, thanks
It’s because of the consecutive calls to BitConverter.SwapEndianness() on the whole screen, as you may have guessed already
But it seems to be solved in preview 3…
This will not change because it is very fast and you can always swap the buffer back. However, we are adding new methods that will make using SPI display a lot faster and better. Stay tuned…
1 Like
Oh, I don’t ask to change anything about this method. It is indeed very fast and useful.
It’s simply not really suitable to be used on the whole display just before sending the data to the device or when you are using windows to draw partial areas. That’s all I wanted to say
I understand. The work done now is not about SPI or displays or bit converter. This is about creating a real example of how someone can effectively use SPI-based display. We are on it 
@Bec_a_Fuel, which SitCore are you using for this display? Are you using the extended 32MB RAM? I am just wondering if a display that size can be effectively used with the SCM20100E.
It works beautifully. We have already tested it 
but you have to plan carefully of how you will be using RAM.
Not only that, we have just added a new feature that lets you use half the memory by only doubling the pixel on the screen. Meaning the 320x240 display is now 160x120. More details on this later.
2 Likes
Sounds great! I will proceed as planned with the SCM20100E.
@skeller : I’m using the SCM20260E SOM. The current graphics lib is (automatically) using the extended 32MB RAM indeed.
I think that the SCM20100 could use this display but, as Gus said, you would have to be very careful about other memory consumption as the underlying bitmap is roughly 150KB large (320x240x2).
The reason for the question is that I can’t fit the SCM20260E in any orientation on my board. The SCM20260N could fit but it would have to go on the back of the board which would make reflow much more difficult. I think I would have to reflow the back first and glue down the SCM20260N, then do the top side with all the other components. It makes me nervous running the SoM through the reflow twice, the second time upside down. In addition, I would have to add the SPI Ethernet. It’s tight but I can make the SC20100 fit on top.
But that extra 32MB RAM would be nice . . .
1 Like
So everyone knows, not only we improved SPI display support greatly, we also started with @Bec_a_Fuel code (thank you) and built a NuGet.
3 Likes
Is this in 2.1 RC2? If so how does it work, is there some documentation on it?
Thanks