TinyCLR OS 2.1 Preview 3

Press Announcements
1

Originally published at: TinyCLR OS 2.1 Preview 3 – GHI Electronics

TinyCLR OS 2.1 Preview 3

We know MORE coding is part of your New Year’s resolution, so we’ve added more features in the latest release of Preview 3 of TinyCLR OS for you to play with before final production release.

In-Field Update Reworked

This very powerful, and secure, feature received even more tricks under its belt. First of all, the feature now takes streams for new firmware and new application. Those streams can be network streams, file streams, and memory streams. You can even mix and match as you desire! We then gave the user the option to either use external RAM or external FLASH to be used as the required temp buffers. This means, small devices with no external RAM (extended heap) can use external flash instead.

Of course, worry not, all temp buffers held in external memories are kept in its encrypted form. All decryption is happening in the internal secure memories.

SPI-Display Graphic

The graphics update callback for updating displays has been updated to handle partial drawing. Meaning, if only few pixels have changed, there is no longer a need to graphic.Flush() the entire screen, partial flush instead Flush(x, y, width, height).

SPI also received a new spi.Write() overload that accepts x, y, width, height. It automatically does the needed matrix extract and sends the proper data.

We did not stop there! We added a “pixel multiplier” that allows you to use larger displays without needing more memory! Basically, you can now use a 320×240 display but then set the column and row multipliers to (2,2) and then the needed memory is only 160×120. You have just used the same display with 25% of the needed memory. This is needed as commercial needs called for larger display but no need for higher resolution. This gets better as you can use the multiplier on either width or height. For example, converting 320×240 to 320×120 display. This saves 50% of the memory but still gives you plenty of resolution.

Software PWM

The built-in support for PWM uses hardware to generate signals very accurately with zero processing. However, hardware-PWM only worked on specific pins. We now support PWM on any pin. While software PWM is not very accurate and requires constant processor time to generate the signal, it works well at lower frequencies. This is good for dimming lights or driving servos. Speaking of servos, we are now introducing a new servo NuGet as well.

FCC/CE Testing

To help our customers in completing their FCC/CE compliance of their final products, we have passed SITCore through the required testing. Provided are those test results.

7 Likes
2

VNC made it into this release! How cool is that! Can’t wait to try it out as well as all the other coolness that is part of TinyCLR 2.

1 Like
3

That’s awesome work guys!

I’m surprised you didn’t make a bigger point of VNC, had to find it hidden away in the release notes.

I can’t seem to find VNC info on the docs yet. Am I too eager and excited and you are still in the process of updating the docs or am I that at searching? :nerd_face:

1 Like
4

No one seemed to care for it but we think it is a good option. You can load VNC app on a 10" tablet and that becomes your SITCore display! We are still not done and docs will come (with an announcement)

@Dat_Tran can you post a small example here?

2 Likes
5 
 var vncServer = new VncServer("yourVNCServerName", 5900);

 vncServer.Screen = YourGraphic; // usually var screen = Graphics.From(....)

 vncServer.Start();

Tested with TightVNC.

1 Like
6

I haven’t had a chance to try Preview 3 yet but I just had a question.

Is it required to have a hardware display connected for VNC to work?

7

Not at all, not need both you can have both of you want

1 Like
8

I am unable to install the VNC nuget package because it requires a dependency that doesnt seem to exist. It seems to need GHIElectronics.TinyCLR.Network. I think that’s a typo? It means GHIElectronics.TinyCLR.Devices.Network right?

Changing this dependcy using a nuget editor seems to fix the problem. Need to test further though.

9

IT should work through NETWORK “via ETHERNET/WIFI” because it was act as SERVER
and you access to it via VNC Client

10

Yes, I understand. But it seems like there was a misconfiguration in the NuGet dependencies.

11

Not sure why it is fine on mine. Probably cached.

Anyway, the simple solution below will help, we will fix later. Thanks

image
image720×552 18.4 KB