Can I run real-time applications on Omega?
-
Hi guys - thanks for writing!
Could you perhaps supply a bit more detail?
- Is it technically possible to totally mask-off (prevent) all interrupts? (note that I use the word "possible", not the concept "good idea" or "achievable" or anything)
- If not, is it possible to vector every interrupt to myself (so my software can arbitrate when, if at all, to permit critical interrupts to go through)?
- Can anyone guess what the O/S might do if (for example) I blocked every interrupt from it for an hour, before re-allowing interrupts again?
- Can anyone guess what the Hardware might do if (for example) I blocked every interrupt from it for an hour, before re-allowing interrupts again?
- Does a high-freq interrupt exist which I can use which has priority over every other interrupt?
Please do not mention or propose hardware alternatives.
-
-
It is possible to totally mask all interrupts. Shortly thereafter the operating system would crash.
-
Yes it is possible to vector all interrupts to your software. You would then have to write an operating system.
-
See first bullet.
-
Waste electricity?
-
Linux systems have a task priority scheme. See the "nice" command. This probably doesn't get you what you want.
-
-
@Chris-Drake said in Can I run real-time applications on Omega?:
Hi guys - thanks for writing!
Could you perhaps supply a bit more detail?
it would also help if you could provide more detail on what you are up to. I mean - what PWM frequencies and resolutions are required, how many channels? etc.That would help us to come up with more useful information.
As @Mark-B said - of course you can block IRQs and change vectors. The MT7688 is a microcontroller like any other. There are few conceptual differences to an atmega or PIC. However, it's a huge difference in complexity and scale.
So you can go and hijack the CPU, reconfigure and mask all IRQs etc. But that means you replace the Linux kernel by your own code. The instant the kernel is not any more in charge of managing all system ressources, you loose network, wifi, flash disk access, I/O buses - pretty much everything. And that's not a matter of hours, but rather milliseconds of blocked IRQs.
Please do not mention or propose hardware alternatives.
I got you don't want to use external hardware! But why not use the MT7688's built-in PWM engine? It has 25nS resolution and 16bits precision for low/high output time. And from the datasheet (a bit sparse when it comes to explain functionality) it seems it can be fed via DMA. Using this, generating precisely timed PWM output is possible without fighting against / killing the OS.
-
you can technically achieve what you are describing by replacing the operating system on your Omega. Assuming you managed to compile your code for MT7688 you can then enter web recovery mode in uBoot and upload your own firmware.
-
Thanks @luz & @Zheng-Han !
During the "duty" of my application, I do not need any O/S support; I merely need to run machine code (which makes no O/S calls), access small amounts of memory, and and accurately control the output timing of my signals (with no exceptions). Normal "duty" would mostly be 10's of seconds, sometimes 10's of minutes, and occasionally as long as 2 hours nonstop - but always ending with enough time to re-enable interrupts and let the O/S service anything it might want to do, before (hopefully) allowing my code to make a couple of O/S calls to (for example) update some files from the stats accumulated in it's memory.
"End of duty" times would always be many seconds at least. I do not need to keep track of time.So yeah - while I don't need any O/S for my main purpose; it would be nice to have it available "in between" duty times for other purposes, like displaying stats, doing updates, and so on.
My purpose for "bit bashing PWM" is confidential (sorry!) but suffice-it-to-say, it is non-linear, non-conventional, non-constant, and "human safety critical" - battling other peoples code and hardware to try and get my application to work with existing tools will be too much work and too high safety risk (one unexpected interrupt doing something unusual could have catastrophic consequences). Or in short: I need "real time" for my code, in the old-school genuine meaning of that phrase.
Do you guys believe the O/S would really "crash" like that Marc guy said? Nothing can "crash" when it has no control - I can't figure out if he's smart or stupid, because he says a mix of both things in his answer! (e.g. "nice" is irrelevant, but he seems to know that, and "Waste electricity" is just plain insulting)
-
Do you guys believe the O/S would really "crash" like that Marc guy said? Nothing can "crash" when it has no control - I can't figure out if he's smart or stupid, because he says a mix of both things in his answer! (e.g. "nice" is irrelevant, but he seems to know that, and "Waste electricity" is just plain insulting)
Yes, when you take complete control of the CPU and block all IRQs, of course then the OS will not be able to do anything, so it can't "crash", but is reduced to a frozen state of bits in the memory, except for some DMA that you'd need to take care of separately.
But it will most likely crash when you just re-enable the IRQs, because by then all time keeping and buffer management will be out of order. What exactly will happen is hard to predict, but I would say it is impossible to reliably get the OS working again this way.
From what you said about your use case, the only safe way I see to get back to Linux from your "duty" code would be doing a reset and have the OS reboot. You'd need to find a way to pass data back from the "duty" phase, like writing to a reserved SPI flash memory area.
On a side note: I can't help but being a bit frightened by the combination of "human safety critical" application, "catastrophic consequences" on one side and the apparently strict requirement that this critical timing stuff must run on a SoC definitely not made for this, instead of in a smaller chip that actually allows proper predictable bit banging. On the MT7688, even with disabled IRQs and DMA, you have DRAM, MMU and cache, which make timing execution cycles not nearly as simple as in a PIC/AVR/MSP type chip.
-
@Chris-Drake said in Can I run real-time applications on Omega?:
Nothing can "crash" when it has no control
An operating system that doesn't have control isn't really an operating system. It is possible to write software that can replace the various functions of the operating system that are necessary for your application, but on a complex processor this is non-trivial. I would expect an effort counted in man-months (and probably a lot of them) for someone familiar with the this sort of thing to do what you've described. This is the essence of the first reply.
Consider this: X Y Problem
If you really need to generate time critical software bit banged I/O on a small single board computer, one of the BeagleBone products would be a better starting point than the Omega. The processor chip used on those boards include both a Linux/ARM main processor and two fast real time processors, so you (relatively) easily get the benefit of both a high level OS and fast hard real time capability.
-
My purpose for "bit bashing PWM" is confidential (sorry!) but suffice-it-to-say, it is non-linear, non-conventional, non-constant, and "human safety critical" - battling other peoples code and hardware to try and get my application to work with existing tools will be too much work and too high safety risk
This is precisely why you need a simple MCU for which you can obtain full engineering information, and not an MT7688 designed to run a complex operating system and for which you will never get the same level of detail out of the manufacturer.
Did you overlook that there's a second CPU in the package over which you have next to no control?
All of your requirements point away from trying to use this device for your purpose.
Additionally, you've presented absolutely no arguments for why it would even be desirable to try to use it for your purpose; it's unlikely that any convincing ones that could survive the most cursory scrutiny exist, but you haven't even tried.
-
I have to agree with the others: this sounds very much like trying to force a square peg into a round hole. Pair a simple MCU with a SoC and you get the best of both worlds, or just go with a more capable MCU from the get-go. There's plenty of choice there, with my favourites being STM32L0-series for the low-end and ESP32 for the high-end.
-
All - I owe a HUGE debt of gratitude to your detailed answers.
Since it does seem the weight of consideration, as well as design (including at least DMA and cache), is going to be fighting against me, I'll head back to the drawing board and find something more architecturally suitable for real-time work!
I feel like I owe you all at least a beer - your patient explanations have almost certainly saved me months of headache.
