@ Gus - OK, that helps. Next question: If you’re using the Windows UWP API does that imply that the underlying driver that GHI has to provide will be significantly different than what you provided for the .Net Micro Framework? For example, we (GHI and I) went through a lot of pain getting the serial port driver to work under heavy serial port traffic (see https://www.ghielectronics.com/community/forum/topic?id=19245 ). That code seems pretty stable at this point. How much will the TinyCLR serial port driver leverage the .NET MF driver? Will it be identical to the old driver? Nearly identical? Wildly different?
@ Gene - starting with identical driver.
@ Gus - That’s good news (probably).
Good luck with the TinyCLR release. I’ll be interested to see what it looks like when it’s ready for prime time.
Cheers
1 Like
I havent contributed yet, but would be quite interested. I’m a professional developer with considerable .Net experience, use Git daily at work with a team I supervise and was originally trained in electronics, so im pretty well positioned.
Ive been gradually equipping a home electronics lab in a spare garage too, and slowly getting my electronics dusted off after years of only coding.
Thanks,
Hugh
I see you guys use the name “TinyCLR OS”. But the CLR (as commonly understood) is quite different to an OS. I would imagine that it would be helpful to distinguish between these two abstractions rather than lump them together?
The CLR is (as im sure you know) specifically concerned with managing the execution of MSIL code on some hardware, managing memory, GC etc.
Do you in any sense separate these abstractions? are they implemented or delivered as distinct items?
[ul]LargeBuffer is useful for RLP, it provides a means of allocating shared memory that is not moveable by the GC but accessible by both managed and unmanaged code.
Has the GC been optimized to handle this new memory allocation strategy? Having large allocations on the manage heap would mean that the current NETMF GC algorithm would be moving larger chunks of memory around, this could result in spikes of slower GC times. Even the full .NET implementation have the large object heap for some of the same reasons.[/ul]
@ taylorza - there is more work we still want to do in the RLP area. Fixed buffers shared between managed and unmanaged are something we’re keeping in mind.
We’re also looking into heap and GC performance. Something similar to the desktop large object heap may be preferable. Removing the max allocation limit is only the first step.
1 Like
@ John - That sounds good, I really need to get back into .NETMF and the new stuff you guys are doing.
2 Likes
When is the next drop planned ?
3…2…1… Go!
2 Likes
I hope with a G400 support
I would ask for more 
1 Like
Where ? Where ? Where ? :whistle:
Compliant with the new leading edge SOM from GHI let’s say the G800?
Exciting!!! Glad to see GHI is moving fast and committed to TinyCLR OS. We just launched our first commercial product based on the G120.
I know this is probably pushing it, but I would love to see TinyCLR OS on Cortex M0+, we develop a lot of ultra low power devices as end points, man runs on coin cell battery. OR, I hope one day TinyCLR OS on a platform/architecture that consume comparable power to the current ultra-low M0+.
2 Likes
@ hunghp -
The M0+ today at flash and 4K RAM is not big enough for a .NETMF type of solution. But don’t stop hoping.
@ Mike - there are extreme low power m0 devices with a decent flash/ram size on the market. But yes 4k is not enough for any managed system.
I’d love to see .Net Micro/TinyCLR on a M0/M0+ also. Is it possible to add external RAM/Flash to any of those devices and get the memory needed?
If you start adding ram the power consumption increases.
It will be interesting to see what the .net nanoFramework comes up with in terms of size and power consumption.
https://github.com/nanoframework/nf-interpreter/issues
List of hardware boards for nFI development
https://github.com/nanoframework/nf-interpreter/issues/6