Today we are excited to release the eighth preview of our TinyCLR OS. This release adds a firmware and bootloader for the FEZ Hydra, a driver for the SPWF04Sx Wi-Fi module from STMicroelectronics, and a build of the core for Cortex-M7 based devices. There are also a number of new smaller APIs that you should find useful.
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.
In case you missed it, take a look at the roadmap detailing our road to 1.0 for TinyCLR OS.
Great job !
I’ve just updated boards: FEZ Spider I, FEZ Spider II, FEZ Cerberus, Brain pad (old and new), Panda III have been easly updated (from v0.7.0) with TinyClr.
For netduino3, update need to be done manually: donwload hex file, use dfu manager to convert to dfu, and use dfuDemoSe to put firmware on netduino3, I don’t know if future version of TinyClr support this board on not.
For FEZ Raptor, when press update Firmware, I get Firmware corrupted . I will try to update manually.
If you’re still accepting suggestions for important functionality, here are a few.
Interrupt driven, DMA UART driver with large buffers (similar in functionality to what’s in .Net Micro).
File system (I know it is on your road map, just sayin’).
Those are the easy ones, here’s the hard one.
Port a rock solid, fully stable version of TinyCLR to several, appropriate evaluation boards from ST Micro, TI, Atmel, Silicon Labs and other significant ARM players and convince those companies to include it with the other software they provide with those evaluation kits (like they already do with Keil, IAR, etc.)… More exposure -> more users -> more market share -> market dominance -> GHI company condos in Hawaii and Vail and free vacations for early supporters!
With regards to the UART buffer size, this release actually allows you to customize the size of the TX and RX buffer on a per port basis to be as large or as small as you want (up to the available heap size of course).
While the methods to do so aren’t exposed on the SerialDevice class, you can use reflection to change them. See SizeReflection.cs · GitHub for an example
Oh. Ok so how does one tell the difference between a Software wifi dongle and a “Hardware” one? This reminds me of the day of sofware and hardware modems.