I’m looking into what I need to know/do to move a NETMF project running on a G120 to TinyCLR and have a couple of questions that I haven’t been able to find the answer to yet. Hopefully someone here can help…
Where is the reference for the API, if there is one? I can only find the tutorials section that has some examples.
In the release notes there is the issue of ‘When not debugging the application may slow down’. How much of an issue is this? Some more information on this would be great.
It seems like the networking solutions are currently limited, is that correct? I am planning to, in the near future, use Ethernet or WiFi for file transfer to/from the G120 (or possibly move to a G400) is this currently possible?
I see that the UART buffer sizes are available to set but not mentioned in the tutorials. Is the default size the same as in NETMF and does anyone know what it is?
Also is Enable() the same as Open() and Disable() the same as Close()?
Currently there is no reference API but it is something on our list to get out. Currently TinyCLR OS Introduction is what is available.
It really depends on your exact application, for some workloads it doesn’t cause much of an issue. It’s something that testing with flesh out for you.
Networking is a high priority for us and is something we’re working to get out as soon as possible, but we don’t have a timeline to share publicly just yet.
The default buffer sizes are not meant to mirror NETMF. You can read the buffer size back to see what the default currently is, but that’s an implementation detail that may change. If you find you need a certain buffer size then feel free to set it.
Open/Close acquire and release the underlying native resources and get everything ready for use. Enable/Disable enable things like raising events and receiving/transmitting data. This pattern is the same for many of the peripherals, though it is still being fleshed out. For now, always call Open and Enable together. When you’re done, call Disable and Close together.
I think the NETMF buffer sizes are fixed and are based on the hardware? How I can found out what they are?
Open/Close acquire and release the underlying native resources and get everything ready for use. Enable/Disable enable things like raising events and receiving/transmitting data. This pattern is the same for many of the peripherals, though it is still being fleshed out. For now, always call Open and Enable together. When you’re done, call Disable and Close together.
I don’t see an Open/Close in TinyCLR, am I missing something?
The reason I am asking about this is because I need to bit-bang on a serial port before writing and reading to/from the port. In NETMF I did this by doing a Close() before setting up the TX/RX pins as OutputPort/InputPort to do the bit-banging, disposing of those ports and then doing an Open() to start reading/writing serial data. I need to now find the right way to do this process in TinyCLR.
In NETMF they are implementation details that can change between releases. We can certainly share what they are in a given release but they’re not guaranteed to hold in different releases.
Ah, sorry, I misread your original post. TinyCLR does have Enable/Disable which function as I mention. When I said Open/Close I should have said Acquire/Release. Acquire and Release are not exposed publicly in the managed drivers and are called automatically when you acquire a controller or dispose of one.
For now, I would create your GPIO pins to bitbang what you need to, then dispose of them and create the UART controller via UartController.FromName.
I would be really grateful to know what the buffer siezes are in NETMF 4.3, on a G120.
Ah, sorry, I misread your original post. TinyCLR does have Enable/Disable which function as I mention. When I said Open/Close I should have said Acquire/Release. Acquire and Release are not exposed publicly in the managed drivers and are called automatically when you acquire a controller or dispose of one.
For now, I would create your GPIO pins to bitbang what you need to, then dispose of them and create the UART controller via UartController.FromName
Understood, thanks.
Regarding SD card access, is the root directory still “\SD”? Or should I get it by doing DriveInfo.GetDrives() then DriveInfo.RootDirectory.Name after mounting the SD card?
OK, thanks. I think I already spotted the root directory path of the SD card is now ‘A:\’ but I see in the example there is a simpler way of getting this.
Regarding GPIO, the new enums for the state of a pin seem to be a step backwards. It used to be possible to toggle an LED for example by doing LED.Write(!LED.READ()) and now i have had to write an if statement to do the same thing, unless I’ve missed something obvious…
You are correct, there is no bool overload anymore. In my use I’ll usually do something like led.Write(led.Read() == GpioPinState.Low ? GpioPinState.High : GpioPinState.Low); Still an if but a bit more compact.
