Introducing TinyCLR OS: a new path for our NETMF devices

I think you are overstating things. I don’t think the community needs a white knight to protect them from “disappointment” - especially this early.

Who knows what optimization tinyCLR will get? I can’t speak for others, but Gus’ responses don’t seem at all dishonest. It’s a new thing, and now in the hands of people who are excited about .net on tiny devices, instead of the large, slow, and under-resourced-and-under-motivated group that was handling .netmf and seemingly happy to ignore it and let it die a slow death.

One way to kill any new fledgling thing is to be overly negative-nancy and debbie-downer about it, before it even takes off.

I’m personally excited about tinyCLR, and checking my mail daily for some compatible hardware to arrive.

I’m not saying you shouldn’t share your opinions - that’s what this place is for, and my opinion isn’t any better than yours - but I do want to offer my opinion that you are coming across as a bit of a “blah blah blah it’s never going to work, I’m really smart and I’m going to tell you why your new thing is actually probably going to be lame and not as cool as you make it sound” sort of a grinch, here.

(No offense intended, just an observation of how your posts are coming across to me personally. I hope you understand the spirit this is offered in. I’m kinda aspergerish myself, and misread people all the time, so take my words with a grain of silicon)


@ godefroi -

Here’s the problem:

Statements like this and it’s cousin “.Net Micro/TinyCLR can’t do real time” are completely misleading. I was actually just kidding about the 75% only because I think Gus and Gary should leave a little bit of the embedded market to their competitors on their way to world domination. But I’m willing to bet a beer or mixed drink or your choice that .Net Micro/TinyCLR can in fact handle an awful large fraction of the real world embedded applications out there including those that require DSP and real time.

Of course the interpreter limits performance and of course the G400 is overkill for my application. Neither of those issues are of any real importance to me, and I’m guessing the majority of industrial embedded developers. The overwhelming consideration in my choice of a development environment is time to market with working, rigorously tested, robust, maintainable software. The cost of the chips is utterly insignificant in the overall life cycle cost of my projects, it’s the development ecosystem that matters. By ecosystem I mean the development environment, availability of test frameworks, libraries (built in, open source, purchased, whatever), example code, a wide range of hardware including processors and peripherals, a robust user community where I can get my stupid questions answered at 4 in the morning because there are developers in New Zealand looking at the forum(s) and all the other stuff that makes for cost effective development.

Of course we need to be honest about what TinyCLR can do and can’t do. And there is plenty or room for improving the ecosystem. But that requires market share. Focusing on whether the language is interpreted or compiled as a metric for what TinyCLR can do is really missing the big picture at least IMHO.


Even thou they are all a bunch of weirdo sheep shaggers wearing grass skirts :smiley:

1 Like

@ Bill Gates - If they’re willing and able to answer my stupid questions at 4 in the morning, I don’t care what they do in the privacy of their own sheep herd, :slight_smile:


It’s currently Friday the 6th 2.33pm at the moment

Bahhhhhhh ;D

An awesome community :slight_smile: I am going to continue to focus with the team on bringing you the next TinyCLR announcement, which will be a big deal for most… Can’t wait to share.


Stop lying to the people on the forum and answer the emails that I’ve been sending you. :whistle:

1 Like

@ Gary - this tech talk tomorrow will show how hard working you are :wink:


@ Gary - I don’t want to be picky but don’t you owe me an e-mail?

@ Gus - Let us have it now!

@ Terrence - we don’t want to just talk about it and hear any whining. We want to give you a decent download.

1 Like

I forgot about that video! :wall:

I actually owe you about 5 emails but I am finally back in the office from the holidays and you are at the top of the good list I have.

@ Gary - Gene’s at the top of the good list?

Wow, dude’s on a roll.


@ mtylerjr - If what you imply is true, and I can singlehandedly kill off NETMF, then NETMF is already doomed.

Maybe I am overstating it here. Entirely possible. However, nothing is going to fundamentally change on the performance front until native compilation comes.

Also, I never claimed to be anything other than a curmudgeon, and a grumpy one at that.

1 Like

@ godefroi - interpreted code will never ever run as fast as the compiled code. This is a had fact. What we are talking about is performance improvements, which is still way too early to measure and be concerned about. We are changing how NETMF work and changing the user experience around it. In the unlikely event we could not improve performance, TinyCLR OS will still be an amazing and easy way to develop real products very effectively, just like NETMF have served thousands of products for about 10 years.

@ Gus - Are you willing to talk about the details of what you’re planning to do to improve performance?

@ godefroi - I don’t think that performance is the main goal of netmf or TinyCLR OS. The main goal is ease of use. Effort spend in improving performance would be subject to steep diminishing returns; and it will never be as fast as native. This is because fast/performance is a subjective term. How much performance do you need? What is fast? How much of the application needs to be in RLP for it to work? Its about balance. Now if you want the fastest thing around here then plug in The Module. At 1Ghz A8 + 200Mhz PRUs, it should be plenty of speed. But you have to program it in C and you have to deal with that Debian Nightmare Kernel.

Ultimately until we have C# compiling to code that the processor natively understands; don’t hold your breath for performance boosts.


This sure has become an interesting thread, I like it.

@ cyberh0me - I’m curious what you mean by

I was stuck for a short time on a project that used Arduino. In the early phase of the project the scientists working on it loved Arduino because they could get small, simple “proof of concept” instrumentation working quite quickly without a lot of software or hardware engineering expertise on their part. It was only when we needed to turn the proof of concept project into a well engineered system that Arduino became problematic. So isn’t it more fair to say something like “Yes, Arduino is really easy to use for simple projects”? But then follow it up with something like “But if you really want to engineer a system from simple to moderately complex, you should take a look at .Net Micro or (in the near future) TinyCLR”.


@ Mr. John Smith - I know exactly what the goals of NETMF are, and I know that performance wasn’t one of them. You don’t design an interpreted system with a goal of hardware efficiency.