I hope ! And if fez spider will be supported, I will be happier !
Spider is EMX. Thatās a big ask, as it hasnāt been a mainstream product for a few years now. Fez Spider 2 is G120, and itās on the list nowā¦
1 Like
how to debug availability of ram and application space throught debug on Spider 2
Great work to the GHI team 
, I just installed this latest preview on my FEZ Panda III and so far so good. Over the past year I have been playing with Win10 Iot core because I thought that there werenāt any significant movement in the GHI camp, but I am glad to see the revised efforts and now eagerly awaiting whatās in store. While I love Iot Core, I forgot just how fast the boot time is when getting a simple application running especially from a cold boot.
Now what I would really like is the ability to build an AllJoyn producer or an Iotivity application running on a TinyCLR OS device. Sometime ago, I watched a session I think from build 2015 and they showed a device running netmf4.4 having AllJoyn support (I think the device was from a secret entity). Seeing that this is a port of netmf4.4, will we be seeing maybe any such support in TinyCLR? Please forgive me of my ignorance here.
1 Like
So, hereās my dream feature for TinyCLR OS : The ability to pull in relocatable .obj/.lib components via nuget. Those modules would get linked in like RLP modules at compile-time.
āBut Martin, that would require a full ARM toolchain (or at least, linker)!ā: Actually, no. All it needs is a limited tool to adjust the relocatable objects - no symbol resolution or optimization required.
Then, also expose some apiās (like ethernet) through pure virtual interfaces and pointers to vtbls at known addresses, and you have a real RLP power tool, and the ability to do things like AllJoyn without either a) taxing people who donāt want that feature or b) eating all your netmf program space and heap by trying to do it in managed code.
With such a feature, you can have a really tiny kernel, and then add in native-code features that you really care about at compile time.
2 Likes
@ mcalsyn - [quote]So, hereās my dream feature for TinyCLR OS : The ability to pull in relocatable .obj/.lib components via nuget. Those modules would get linked in like RLP modules at compile-time.[/quote]
1 Like
I take that to mean you are already implementing the brilliant proposal.
Good stuff. Up and running and will start playing with it.
Best of all would be to use a less ā¦ curly-braced languageā¦ like vbā¦ and some price reduction on the devBoards. 
Eagerly waiting for G400
Will it be possibly to have changes made to the native code, and included in future releases of Tinyclr, or be able to load them as needed? Specifically, an example would be completing the overdrive code for 1 wire devices? I am definitely a fan of the G400ās horsepower, I just donāt want to have to do my own port or recreate the entire library to tweak a small feature,
1 Like
@ Gus -
Will be compatible applications code on TinyCLR OS and LLILUM at the source code level ?
Hi John,
Is TinyCLR open source? if not do you plan to make it open source?
Can you also confirm for me that TinyCLR is distinct from and compatible with Microsoftās .Net Micro Framework or does TinyCLR itself include its own version of this?
Thanks
@ KorporalKernel - TinyCLR starts with netmf but we are quickly moving forward.
The open source question is to be answered in future releases. Have you contributed to netmf and are you planning on contributing to TinyCLR?
Iād just like to check my understanding about what to expect when TinyCLR gets released in order to plan a little bit better for my existing and upcoming projects.
- If i really like C# and the .Net Micro Framework (which I do), Iām going to love TinyCLR and it will be worth the time and effort required to upgrade, right?
- I shouldnāt expect any new releases of .Net Micro Framework after the current 4.3 (QFE2) and the GHI Electronics NETMF SDK after 2016 R1, right?
- Will there be anything I can do now with .Net Micro that I wonāt be able to do with the initial release of TinyCLR? Later releases?
- It looks like some of the API in TinyCLR will be different than .Net Micro. Can you provide more detail about what parts of my existing code Iāll have to rewrite to take advantage of the shiny new TinyCLR?
Thanks
As Gene, having a better understanding of what will happened soon is of big interest escpecially when you are using GHI devices for professionnal purpose. For now G400 is still not supported and this is our prefered platform. We still have some bugs or strange behavior with current sdk (can filters, TCP/Ip stack that does not work properly on some application when deploy with visualā¦) and my feeling is it wonāt be solved anymore in the next minor release of the sdk due to the fact GHI seems more focused on TinyCLR. Anyway if this can be fixed in the new core it will be good.
BUT as professionnal we need to anticipate the move and a timeline could help us
@ Gene - your understanding is mostly correct, however it is still very early for TinyCLR to give concrete answers. I would still recommend you give TinyCLR a spin, even if you just block an led.
Yes the API is different, we are now using the windows 10 API. This makes sense for the future as an upgrade or downgrade party.
@ leforban - we have our commercial is in mind and we are planning accordingly. There will be plenty of announcements. Like I keep saying, TinyCLR is in the very early stages and it is only public so everyone can get a chance to try it out and give us feedback.
Continue using NETMF for all products, but give TinyCLR a try and let us know what you think please.
1 Like
When third preview or first release will be launched ? I think we need a roadmap indeed.
1 Like
Yes UWP, or as close as we can to that, considering the hardware limitations.
Yes agree, and we will share the roadmap once we are ready.
2 Likes
I hope itāll be soon ! Yesterday ? 