Thanks for your table, we had no time to compare between G120 RLP and SITCore, this table is really good for us.
Of course G120 RLP is a bit faster but from your result, not much enough to think about RLP on SITCore for at this time.
We added some advance graphic, cryptography, array convert that use native directly.
We are not going to add RLP just for run simple code and compare the speed. Need to show us what SITCore can’t do, then we will think about RLP again, seriously.
We don’t mean SITCore is perfect 100%, there is still few things need to improve. We have some issue need RLP also. But better if those thing come from our customers who have a lot of experiences about real project.
In other hand, we are listening from our customers to decide about adding RLP or not.
By the way, can you share us your simple project? because this is good comparation that need to add to our document, I believe.
Give me a couple of days to make the code readable.
I just got back from vacation and I need to deal with the backlog of cases.
Judging by these measurements, about 1-3%.
I didn’t do anything special either to.
Checked on RC1.
I upgraded the module to RC2.
Updated nuget packages in the project.
Checked on RC2.
Perhaps some package indirectly affects.
List of packages in the project:
GHIElectronics.TinyCLR.Core
GHIElectronics.TinyCLR.Devices.Display
GHIElectronics.TinyCLR.Devices.Gpio
GHIElectronics.TinyCLR.Devices.Spi
GHIElectronics.TinyCLR.Drawing
GHIElectronics.TinyCLR.Native
GHIElectronics.TinyCLR.Pins
GHIElectronics.TinyCLR.UI
We have many C ( and C++ libraries as source and object form that are called from Python, C#, managed C++ etc. The use case is pretty simple. We have a lot of well tested and proprietary algorithms in C that we would like to call. They have well defined interfaces and well defined fixed memory requirements. Is there a way re-use this? I have no problem generating obj code for the processor, I just don’t know if there is a way to call this code from the current implementation. We did this with RLP previously. Can we possibly discuss off the forum?
Not currently supported but so far we have found answers for most needs. Native code is fast but not portable and can’t be debugged. You are welcome to reach out directly and we can discuss options.
It seems like a lot of people would like to make “extensions to the operating system”. Debugging is not a problem in many cases, if the code does not write to the uP hardware. Code can be debugged on the PC, and we assume that the cross-compiler generates code that works, so we do not need to debug it, just the code that calls it. Portability is usually a minor issue, if the code is designed for it.
P.S. When you say “reach out directly and we can discuss options”, what does this mean? (Set us up with a way to build and debug additions in C to your TinyCLR and we could certainly help ) But I think this goes way beyond the scope of the TinyCLR project - sometimes it’s good to keep it simple.
What Gus means is you should contact GHI directly from their website, and reference this thread. There, you can discuss the commercial realities of your project/s and your requirement.
The bottom line, today, is that extending the platform with compiled code is not possible today, and no compelling reason for GHI to do so and to add that complexity has come forward. Any use-cases that have come up so far have found ways to either be included in TinyCLR (or put on the roadmap) or an alternative approach of sufficient speed has been found.
You are right. I don’t really have a compelling reason for it, and there is a very good chance that my project does not have any great commercial reality (but the alternative is equally possible ) I can always use a different SbC which has low-level programming support in C and native assembler, most of them have that. But for prototyping, and projects where speed is not an issue, TinyCLR is fine.
) But I think this goes way beyond the scope of the TinyCLR project - sometimes it’s good to keep it simple.
) I can always use a different SbC which has low-level programming support in C and native assembler, most of them have that. But for prototyping, and projects where speed is not an issue, TinyCLR is fine.