Author Topic: techniques for writing non blocking code  (Read 17598 times)

0 Members and 1 Guest are viewing this topic.

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10690
  • Country: gb
    • Having fun doing more, with less
Re: techniques for writing non blocking code
« Reply #125 on: August 07, 2017, 09:51:52 pm »
Quote
PIC16 doesn't have nested interrupts. Theoretically, you can do it in software, but it is so inefficient that it certainly isn't worth it.
If some of your ISR are very long,...

If your ISRs are very long, then you are "Doing Something Very Wrong"TM.

An ISR should
  • determine the source of the interrupt
  • gather neccessary context
  • create an Event containing the necessary context
  • submit that Event for consumption and processing by a background task/thread/process, probably via a FIFO or mailbox
  • and exit the ISR A.S.A.P.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 
The following users thanked this post: JPortici

Online KL27x

  • Super Contributor
  • ***
  • Posts: 3807
  • Country: us
Re: techniques for writing non blocking code
« Reply #126 on: August 07, 2017, 10:20:24 pm »
Tggzzz. Let me guess. Are you by any chance a senior level engineer who manages a bunch of immigrant programmers who write all the code, and you spend 90% of your time learning ways to make them feel inferior and otherwise boosting your perceived value to the guy writing the checks? I'm not gonna say this isn't an important job. My GF is incredibly productive. She gets more done in a day than I do in a month. But her primary mode of getting things done is to pick up the phone and convince other people into doing things.

There are many instances where you might want to do things in the ISR. One of the main purposes, for example, for one of my project is to get 2 ADC reads from single randomly triggered signals but which must happen in a small microsecond window. In this case, it is easier to put the ADC acquisition time in the ISR and has no significant detriment to the rest of the code. Yes, I could have done ADC acquisition delay as a timer interrupt. But this was not a necessary complication. I could have even dedicated a micro just to get these reads and have the master request this data at its leisure. But it was not necessary.

As I said this is unusual situation where you might want to do this. If all your ISR is super short, then priority doesn't matter anyway, does it? They all get done in plenty of time, since they only take a few instructions cycles to complete.

Microcontrollers are not necessarily needing to calculate ballistic trajectory in nanoseconds with floating point math. And for someone so concerned with bugs, you seem to miss the forest for the trees.

If you want to treat your coders as disposable, then yes. It is better for them to follow your mandate to the letter, despite all the other problems and inefficiencies it may cause. You can dictate what hardware and ide they must use and how to write the code to the letter. This way you can fire them and plug in another brown/yellow engineer and continue with your bug ridden, bloated, overbudget project (sometimes this ends up the best or only solution, for complexity and/or security reason,  but as engineers we don't have to LIKE it; and I bet a heck of a lot of the visitors/participants on this forum are doing one man projects as the norm). But if you have coder you can depend on to do the project start to finish and support/maintenance, following strict mandate with no room for change may not be the best way to go. Believe it or not, he may have a better way to get it done. Sometimes exceptions to the rule can have more pros than cons.
« Last Edit: August 08, 2017, 01:20:46 am by KL27x »
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 950
  • Country: us
    • Embedded Tales Blog
Re: techniques for writing non blocking code
« Reply #127 on: August 07, 2017, 11:10:43 pm »
What the hell is "programming ecosystem"?

It's just another of those hipster terms like code smells, refactoring, and technical debt. Why use simple language when you can embellish it and make it sound grandiose?
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 950
  • Country: us
    • Embedded Tales Blog
Re: techniques for writing non blocking code
« Reply #128 on: August 07, 2017, 11:22:45 pm »
Context switches with hard floating point can get pretty expensive because the floating point registers have to be saved/restored too.

The Cortex-M4 and M7 have a feature called lazy stacking. If the outgoing task didn't use the FPU (as indicated by a bit in the link register), the context switch code doesn't need to save the floating point registers.
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: techniques for writing non blocking code
« Reply #129 on: August 08, 2017, 12:25:19 am »
The Cortex-M4 and M7 have a feature called lazy stacking. If the outgoing task didn't use the FPU (as indicated by a bit in the link register), the context switch code doesn't need to save the floating point registers.

 :-+

I think it still adjusts the stack pointer as if they were saved, right?
 

Online Sal Ammoniac

  • Frequent Contributor
  • **
  • Posts: 950
  • Country: us
    • Embedded Tales Blog
Re: techniques for writing non blocking code
« Reply #130 on: August 08, 2017, 12:31:47 am »
The Cortex-M4 and M7 have a feature called lazy stacking. If the outgoing task didn't use the FPU (as indicated by a bit in the link register), the context switch code doesn't need to save the floating point registers.

 :-+

I think it still adjusts the stack pointer as if they were saved, right?

Yes. It reserves space on the stack whether it saves anything or not.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10690
  • Country: gb
    • Having fun doing more, with less
Re: techniques for writing non blocking code
« Reply #131 on: August 08, 2017, 06:30:37 am »
Tggzzz. Let me guess. Are you by any chance a senior level engineer who manages a bunch of immigrant programmers who write all the code, and you spend 90% of your time learning ways to make them feel inferior and otherwise boosting your perceived value to the guy writing the checks?

Nope, completely and 100% off-beam; a fantasy.

In my mid-20s in a contract r&D house I tested whether or not I was interested in technical management and business. I decided I wasn't, and studiously avoided climbing that ladder. Instead I spent the largest part of my career doing hardcore engineering in the R&d part of a large company, surrounded by extremely competent engineers distributed across the world.

I saw one (new) employee attempt to boost our self respect by claiming we were better than other parts of the company; that was exquisitely embarrassing and they were shown the door very quickly.

Quote
There are many instances where you might want to do things in the ISR. One of the main purposes, for example, for one of my project is to get 2 ADC reads from single randomly triggered signals but which must happen in a small microsecond window. In this case, it is easier to put the ADC acquisition time in the ISR and has no significant detriment to the rest of the code. Yes, I could have done ADC acquisition delay as a timer interrupt. But this was not a necessary complication. I could have even dedicated a micro just to get these reads and have the master request this data at its leisure. But it was not necessary.

Well, that isn't a long time, and the ADC readings are the necessary context, so I don't see any relevance to what I wrote.

For the avoidance of doubt, the context you decided to snip was that you wrote "If some of your ISR are very long,...". My statements were in that context, and they stand.

Quote
As I said this is unusual situation where you might want to do this. If all your ISR is super short, then priority doesn't matter anyway, does it? They all get done in plenty of time, since they only take a few instructions cycles to complete.

It wouldn't matter how long/short it was if the system jammed due to priority inversion - in which case priority would definitely matter.

Quote
If you want to treat your coders as disposable, then yes. It is better for them to follow your mandate to the letter, despite all the other problems and inefficiencies it may cause. You can dictate what hardware and ide they must use and how to write the code to the letter. This way you can fire them and plug in another brown/yellow engineer and continue with your bug ridden, bloated, overbudget project (sometimes this ends up the best or only solution, for complexity and/or security reason,  but as engineers we don't have to LIKE it; and I bet a heck of a lot of the visitors/participants on this forum are doing one man projects as the norm). But if you have coder you can depend on to do the project start to finish and support/maintenance, following strict mandate with no room for change may not be the best way to go. Believe it or not, he may have a better way to get it done. Sometimes exceptions to the rule can have more pros than cons.

That's an irrelevant strawman rant.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online KL27x

  • Super Contributor
  • ***
  • Posts: 3807
  • Country: us
Re: techniques for writing non blocking code
« Reply #132 on: August 08, 2017, 08:33:35 am »
Quote
Well, that isn't a long time, and the ADC readings are the necessary context, so I don't see any relevance to what I wrote.
Quote
For the avoidance of doubt, the context you decided to snip was that you wrote "If some of your ISR are very long,...". My statements were in that context, and they stand.
"Very long" is relative. If it's long enough that you may want to prioritize other interrupt, then it is "very long." If I'm burning potentially a hundred instruction cycles just waiting for ADC cap to stabilize after switching the pin MUX, that might be considered long. We were just discussing how micro X has 125nS latency by virtue of saving registers by hardware, were we not? And by virtue of you recognizing that this "isn't very long" but that I consider it as potentially being "very long," why you feel need to lecture me by saying I AM DOING SOMETHING VERY WRONG!? But for sake of argument, who cares if ISR takes even 5 minutes, if it serves the purpose?

My point was that while waiting for cap to stabilize, I could potentially do software prioritization of higher interrupt by polling (or I could divide the ADC ISR into 2 and finish it with a timer interrupt). This was reply to preceeding post about how software prioritization of ISR is difficult. I contend that it can be very easy, given certain conditions, namely lack of memory conflict. At least it is very easy in assembly. ISR organization/flow/prioritization seems to be one place where assembly can be easier. I find it very hard to understand how ISR is organized in C, not that I'm very good with the language.

Quote
It wouldn't matter how long/short it was if the system jammed due to priority inversion - in which case priority would definitely matter.

If priority inversion causes bug (for example someone brought up the Mar's Rover, where the bug was, IIUC, that a lower priority interrupt never finished if it was interrupted), then presumably some of the interrupts ARE relatively long. Prioritizing interrupts obviously takes some extra code and memory and uses up stack and creates potential for RARELY SEEN BUG.* In the Mars Rover case, who knows how bad the screwup was? It could have been complete and utter laziness. Giving it a fancy name doesn't mean it wasn't necessarily a grievously stupid oversight. Maybe device's hardware interrupt priority failed. Maybe compiler had error. Or maybe some dumbass did software prioritization and forget that he was pusing the stack. And if ISRs are all very short, you can just NOT do it.

Quote
That's an irrelevant strawman rant.
What I should have meant was a metaphorical "you." Or "one." I got carried away, and I apologize, Tggzzzz, because I see why you would have taken that personally.

*This seems to be one of your many issues with interrupts. But I don't understand why this can't be tested. You can create this condition on demand with testing setup. Sure, it takes some work, but what doesn't?
« Last Edit: August 08, 2017, 09:41:02 am by KL27x »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18543
  • Country: nl
    • NCT Developments
Re: techniques for writing non blocking code
« Reply #133 on: August 08, 2017, 08:41:15 am »
Quote
PIC16 doesn't have nested interrupts. Theoretically, you can do it in software, but it is so inefficient that it certainly isn't worth it.
If some of your ISR are very long,...

If your ISRs are very long, then you are "Doing Something Very Wrong"TM.

An ISR should
  • determine the source of the interrupt
  • gather neccessary context
  • create an Event containing the necessary context
  • submit that Event for consumption and processing by a background task/thread/process, probably via a FIFO or mailbox
  • and exit the ISR A.S.A.P.
Utter nonsense! There are two reasons for this: shuffling data around in events & buffers means extra overhead and it puts unnecessary timing requirements on the rest of the software which complicates things a lot (*). It really is much better to process everything inside an interrupt and use nested interrupts to perform higher priority tasks if necessary. You need to look at an interrupt controller as an OS time slicer in hardware. This keeps things simple because the time critical stuff stays in a small area.

Ofcourse all bets are off if you need to handle bursts of data but even then it may be better to use a timer interrupt for processing chunks of data at regular intervals so the timing requirements don't not leak into a slow (housekeeping) main loop.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: techniques for writing non blocking code
« Reply #134 on: August 08, 2017, 09:13:16 am »
they were shown the door very quickly

I frankly appreciate a lot when you talk, your English sounds so elegant that I find it a pleasure to read, but I also appreciate the concept you expose since I work in avionics and we have a lot of problems in common.

I like it, because usually people in avionics don't like to talk for free, courses and the business of giving expert advice to other professionals, typically in financial and business matters, all of these things cost a lot of money as well a full training costs a lot of time.

Something like K euro. May be your boss pay it for you, may be not, may be you are a person who works freelance, thus it's all on your wallet *IF* your can invest money on it.

Someone here simply assumes that he/she can access everything everytime everywhere for free. Like when he/she clones a git repository in a couple of seconds. That's the problem of "opensource" which always introduce a distorted prospect of the reality, because of course, these kind of people believe they can access concept online, thus they have no respect when someone has the intention to talk.

The problem of modern computer science is also that even a nogooder can access internet and claim that he/she can programs something. It should be proved, in first place. I see Km of fsking garbage online.

But who cares? I am not interested to have the proof of expert skill and knowledge in a particular field from people in the topic, not interested in showing any supremacy about who is allowed to talk, and who should shut the fsking, but!

But I can't ignore that someone here comes from a more relaxed area, like Home automation, where you have light constraints and requirements to be respected in your code and you are 100% guaranteed that nobody will ever die even if you write poor quality code: never thought that these kind of people have ever felt the forum talk on mission critical field as the quality of being arrogantly superior and disdainful against them.

Thus, let me summarize: you spend your coffee-break time contributing on things that usually kept in-doors, therefore cost money on courses and consulting, and  people believe that it's a manifest of your arrogantly superior.

Does it make sense? For me, they can have shown the door very quickly.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10690
  • Country: gb
    • Having fun doing more, with less
Re: techniques for writing non blocking code
« Reply #135 on: August 08, 2017, 09:21:59 am »
Quote
It wouldn't matter how long/short it was if the system jammed due to priority inversion - in which case priority would definitely matter.

If priority inversion causes bug (for example someone brought up the Mar's Rover, where the bug was, IIUC, that a lower priority interrupt never finished if it was interrupted), then presumably some of the interrupts ARE relatively long. Prioritizing interrupts obviously takes some extra code and memory and uses up stack and creates potential for RARELY SEEN BUG.* In the Mars Rover case, who knows how bad the screwup was? It could have been complete and utter laziness. Giving it a fancy name doesn't mean it wasn't necessarily a grievously stupid oversight. And if ISRs are all very short, you can just NOT do it.

Clearly you don't understand what priority inversion is, its causes, and its cures.

Quote
Quote
That's an irrelevant strawman rant.
What I should have meant was a metaphorical "you." Or "one." I got carried away, and I apologize, Tggzzzz.

No problem; I didn't take it personally :)

Quote
*This seems to be one of your many issues with interrupts. But I don't understand why this can't be tested. You can create this on demand with testing setup. Sure, it takes some work, but what doesn't?

It isn't my issue with interrupts; it is a well-recognised problematic characteristic.

You shouldn't feel bad that "...I don't understand why this can't be tested" - nobody understands how to adequately test that! Actually it is worse - people understand why you cannot do such tests.

Testing cannot be done for several reasons:
  • the designer has to recognise the possibility of a problem - and when they've done that they normally take well-understood steps to reliably avoid the problem by design (usually capture the context, turn it into an event, deliver event to FSM for processing)
  • combinatorial explosion associated with asynchronous events. Exactly the same happens in hardware where, with skill it is just about possible to design circuits that will work with two asynchronous inputs that can change at any time w.r.t. each other. That is known to be impractical (impossible?) with three mutually asynchronous inputs!
  • tests and their test harnesses have to be repeatable. That means they are synchronous. Obviously interrupts are asynchronous and unpredictable (except timer ticks)
  • not being able to predict which program/hardware state is a precondition for a problem. (And if you predict a possible problem, you would be an idiot not to design-out the possibility!)
  • inaccessibility of internal program/hardware state, so even if you predict a problem it can't be used to trigger an interrupt
  • testing doesn't demonstrate correctness; at best it demonstrates the absence of one specific problem
  • and, of course, you can't test quality into a product

You have to adopt implementation strategies that avoid typical common problems in the first place.
« Last Edit: August 08, 2017, 09:27:04 am by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10690
  • Country: gb
    • Having fun doing more, with less
Re: techniques for writing non blocking code
« Reply #136 on: August 08, 2017, 09:41:43 am »
they were shown the door very quickly
I frankly appreciate a lot when you talk, your English sounds so elegant that I find it a pleasure to read, but I also appreciate the concept you expose since I work in avionics and we have a lot of problems in common.

Thanks; I try :) I also try to spot weaknesses in what I've done and to figure out how I would avoid them in practice.

Quote
Someone here simply assumes that he/she can access everything everytime everywhere for free. Like when he/she clones a git repository in a couple of seconds. That's the problem of "opensource" which always introduce a distorted prospect of the reality, because of course, these kind of people believe they can access concept online, thus they have no respect when someone has the intention to talk.

The problem of modern computer science is also that even a nogooder can access internet and claim that he/she can programs something. It should be proved, in first place. I see Km of fsking garbage online.

Yes and yes. Some people should be physically prevented from touching a keyboard or soldering iron!

Quote
But I can't ignore that someone here comes from a more relaxed area, like Home automation, where you have light constraints and requirements to be respected in your code and you are 100% guaranteed that nobody will ever die even if you write poor quality code: never thought that these kind of people have ever felt the forum talk on mission critical field as the quality of being arrogantly superior and disdainful against them.

Even home automation isn't as simple and safe as people seem to imagine.
Consider remotely turning a fridge off for a day, then turning it back on. The food might have become dangerous, which isn't too bad if it is obviously dangerous.
Consider remotely starting the heating and setting the thermostat to maximum; pets might get heatstroke.
Consider remotely turning off heating and setting the thermostat to minimum; water pipes freeze, then burst, and the water causes electrical fires.
Consider publishing the electricity consumption, so that a burglar can predict when the house is occupied.
Consider using a webcam to remotely spy on the inhabitants.
Consider suboptimal security, so that a device is pwned and becomes an attack vector for other devices in the home.

Note that some of those aren't only theoretical; they have been seen in the wild.

Quote
Thus, let me summarize: you spend your coffee-break time contributing on things that usually kept in-doors, therefore cost money on courses and consulting, and  people believe that it's a manifest of your arrogantly superior.

Does it make sense? For me, they can have shown the door very quickly.

I'm probably retired, so I have more than a coffee break!

I also like helping youngsters improve and make new mistakes. OTOH, I hate unnecessarily repeating old mistakes.

I've also seen many problems (and created a few myself :( ), and so I'm often a step ahead of those with less experience. Been there, done that, got the T-shirt.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 1803
  • Country: fi
  • Embedded SW/HW.
Re: techniques for writing non blocking code
« Reply #137 on: August 08, 2017, 09:54:44 am »
Nested interrupts are quite handy if you want to make "long interrupt handlers" and your system tolerates nested interrupts (ie. interrupts may be interrupted). The main program context will be run at the main() context. There may be some interrupt-driven activity like ADC-reading which may contain some delays, thus creating "long interrupt handler". At a higher interrupt priority level there may be a timer tick which may perform some periodic activity above all other processes/tasks. It is just a matter of systems engineering and architecture design how you implement the system. There is no single right way of doing things, although there are numerous ways of doing things wrong.
 

Online KL27x

  • Super Contributor
  • ***
  • Posts: 3807
  • Country: us
Re: techniques for writing non blocking code
« Reply #138 on: August 08, 2017, 10:10:38 am »
Edited:

Tggzzz, I am sorry I brought up Mars Rover and priority inversion, but feel free to continue the lecture. All I was initially discussing were the use of interrupts in an 8 bit PIC.

You suggest that my consideration for length of ISR is evidence I don't know what I'm even talking about. You state flatly that the length of ISR must be short. But even if it is short or long, it doesn't matter when considering whether or not and/or how you prioritize them (thru hardware or software). But I don't see your reasoning.

The way I see it:
If ISR are all relatively short, you would NOT HAVE TO PRIORITIZE or NEST the INTERRUPTS to begin with. They will all get done sequentially, and none will have to be interrupted, themselves. If one is relatively long, you might consider interrupting it with a technically lower importance interrupt which is both very brief and which can't repeat within timeframe of the longer one. I don't know why you bring FSM and event driven code and RTOS into it in the first place. I wasn't part of that discussion, but it seems impossible to avoid when you are in the thread. You see things only thru lens of event driven code and xCORE. I wish I would learn something useful when you "correct me." It almost seems possible.
« Last Edit: August 08, 2017, 11:35:47 pm by KL27x »
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: techniques for writing non blocking code
« Reply #139 on: August 08, 2017, 10:15:51 am »
Nested interrupts are quite handy

In avionics, we are usually not allowed to use nested interrupts. In this moment I am writing the final report (hopefully the last one before vacation), and I have to spend time on a specific set of test cases whose meaning is: assuring that the firmware inside the fly-board doesn't use nested-interrupt since it's a low-level requisite committed by the final user.

It's easy, you have to show a few points in the source code, but mind the point: they don't want nested interrupts used, and they are paying guys to check it.

Funny, ain't it :D ?

(it's my turn, because other people is already on vacation)
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 1803
  • Country: fi
  • Embedded SW/HW.
Re: techniques for writing non blocking code
« Reply #140 on: August 08, 2017, 10:34:51 am »
Nested interrupts are quite handy

In avionics, we are usually not allowed to use nested interrupts. In this moment I am writing the final report (hopefully the last one before vacation), and I have to spend time on a specific set of test cases whose meaning is: assuring that the firmware inside the fly-board doesn't use nested-interrupt since it's a low-level requisite committed by the final user.

It is all about systems requirements. Using nested interrupts may or may not be suitable/allowed. Using interrupts may or may not be suitable/allowed. It all depends on the requirements.
 

Offline Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9386
  • Country: my
  • reassessing directives...
Re: techniques for writing non blocking code
« Reply #141 on: August 08, 2017, 12:01:44 pm »
Nested interrupts are quite handy
In avionics, we are usually not allowed to use nested interrupts.
here, in not avionics, we are allowed.

if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Online KL27x

  • Super Contributor
  • ***
  • Posts: 3807
  • Country: us
Re: techniques for writing non blocking code
« Reply #142 on: August 08, 2017, 12:58:23 pm »
When something has to explicitly disallowed, it is usually useful. If they do it in a 4mph rc moon car, it must be good.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18543
  • Country: nl
    • NCT Developments
Re: techniques for writing non blocking code
« Reply #143 on: August 08, 2017, 01:08:39 pm »
When something has to explicitly disallowed, it is usually useful.
Usually it is to prevent rookie mistakes but look how the MISRA rules have evolved over the past decades.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online KL27x

  • Super Contributor
  • ***
  • Posts: 3807
  • Country: us
Re: techniques for writing non blocking code
« Reply #144 on: August 08, 2017, 11:50:15 pm »
I have been motivated to go back and read some of the previous posts. Namely because certain person has annoyed me.

Quote
Quote
If you have only one CPU, it is absolutely impossible for these two tasks to run at the same time. What you can do about this? You can run task A. This increases the latency of task B, and it is no longer equal to interrupt latency, but is equal  to (interrupt latency + time to do the minimum processing for task A). Or, you can run task B, then the latency of task A will not be zero any longer, but will be equal to the time necessary to do some minimum processing for task B. If neither of these meets your timing requirements, nothing you can do. This is interference caused by multitasking. A can be served alone, B can be served alone, but A and B together cannot.




Not necessarily: providing constraints are met, interference can be absent. Meeting constraints can be aided/prevented by appropriate hardware+software mechanisms.
How in the world do you refute this with "not necessarily." NorthGuy has stated a concrete scenario. Single processor. Two external inputs requiring immediate action. Nowhere do I see NorthGuy state that either event can be logged as future event to be processed later.

Adding to that, perhaps some explanation of how xCORE responds to 8 external random events at a time within 100nS, without having any interrupts, can be offered.
Quote
The XS1 architecture is event-driven. It has an instruction that can dispatch an external events in addition to traditional interrupts. If the program chooses to use events, then the underlying processor has to expect an event and wait in a specific place so that it can be handled synchronously. If desired, I/O can be handled asynchronously using interrupts. Events and interrupts can be used on any resource that the implementation supports.
Unless you dedicate a core to do nothing but poll for each input, you would have to use interrupts. Unless you can explain how it is possible plan events around an event which is random. So technically, yes, you can dedicate an entire cpu to something to remove need for an interrupt. I get that there's a benefit to this setup due to communication between cored and shared memory (also many drawbacks). But you can't have your cake and eat it, too.

« Last Edit: August 09, 2017, 12:11:06 am by KL27x »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18543
  • Country: nl
    • NCT Developments
Re: techniques for writing non blocking code
« Reply #145 on: August 09, 2017, 06:53:28 am »
The bottom line is: one processor can deal with one instruction at a time so you can't handle two (or more) interrupts (with equal priority) at exactly the same time. But this is turning into a semantic discussion anyway.
At the system design stage I make an analysis of the processor power required and latency requirements. Based on that I select the appropriate hardware and decide on what priorities each task gets. At this point I have not written a single line of code or created a new schematic for the final product.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9386
  • Country: my
  • reassessing directives...
Re: techniques for writing non blocking code
« Reply #146 on: August 09, 2017, 08:01:25 am »
Based on that I select the appropriate hardware and decide on what priorities each task gets.
there are broad engineering and economic requirements that results in a very different hardware choices. in the narrow band highly safety priority of avionics there probably not much to choose, so they avionics people are locked to the very narrow band of techniques set. even in the mechanical aspects of avionics will entirely not be applicable to automotive industry, this will result in a car that 10-100X more expensive than they already are. so people from other industries need to be aware of this economical vs engineering facts.
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline MT

  • Super Contributor
  • ***
  • Posts: 1275
  • Country: cn
Re: techniques for writing non blocking code
« Reply #147 on: August 09, 2017, 01:22:31 pm »
Anyhow i sometimes try to use DMA sequences to offload blocking situations, i wish ST could
have made their DMA engine abit clever by implementing some sort of a tiny programmable
sequenciator as to behave more like a very simple coprocessor.
« Last Edit: August 09, 2017, 01:56:22 pm by MT »
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: techniques for writing non blocking code
« Reply #148 on: August 09, 2017, 04:41:53 pm »
Anyhow i sometimes try to use DMA sequences to offload blocking situations, i wish ST could
have made their DMA engine abit clever by implementing some sort of a tiny programmable
sequenciator as to behave more like a very simple coprocessor.

You can do some tricky stuff with STM32 DMA when it's controlled by timers. The bigger timers can generate half a dozen different events that you can plumb into different DMA streams. Use one of those streams to reprogram the timer itself along the way for complex (and difficult to maintain) behavior.
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 10471
  • Country: us
  • DavidH
Re: techniques for writing non blocking code
« Reply #149 on: August 09, 2017, 05:46:51 pm »
Anyhow i sometimes try to use DMA sequences to offload blocking situations, i wish ST could
have made their DMA engine abit clever by implementing some sort of a tiny programmable
sequenciator as to behave more like a very simple coprocessor.

I was very impressed with TI's solution which is available on the BeagleBone boards:

http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf