This keeps coming up so let me clarify please. We understand you have invested time and money into a design and you want the upgrade to be as simple as possible. After all, we also have designs and we understand the pains of updating hardware and software.
First of all, all of our commercial products come with 10 year guarantee promise. We are not asking you to upgrade today. Also, we are ready to help you with any hardware and software changes. There might be a fee and might be free, depending on your project and purchasing volumes.
Software: Updating NETMF to TinyCLR is very easy, but do not take my word for it, look at what Dave had to say
Hardware: We have designed TinyCLR 2.0 to be modern and secure. This unfortunately has ruled out old CPUs. G400 for example used SAM ARM9, a very old and non-secure micro! You simply will have to use the new SITCore hardware in your designs. Sometimes there is no change at all, like if you use G400D because the new SC20260D is a drop-in hardware replacement. But unfortunately, sometimes you have to change your circuit, like if you are using G400S.
Here is a lookup table with suggested replacements:
G30 and G80 => SC20100 (LQFP100 but the pinout is not compatible: PCB changes are necessary)
G120 => SC20260B (99% compatible drop-in replacement)
G120E => SC20260E (99% compatible drop-in replacement)
G400S => SC20260E (not compatible, PCB changes are necessary)
G400D => SC20260D (99% compatible drop-in replacement)
UC25 and UC55 => SC20260D (very close but not compatible, very small PCB changes are necessary)
Please go ahead and ask for further clarification if necessary.
How soon can we get access to the hardware details?
I am busy making a G120 board as we have discussed and I would like to see what is needed to use the SC2060B in the current design. I can spin small runs with the G120 to test with but ideally I would like to have something future proof.
We are on that bucket as well.
I’m worry mainly about the RLP code. We are running some fast math there and it needs to be processed at at rate between 200 Hz to 500 Hz. We are able to reach this in a G120 using low level and one interrupt (to get the signal and process in microseconds).
How will this translate in the new SITCore, do you foresee that this code will run now on the TinyCLR 2.0 (no need for low level code) or we will need to implement this on the new microcontroller? (requiring mapping files for the new microcontroller and porting of the logic)
serious reply for a moment. I know, what has come over me…
This may actually be a better topic outside the specifics here, but it’s very closely tied to upgrades and longer-term evolution for those who jumped on TinyCLR OS 1.0 and stayed…
I will just ask the floor here (because I’ve already asked Gus) what is people’s take on how the community will perceive the lack of forward support and roadmap for legacy TinyCLR 1.0 ports eg STM32 line ? That’s been community driven but those ports and those devices now kinda stop being able to come forward to the 2.0 world. I want the best outcome here for GHI, what I’m concerned by is whether the (lack of) upgrade path for not only the STM32’s but also the G120/G400 lines will affect the enthusiast market (the “I’ve already got this device” group) to the point that it affects overall adoption. I realise that I am probably one of the minority in the insider community - I know I personally will never have hundreds of commercial products out there like so many of you do now and will in the future, so the weight of my investment into the success of TinyCLR OS is low compared to you all, but I’d hate to see this hard topic cause grief. Am I too focussed on the community here?
I have no idea whether there’s a “middle ground” way forward, or at least a way that minimises “enthusiast” defections. Bug fixes in the 1.0 branch that cause issues and let the community (continue to) take it from there?
I need someone to correct my understanding here is I have missed something please. I think in most cases you either have:
Commercial customer: those refused to adopt 1.0 because it was missing important features. And they kept in using the same closed source modules we have been offering for 10 years
Hobbyist/maker: those love to always experiment with the latest, nano framework, micro python…etc. however our strongest following was with fez Panda, a closed source device that simply worked. There was very little adoption of TinyCLR 1.0 from these users as well.
Now, the only thing I see missing is a few low cost boards for makers, a FEZ. This is for those interested in “playing”. And those are in the roadmap but we do not want to take about them because we do not to over promise. We did that before. Instead of “coming soon” we want to surprise everyone with the announcement
I am part of the second group but not only interested in FEZ. the idea is to learn and experiment first. then try to find one intersting project. for this I am more interested in a more sophisticated board. In summary, I have interest for both
This is why I do not want o say too much but here you go… A FEZ board with SITCore is a very powerful board that can do anything G400 can do and much more!!! And it’s is even faster
Let me ask, how do you feel about our new plan? And does Brett’s argument effect you?
honestly, i can’t say that I am pleased to see that the current boards will not be working with Tinyclr 2.
(and i do not have the knowledge to adapt some other boards to tinyclr neither)
but I can understand the reasons for not doing it.
GHI main focus is commercial customers.
so far, TinyClr is given free to people that want to play with it. and I am not sure that they are many companies having a close connection with professionals and hobbyist via the forum
Having a Fez with SITCore and 2.0 is a good news (and i will try to find some applications for the current boards I have running on 1.0)
I agree with you but the new boards will be such a great update the I believe users will simply but the new ones even if we have TinyCLR offered on old boards. Meaning porting TinyCLR to old boards will only slow the 2.0 development like it did for 1.0.
Not to forget that porting meaning crippling 2.0 and making it less secure, since this time the hardware and software were designed for each other.
hopefully none of your designs 
