Today we are excited to release the tenth preview of our TinyCLR OS. This release fixes a number of bugs including some that caused lockup during debugging and deployment. We added RTC to many devices and also added a target for the STM32F7 in the ports repo that we will maintain.
.constrained continues to throw in this release as we gather more data. We have not found any other common cases beyond
ToString on an enum.
As before, you can find all downloads in their respective sections on the downloads page. Just download the new installers and NuGet packages to get going. You don’t even need to download the firmwares since you can use the update firmware feature in TinyCLR Config to automatically download them for you. There are no new bootloaders in this release.
While we were planning on doing a preview for 1.0 now, we decided instead to focus on fixing a number of bugs and getting the STM32F7 target and new device firmwares out first.
TinyCLR OS Downloads: Downloads
TinyCLR OS Release Notes: http://docs.ghielectronics.com/software/tinyclr/release_notes.html
Excellent, Thanks for all your efforts guys!
And thank’s for the good work on the web site
You saw the website We are finally done with the GHI 2.0 plans and you guys will see a lot more in the coming weeks.
Thank you guys !!
Ahaha, I got a 0.10.0 big-bang with GPIO reset code (STM32F4/7 for the moment). The code need definitely to be changed for next release. Be aware that GPIO reset screw up also debug USB port in many situations.
I did not understand what you mean.
Cool. And at the same time, I’m doing my inventory of GHI electronics.
Our goal is for you to be able to use them all
If you don’t know what to do with all of them …
There’s a bug in the GPIO reset code, but I see it’s already on the issue list. … GPIO Reset caused also an USB port disruption in many situations.
GPIO Reset caused also an USB port disruption in many situations.
Did you try on real devices and can not debug through USB debugger?
What issue do you see on the issue list that you are talking bout, please? There few issue relates to GPIO reset but not because what we changed in this release.
Ideally, in device.h you can ignore some pins you don’t want to touch.
@Dat_Tran: Yes, I see you implemented a NO_INIT macro (the structure “apply” field need to be false).
I confirm that USB debug is disrupted unless I use NO_INIT macro for all the peripheral not using GPIO. But this is a very long operation to change all default() to no_init() for the boards device.h.
When I’ll succed to change the pins, I will report you the result.
all are very appreciated by my studentes