Wow, this place has become quiet

In defense of StackExchange, which can be a nightmare due to multiple postings on the same subject, it has helped me out tremendously with Android development related issues. :sunglasses:

Thanks @Mr_John_Smith and @Kevin_Flint for some clarifications, I will dig into that.

Quentin I’m building out on a line of products for the exact reasons you mention as obstacles in yours. :slight_smile:

Around here it’s far easier to find out of work .NET programmers than it is any other, with all the layoffs from Caterpillar and subcontractors of Caterpillar, and other large employers in the area.

As far as GHI / trusting one company, one provider, etc, I don’t understand this. If they fail to fully launch TinyCLR you still have NETMF which is fully open source. OR you have the option of using the underlying ARM CPU’s directly, and foregoing NETMF entirely, on the exact same hardware… So what’s the risk? If GHI fails and goes out of business, it’s not like your products evaporate with them. You can still use the exact same hardware you already built, or build new products on non-GHI MCU layouts you design yourself.

Where’s the single point of failure exactly on the supply chain? I’ve looked, hard, during due diligence before deciding on a platform for our industrial control modules; and I simply haven’t found one.

As far as real time stuff goes, if/when I ever need it I’m just going to toss a cheap Microchip PIC coprocessor on the board or module, and program it with straight C or assembly. Then instead of making elaborate, hard to debug RTM calls, I can test and program the coprocessor and it’s functionality as a discreet subassembly, and call the triggering function with RTM from .NET, to signal the coprocessor and activate it’s predefined functions. That way it fully offloads from out of the .NET environment and the core system is able to carry on with whatever it’s supposed to do. (Or vice versa, for inputs have the PIC handle everything and then signal the main .NET CPU by raising a GPIO high to indicate “hey I’m ready to send you stuff.”)

This way I can keep my low level stuff totally separate from my high-level stuff and not worry about my .NET programmers screwing up incredibly time-sensitive code with stupid human errors. Just give them an API to tie in to, to call the small coprocessors. MCP’s PIC line starts at 44 cents at qty 1 for an 8 bit MCU, a buck 17 for either a 16 bit MCU or 32-bit MCU @ qty 1.


Great points but I would like to add that we have been growing for about 17 years and have been in the SOM business for over 10 years. Plus we are very transparent and open… The likely hood of GHI going out of business shouldn’t be a concern.


Which is all things people who are evaluating GHI’s offerings for a commercial product need. (Especially CAN & USB)

Do share! I would love to know more about this option, as the AM3358 processing power is very appealing. The big question would it be possible to do native driver development in C#? or how would that look? For example, using the CAN peripheral on the AM3358. The biggest downfall to this options, is the darn boot times!

My biggest concern with GHI currently, is with the big shift to TinyCLR, those who are “holding out” for the advance features really have no roadmap. I don’t want to burn up a ton of time in .NETMF to use those features, if TinyCLR will get them relatively soon… IMO, TinyCLR is a big mystery right now

This was the thread about getting C# on the AM3358

I have been busy building a PCB with a coprocessor to create a GPIB to serial converter (:

SO close to finishing my project.

If you’re a commercial entity who has real concerns, jump on the phone and talk with the team. While Gus says he and the team are as transparent as they can be here, I suspect timing is one key thing he will never be able to be fully open with the full forum on. In a conversation, or perhaps under an NDA, I am sure he can help confirm timing that can help your planning, either by giving you the timing or taking your timing into account and telling you if TinyCLR OS is going to be something you can/should wait for

Fantastic Jay, thats good to know!

I just tried it out, and glad to see the back up and running and the links working.
Also test that the old Google links work.
It was suprising just how many times I go back to the old info, or found a link that took me there.
Its a value resource, so glad you got it back up!!



Yes I’ve had private conversations regarding the timeline of TinyCLR with them and they’ve been pretty transparent about timelines. It’s understandable that they don’t want to commit to a deadline publicly - that would be foolish.

Every software project I’ve worked on is “well… it’s done when it’s done!”

If people want hard deadlines I can give them my gut feeling based on experience, but you just never know what kind of obstacles you will encounter. Sometimes you may hit a roadblock that requires re-factoring very large amounts of code, and that slows things down badly. Other times, something you thought would be very tricky, turns out to be pretty simple; or someone has an epiphany that just works.

When you are on a large, complex project like TinyCLR, how do you know when it’s going to be done? You don’t. Just like an artist can’t commit to a deadline… if it has never been done before (or done THIS way), there’s no measuring stick to go off of.

Once it is OUT, them I’m sure they’ll commit to a standard release schedule of updates, etc. Layered tracking of issues, and feature requests, with locked in, set in stone “this is going in to the next version, that’s going in to the version after, and so on.”

The nice thing about GHI is they are light and agile, compared to a massive monolithic entity like MS, etc. You ever work with MS on a private hotfix for Server OS or Exchange? My god that’s an ordeal. By the time they get through reproduction in a lab, coding, regression testing, shiproom quality control, 6 or 8 months may pass. And that’s just for a bugfix

it looks like you have not much experience with GHI
in the past we had to wait months, sometimes years for fixes and sometimes we are still waiting for fixes…

edit: and don’t forget GHI’s stable release cycle, was it once a year ?

Really sounds like you have an ax to grind Kevin.

Every post I’ve seen you make is negative of either GHI or critical / insulting to users on this board.

Not just in this thread, but everywhere on here.


i am so sorry that you miss understand the correction of false statements
what you wrote is wrong and i have in the past and will in the future correct such wrong statements

serious ? the next false statement

last but not least, i am happy that GHI’s biggest argument (Microsoft) does no longer exist and only GHI is responsible for the quality of their builds and speed of their releases (and of course bug fixes…)


I dont know about you but I have a great help and good experience with GHI even for stupid and amateur questions.

So for electronics product if reach stability in production there no need to change things so this is a reason why there’s less fix-es and you need to find way how/know with your hardware and you can not compare .net in pc with .net in mcu for fixes.

Also you have alternative instead using .NET (mbed,keil,python,arduino) for STM32F4 mcu

So you need to deal and split software and hardware for optimisation.

For example i use tinny85 with arduino or arduino mini as noded sensors reader or relay trigger and .net as master controller buy using rs232 or rs485 and i have no problem even with unfinished TinyClr since 0.5.0 because work well in all my projects

@valon_hoti_gmail_com absolutely, GHI’s support is one of the greatest

but that’s alone is not enough
at the end the finished product counts (with all the functions, bugs and missing features)

TinyCLR is promising but unfortunately not stable enough for production use and required features are not available (but that’s ok as TinyCLR is early alpha)

what you should not forget about your “alternative instead using .NET”…
as soon as a product is finished, why should one waste money to go back to TinyCLR only because TinyCLR is now production ready ?

Yes yes and yes. We take pride of our quality and work ethics. It is very sad that we on some occasions we came short and we are working very hard on fixing all previous mistakes.


@Gus_Issa well, you already did the first steps, you have realized and admitted some mistakes, i think that’s one of the hardest parts of your v1 into v2 transformation

I have netduino, arduino, tessel, raspberry pi 2-3, padi, esp8266, esp32, nucleo 401ret, brainpad, I bought almost all the gadgeteer modules + raptors + hydra + spiders, fezcream, fezhat, fezutility, and also I got atsaml21 dev kit… I code in C, C++, Java, kotlin, python, vb, delphi, C#, R, etc… from my perspective, it’s all about how you can deliver ‘value’ to your customers, so company decide what is the best strategy to make their products and services better, unique and different than the competitors. Microsoft is now open for all platform and all languages coz they want everyone can enjoy Azure regardless what are they using… for example, they put a lot of effort to provide IoT SDK to all embedded platforms, they slim down the win 10 to fit in SBC like raspi, joule, dragon board, etc. so how about GHI? I have created a lot of events in my country and introduce gadgeteer concept, netmf, tinyclr… then I collects my audience oppinions… what are they said? 1. expensive, but I understand its because the taxes and delivery cost. so, we can reduce the cost by porting tinyclr to the available dev boards in my country 2. the develoment of tinyclr is slow, of course they need to form and acquire a brilliant team for this or open the code for community contributions 3. community support, I know it’s about language barrier so I created local community 4. more sample code, drivers, projects… so I push the code on github and create some tutorials on youtube.

I have some notes from my experiences when using GHI products:

  1. nothing wrong with gadgeteer, its just costly… I can perform live demo in front of my customers/audiences from the scratch smoothly. when you start your project use plain netmf or tinyclr.
  2. if you want to runs faster, just take on C/asm
  3. drivers and libraries for CAN, usb client/host, glide, sqlite, cryptography are bonuses from GHI, if you want it, take the netmf version and port to tinyclr by yourself
  4. every platform has it’s own purpose, so, don’t write a blog using asm
  5. GHI is on the right direction, I love what I see on the back of brainpad case. you can code with python, c++, mbed,…
  6. the reason why I use C# for embedded is about productivity and time to market, because I have put a lot of investment in this language

so, we need more supports and contributions from people like you…


those were/are arguments to buy the more expensive GHI products… if my company would have to port it other already finished solutions are much cheaper

What company is that?