See [url]https://github.com/NETMF/netmf-interpreter/issues/467[/url] and [url]https://gitter.im/NETMF/netmf-interpreter[/url].
thumbs down!
generics a way more important to me than the sync Keywords.
The micro framework is targeted to the smallest devices. For async or genetics, the target is a device with more resources and Windows 10 core. Or Linux with Mono.
Too many requests for ālargeā features might make Microsoft think we have outgrown MF, resulting in a product freeze.
While I understand where youāre going, I also think that one of the best features of NETMF has always been the simplicity of creating multithreaded applications. Async/await would only further simplify the existing functionality and make it easier to move between .NET platforms. On the flip side, I fear that it may make it too easy to multithread and lead to lots of performance issues. But, thatās a problem for programmers not compilers.
2 Likes
NetMF is an open source platform. If you love a feature enough, you can port that functionality over yourself and do a pull request and/or maintain your own fork, and I say āportā because the code for these features is already open-sourced.
Waiting for Microsoft to resource your favorite feature is not the only way to get stuff done.
That said, async/await is just syntactic shorthand for stuff we can already do. I believe async/await would also probably require generic support first (because Task is genericized over the return type), and all of that is going to substantially bloat the interpreter and core assemblies - all in the name of features that are just author-time programming aids. I donāt like the idea of putting too much into author-time sugar in a framework that needs to be optimized for runtime size and speed.
The cost is a lot smaller in the AOT solutions like Ilium, so I will look for those features there.
1 Like
Yeah, thumbs down; Iād give up threading altogether if itād get me Llilum faster. Instead of async/await and threading in general, we need better access to the timer hardware.
Generics need to be handled in the compiler and infrastructure and would go a long way, even for NETMF.
āTasksā have already been done, for a year now, I did them.
āasync/awaitā is just more compiler state machine magic
Doesnāt it have to thaw before it can freeze? :whistle:
I donāt think I said anything like that. I was mostly responding to @ Mikeās statement that requesting big features in NETMF would lead to a product freeze. Although, I realize this is a big feature to implement I donāt think the request should be unexpected by anyone since async/await are so common in everything else .NET. Do I think it would be awesome to have? Yep! Do I think its really that important for NETMF? Nope!
Yes, timer could use improvements. Such as being able to use hardware RTC. Iāve submitted PR #359 adding RTC support for SMT32F4 last December. Is still on the queue waiting forā¦ something to happenā¦ 
My 2 cents. In the absence of multi core NEETMF we shouldnāt have wait and async features.
@ JSimoes - The RTC is important, and should be supported, but the timer hardware as well. The STM32 (and most microcontrollers) have a large selection of very capable timers; in the STM32 case, there are 14 available. They can generate PWM output (with programmable dead time), do input capture or output compare, read quadrature encoders or hall effect sensors. Much of this is clunky or impossible right now without RLP.