@Quentin to simplify it, TinyCLR OS is early alpha and currently only implements base functionalities like GPIO, UART, I2C, SPI, PWM, ADC, DAC and Display
without support for USB, CAN, Networking, IFU, RLP and SQLite
serious? you compare StackExchange with GHIās Forum ?
kurtnelle, you donāt know the half of it 
Yes. Yes I did Kevin.
more than 4,000,000 users and 10,000,000 questions compared with what ? 100 users and 10,000 questions ?
multiple programming languages with only C# ?
different topics with only GHI related stuff ?
so funny
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. 
Quentin Iām building out on a line of products for the exact reasons you mention as obstacles in yours. 
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.
2 Likes
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.
3 Likes
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 old.ghielectronics.com 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!!
Thanks!
2 Likes
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.
2 Likes
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.
2 Likes