Future products: C/C++ or TinyCLR 2.0

SITCore
1

I have to admit I haven’t been able to spend much time understanding the current and future GHI product line but I have to make some decisions in the near future about what ecosystem to use for the new projects I have lined up and waiting for me. I definitely could use some input from the GHI community that has been so helpful in the past.

Here are the choices as I see them along with a few pros and cons

Choice 1: Stick with .Net Micro and the G400 like I’ve been doing for 8 or so years
.Net Micro, GHI and this community have been very, very good to me. My current major product literally would have been cancelled if I didn’t discover .Net Micro and GHI.

But…
.Net Micro isn’t going to be supported anymore.

But …
It does everything I need for now and for the foreseeable future and I’m pretty familiar with it.

But …
It isn’t going to be supported in the future (I know I’m repeating myself here).

Choice 2: Bite the bullet and dive into C/C++
There’s a huge variety of low power controllers out there and more importantly, critical software libraries. I’ve mentioned the QP Framework in the past and this is a big, big plus for my future projects.

But…
It is incredibly painful getting all the details right for even a simple bare metal C/C++ project. .Net Micro took care of all this stuff for me which was a huge plus for a reluctant programmer like myself.
My current fiddling around with STM32 processors and bare metal VisualGDB has been 80% figuring out how to the get a project configured properly with all the right libraries and startup code and 20% (or less) actually writing code I care about.

But …
Consultants are much more readily available in the C/C++ world and we have used them on a few occasions very effectively in the past.

Choice 3: Buy into TinyCLR 2.0 and SITCore
All the benefits of .Net Micro that saved by butt.

But…
It is pretty unclear to me what the capabilities of the SITCore processors and TinyCLR 2.0 are now and will be in the near future (6 months or so). I’ve been searching the Forum but at this point I haven’t been able to figure out a few key numbers. For example, a) the 20260s have either 7 and 8 UART ports but are they all available after all the pins have been mapped to other functions? b) How much external memory will be available on the production SOMs? I’ve found the generous memory on the G400 to be extremely helpful in making my programs more robust. And maybe most important is c) What is the power consumption and how effective are the low power modes?

A few last points: The overall cost and risk of our projects is overwhelmingly software design, development and test. I build oceanographic research equipment. Fairly complex, mostly battery powered autonomous systems. Production quantities will never be enough to drive the GHI train in our direction but spending money on NRE to get something customized for us in order to reduce risk is usually well worth the investment.

Sorry for the long post but this community has been incredibly helpful in the past and this decision is keeping me up at night. Like I said earlier, I’ve drunk the GHI Kool-Aid and am a big fan. I just haven’t figured out if I should keep drinking the Kool-Aid.

Thanks - Gene

2 Likes
2

Netmf is the past, bad idea.

C++ is nice but not productive like managed .net

TinyCLR and SITCore are done and that is the future. Productive, secure and fill featured… Backed by GHI Electronics’ legendary support.

2 Likes
3

Gus - Thanks for the quick response. Any chance of getting answers or even hints to the questions I asked in 3rd to last paragraph?

4

Go ahead list your questions and I would happily answer them. Also please take a look at the docs. It now includes a lot of new info.

5

Gus - Thanks for the offer, here are my questions:

6

A. Check the pinout of the som to see what features you need. If all you need is uart then you get all of them

B. There is plenty of memory to handle any IoT need. If you tell us more about what you need we been give it a better answer. Generally speaking, you should not have memory concerns.

C. It is less lower than g400 and we already have implemented few power saving modes. Keep in mind this is 480mhz

1 Like
7

Well I just spent 20 minutes looking for the SOM pinout without success, maybe you could point me at it. I know we’ll need external RAM and ROM and every time I’ve mapped pins on a STM32 device, the pins needed for RAM and ROM conflict with at least one UART port.

My application is not IoT and uses a lot of memory, at least 16 MBytes or RAM and 4+ MBytes of ROM. Hard numbers would help, even a hint at whether there will be more or less than 16 or better yet 32 MBytes of RAM and another hint for 4 or better yet 8 MBytes of ROM.

“lower than g400” isn’t really enough detail to help with my decision. The G400 is an order of magnitude more than what I can achieve with a STM32L4+ for example. And 480 MHz isn’t necessarily a plus in my case. We sleep as much as we can but when we’re awake there are significant sections of code that interact with other very slow devices. We can’t easily go to sleep during the interaction so we’re still burning power at the 480 MHz rate.

8

Where did you look? docs.ghielectronics.com?

A lot of users come from the PC world and they assume they need xxx for memory and yyy for storage. What does your application do that you are sure on exact needed memory? In most commercial application I have seen less than a megabyte is enough. The additional memory was only needed to support larger displays.

For power, we can’t share exact figured as this is changing still. Perhaps tell us what you need and we can tell you if we are close or not. This is not a tiny m0. This will draw over 100ma easily when fully operational. If you need something running at few ma then this is not the right solution for you… But then you said earlier your allocation need few megabytes.

May I suggest we get on the phone and discuss your application/needs or if you prefer you can explain what your application does here.

9

Thanks for the link, it is certainly easier when I know where to look. It looks to me like if I want to use SDMMC for external memory, I can get 7 serial ports.

My estimates for memory are based on previous projects. Like I said, the generous amount of memory on the G400 was a luxury that I took full advantage of and would hate to give up. Most memory intensive are the asynchronous queues I use to keep IO from devices (inherently asynchronous) separate from the rest of my program so I can keep things non-polled and non-blocking. I also have a few jobs where I have to store 10s of MBytes of data from sensors that are too fast for the SD card. I may also on occasion use fairly large lookup tables.

The testing I’ve done on a bare metal STM32L4+ indicates I can run full up at less than 100 mA. If your products running full up are less than 500 mA, that might be an acceptable upper limit.

I just need a few key metrics like these for now to figure out how much of my time I should invest in choice number 3. Like I said, I am a big fan of .Net Micro and it would be great if your new products fit my needs, or at least come close, as well. A phone call would be great when I’m a little better educated about all my options.

10

A call with an expert might help you get better educated about all your options.

11

Sounds like you got spoiled :grin: Do not worry, you do get 32MB of external RAM. If you run out of memory then you are probably doing something wrong. And you will be happy with power consumption ass well.

12

I’m sure you have written about this before, but can you link to some comparative documentation that explains exactly why Netmf is the past and TinyCLR the future, showing pointwise the advantages of the new system over the old, for us as users and you as developers?

I would love to jump on board, but need some compelling reasons to leave something I am very familiar with and “just works” for something new.

At present the Cons counting against a move to TinyCLR include:

  1. It doesn’t support the EMX, which the majority of our field products use, and which we will need to maintain for years to come.
  2. It doesn’t appear to support MassStorage (USB<=>microSD) yet, which is essential to our products,
  3. Documentation and code samples are improving but still way short of what Netmf had built up

What are the Pros for making the move?

For example our present boards pull around 210mA when not in hibernate, which allows us to run for one shift between recharges. Given the improvement in power consumption of tiny devices in the 10-odd years since we started, I would hope to see an improvement of 1- or 2 orders of magnitude, so we could run for weeks or months instead. Performance isn’t an issue, the EMX boards have plenty of grunt for our needs.

13

I just checked and I am surprised you are not in insider yet, which explain your questions. You can wait for the big announcement of shoot us an email to get you the steps needed to become an insider support@ghielec…

14

… Done!

2 Likes
15

To me the biggest thing is that netmf is now an open source “product” that isn’t being advanced as a platform. GHI were by far the largest supporter and built lots of cool products based around it.

Meanwhile, new hardware and processor options keep coming along. And software deficiencies need to be taken into account - eg TLS version deprecation. So if you want to make netmf support a new platform, you have to go through the entire process… which isn’t something any vendor has signed up to do so far, and very few community ports iterated on netmf as a whole (@Justin is about the only one who has built 4.4 ports for new STM32 family devices).

So some day, EMXes are going to be Unobtanium, and your stock will be tapped dry… What will you do then? It’s the same choice that @Gene posed for this thread; do I completely shift paradigm (C/C++) or do I move to a similar place with TinyCLR OS

TinyCLR OS is the only “close relative” that has sprung up from the netmf ecosystem. It took the principles that netmf held early on (like closeness to the .Net way of thinking and APIs way back when it came about) but that netmf didn’t adapt as .Net changed (it drifted until it seemed at odds to .Net in some cases) and now TinyCLR brings that back to reality. And the plus is that GHI are continuing developing this, and they have a great history of pioneering work in this exact field. To me, that’s why a future strategy with TinyCLR makes a lot of sense. This will (only) be TinyCLR’s second major version - this would be much like the very early Netmf 3 lifecycle, without all the GHI lovely added goodness (remember onewire support? First in GHI’s builds, then got into mainstream through a community addition) so even if things you need are not there right now, they’re the ones to help drive that forward (as IMHO, nobody else is coming close)

2 Likes
16

Thanks Brett. It is great when we hear the community seeing the big picture and understanding where we are heading. We had 3 slow years as we ripped netmf apart to build the foundations of TinyCLR, but now that we have it compete, the future is just fantastic. Like in the last 2 weeks, we completely reworked USB host. We now have three luxury to add more bells and whistles.

1 Like
17

@Brett Thanks for your detailed reply :grinning:
The takeaway I get is that we need to move to TinyCLR because that is where GHI is going, and their reason for the big shift is that Netmf had moved too far away from .Net standard and they need to realign it?
There are no doubt many other reasons, such as ease of porting to new hardware, which will become clear once I receive Gus’ email and am inducted into the rank of Insider!

If I then get to see a roadmap that includes a MassStorage look-alike for TinyCLR and a backport to EMX then that covers my bases for now. Our new G120 main board with ESP12 WiFi is working really nicely (running the same code as on the EMX), which gives me a path forward to the TinyCLR and SITCore boards, but as all the hardware currently in the field is EMX based I can’t afford to drop that support or try and force them all to upgrade to new boards. (Although I can try to entice them with added functionality - say a month’s operation between recharges, WiFi data transfer, possibly a color-graphics screen :wink:)

1 Like
18

GHI moved on because, well, the legacy of netmf was lagging with Microsoft’s “almost-but-not-quite-shut-down” netmf. So until it was open sourced, which was late in the game, the real core release work had to be done by MSFT and that meant everyone was held to ransom by Colin’s team’s ability to get funding from the MSFT machine to do that work. (Just want to also point out - I am an ex MSFT employee, in an unrelated area, working in AUS. I have no axe to grind, but just saying it how things were). These things were a huge hinderance to correcting some significant deficiencies and defects (TLS versions and network stack!). The reason I point out the newer alignment to .Net is simply that things have moved on and netmf hadn’t, and if you want to get the benefit from one programming realm, and not spending your time learning the quirks of netmf vs taking an off-the-street programmer, then TinyCLR OS is the one.

Also want to point out that GHI stopped building netmf for their devices at 4.3, but there were a few releases past that point (in 4.4) that didn’t make it out for GHI commercial boards.

G120’s too will be unobtanium soon. Some time, you’ll have to move on :wink: So yes, break out the SITCore kit and start building fresh new innovative features that your users will want, nay, need, so you can build your skills on TinyCLR OS !

1 Like
19

Having contracted to a particular Microsoft team in the UK and seeing first hand how much NETMF was the bastard love child that was only whispered about behind closed doors don’t get me started else i might say something i might regret. But then again venting might be healthy :face_with_raised_eyebrow:

4 Likes
20

Longevity - GHI Electronics says they will be available for another 7 years, plus they run TinyCLR. Hopefully that should be enough time to make the transition!