I’m starting to look at how much pain I’m going to suffer if I start using TinyCLR OS. One of the deciding factors in my using .Net Micro many years ago was the ease of use, functionality and code examples of the built-in SerialPort Class. My understanding is in the last version of .Net Micro, the serial port event handler is interrupt driven and has quite large send and receive buffers. This makes my job of processing many serial devices immensely easier. The TinyCLR UART example appears to be a simple polled application (no event handler) and I haven’t found anything in the Microsoft UWP documentation that helps me understand if I can get the same interrupt driven/large buffer capability in TinyCLR OS. If someone could point me at the relevant information, I’d sure appreciate it.
firstly lets split interrupt driven versus not interrupt driven from buffers as those are two different things
GHI try to be “compatible” with UWP and UWP does not support interrupt driven UART readings but async read operations so the principle is nearly the same
i am sure you will not have issues because you have to poll instead of using interrupts
regarding buffers i think GHI will try its best to have at least the same size as in .NETMF but the buffer size is part of OS optimization and one of the last steps in the development cycle
With regards to buffer sizes, one thing we’d like to expose going forward is more control over their sizes so you can tune them to your application’s needs.
In the current release of TinyCLR, while there’s no event exposed in managed, there is a native event. See SetDataReceivedHandler on the UART provider. Right now the handler we set doesn’t raise any managed event but we’ll be looking into changing that. While we won’t be changing the SerialDevice API (we want to be as close to UWP as possible), you’ll be able to get an instance of NativeEventDispatcher that corresponds to the data received event. Currently only ErrorReceived and PinChanged are exposed in managed, since that’s all the UWP API needs (I believe PinChanged isn’t implemented in the firmware yet).
Of course, you’re able to make that change in the firmware yourself since we have it open now if you want to test it out without waiting for us. All that’s need to raise a managed event from native is call RaiseEvent on the interop provider. The event dispatcher name you pass to that function is the one you’ll get a native event dispatcher on in managed.
Good information from Kevin and John. Kevin mentioned async read operations and that was the Google search I needed. These documents helped
Apparently
await LoadAsync(numberOfBytesToLoadIntoTheIntermediateBuffer)
allows me to start an asynchronous read that runs in a separate thread while the rest of my program keeps doing its thing.
@John_Brochue - Couple of questions: 1) This functionality seems like a standard part of the UWP SerialDevice and StreamReader classes. Is it currently in or planned for TinyCLR OS? and 2) Where do I look to “See SetDataReceivedHandler on the UART provider”?
Unfortunately the rewriting that async relies on uses generics, so it can’t work in TinyCLR today, which is why we don’t have of the async functions. You’ll need to spawn a thread to manage it yourself.
The UART provider is part of the native code. You can find more information in the docs. Any changes on the native side require compiling your own firmware, but that process is much simpler now than in the past.
Thanks for the quick response. Not the answer I was hoping for, but it just means I’ll wait a little longer to start experimenting with TinyCLR OS.
BTW - if you’re still interested in user input on new functionality for TinyCLR OS, more control of the garbage collector (kind of like what microPython provides) would be great.
Do you have more specific details on what you’d like with the garbage collector? A new thread may be best for that
lol - great to throw that in on a discussion on such things 