You mean that it is locked out from dicussion? 
Locked from use except by us. We want to add features for you instead of you bothering with it
3 Likes
wish i have ability to use with MbedOs (with included perihal drivers) too,
to be able to use with VisualGdb
But not all !
Also. From time to time there is a need to process a large amount of data.
The current task is to create firmware of the signal spectrum by parameters. With different order and phase of its constituent harmonics. The number of harmonics is from 1 to 16 (for now).
Comparison table for identical execution algorithms on RLP and TinyCLR2 for 16k flash points.
In seconds
| Harmonics | G120 (RLP) | SCM20260 (TinyCLR2 RC1) | SCM20260 (TinyCLR2 RC2) |
|---|---|---|---|
| 1 | 0.656 | 1.104 | 1.094 |
| 2 | 0.893 | 1.342 | 1.333 |
| 3 | 1.098 | 1.588 | 1.561 |
| 4 | 1.323 | 1.821 | 1.806 |
| 5 | 1.487 | 2.07 | 2.038 |
| 6 | 1.707 | 2.312 | 2.263 |
| 7 | 1.931 | 2.551 | 2.505 |
| 8 | 2.124 | 2.799 | 2.736 |
| 9 | 2.357 | 3.038 | 2.968 |
| 10 | 2.542 | 3.283 | 3.192 |
| 11 | 2.76 | 3.519 | 3.435 |
| 12 | 3.002 | 3.765 | 3.672 |
| 13 | 3.194 | 4.001 | 3.916 |
| 14 | 3.382 | 4.246 | 4.131 |
| 15 | 3.597 | 4.493 | 4.37 |
| 16 | 3.86 | 4.725 | 4.597 |
1 Like
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.
No way, everything we do is perfect 
And, how RC2 is faster than RC1?
We didn’t touch anything relate to speed between RC1 and RC2.
“I am sure 100%” that nothing is 100% :)).
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 just asked by self.
@Gus_Issa We have some legacy c code that we would like to call ( and not re-write in c#) - Is this currently possible?
As security comes at a higher priority, adding native code is not supported.
Also, C code is typically not portable and defeats the purpose of having a managed and secure system.
We have been finding answers to customers that needed native code. If you like, share with us what you need done and we will try to help
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?
This is not available today but we can discuss directly and see what options we can bring to you. Please email support and we will take it from there.
I’m interested in the same thing…
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.