Interrupt routine duration - Page 1
Forum section: electronics / general

author: Red_Micro
author_rank: Regular Contributor
timestamp: August 12, 2022, 05:32:28 pm
content: How long is it safe for a interrupt routine to process things in it? Let's say I have an interrupt every 300 us. It means I need to keep any processing time inside below 300 us, right?

author: nctnico
author_rank: Super Contributor
timestamp: August 12, 2022, 05:49:42 pm
content: Yes. Typically I try to keep total interrupt processing below 90% of all available CPU time so that there is room left to do housekeeping tasks (like handling buttons). If you have several time critical processes, you'll need to create a plan on how to deal with all the priorities. There is no general approach that works for all applications.

author: hans
author_rank: Super Contributor
timestamp: August 12, 2022, 05:57:06 pm
content: Yes.But also to leave enough cycles for main() code or other interrupt vectors.The main importance of IRQs is to service the hardware to keep it operating properly. E.g. reading a received byte from an UART has some time sensitivity, as the buffer needs to be cleared before the next byte arrives. It's real-timeBut in this case it depends how bursty the incoming data stream is. If you can guarantee that only 1 byte arrives every 300us, then there is nothing stopping you from spending 300us in 1 IRQ. The CPU simply doesn't care if it's executing code in IRQ or main.However, if you can't guarantee that (e.g. only in the happy path, not during fault etc.), then the firmware may break. It's therefore still best practice to keep IRQs as short as possible though. On some MCUs without a nested interrupt controller, you may also block all other interrupts for that particular amount of processing time, which could introduce issues or timing jitter. Pushing data around with buffers between IRQ and main() can solve a lot of the problems associated with bursty interrupts and long processing times.

author: Ian.M
author_rank: Super Contributor
timestamp: August 12, 2022, 06:00:24 pm
content: It depends - if the peripheral raising the interrupt has a multi-item hardware buffer or queue, then it *may* be acceptable to occasionally take longer to handle an interrupt than the interval to the next one, as long as on average it takes less time and the buffer/queue never overflows.

author: tggzzz
author_rank: Super Contributor
timestamp: August 12, 2022, 06:08:56 pm
content: Quote from: Red_Micro on August 12, 2022, 05:32:28 pmThat would work if either there is no other processing to be done, or the other processing can be done on a separate core. But... If there is no other processing to be done, then it would be simpler and more predictable to spinloop waiting for the event that triggers the interrupt! Interrupts are a pragmatic complication, since in most applications it is not practical to do nothing until an input occurs.If there is other processing to be done, especially if it is on another core, a sound technique is that the ISR captures the essential information contained in the event, puts that information in a mailbox or FIFO, and returns as fast as possible. The other core or background thread spinloops until there is something in the mailbox or FIFO, gets the event information, and processes it. That technique is easy to design, implement, verify, and (if necessary) debug. If the other system constraints allow it, then that technique can also allow for short bursts of interrupt events less than 300µs apart.Naturally in some cases that is ideal, in some cases impossible.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 12, 2022, 06:17:17 pm
content: Quote from: Red_Micro on August 12, 2022, 05:32:28 pmWell, any processing inside the interrupt handler PLUS any processing outside of it must fit within the 300 us period. How you balance that completely depends on what your code is supposed to be doing. Obviously if you take all 300 us inside the interrupt handler, there won't be any CPU time left for anything outside of it. Which is probably not what you want, but we don't know.So while there is absolutely no hard rule about this apart from what I just said above, the usual approach is to limit any processing inside interrupt handlers to the bare minimum. But, again, it all depends on your overall architecture.

author: nctnico
author_rank: Super Contributor
timestamp: August 12, 2022, 07:29:54 pm
content: The way I look at interrupts is like having a time slicing / pre-emptive multitasking OS in hardware. Each interrupt source is a seperate process. If the hardware supports nested interrupts, you can give these processes priorities where a higher priority process can halt a lower priority process for a little while. I don't see keeping interrupts as short as possible as some kind of ultimate goal; data will need to be processed one way or another.One complicating factor can be getting large amounts of data in bursts that can't be handled as fast as the data comes in. In that case there is no alternative to buffer the data and handle it at a slower overall pace that on average keeps up with the incoming data. This can be done from the main loop but another solution is to use a timer interrupt to create a process that is run at preset intervals and thus can claim a fixed amount of CPU time without complicating housekeeping tasks in a main loop.What is important to keep in mind is that a processor has X time to process an Y amount of instructions. That is a hard limit you can't go around. If you have two or more time critical processes, one will need to halt the other at some point. Solving this starts with obtaining accurate execution times and limits on maximum execution times of each cycle of the process. From there it can be determined whether the process can be halted long enough or that a different approach is needed (for example some form of hardware accelleration, multiple CPU cores, buffering, etc).

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 12, 2022, 09:40:40 pm
content: Short enough not to interfere with other things.Based on the scant information provided, there are zero or more possible restrictions on execution time.That it recurs periodically, isn't a reason to require it shorter than that.Examples:Maybe there's little or no penalty for failure: maybe a display flickers, or there's a momentary hiccup in a slow control loop, or a delayed or dropped packet in a UDP application.Maybe it's just a timer that schedules work to be done, and most of the time it returns immediately, but occasionally it takes much longer to finish (due to various reasons: external data, internal sequencing, etc.). And maybe that work must be done. So it just continues until it finishes. And in the mean time, the interrupt is skipped, or queued, or just keeps on running on top (the shorter passes finishing and returning to the longer run).Thinking of things in terms of threads of execution, and concurrency, is useful, if a somewhat advanced topic. I'm guessing discussing it won't be of immediate help, but introducing the concept and getting accustomed to it is.Interrupts are a rather basic primitive, almost not worth thinking in terms of threads -- you can't create and destroy interrupts arbitrarily, and you might not be able to delay or sleep them, as such -- but the other aspects are no less relevant, concurrency in particular.Indeed, the latter case (a recurring interrupt that is allowed to overlap itself) can be considered a source of concurrent threads, placed on the stack, and running in order until they finish (equivalent to cooperative multitasking). You need to make very sure, of course, that the actions of each instance do not overlap and corrupt each others' state (including non-atomic / multi-word accesses that might get interrupted in the process). Use buffers/queues, mutexes, etc. to manage shared objects.As for the usual case, you want to handle a minimum in the interrupt itself, and handle the rest in main() loop, or at least a lower priority interrupt. Example: put serial data into/out of a buffer, and interact only with the buffer from elsewhere.I've also done before, an interrupt which dominates CPU usage. This must be done carefully, at low enough priority that it doesn't block other functions, but driven by a high enough priority interrupt for the hard real-time application. The XMEGA happened to have the right combination of features to do it:https://github.com/T3sl4co1l/Reverb/The ADC samples come into an accumulator (unnecessary, turns out the XMEGA ADC is pretty clean), which is copied down periodically (ADC samples counted by a timer-counter). This gets a sample out of the super fast accumulator loop and into main memory. The timer fires a low-priority interrupt halfway between (every 4 samples, either the accumulator value is copied and reset, or the copy is processed), and this allows the processing to happen over a longer time scale without delaying others. In this way I can use, like, >90% of CPU cycles in that interrupt, without requiring main() to loop at high frequency (25kHz).Tim

author: Kjelt
author_rank: Super Contributor
timestamp: August 12, 2022, 09:44:57 pm
content: Some things to read for TS.No RTOS needed, you can schedule tasks yourself with Rate Monotonic Analysis of the code you should make sure you will always stay within the uC timing requirements.https://en.wikipedia.org/wiki/Rate-monotonic_scheduling

author: tggzzz
author_rank: Super Contributor
timestamp: August 12, 2022, 10:09:37 pm
content: Quote from: nctnico on August 12, 2022, 07:29:54 pmIf you choose the right processor and language and design mentality, that is exactly the way you implement an application.I refer, of course to the XMOS xCORE processors, xC , and CSP.They completely avoid the need for interrupts, and the RTOS/scheduling is done in hardware. Plus, uniquely, the IDEguaranteesexecution times without resorting to measuring and hoping you've spotted the worse case.

author: tggzzz
author_rank: Super Contributor
timestamp: August 12, 2022, 10:11:10 pm
content: Quote from: Kjelt on August 12, 2022, 09:44:57 pmYou only need to do that if you haven't got enough cores. Nowadays cores are cheap.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 13, 2022, 06:11:29 am
content: No need to make things difficult, write schedulers, use OS or buy esoteric special snowflake products however good they all are in some cases.Just use a microcontroller with pre-emptive, prioritized interrupt controller (for example, ARM Cortex-M0 and above), and interrupts can interrupt other interrupts based on the priorities you assign to them. It is not a problem at all to spend "a lot" of time in an interrupt. My programs have all basically had empty while(1); loops for years, I do all in ISRs after init.Instead of:important_isr:important_flag=1returnless_important_isr:less_important_flag=1returnmain() while(1)if(important_flag)do important thingsimportant_flag = 0if(less_important_flag)do less important things// what do you do if important_flag is set in the middle of things here?less_important_flag = 0I do this:important_isr()do important thingsless_important_isr()do less important thingsmain()set_priority(important_isr, HIGH)set_priority(less_important_isr, LOW)while(1) do nothingAlso this is possibleimportant_isr1:do important things, quicklygenerate_software_interrupt(slow_processing_of_important1_data)important_isr2:do unrelated important things, quicklyslow_processing_of_important1_data:do calculations after important_isr1, slowly, but of course must finish before next important_isr1main:set_priority(important_isr1, HIGH)set_priority(slow_processing_of_important1_data, LOW)set_priority(important_isr2, MEDIUM)// thanks to SW interrupt, processing of isr1 data commences automagically after important_isr1 (and possibly pending important_isr2) returns,// important_isr2 can't interrupt interrupt_isr1, but can interrupt the processing part// slow_processing_of_important1_data won't block any other interrupt, so it can take its time no problemwhile(1) do nothingOf course, you still can't spend more than 300µs if you want to react to the next interrupt with same priority after that 300µs in time.

author: Kjelt
author_rank: Super Contributor
timestamp: August 13, 2022, 07:05:11 am
content: Quote from: tggzzz on August 12, 2022, 10:11:10 pmWhat devices are you talking about ? I am talking about embedded devices like Arm cortex etc.And it is still valid to learn about this in 2022.For instance TS could think about offloading processing outside the ISR.If you need 32 samples and only then do a lot of calculation you do the time critical sampling in the ISR, save the data and offload the processing for another process, perhaps in small steps etc. In that case you might get the calculated data at a later stage but the samples are at least valid. You always have to take the whole design into consideration for these decisions.And more cores can help but donot always solve your problems, just as that 9 women will not bear a child in one month

author: nctnico
author_rank: Super Contributor
timestamp: August 13, 2022, 08:34:39 am
content: Quote from: Kjelt on August 13, 2022, 07:05:11 amWhy would you do that? These are precisely the blanket statements that make a lot of simple signal processing devices overcomplicated. Basic rule: remove complexity. Your blanket statement only adds complexity by creating extra time sensitive processes and adding buffering / signaling between them.

author: tggzzz
author_rank: Super Contributor
timestamp: August 13, 2022, 08:55:12 am
content: Quote from: Kjelt on August 13, 2022, 07:05:11 amI'm not, of course, since ARM cortex hasn't got these properties: 1-32 cores, 500-4000MIPS,guaranteedhard realtime operation, no RTOS available - since it isn't necessary and would only degrade performancehttps://www.digikey.co.uk/en/products/filter/embedded-microcontrollers/685?s=N4IgjCBcpgnAHLKoDGUBmBDANgZwKYA0IA9lANogAMIAugL7EC0ATMiGpAC4BOArkVIUQAVjr1GINpEoAPFCR75xQAhttps://www.eevblog.com/forum/microcontrollers/interrupt-routine-duration/msg4354999/#msg4354999I've ignored your boring point about Amdahl's law, on the grounds that no technology solves all problems. What's interesting is the set of problems that can be avoided by use of appropriate technology.

author: tggzzz
author_rank: Super Contributor
timestamp: August 13, 2022, 08:56:47 am
content: Quote from: nctnico on August 13, 2022, 08:34:39 amThings should be as simple as possible,but no simpler.The definition of "simple" is left as an exercise for the student.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 13, 2022, 09:32:49 am
content: Quote from: Red_Micro on August 12, 2022, 05:32:28 pmEssentially yes,though "time inside" also needs to include context save/restore time, which will typically be hidden by the compiler.Although generally speaking it's good to minimise the amount of time spent in in ISR there are situations where doing more can be useful. The risk is that the time available, and latency of other tasks can start to suffer in ways that can be hard to predict.An example I did a while ago, doing bit-bashed UART receive at 250kbaud on a PIC10F322 - the ISR entry/exit time took too long to do the traditional timer interrupt to sample each bit, so I generated an interrupt on the startbit falling edge, and the ISR read the whole byte before returning.This only left a few cycles for the foreground task, but that didn't have much to do so it worked fine.

author: hans
author_rank: Super Contributor
timestamp: August 13, 2022, 11:42:24 am
content: Quote from: tggzzz on August 13, 2022, 08:55:12 amBut then I could also pitch how FPGAs are great for real-time control, because you can try to fit as much computation in 1 clock cycle as you specify. Those parts are very expensive. Most multi-core MCUs like the xCore, STM32H7, NXP parts (LPC4300), etc. are all expensive parts (10$+ each). Some exceptions exist like dsPIC33CH or RP2040, but still are relative beasts. Would youneedthat if you can solve a problem in firmware? 'The definition of "simple" is left as an exercise for the student.' is indeed very ambiguous. You could say that code implementation wise, a blinky in VHDL is less much work than on a MCU. But still I think only a few people would get out a whole FPGA board and toolchain to start doing those tasks.The question of OP is still valid: how can you implement said problem on 1 CPU core without things starting to break. If the hardware is computationally capable of doing so, it's an implementation detail how it's done. Choosing a different part that is far more capable an escape to not having to fuss with this stuff.I fully agree here that it's okay to stretch IRQs if that makes sense for the application (e.g. straightforward to implement). The exact schedulability of tasks depends on the CPU utilization of each task, and how many there are. For example with a Rate Monotic Scheduling (behaviour), you can get away with 1 task having a very short run-time while the other takes a really long time to complete. The Liu&Layland upper bound is aleastupper bound which decreases to ln(2)=69% for infinite tasks on 1 CPU. However the hyperbolic upper bound is tighter on the basis of the same amount of information.E.g. if you have 2 tasks that consume 90% and 5% of CPU time, then Liu&Layland says these cannot not be scheduled because CPU utilization must stay below 82.8% for 2 tasks, which is grossly violated with 95% usage. However the hyperbolic upper bound says that {product[i=1..n] U_i+1}<2, which is 1.9*1.05=1.995. So it should work out fine!This is the main reason I like to keep interrupts as short as possible. IRQ 'tasks' scheduled by hardware behave like RMS, and by keeping those CPU utilization factors low, the product in the hyperbolic bound stays as close to 1 as possible. Then in the main() code, if you can properly prioritize which process needs to be completed first (earliest deadline first scheduling), you can push that part of the application close to 100% utilization, as the CPU upper bound is not a product but a sum. This of course requires more firmware work for IPC between IRQ and main(), and also a main() that is able to switch context depending on arriving deadlines, for example using a preemptive RTOS with deadline knowledge.The question is if you want to fuss around with RTOS for a theoretical 30% max profit in available CPU power (assuming all IPC and the IRQs are implemented with zero overhead). So both are valid options.

author: nctnico
author_rank: Super Contributor
timestamp: August 13, 2022, 12:33:56 pm
content: Interesting, but if you treat interrupts as processes that can interrupt eachother (using nested interrupts), you are back to the situation where you are scheduling using an OS... From a functional POV there is no difference.

author: tggzzz
author_rank: Super Contributor
timestamp: August 13, 2022, 01:34:07 pm
content: Hell's teeth, that's a lot of randomly interleaved points, which I won't attempt to disentangle.Quote from: hans on August 13, 2022, 11:42:24 amThis thread is about interrupts in MCUs.Actually, FPGAs arecheaperthan MCUs (and vice versa). It all depends on the application and constraints, and gross generalisations are silly.The xCORE devices are MCUs that have many FPGA-like benefits without the pain of FPGAs, notably simulation, placing and routing. They are not a complete replacement for FPGAs, of course, but they do have beneficial characteristics that developer with only conventional MCU experience cannot believe exists. Wider experience is often beneficial, especially since technology changes regularly."...try to fit as much computation..." is right for FPGAs; placement and routing greatly affects what is possible. When pushing the limits, fmaxcan vary a lot with "trivial" placement changes.systemIf I wanted to do a blinky, I would use one resistor, one transistor, one capacitor, plus an LED. A 555 - let alone an MCU - would be unimaginative overkill.Of course "'The definition of "simple" is left as an exercise for the student.' is indeed very ambiguous." is ambiguous. It must be read in the context (which you chose to snip) of the preceding sentence famously said by Einstein.QuoteYou are inventing constraints. The OP did not mention the number of cores.QuoteWhile I agree with many of those points, they ignore the most important point. That can be summed up as "if it is allowable to get the wrong result, then I can make a design that is faster and cheaper than any different design". "Fitness for purpose" matters!

author: Kjelt
author_rank: Super Contributor
timestamp: August 13, 2022, 02:02:34 pm
content: Quote from: nctnico on August 13, 2022, 08:34:39 amIn case it does not fit. That is when MRA comes in.If it does fit and you are swimming in idle cycles, then why open a topicQuoteYes the KISS principle is always valid when you start. Then fifteen SW versions later, you run out of processing time somewhere and you have to get smart and creative. When is what time consuming calculation absolutely necessary? When can we stop sampling some input since that is in the current state not needed, etc. etc.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 13, 2022, 03:43:27 pm
content: Quote from: Kjelt on August 13, 2022, 07:05:11 amHe's a fanboi; don't expect reason to get involved.Mind, fandom is strong with MCUs anyways; this is no accident. Whereas hammers and screwdrivers are fairly intuitive to pick up and use on anything remotely like a nail or screw; MCUs are very far from it, and so one tends to use whatever hammer they have available.(I can't speak for others, but I for one, at least, appreciate the intent, and value, of the xMOS design. It's just that I'm essentially never going to need that value. Not with that price point, learning curve, or single source*.)(*Not that most any MCU isn't single-sourced anyway, just that the more conventional designs are more likely easier to port between, if it comes to it.)(*And not that it's necessarily a huge learning curve. It's just yet another new thing I don't have time to learn.)Tim

author: tggzzz
author_rank: Super Contributor
timestamp: August 13, 2022, 05:23:26 pm
content: Quote from: T3sl4co1l on August 13, 2022, 03:43:27 pmIn some ways yes, in some no.I get tired of comparing essentially similar MCUs (and programming languages for that matter) where people argue over trivial differences and ignore glaring flaws/gaps. How to achieve hard realtime guarantees is one such area.I am interested in exploring significantly different approaches to a problem space, where the differences lead to significant advantages (with some disadvantages, of course).Examples....There used to be endless discussions as to whether Delphi was better than Pascal was better than C. To me they were boringly identical when compared with, say, Smalltalk/Objective-C or Prolog/LISP/ML etc.When I returned to embedded programming after 25years, I was appalled that little had changed since the early 80s. People still programmed 8/16/32 bit processors in C. I was horrified at how little I had to re-learn.People thinking that testing can ensure quality, in this case that measuring hard realtime performance is sufficient. Prediction is far more important than measurement, and much faster!The point is to know that there are more than nails; screws and glue exist. Then choose which tool to use.QuoteEntirely reasonable.The one point I'll make is that the XMOS mentality can be used in far more than XMOS processors. CSP style message passing is common in the HPC community, and TI DSPs have xC like channels for communication. (Both originated in the Transputer/CSP/Occam world in the early 80s). Such concepts can be a valuable way to structure designs and implementations on any embedded processor.Single source is a very valid issue, one that always occurs when something is significantly different. Multi sourcemustbe "me too", for better for worse.The lack of time is why I chose not to learn Delphi nor C++, a decision I've never regretted.

author: TC
author_rank: Contributor
timestamp: August 13, 2022, 05:33:31 pm
content: Its hard to know how experienced you are from your post. Assuming you don't have lots of experience, I'll suggest you look into the topic of deferred interrupt processing. I know FreeRTOS has a reasonable discussion of this on the web but this is a widely discussed topic and I'm sure that there are plenty of good web resources.If you are opposed to the use of an RTOS then you might want to learn about co-routines. Miro Samek (Quantum Leaps) has an excellent book that explores this in detail with excellent examples... "state machines" or something like that in the book title.With an understanding of deferred interrupt processing and some of these programming techniques you will understand the benefits of keeping processing in an ISR to a bare minimum and the techniques that you can use to do this.Good practice is to do the time critical hardware servicing like getting the ISR status and clearing the interrupt, setting a flag (for deferred interrupt processing) and then exit the ISR. Do the rest of the processing when not in an interrupt service routine.

author: nctnico
author_rank: Super Contributor
timestamp: August 14, 2022, 12:23:19 am
content: Quote from: tggzzz on August 13, 2022, 05:23:26 pmWell, people that are programming microcontrollers in assembly seem to have gone during the last decade so there is progressBut I see your point. I was kind of hoping to see more like Ada to write software in a less messy, better controlled way. But the problem is the all-or-nothing approach that is generally followed. For example: Ada needs a large runtime environment which then needs to be ported to every microcontroller before it can be used. But I see the same where it comes to using languages like Python and Lua on microcontrollers. I've looked at various projects but they all go for the all-or-nothing approach where you either write the entire application in Lua / Python or not. C is much less demanding in that respect.However, every now and then I have a project which would greatly benefit for having the business logic implemented as a script so I looked into using Lua on a microcontroller -again-. This time with the clear goal that Lua should have a supporting role. C does the heavy lifting and Lua just ties everything together by calling C functions, shove data around and make decissions. For this purpose I took the emblua project (https://github.com/szieke/embLua) and modified it so it can run a script in parallel with C code without needing an OS. It still needs a bit of testing and a few tweaks (to allow debugging) but I plan to put this on Github when it is finished.

author: uer166
author_rank: Super Contributor
timestamp: August 14, 2022, 12:50:32 am
content: Quote from: Siwastaja on August 13, 2022, 06:11:29 amI used to be a proponent for co-operative schedulers (no interrupts allowed at all). But with the exception of some regulatory and reliability edge cases, the nested ISR way you mention is generally easier to understand, and can still be designed to pretty high assurance levels.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 14, 2022, 12:52:19 am
content: Quote from: nctnico on August 14, 2022, 12:23:19 amKinda tempted to learn Rust and see how that goes. Not very well supported on AVR though (just barely, I think? an LLVM outputter?), so that would assume, in addition to learning the whole language, potentially also grappling with compiler bugs, or just poor optimization (granted, not that avr-gcc is a high hurdle to clear).Regarding scripts, there's also MicroPython, too big to put on small like 8-bit or entry level parts, but STM32F4 will certainly get you there IIRC. Maybe not something you'd want to embed for production?, but a handy way to test out a lot of things quickly.Tim

author: Siwastaja
author_rank: Super Contributor
timestamp: August 14, 2022, 06:29:24 am
content: Quote from: uer166 on August 14, 2022, 12:50:32 amIn very complex interdependence cases my interrupt way might fall apart; I don't know because I have not seen this happen.The upside is simplicity, which eases analysis and reduces risks. For example, often you have say an analog signal which signifies overcurrent event, and say another digital signal which signifies Failure of a Safety System. It is trivially easy to configure both for highest priority, and assign them the same "safe shutdown" handler. They will pre-empt any other "normal operation" ISR.Things could get difficult if safe recovery from an overcurrent event requires some weird, slow process, and recovery from Failure of a Safety System requires another, different kind of weird, slow process. Then you would need to choose which gets higher priority, which might not be allowable, they would need to run simultaneously.But I have not encountered anything like this in real life. Then again, I also realize that sometimes you can't do everything on an MCU, but need a CPLD as a helper, or a full FPGA design. In fact, many VFDs (variable frequency drive) I have teared down seem to use MCU + CPLD, and I wonder why because at least I don't have any issue doing a VFD in full-MCU design, and have done many.

author: Kjelt
author_rank: Super Contributor
timestamp: August 14, 2022, 08:18:45 am
content: Quote from: nctnico on August 14, 2022, 12:23:19 amMy prediction from 2006 is failing miserably.I expected in 2026 that there would be more manufacturer tied in abstract block tools like rational rose. That an engineer picked an all-ready premanufactured module based on analog inputs (choose your MHz/GHz sampling requirements) and digital processing capabilities (Gflops/RAM etc) from the manufacturer, drawn in an abstract model based program what it needs to do, presses a button and all the HW and SW code is generated, downloaded to the module and ready for testing.A bit like a further mainstream low budget NI / labview development.In that sense developments are slow

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 14, 2022, 09:50:25 am
content: Quote from: Siwastaja on August 14, 2022, 06:29:24 amI suspect this is pragmatism and cautious design - they use hardware to enforce anything that could cause damage or present a safety hazard. It is very easy to mess up software in subtle ways. For long-lifetime industrial products like VFDs, it is quite likely that it needs to be maintained by different software people over time, and the risk of a software change causing problems in an industrial scenario, where it could literally cost millions in equipment damage & downtime is too high to be worth saving a few dollars on hardware.Having all "safety" related stuff in hardware means your software people don't need to be as expert in dealing with low-level timings, interrupt priorities etc. I doubt VFD manufacturers are as attractive to good software talent as "sexier" industries.It is also likely to be much easier to demonstrate to any internal or external QC inspection/review process that a hardware solution guarantees safe behaviour than software.Knowing for sure that any software change can't melt anything reduces the amount of testing needed for a new release.Industrial manufacturers will be concerned about things like noise, transients etc. causing disruption to software flow - again having hardware (CPLD) controlling things is likely to be more robust as it's less dependent on state information that could get corrupted.

author: nctnico
author_rank: Super Contributor
timestamp: August 14, 2022, 09:50:50 am
content: Quote from: T3sl4co1l on August 14, 2022, 12:52:19 amRust looks like it is another all-or-nothing approach. IMHO a better solution is to have a hybrid solution where you can mix another language with C / C++.QuoteWhy wouldn't it be useful for production? Actually one of the goals for using a different language is to get rid of the pitfalls of C that can introduce bugs. IOW: make software more robust. Micropython and Lua both run in a sandbox (VM). The Lua project I'm working on uses a fixed memory pool as well so whatever the Lua code does, it can not interfere with safety related code.

author: nctnico
author_rank: Super Contributor
timestamp: August 14, 2022, 09:56:45 am
content: Quote from: Siwastaja on August 14, 2022, 06:29:24 amI assume the CPLD has some protection logic inside. In the software controlled SMPS-ish devices I have designed so far, I always have some discrete logic to switch the power stage off when an overcurrent event occurs AND make sure that the control signals are valid (dissallow to enable the high & low side drivers simultaneously). It makes the hardware virtually indestructible.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 14, 2022, 12:24:39 pm
content: Quote from: nctnico on August 14, 2022, 09:56:45 amBut this logic is usually available, in hardware, in the MCU peripherals. Of course there is a risk of misconfiguring it, but it's a simple "one line of code during init only", so it's much less likely than messing up the program state during run.Quote from: mikeselectricstuff on August 14, 2022, 09:50:25 amI kind of understand this, and kind-of don't. After all, say in motor controller, as long as the application MCU can control the speed setpoint, which it definitely does, then all the risk is there. CPLD being responsible for protecting IGBTs from blowing up in case of software error, this is much less of a safety concern, as it will only blow a fuse and brick the product, causing downtime. OTOH, instructing the wrong speed, or ignoring an enable input, can be actually pretty dangerous and well possible by a simple software bug even if CPLD handles the lowest level switching.Hence my own guesstimate is, VFDs that do use CPLDs do this for legacy reasons, they have done that with earlier MCUs which simply lacked proper motor control HW (probably in the 1990's). Later, in 2000's, microcontroller manufacturers started to integrate this functionality.

author: TC
author_rank: Contributor
timestamp: August 14, 2022, 12:51:07 pm
content: I kind of understand this, and kind-of don't. After all, say in motor controller, as long as the application MCU can control the speed setpoint, which it definitely does, then all the risk is there. CPLD being responsible for protecting IGBTs from blowing up in case of software error, this is much less of a safety concern, as it will only blow a fuse and brick the product, causing downtime. OTOH, instructing the wrong speed, or ignoring an enable input, can be actually pretty dangerous and well possible by a simple software bug even if CPLD handles the lowest level switching.Hence my own guesstimate is, VFDs that do use CPLDs do this for legacy reasons, they have done that with earlier MCUs which simply lacked proper motor control HW (probably in the 1990's). Later, in 2000's, microcontroller manufacturers started to integrate this functionality.You don't fully understand requirements for safety in this context. Look up IEC 61508 and related standards (for example, the standard that includes "safe torque off" for motor safety. Things like unexpected startup, emergency stops, etc. are generally encompassed in motor safety.In IEC 61508 there are both hardware and software requirements. As the level of risk reduction increases (the safety requirements increase) the rigor of the development processes for "safe" hardware and software increases. Traceability of safety requirements, validation, control of the manufacturing process, and control of the entire life-cycle of the device (including any changes or maintainance) are typically required.So... when people say "safety"... this isn't something that you make "guesstimates" about. If you are developing motor drives familiarize yourself with safe-torque-off... then you will start to appreciate the simplicity of it and therefor the improved safety that such a hardware-based preventive measure can provide vs. software.

author: TC
author_rank: Contributor
timestamp: August 14, 2022, 01:02:05 pm
content: I should have also mentioned IEC 60204 Safety of Machinery... check that out, at least what the scope/purpose of the standard is.

author: TC
author_rank: Contributor
timestamp: August 14, 2022, 01:14:10 pm
content: RE: hardware vs. software safety...Safety of software will generally require that the custom code is certified, that the tools that are used to develop it are certified, that numerous constraints for the development of that software are enforced (like no object-oriented languages, MISRA C, etc.), safety-certified RTOS, safety-certified hardware, etc.In contrast, it is much easier to do a fault analysis of something like a CPLD that implements a safe-torque off function in hardware. Consider also the performance of the safety function (i.e. real-time performance of hardware vs. a bunch of code).So this is a good example of why hardware-based safety-functions are so important.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 14, 2022, 03:45:03 pm
content: Quote from: TC on August 14, 2022, 12:51:07 pmBefore judging what I understand and what I do not, maybe read the context and what I actually said?I was replying to a post which said CPLD is used for semiconductor switching to prevent MCU from blowing up the semiconductors so that inexperienced software team can be used. I don't think this is a correct description at all. The safety you describemustfollow into the MCU firmware, too, unless we talk about a completely separate infotainment part, which VFDs do not have.As the configuration such as speed, or configuration of enable signals goesthroughthat MCU, the software needs to comply to all relevant safety standards you discussed. Hence, I don't see any mandate to use a CPLD as long as the MCU provides all the required resources, and they do nowadays. Hardware inside the MCU will count as hardware as much as CPLD does.Hence I vote for "legacy", as I wrote above.But your reply is typical safety speak.Technicalquestions you are unable to answer are dodged by "you don't understand safety" and then throwing around standard numbers. I have done safety critical firmware and oh boy the biggest challenge is to find the balance between common sense and following the relevant standards, because standards rarely have 1:1 relevance on the actual product, so if followed blindly without understanding, have very high risk of reducing safety, sometimes significantly, and for me, most important is I can sleep well at night, and for me that means "nobody dies", instead of "if somebody dies, I have a good paper trail".

author: tggzzz
author_rank: Super Contributor
timestamp: August 14, 2022, 06:37:50 pm
content: Quote from: nctnico on August 14, 2022, 12:23:19 amindeedQuoteI'm enjoy applications that are tied tightly to the hardware and have hard realtime constraints, but which are specified at a much higher level. The interesting points then become hardware/software partitioning with as much in software as possible, plus ensuring that the high level specs arevisiblyimplemented correctly in the application.If I can arrange that changes to the high level spec are quick and easy to implement, so much the better.QuoteI haven't done that, but it seems sane and I would do it if the occasion arose.The polar opposite, creating a DIY scripting language in C - um, not so much"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

author: tggzzz
author_rank: Super Contributor
timestamp: August 14, 2022, 06:43:01 pm
content: Quote from: uer166 on August 14, 2022, 12:50:32 amIf the customer doesn't need it to be reliable, then I can deliver something arbitrarily fast, cheap, and soonI've seen nested ISRs become hairy and unpredictable, especially where realtime constraints and long-duration processing is involved.Short ISRs generating events handled by a cooperative scheduler seems a good middle ground. Such events are processed identically to events generated by applications within the cooperative scheduler.

author: tggzzz
author_rank: Super Contributor
timestamp: August 14, 2022, 06:48:36 pm
content: Quote from: T3sl4co1l on August 14, 2022, 12:52:19 amI have similar thoughts. Currently I'm content to watch other people push Rust as hard as possible as a C "replacement" (for want of a better word), to see where and how it is insufficient.QuoteQuick and dirty is certainly valid in some applications.

author: tggzzz
author_rank: Super Contributor
timestamp: August 14, 2022, 06:59:49 pm
content: Quote from: nctnico on August 14, 2022, 09:50:50 amI regard C as an all-or-nothing approach, especially when considering hardware as the other half of such a hybrid solutionAlternatively, what about a hybrid solution where Java is mixed with C via JNI.Oooh, tweaking people's tails is fun. I sometime have fun with softies, when having a drink in a pub. I tell them I can't tell the difference between hardware and software, then provide counter-examples to each definition they invent.QuoteYes indeed. I'm still looking for an ideal solution, but progress is being made!

author: nctnico
author_rank: Super Contributor
timestamp: August 14, 2022, 07:08:45 pm
content: Quote from: tggzzz on August 14, 2022, 06:59:49 pmHas been tried already:https://www.st.com/en/evaluation-tools/stm3220g-java.htmlObsolete but also seemed to be a costly solution to use.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 14, 2022, 10:37:52 pm
content: Quote from: tggzzz on August 14, 2022, 06:43:01 pmLike, my examples use relatively few ISRs, and short ones (with Reverb's DSP being the outstanding exception); there's only so many combinations in which they can be overlapped. (Also, my XMEGA+ projects, the PMIC/CPUINT prohibits self-interruption, so nesting a given ISR isn't even an option. I've done it on ATMEGA though.*) When you have small projects like these, it's quite feasible.When you don't have small projects, well, the complexity grows exponentially. It's ever harder to reason about, or test against, let alone organize, or control in any meaningful way!*Which was almost certainly a bad idea, but it was an early project (back in college!) so it's hard to say exactly how many bugs I wrote into it and where, and if the nested update interrupt was terminally unfixable, or just poorly implemented or guarded. I certainly wouldn't write it the same way today. Which, indeed, I didn't: the Reverb project's character-LCD menu system basically represents the buggiest part of that early project (the menu system), but written more-or-less properly.QuoteTo put this another way: if you can spare the extra response time (latency, propagation delay, etc.), you can trade priority CPU cycles for memory use. Compact your received/ready-to-transmit data into buffers (be it a global event queue, or per device/peripheral/interface), and deal with it at a more relaxed pace, in an order you can comfortably reason about. You can completely avoid interrupting one calculation partway through, and only need to concern yourself with the handoff from one event to the next; each event executes atomically, and the only shared state you need to think about is what's done after each one executes.There's some abstraction/formatting that's worth thinking about here too, probably. How do you queue an event -- what is an event? When it's simple stream data, like a USART, it's just a circular char buffer, offset and length, easy. But you could have things that are much less straightforward to describe; network packets, obviously, need to be buffered with arbitrary sizes, say with an array of offsets and lengths. Maybe it should be packed into a stream of enumerated commands (e.g. display lists). Or processed by OSI layers: maybe protocol-level character data (JSON? XML?) is parsed into objects, structures, pointers, etc., and those more abstract objects are passed to the application layer, and so on. And maybe you have buffers on each layer, allowing things like resolving out-of-order packets, or merging/splitting requests, etc..And, compare to the traditional JS VM: there's only ever one thread of execution*, and control is transferred to a received event after each function (or the global) finishes.*Except Workers, but those are a newer feature, hence, "traditional JS"...You can also figure out, if you don't have enough CPU cycles to handle things via scheduler, you almost certainly won't with them interrupting each other in (potentially) random orderplus calling overhead. And you have meaningful control over what happens when you do run out of CPU cycles: for example, you can always force a main() cycle every loop, using a round-robin scheduler say; and you can drop certain events by priority, or by limiting overflow of their buffers. Interrupts are mostly a free-for-all, and anyway, platforms usually provide just a few levels of priority, so you have no way to organize more, or make them based on conditions -- it's the same call every time, you'd have to go well out of your way to be able to make further interrupts contingent on available resources.Which isn't exactly intractable -- a common pattern in ISRs, is to finish up by preparing for the next cycle. For example, an ADC ISR advancing to the next MUX channel; or the next-next, even, if the next is already sequenced (i.e., we're processing sample N, and it's already acquiring sample N+1, so we need to set it up to acquire sample N+2). Well, we could add checks if resources will be available to handle it next time; and if not, e.g. disable the interrupt (dropping received data) if buffers are full, or if a higher-priority buffer is filling up and will need more CPU cycles committed to it, etc.. But then we also need something to re-enable the peripheral once resources are available again, and hopefully we don't have that spread across, you know, main(), and the scheduler, and a timer interrupt, and a half dozen other interrupts..... it can all get very messy very quickly, if you just try to wing it without an overarching structure to plan from.Tim

author: tggzzz
author_rank: Super Contributor
timestamp: August 14, 2022, 11:10:40 pm
content: Quote from: T3sl4co1l on August 14, 2022, 10:37:52 pmSmall is trivial. Great for beginners, but professionals have to deal with more.You can'ttestquality into adesign. Tests can only prove the prescence of faults, not their absence.I'm sure you are perfectly aware of that, but it horrifies me every time someone is surprised by that new (to them) concept.As I taught my daughter, "let's makenewmistakes", i.e. think about how X could have failed, and how to avoid that next time.QuoteThat consideration is often the key determinant of what is done in hardware, and what in software.QuoteYup. The "half-async half-sync" design pattern is a standard technique that is useful in many applications.QuoteGetting the right level/levels of abstraction is absolutely key to an understandable specification and design.Frequently it is useful to have multiple chained FSMs. In yout example, the first FSM would gather bits into a char, then generate a "char received" event. Another FSM would react to char received events, and gather them into a "packet recieved" event. Another FSM would react to "packet received" events, and generate maybe "high level" events.Some of those FSMs will be implemented in software, some in hardware; who cares: an FSM is an FSM.That's nothing novel; the entire telecom system is specified in that way, where the "highest" level events night be "call connected" "call disconnected" or "money run out" events.Some of the XML stream parsers (i.e not those that are DOM based) are based onexactlysuch event processing concepts.QuoteI've always run away from anything JavaScript based. I have zero interest in interactive web pages.QuoteIn my experience it is best to have only two levels of thread priority and/or interrupt priority: "normal" and "panic". You should be able to do anything with those, and if more are introduced then it is a sign the system needs radical refactoring before the technical debt becomes intractible.I will listen to other cases, but will ignore claims of "convenience" and demand to be convinced claims of "necessity".

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 15, 2022, 02:07:16 am
content: Quote from: tggzzz on August 14, 2022, 11:10:40 pmSure you can. That's what they said about semiconductors. The yield might've been shite early on (like the <1% of early JP transistor lines, or certain Intel lines, etc.), but all they needed was a few parts that worked, and refinements to gradually bring that up.Mind, this is a case where the design is essentially correct, there's just finitely many errors that occur in manufacturing (process impurities, dust, etc.), and they only need to get lucky enough to find one free of defects.Does that workin software?Maybe. But it's worth noting, if nothing else, the meaning behind that statement, and where it may or may not apply. It was applied erroneously to them, by those righteous hardware reliability types. We must always be cognizant of the limitations of our knowledge, like this.So, software. Well, fundamentally it's a design, not a production process. So, the above is out (and, to be clear, I'm not trying to force the above meaning into current context!).And, I know where you're coming from. To be clear: software design is something that -- given adequately comprehensive specifications -- we canprove, perfectlyto work. Not just "beyond a shadow of a doubt", not anything that could be tested (complete test coverage is combinatorial in complexity, it can't be done in general!), perfect proof.Assuming all the toolchain and stuff is working correctly, I mean, but a lot of work goes into those, along similar lines, when you're asking for something so reliable. Provable stacks exist, from transistor level to compiler.Now, I'm not quite sure if you're talking about formally proven systems here, or more informally, but it's good to know in any case that it's out there, and doable.AFAIK, provable computing is not very often used, even in high-rel circles, just because it's, I don't know, so much of a pain, so different from regular development processes?And most of the time, it doesn't matter: if the thing does what it needs to, most of the time, and is reasonably tolerant of nonstandard inputs (as fuzzing can cover -- whether formally, or by the crude efforts of testers), who cares, ship it. Some customers will eventually hit the edge cases, and maybe you patch those things up on an as-needed basis. Maybe the thing is still chock full of disastrous bugs (like RCE), but who's ever going to activate them? And what does it matter if it's not a life-support function, or connected to billions of other nodes (as where viruses can spread)?So, to be clear, it depends on the level of competency required. Provable computing is just another option in the toolbox.Clearly, you're approaching things from a high-rel standpoint. That's an important responsibility. But it's also not something that can be applied in general. At least, not with developers and toolchains where they are right now.And that's even assuming that every project was specified perfectly to begin with. Clients or managers come to engineers for solutions, not for mathematical proofs; it's up to the engineers to figure out if proofs are warranted, or if winging it will suffice. And for 99.9% of everything, the latter is true, and so things are.And, I also mention testing for a couple reasons:1. It's the most basic way to figure out how something works (or doesn't). It can be exceedingly inefficient (trivially, say, how do you test a 1000 year timer?), but to the extent anything can be learned by doing it, in any particular case -- that's at least some information rather than complete ignorance, or guesswork.2. There's "test driven development". Which, I don't even have any good ways to do, in most embedded projects; most of the tools I have, don't come with test suites, so I can't even run tests to confirm they work on my platform. And most embedded platforms have no meaningful way of confirming results, other than what I've put into them (e.g. debug port). In relatively few cases, I can write a function in C, and test it on the PC -- exhaustively if need be (a lazy, and often infeasible method, but when it is, it's no less effective than direct proof).TDD can be equivalent to proof, even without exhaustive testing, if all code paths can be interrogated and checked; granted, this is also, in general, not something you're often going to have (the code paths are invisible to the test harness, and highly nonlinear against the input, i.e. how the compiler decides to create branches may vary erratically with how the input is formulated or structured). Though, this hints at something which can: if we add flags into every code path, and fuzz until we find the extent of which inputs, given other inputs, activate those paths, we can attempt to solve for all of them -- and as a result, know how many we're yet missing.TDD I think is mainly a level-up in responsibility, where the project is persistent enough to not only be worth writing tests for, but to accumulate tests over time as bugs are found (write a test for it, to prevent it popping up in later refactoring!), while evolving new features -- extending an API while keeping it backwards-compatible, say. It's far more agile than drawing up a comprehensive provable spec every time, and it's reliable enough for commercial application. (So, it would figure that I haven't been exposed to it; I simply don't work on a scale where that's useful, besides the practicability issue.)(And maybe I'm overstating how much trouble it is to do provable computing, or something in the spirit of it, if not formal. I don't work with it either, and curious readers should read up on it instead.)And fuzzing, while it's still not going to be exhaustive; anywhere that we can ensure, or at least expect, linearity between ranges (i.e., a contiguous range of inputs does nothing different with respect to execution), we are at least very unlikely to need test coverage there. (Insert Pentium FDIV bug here.)Actually, heh, I wonder how that's affected by branch-free programming. One would want to include flags equivalent to program branches. So, it's not something that can be obviously discovered from the machine code, for example; the compiler may emit branchless style instructions instead of literally implementing a control statement. It might not even branch in the source, if similar [branch-free] techniques are used (like logical and bit operators, and bit or array vectorization tricks).QuoteAnd, it's no accident that it's reminiscent of (or explicitly referencing..) the OSI model, which came out of telecom (more or less?)!QuoteFor point of reference, for those more on the software or web dev side of things, you understand.QuoteAgreed.Tim

author: tggzzz
author_rank: Super Contributor
timestamp: August 15, 2022, 09:23:41 am
content: Quote from: T3sl4co1l on August 15, 2022, 02:07:16 amAnd as you realise, that testing is very different. Trying to use design validation/verification tests to detect replication errors is not fruitful!QuoteValidation vs verification is relevant at this point!QuoteI've always rather liked the strategy Boeing used with the 777. Hatley & Pirbhai's technique was to have one stack for the specifications using whichever techniques were suitable for the component of the design. It was almost executable (unlike the later UML kitchen sink). They also had an separateindependentstack for the implementation. The only part they thought worth automating was a database linking every specification artefact with a corresponding implementation artefact - which could be hardware/software/mechanical (or in the case of the 737 MAX, maybe wetware!). That ensured that nothing fell down the gaps between the floorboards.QuoteIt does seem to require specialists with domain knowledge and maths experience, which is usually an empty set!Back in the 80s I was beguiled by the promise of formal methods. They did have some success (IBM's CICS, Transputer's floating point), but then at least one unpleasant failure (RSRE's VIPER processor, where theyalmostmanaged to have formal traceability from instruction set specification to transistors).Then I realised that the even if formal methods could become practical, they would always run into the issue of interacting with things that aren't formally specified.QuoteHow systems work is usually easy and boring. It is much more interesting and important to understand how it fails, and how that failure is detected and corrected.I would be satisfied with people thatcan spot where salesmen are effectively claiming they've solved the Byzantine Generals or Dining Philosophers problemsensure there are manual correction mechanisms that can overcome inevitable automated failuresdon't seriously believe that a system is workingbecausenone of the unit tests has failedrealise that unit tests aren't going to be much with, say, ACID transactional propertiesEverybody has seen the first two; I've seen the last twoQuoteNot really w.r.t. "works" (doesn't work, yes)The nearest is using subtlefailures(especially in wetware) to give glimpses as to how things normally operate.QuoteIn theory, yes. In practice, not really. There is neither the time nor expertise to create decent tests that will detect flaws. At best there will be "happy days" (?daze?) unit tests, and idiotically trivial unit tests that give an appearance of code coverage.Whether or not the unit tests are sufficient to discover edge-case errors is rarely explored, since it is perceived as too expensive.QuoteTDD is a useful organisational tool to break atherosclerotic waterfall processes. Too often converts then have a pseudo-religious faith in TDD's powers, and think it is sufficient. It isn't, of course.TDD is highly beneficial, but neither necessary nor sufficient.QuoteHaving observed, from a distance, people paid to explore the possibilities - you're not overstating it.QuoteFuzzing, in any of its forms, is a useful extra tool in the armoury. Especially where it is able to spot cracks between organisational boundaries, or grossly naive programming presumptions.<snipped points of violent agreement>

author: uer166
author_rank: Super Contributor
timestamp: August 15, 2022, 05:37:49 pm
content: Quote from: tggzzz on August 14, 2022, 06:43:01 pmThe issue with this is you've erased most of the guarantees that a "true" co-op scheduler if you add an interrupt. Namely stuff like:No issues with data consistency. This means no physical way to get corrupt data due to non-atomicityFully deterministic execution: you can always say that at time T+<arbitrary ms>, you're executing task XWorst case analysis triviality given some constraintsEasy runtime checking of health, such as a baked-in task sequence check, deadline check, etc etcThe problem with true co-op of course is the massive headache that it causes when you try to implement complex stuff: everything needs to be synchronized to the tick rate, no task can take longer to execute than the tick rate, total ban on interrupts, etc. Lots of fast stuff needs to be delegated to pure hardware. A lot can be done in this architecture, but even stuff like life-saving UL991/UL1998 GFCI equipment doesn't need this kind of assurance. Maybe a jet turbine FADEC is a different situation of course..

author: uer166
author_rank: Super Contributor
timestamp: August 15, 2022, 05:50:31 pm
content: Quote from: TC on August 14, 2022, 01:14:10 pmYour code of course needs to be certified, but the toolsgenerallydon't need to be. It's perfectly fine to use a specific GCC release in 99.9% of cases, and stick with it. The exact same is true of the place/route tools for the CPLD: I bet you'd use the normal vendor tools to convert your VHDL into the CPLD config. Of course if you switch the GCC version + recompile, and the issued binary is different, you need to re-certify and get the notified bodies involved, but like, just don't change the code..QuoteIs it? Modern MCUs are more ASICs than MCUs. There is plenty of hardware in the MCU to do a guaranteed shutdown to end up in a regulatory-defined risk-averse state. I've done UL2231 GFCI systems for shock protection implemented almost 100% in STM32G4 firmware and internal periphery since there's really no way to do it in pure hardware anymore. It used to be just some opamps and comparators, but times are changing: the new requirements are much too tight and complex nowadays.

author: tggzzz
author_rank: Super Contributor
timestamp: August 15, 2022, 06:38:27 pm
content: Quote from: uer166 on August 15, 2022, 05:37:49 pmNone of those points is useful; they are all true in any embedded realtime system! (Exception: xCORE+xC systems with their (regrettably) unique architecture concepts and design-timeguarantees. See my other posts for those!)The point is to ensure the ISRs merely read the peripheral and atomically insert a message in a queue; that queue is atomically read by the cooperative scheduler whenever it chooses what to do next.Now I know you can't do such atomic actions is most C standards. In that case assembler is required, but that is eminently tractable since it executesonlyin a few well designated places.See my other posts about interrupt and task priorities; there should be two of each: normal and panic.

author: uer166
author_rank: Super Contributor
timestamp: August 15, 2022, 07:03:46 pm
content: Quote from: tggzzz on August 15, 2022, 06:38:27 pmHuh? How are they not useful if they can create aprovablycorrect realtime system; none of those points are true normally.. You don't get any of those points/guarantees in any run-of-the-mill embedded system. With time-triggered co-op you're getting true determinism at the expense of it being an absolute dog to design for and being generally inflexible/fragile, but that is a trade-off you might want to do in some contexts.Think about it: as you execute your code in a co-op scheduler, there can benothingthat can interrupt your instructions, change control flow, or modify any state. This reduces the overall state space of your system by many orders of magnitude. As soon as you have even one interrupt, your tasks can get interrupted at any point in control flow, and all those guarantees go out the window. TT co-op more-or-less erases a very large subset of hard to reproduce possible bugs, which means you don't need to mitigate them and deal with them in any way.Now is that something you'd do as a matter of course? Hell no, it's in a similar category to provably correct, fully statically analyzed systems: it's limiting, difficult, slow, sub-optimal in terms of resource use, and inflexible. P.s.: quit shilling for xCORE, I've read enough about it and it's uninteresting to me and probably to most people on these forums.

author: tggzzz
author_rank: Super Contributor
timestamp: August 15, 2022, 07:31:31 pm
content: Quote from: uer166 on August 15, 2022, 07:03:46 pmYou are going to have to explain how the techniques you mention can "create aprovablycorrect realtime system".Start by stating what you do and don't mean by "correct", then move on to outline what you do to assure correctness in that sense.Finally explain why limited duration ISRs plus queue for the events for the schedulerfundamentally preventsanything in your preferred technique. Assume ISRs capture i/o and atomically deposit events in the queue, but no more.You might not like the XMOS ecosystem. I don't like people ignoring/denying the problems with their preferred technique.

author: nctnico
author_rank: Super Contributor
timestamp: August 15, 2022, 07:42:17 pm
content: The answer is in 'view the interrupt controller as your OS scheduler'. On one hand you propose that hardware and software work in harmony (and part of the solution can be implemented in hardware) but on the other hand you propose a software only solution. In the end your OS scheduling comes from a (timer) interrupt as well so you can get rid of a lot of overhead by letting the hardware (= the interrupt controller and other peripherals) do the scheduling. Whether you do software scheduling or nested interrupts, the basic problem that needs to be solved stays the same because nested interrupts and parallel processes with different priorities are fundamentally the same from a functional point of view.In the end it all comes down to having X processing power to do Y work. The best solution depends entirely on the actual problem at hand as I have outlined in my earlier posting.

author: uer166
author_rank: Super Contributor
timestamp: August 15, 2022, 08:14:05 pm
content: Quote from: tggzzz on August 15, 2022, 07:31:31 pmYou're not UL or VDE or the FAA, so I don't need to explain anything to you, I was just giving an example of an alternate system that I know works well in special contexts. I'm not saying your interrupt queue way (or literallyanyway), cannot accomplish a specific task or be provably correct, that's a strawman.What I'm claiming is that a TT co-op scheduler makes it easy to prove system correctness at the general level. For example, in your proposed architecture youhaveto prove that your ISR deposits events atomically into a queue. In TT co-op you don't need to prove anything, it just does it by design with zero extra effort for any and all variable sizes and buffer lengths automatically, without mutexes or locks. Because you don't need mutexes/locks, you can't have priority inversion, you don't have to deal with deadlocks. Because you don't have interrupts, timing is fixed and task jitter has a tight upper bound, etc etc.. This argument is obviously a waste of server space so I'll shut up for now.

author: tggzzz
author_rank: Super Contributor
timestamp: August 15, 2022, 09:22:44 pm
content: Quote from: uer166 on August 15, 2022, 08:14:05 pmAnd that last sentence is itself a strawman. You claimed (in context that you chose to snip) that the techniques I noted will remove benefits you assert about some other techniques. I challengedyouto justify the benefitsyouasserted about "your" techniques - not about my techniques/assertions.I believe you are wise to deflect attention from your assertions such as...Quote from: uer166 on August 15, 2022, 07:03:46 pm"they" areQuote from: uer166 on August 15, 2022, 05:37:49 pmQuoteWow, there are a lot of false assumptions and assertions there! I'll point out some and ignore others..."In TT co-op you don't need to prove anything" - I think not. And adding ISRs+event queue to a TT co-op doesn't change the fundamental properties of a TT co-op."you don't have to deal with deadlocks" - I think not. You have to consider deadlocks and livelocks in the entire system."Because you don't have interrupts, timing is fixed and task jitter has a tight upper bound," - I think not, especially when you have toprovethe upper bound (i.e. not measure and hope you have spotted it by chance), doubly so with a modern processor.Your last statement is wise, however.

author: tggzzz
author_rank: Super Contributor
timestamp: August 15, 2022, 09:32:03 pm
content: Quote from: nctnico on August 15, 2022, 07:42:17 pmMy world view was unpleasantly (and probably unjustifiably) shaped by the first interrupt controller I designed into a system. When I got the first device in my hand I noticed it was "Rev G", which in retrospect should have been a big red flag. It never worked to specI've always thought ny brain is too small to "reason" about the horrible graublychanging detailsof a system built around multiple interrrupt priorities and task priorities. IMNSHO in single purpose dedicated embedded systems there should only be "normal" and "panic" priorities. (That doesn't apply to desktop/general purpose desktop/computation systems.)