I’m working on porting some Arduino code and I was looking to see if there was an existing way to get the number of milliseconds/nanoseconds since boot (millis() and nanos()). If not, I imagine it could be implemented with a timer interrupt.
Second question is related to global interrupts. I’m porting some SPI code, and I’m trying to see if it will work in the managed section. The Arduino library uses interrupts() and noInterrupts() liberally to ensure the SPI transactions are not blocked in between calls (like if 4 different SPI transactions need to be performed). I saw that the RLP has a way to do this (RLP->Interrupt.disableGlobalInterrupts() or somesuch). It also has a lot of calls to SPI::beginTransaction() and SPI::endTransaction() but it appears that setting the configuration on an SPI object takes care of this (SPI.Config = SPIConfiguration).
Thanks for any help you can provide, and I apologize in advance for so many questions on the forums.
As a general rule I would first try to implement your Arduino code as managed C# code in NETMF. I’d only switch to native code in RLP if you find a compelling need to do so. Most SPI devices work perfectly well in managed code using the built in SPI driver. What SPI device are you trying to get working?
Thanks for the quick reply! I’m porting code for the MCP2517FD (GitHub - pierremolinaro/acan2517FD: Distribution of Arduino driver for MCP2517FD CAN controller (CANFD mode)). I will continue to report back as I’m working through it. One of the things I have to make sure of is that the SPI example puts the SPI controller into SPIMODE0 and transfers MSB first. But this can always be switched around by switching the byte order of the byte array.
I did a quick look through the datasheet and nothing immediately stood out as problematic from a NETMF perspective, though of course actual implementation may prove otherwise.
NETMF and the G400D do support SPI mode 0, though you configure it by specifying the polarity and edges on the configuration object directly, instead of specifying a mode.
Since this is a CAN module, depending on your exact timing and traffic requirements, managed code may not be able to keep up. If you do find that to be the case, RLP in NETMF unfortunately doesn’t have any SPI wrappers so you’ll have to talk to the processor registers yourself, which is pretty advanced (TinyCLR on the other hand, does provide SPI wrappers in native code). Of course, you can configure SPI in managed then do the writing and reading only in native. I’d still try to implement in managed first and only move to native as a last resort.
To at least answer your original questions in a general sense:
In managed code relying on timing in the millisecond and nanosecond range is not possible, the system is not deterministic in that case. In native code, our RLP helper does provide a delay function that take microseconds, though that’s it. Anything else will require to use a free timer (make sure you don’t use one that the firmware itself uses) to keep track on your own as you suspected.
In managed code, you can’t block interrupts or assume exclusive control. You could be preempted at any time. Even if you have a single thread, the system may need to take some time for tasks internally that pause your thread briefly. In native code you can indeed disable interrupts which gives you exclusive control, but be careful not to do that for too long because the rest of the system is unresponsive in the meantime and things like network sockets will eventually timeout.
For beginTransaction and endTransaction, you’re on the right track. Assuming a single SPI device, once you create it and configure it once at the beginning, it’s good to go. You just need to call Write/Read from here on out. There aren’t any begin or end functions.
I really appreciate the very helpful response. Regarding TinyCLR OS; I’d like to begin my new project with TinyCLR OS instead of NETMF (better support, more native bindings, newer Visual Studio, etc). What is the status of TinyCLR OS on the G400? I tried to compile a basic Hello, World and it was not able to upload to the board. Perhaps I need to change the bootloader firmware?
Output from Build:
1>------ Deploy started: Project: TinyCLRApplication1, Configuration: Debug Any CPU ------
1>------ Deploy started: Project: TinyCLRApplication1, Configuration: Debug Any CPU ------
1>An error has occurred: please check your hardware.
1>DebugPort.GetDeviceProcess() called with no argument
1>Source: GHIElectronics.TinyCLR.VisualStudio.ProjectSystem
1>Stack :
1> at GHIElectronics.TinyCLR.VisualStudio.ProjectSystem.DebugPort.GetDeviceProcess(String deviceName)
1> at GHIElectronics.TinyCLR.VisualStudio.ProjectSystem.VsProjectFlavorCfg.GetDeviceProcess()
1> at GHIElectronics.TinyCLR.VisualStudio.ProjectSystem.VsProjectFlavorCfg.Deploy(DebugPort port)
1> at GHIElectronics.TinyCLR.VisualStudio.ProjectSystem.VsProjectFlavorCfg.<>c__DisplayClass53_0.<Microsoft.VisualStudio.Shell.Interop.IVsDeployableProjectCfg.StartDeploy>b__0()
========== Deploy: 0 succeeded, 1 failed, 0 skipped ==========
Output from TinyCLR Device Deployment:
Looking for a device on transport ‘USB’.
Found device port ‘USB’ with ID ‘ce3e70c3-69e6-4e90-95ad-fed10db15c21’ for transport ‘Usb’.
Starting device deployment.
Attempting to connect to device ‘USB:’: iteration 0.
Thanks for your help! I was able to update the bootloader to 2.0.4 and install the TinyCLR firmware. I like TinyCLR OS much more from a native standpoint (all the implementation information is available in the TinyCLR-Ports repo) so I can easily see how stuff is implemented vs how it’s implemented on Arduino/AVR to troubleshoot problems. Thanks again!
We are using the G400 because we have it as an existing product (a breakout board with some additional functionality). The rest of the products are using .NETMF 4.3 but I am needed a little more native functionality so I wanted to try out TinyCLR OS.