Future products: C/C++ or TinyCLR 2.0

You are reading that page wrong. Module was made in 2012 and with 10 year guarantee you will be at 2022.

But like I said in the every beginning, you have half the info. You should be taking to us directly about your commercial needs and longevity. You should have been an insider months ago when we emailed everyone. You missed on some free boards :grin:

Anyway, announcement is coming in a few days.

@Justin I don’t understand why Microsoft insists on taking something good, modifying it to be unusable, and then dropping it, but I guess it works for then as they aren’t short of a quid!

Take Windows CE, that was a great little OS. Small, capable of hard real-time, with good control over threads and fibers, but a familiar Windows programming model. Apparently designed by some of the people behind the Amiga OS, another very nice system. We had WinCE running industrial control systems years ago, they are up for renewal in the next two years and we don’t see an alternative to switching to Linux as Microsoft has dropped WinCE.

The page says CPU Maturity Date Jul-2027.
I took that to mean you supported it until then.
If it means something different then I think the page needs to be made clearer, if I’m reading it wrong I think most people would read it that way.

CPU maturity to me implies the CPU vendor will offer the CPUs until then, and that’s their “confirmed” date. It has no direct link to whether GHI will or will not offer to make you any modules using that CPU… important to note that you’re NOT buying a CPU, you’re buying an implementation of that CPU onto something else…

Again, I have been in MSFT so get some of this strategically. The problem was that each of these “good ideas” was a fragment of the big picture, and each had their own misalignment to Full Windows. Sure, there were similarities but equally there were differences and quirks. That manifested in two things - the ecosystem had Full Windows devs who still had to re-learn stuff they took for granted on Windows who then came to WinCE with it’s quirks, and netmf had it’s own similar but different quirks - and secondly there was internal tension where one group could choose to do something against the grain because they thought it made sense but it just drove the divide deeper. All those things came at a cost (some of that to the ecosystem and developers, some to MSFT) and that didn’t make sense to continue, so things coalesced into a single roadmap where we are today.

as for what you can look at, Windows 10 IoT is designed to fill some of that void; small devices with long lifecycles and cheap ARM processors, or even Win10 in LTSC variants on Intel may suit, depending on applications.

1 Like

@Brett I don’t buy it, this is on the vendor’s product longevity page, in the table Long Term Product Availability
If they then claimed it was referring only to the CPU,and not their product it would be a clear case of misleading advertising.
In any case, it is also shown as Active which they say means:

Active: This product is recommended for new designs

The product lifecycle status section says a product goes from Active to Mature to Legacy.
At the transition from Active to Mature there is another 5 years support. The G120 is still shown as Active, not Mature, which ties in with the 2027 maturity date, assuming it becomes Mature next year.

Anyway, I guess it means whatever Gus says it means, but it certainly is NOT clear (at least to me) in its meaning!

The politics inside MS drove me crazy, to me NETMF was and still is a great option for lots of projects.

I will happily support TinyCLR OS - but NETMF will be in my future for along time to come yet :slight_smile:

3 Likes

Correct. It is not clear and that is why the page has now removed that column on the new website.

1 Like

I’ve looked at the MS plan to move WinCE on to Win10 using “pico processes” that provide emulated environments and I’m not buying it.
That’s why we decided to migrate to a Unix/Linux model for the next iteration, we get a stable environment with open source so we can lock everything in and move on when we want to.
With VS Code we even get a nice development/debugging environment at last!

… lock everything and hope for the best and if we need support then we are stuck browsing the internet for answers and hoping you will find an answer… sorry I couldn’t help myslef!

Linux is great, do not take me wrong but for companies who have Linux experts who can self maintain.

1 Like

couldn’t agree more Gus, it changes what you need to be able to develop… the kernel (or higher, in a huuuuge project) or just something a little easier (even netmf in it’s current state)

1 Like

Been building and maintaining Unix/Linux systems since the early 1980s, Gus.
You could call this “Legacy” code dating back to 1981 when I worked on the real-time OS used to run the Australian National Animal Health Laboratory (ANAHL, renamed to AAHL because people used to pronounce it Anal, and recently renamed the Australian Centre for Disease Preparedness - ACDP - because of the outstanding work they are doing there on COVID-19. I do think they should have called it the Australian Centre for Disease Control, so we could all call it the ACDC! :grinning:)

The code transitioned from M6800 assembler to C (6809->68008->68340) and then to various operating systems, including AmigaDOS, VAX VMS and Tru64 Unix, before corporate powers insisted on Windows (NT ->2000… etc). The field stuff stayed on our own hard real-time OS and dedicated hardware (where most of it still is) until the move to WinCE starting around 2007.

At this stage there is no plan to move those decades of legacy C code to C# or even touch the bulk of the code, just put emulation wrappers around it, which is MUCH easier with the more recent Linux tools than it was in the past. Despite the fact that these days your smallest processor would have ample memory and speed for the job, nobody is interested in paying for the old software to be ported.

3 Likes

yes, they should. Start a petition and I’ll sign it :slight_smile:

1 Like

A bit like when we got (partially) kicked out of ANZUS by the yanks - i guess they like ANUS over no Nukes in NZ…

+1 to ACDC

Now totally off topic :blush:

2 Likes

Super interesting conversation. No help at all with my original question. But interesting. :slight_smile:

1 Like

The openness and transparency in this community of professional developers is not found anywhere.

3 Likes

For the sake of completeness on this conversation (the original one :wink: ), it is worth mentioning .NET nanoFramework is a 100% Open Source project that picked up where the defunct .NETMF left off!

3 Likes

nf is where we are going as well with our app code

+1 to induct Justin to the NETMF Hall of Fame!

1 Like

I am facing a similar issue
I have use .NETMF and Gadgteer in the past.
Found a an old box full of GHI stuff for both the other day on the shelf.

I have a number of projects where I have used AVRs. Been happy with using VisualMicro and VS. Debugging has been reasonable. quite like the fact you can use Arduino libraries etc

Also have been playing around with STM32 stuff. Quite interesting but certainly more difficult to get running than .NETMF was.

I tried TinyOS (yes not on supported hardware) and I found it quite good. Easier in many ways to NETMF. It seemed to lack documentation and what I would call “good” examples. I managed to get a basic GUI working.

Going forward I will keep using ATMEL stuff. certainly I will keep playing with the STM32 stuff as its powerful, cheap and lots of tools. The TouchGFX interface designer is very nice, and they are simply giving it away. The ST Eclipse based IDE seems ok. I am yet to try Visual Micro with it.

1 Like