C# is wonderful, but the interpreter can be slow, even with a fast processor.
I have often mixed native uP code (written in C or assembly language) with interpreted code, usually by using “platform-invoke” [dllimport] to call my own methods in a DLL.
Can we do something like this with SITCore?
(Debugging could be tough though!)
Once upon a time, before TinyCLR, we had runtime loadable procedures. See https://docs.ghielectronics.com/software/netmf/tutorials/rlp.html. This provided exactly what you want.
Unfortunately, this feature is not available with TinyClr… yet…
1 Like
What I need is to be able to make extensions to the firmware. I guess that’s written in C, based on the old .NET micro platform?
Extension to do what? What are you trying to do?
So far speed has not been an issue as SC20 is 30 times faster than G120!!
OK, it’s a bit esoteric - but here goes… For a long time I have been thinking about developing a “virtual machine” (e.g. an interpreter) for my own language (MOSAIC - Matt’s Operating System for Automation and Industrial Controllers). This would be a language/model designed for industrial Programmable Controllers, with a simple “unified configuration and programming” model, supporting parallelism/data streams/state machines/graphical programming/etc… (I developed a virtual machine’s Instruction List macro language for a Honeywell subsidiary - plus the assembler/linker/debugger/IL editor, full IDE etc, so this is my field.) The old IEC61131 PLC system is not really suitable for the next (industry 5.0) generation, and I have many ideas about this.
Now that I’ve been made redundant (wise managers decided to move development to China), I have time to try a few things, so I’m looking around for SBCs that I can use for the prototypes. I played around with the old G120 a few years back and it looked really good. Now I’m playing with the Duinos.
MOSAIC will be developed in C for portability. It needs all the features that your SITCore has, but to write an interpreter - that runs on an interpreter - is probably not a good idea.
(I’m also working on my “electron tube tester” project, using the Duino, which is going really well. The 0…600v intelligent PSU works fine with the C# code handling the PWM and SPI A/D sensors, and I have not electrocuted myself, yet.)
TinyCLR does not (currently) support running native code next to it. I suspect that won’t remain the case, however, that’s where things are today.
If I need native code running on a SOC without a bootloader, I have been using https://platformio.org/. If you must do native, it doesn’t get easier than that. It can target over 800 SOCs/boards but it doesn’t integrate well with bootloaders (yet). You can build against FreeRTOS, Zephyr, mbed, arduino, etc as the base ‘os’.
For larger projects where I need IFU and consequently a bootloader, I have been using https://www.zephyrproject.org/ together with https://mcuboot.com/ which is the default bootloader for Zephyr. Again, there is support for a huge set of SoCs and boards.
PlatformIO and Zephyr projects should be able to run on the SC13048 boards. I only say ‘should’ because I haven’t tried it yet and there are some fiddly bits around creating the board definition and handling any init/re-init required after the GHI bootloader runs.
One nice thing about the PlatformIO and Zephyr environments is that you can develop on Discovery/Nucleo boards with GHI-compatible processors where you have JTAG/SWD for debugging, and then just change the board definition to move your code over to the GHI SC13048. Again, I haven’t tried that, but it is on my list to create an SC13048 board definition and publish that and a how-to.
The advantage of being able to load next to TinyCLR, of course, would be that you can leverage all the great work that is already there, and just dip into the netherworld of native when you need the speed. I’m looking forward to the re-arrival of that into TinyCLR.
2 Likes
That is how DUE works and it is great.
https://docs.ghielectronics.com/software/tinyclr/due/overview.html
1 Like
Thanks mcalsyn, some good advice there. PlatformIO looks nice, and the boards it supports. Zephyr seems to have just about everything…
OK. I’ll do a few speed tests with my bare-bones interpreter coded in C#, comparing it with the PLCs I know, and let you know how I get on…