Hi,
found the event system (General Purpose Input Output (GPIO)) looks nice but … there is no data about the longest interval I have to calculate for the systems reaction.
How ‘realtime’ is TinyOS?
With best regards
Gerhard
It’s is not real time however the system is only running your application so you can somewhat predict response times.
Perhaps change your question to what you are trying to do and then we can tell you if TinyCLR is the right tool or not.
Hi,
to decide that the system can do the job, we should have an idea of the response time.
Is it possible to get a reliable response within 200µs???
With best regards
Gerhard
actually, if you’re driving a large display with a GUI and writing to storage, versus driving a single SPI device, the requirements are much much much more telling. So i really think you’re asking the wrong question without the required inputs
Response to what? I do not want to give give you a misleading answer.
Also, to add to Guss_Issa question:
If you need reliable response within 200us …and that timing is truly what your gadget predicates, why rely on OS at all?
IMO, whatever 200us IO changes (assumed) should be handled by circuity + interrupt(s).
Yes, TinyCLR is NOT an RTOS…where RTOS, I have found does not always = ‘Real-Time’
There are ‘ALWAYS’ trade-offs…I say such because of extended experience with the panacea of ‘Real-Time’ OS’s, from the cheap to the very expensive.
…There is no such thing as ‘Real-Time’ other than in the imagination of engineers.
So, boiling all down…
Do you want an OS like TinyCLR and the VS environment which far rocks any other embedded tool-chains with max capabilities and productivity.
…or
Do you want to develop with an RTOS using Assembly, C, C++ with an IDE like Eclipse.
…Again, perhaps you gadgets requirements could be offloaded to circuitry?
My comments are not some piss-party thing…!
Just have been down the ‘Real-Time’ path many times in the past and sharing what I have found, be it right or wrong… only you can discover.
…btw, we run .netMF and have recently devoted a full time engineer to porting to TinyCLR.
We do real-world heavily intensive broad scope automation.
Have never looked back since .netMF / G120 and now TinyCLR / sitCore.
Really again, HARD evaluate your specs.
…You will find no better tool-chain and hardware than what GHI offers…!
2 Likes
Thanks for the awesome reply. While we offer some amazing software/hardware combos, some needs may not be covered by what we have. Like we do but play video and do not render PDF files, there is Linux for that. We also do not offer things suited for hard real time, like driving stepper motors, there are fpga chips for that.
I have seen it many times where customers ask a specific question but the answer can be very tricky. Which why I always try to understand what they are trying to do. Like does @Gerhard really need 200us or there are better ways to handle what he needs. We are still waiting to hear more info on what he is trying to do.
10-4, understood…!
…btw: The engineer I put on porting our code from .netMF / G120 to tinyCLR / sitCore
SC20260D dev board.
So far no problems… I asked engineer what .net stuff (libraries, namespaces, etc) does tinyCLR NOT support. Was told tinyCLR supports everything in .net…what?
Assumed such could not be true…!?
I have not yet had time with tinyCLR…hence put another engineer on it.
Our big stop-gate with .netMF was XML support.
Specifically, we could not write code to support openADR… a utility protocol.
Link: GitHub - epri-dev/OpenADR-Virtual-End-Node: This application is an implementation of a virtual end node (VEN) as defined in the OpenADR Alliance’s OpenADR 2.0 Profile B Specification (HTTP pull), updated July 1, 2013. OpenADR defines a machine-to-machine interface and includes the information model, transport and security mechanisms, and the manner in which data is exchanged between two end points.
We found a way around this by using a daughter-board from another vendor.
Really no big problem, i.e. we will still use .netMF and G120 …planning for future with sitCore
Is openADR possible with tinyCLR?
Don’t go look into such to deep, openADR requires ‘pretty-much’ the full set of xml capabilities.
So far, like the feedback that I am getting on tinyCLR…Can’t come up with a better mnemonic than FEZ…But if someone can use ‘Frickin Awesome…’ in some way, would get my vote.!
1 Like
We can very easily add XML. We choose json instead as it is more widely used, especially sure cloud services. Json and mqtt were required and were added.
If XML is needed and someone can show why it is a must, then we can add it. By the way, there is already community work that ported XML and glide to TinyCLR. But if course if XML is needed then we want an officially supported library. Here is is
I will present your request to the team on Monday.
I just looked at OpenADR. I have never heard of it before. Would it be necessary for us to add it as a standard NuGet?
My choice would be json…but xml is de-facto for the openADR protocol.
I have no leverage to change such an industry wide ‘Smart Grid’ protocol…Kinda, beat it or eat it.
As said, we were able to overcome .netMF XML limitations using another vendors daughter-board.
Given such, my preference would be that GHI continue on the core path. No need to devote cycles to xml…
There is one more item that would really be a help.
Have ability to zip / unzip files.
Again, if such is a real pain-in-the-ass…forget about it…continue on core path.
1 Like
This is on the list as well. It is a memory hungry feature. Can you give us more examples on how and why you need this please?
Hi Gus,
my question is not about the eco-system.
I know .netMF, G120 and I am also a fan of a good ecosystem, so I don’t use C, C++, Eclipse if there is another way.
But, I am also an electronic engineer and I know, that we need a reliable reaction of a system. ‘Reliable’ didn’t mean fast. It means, that the system will react within this time span, how long ‘this timespan’ ever will be.
In one project I use a SoM running WEC 2013 (Windows Compact Edition 2013) and I do lot of research and I found out, that this system reacts within 100µs. (After Microsoft fixed a bug in the scheduler).
==> I configure a GPIO as input, an interrupt on falling edges and start a SPI transfer.
I also use a processor running FreeRTOS which do the really fast stuff and you can use a FPGA if this isn’t fast enough. My current project will need a FPGA.
Than the collected data will be stored in a buffer and transferred to the SoM using a bus like SPI.
If there is an ADC generating 21 byte of data (6 channels with 24 bit resolution, sampling simultanously and 3 byte of status info) each 66.67µs you need a large buffer if the main system needs more time to fetch the data.
In this case I have to know the longest timespan needed to fetch data to calculate the amount of buffer needed.
And if this timespan is too long, so the available memory isn’t big enough, the system didn’t fit the needs, so if there is the best ecosystem worldwide, fine, but still no chance to go with it.
==> To know, if the system (with this nice ecosystem) is usable, I need to know the length of this timespan. And every engineer which do similar will need it.
If the project can be done on a standard PC (Win or Linux) without any relation to time, than I can use every modul, RasPI, Beaglbone and so on, just to save costs, space and energy. Think about home automation or weather stations.
In the moment we go closer to hardware, getting large amount of data from ADCs or other sources containing properties related to time (frequency, periode time, wave form) we have to deal with ‘realtime’ systems.
And if you answer me, processing (begin of processing) of an event will not take more than a second than it is also ok. It isn’t the length of the time span per se its the reliability.
If you do not have this data now, it is also ok, so we have to set out research to find it out.
But sorry, this bit of data is a key value to select systems. A nice ecosysem is ‘only’ a goodie. Which means, if I have to choose between systems, I have to check the reaction time and calculate buffer length and so I will see, is it possible or not, and if there were more than one system left, I choose the better eco-system (IDE, programming language …) no question, and .net is my favorite.
With best regards
Gerhard
if you want very fast responsive i can suggest
raspberry pi cm+ 8/16gb with .net core
but i don’t know did that will fullfill your needs
latest i did an test with blink with own delays i’ve got 60 uS (microseconds) on/off …
so depend on your need but based on my experience (realtime alert or trigger can be used only on medicine,virusology,or similiar event or in at least case of sensors) and for iot/m2m/mqtt/http it dosn’t matter if this micro,milliseconds because on network time is not relative more because of network latency…
so till know from test how i seen TinyClr do excellent job in my case 100% with threads/db/network/security/graphics and inside/outer communication bus protocols that are included.
but in your case i don’t see needs for such capability
weather station (doesnt matter if you collect info at micro/milli even second level) for rt os …
Almost 100% percent of our devices have an embedded cellular modem for communications over cell carrier, mvno(s) all VPNd with at min double-redundancy to our NOC (server).
We hardly remember what an ethernet cable is, i.e. our stuff is in the brittle sticks…remote.
When we need to update the C# application on our device(s). We OTA (over-the-air) transmit this new application, stick it on SD and via inFieldUpdate(…) update the device / G120.
In general we call these new applications cdapp_XXXX.HEX
If one of our techs was local, they could update the device via Fez Config. Usually, this is not the case…remote.
We also have another file that (sometimes) needs to be updated simultaneously with the new application. This file configures the device for specific geo-site needs as well if say a new cell modem, LoRaWan, etc needs deployment. In general we call this file config.csv.
We also cell modem FOTA (Firmware-Over-The-Air) updates that need to be performed.
Whether we are updating the application, config file, or modem FW…we OTA (download) to SD and reboot our device. Upon reboot, the updates get set.
We have, over the years, developed essentially a check list of how to update (OTA) our device(s).
Sometimes it is just a straight forward OTA. One and done.
Sometimes we must downgrade the device and then in specific order update the device in a sequence so that we don’t ‘Brick’ the unit…Such is prone to error, a pain-in-the-ass, and very costly to roll a tech to such remote environs.
If we had a way to zip all updates, OTA updates, reboot, unzip and apply all updates in a sequence determined locally by the device…would be a huge improvement to what we do now.
As a less important consideration, being able to simply compress files (big log files) on our device so that cell data transmission is decreased and hence cost is certainly something we want and need.
As said, trade-offs are part of building a full system. We would like to shorten this list of trade-offs…!
Sounds like you only need to decompress, not compress. Is this true?
And you need this to lower how much data you need over cell?
We need both compress and decompress and actually of more importance is to be able to send a single zip file which may contain multiple individual files.
compress: Log file is on remote device and we want to send to NOC (server). Compress log file and send to NOC.
decompress: We want to update application, configuration, modem fw.
Zip / compress all three on NOC, send to device, device unzips and does it’s updating.
1 Like
Trying to fully wrap my head around your question, but I think I understand(?)
You are looking for a reliable (fail-safe) scheduler to process hunks of data, correct?
I am closing my responses for tonight…getting late (Boise, ID).
Will check in morning.
Always great to understand other devs problems…I thought I was the only one with problems. Will sleep better.
, sorry, but you missunderstood me totally.
1.) Yes to toggle a GPIO in a loop is nice, but normally not equal spaced in time, so for stuff close to the hardware not reliable enough.
2.) I talked about interrupt response or event response. This is much more interesting for hardware engineers.
3.) The key feature isn’t the timespan needed for a reaction it is the stability of that time span.
Setup some hardware, write software which configuers an interrupt/event on falling edge of a GPIO pin, toggle another GPIO pin within the interrupt service routine/event handler and use a (good) scope to measure the timespan between the falling edge and the toggling of the pin. Do this over a long time span (millions of tries) and use the system somehow (keyboard, graphics, file transfer, network traffic …)
The maximum of all measured reaction time span values is probably a good guess about the systems reaction.
And no, I dont want to build weatherstations this way. I build scientific measurement systems, fetching signals which time related properties like frequency, periode and wave form were important informations.
And this systems needed data management (storing, calculation, visualization) which I will do in a high level language and using a good eco system like .net amd Visual Studion.
With best regards
Gerhard
so than even better are you tried to
use signal generator is .net /tinclr
https://docs.ghielectronics.com/software/tinyclr/tutorials/signal-control.html