Indeed interrupts are necessary for those who want them, and will be a leverage on the P2, especially when doing signal acquisition. The lack of interrupts on the P1 was something that I didn't get used to. For example, one could do a frequency meter if P1 had interrupts, using a counter and using an external RTC for the interrupts.
The problem with interrupts is: it breaks thinking. Ones used to be interrupted, simple solutions no longer are obvious. Set up a counter, read the counter and the system timer now and then, determine number of counts and number of clock and there relation is the frequency. Resume thinking.
The problem with interrupts is: it breaks thinking. Ones used to be interrupted, simple solutions no longer are obvious. Set up a counter, read the counter and the system timer now and then, determine number of counts and number of clock and there relation is the frequency. Resume thinking.
I agree that interrupts as implemented in most microcontrollers and microprocessors are relatively complex and can break the chain of thought when writing code. Unless the P2 interrupt scheme has changed drastically from the initial design without me noticing this is not the case for the propeller. What it amounts to is having two programs in the cog, an "interrupt" program that runs as a result of the interrupt and returns to the "main" program that runs the rest of the time.
This is relatively simple to code for yet is a very powerful option for many purposes. In the case of your frequency measurement it would simplify and speed up the code since a polling loop or waitcnt is not required.
The problem with interrupts is: it breaks thinking. Ones used to be interrupted, simple solutions no longer are obvious. Set up a counter, read the counter and the system timer now and then, determine number of counts and number of clock and there relation is the frequency. Resume thinking.
I agree that interrupts as implemented in most microcontrollers and microprocessors are relatively complex and can break the chain of thought when writing code. Unless the P2 interrupt scheme has changed drastically from the initial design without me noticing this is not the case for the propeller. What it amounts to is having two programs in the cog, an "interrupt" program that runs as a result of the interrupt and returns to the "main" program that runs the rest of the time.
This is relatively simple to code for yet is a very powerful option for many purposes. In the case of your frequency measurement it would simplify and speed up the code since a polling loop or waitcnt is not required.
How is the P2 method for interrupts any easier to use than interrupts for other processors. It seems to me that the mechanisms are basically the same. What sets the P2 apart is that interrupts are local to a COG so you can have some other COG doing time-critical processing without worrying that it will be interrupted.
The problem with interrupts is: it breaks thinking. Ones used to be interrupted, simple solutions no longer are obvious. Set up a counter, read the counter and the system timer now and then, determine number of counts and number of clock and there relation is the frequency. Resume thinking.
I agree that interrupts as implemented in most microcontrollers and microprocessors are relatively complex and can break the chain of thought when writing code. Unless the P2 interrupt scheme has changed drastically from the initial design without me noticing this is not the case for the propeller. What it amounts to is having two programs in the cog, an "interrupt" program that runs as a result of the interrupt and returns to the "main" program that runs the rest of the time.
This is relatively simple to code for yet is a very powerful option for many purposes. In the case of your frequency measurement it would simplify and speed up the code since a polling loop or waitcnt is not required.
How is the P2 method for interrupts any easier to use than interrupts for other processors. It seems to me that the mechanisms are basically the same. What sets the P2 apart is that interrupts are local to a COG so you can have some other COG doing time-critical processing without worrying that it will be interrupted.
Only one interrupt source can be active at any time, which is much easier to deal with than multiple prioritized interrupt sources. Having a simple interrupt allows a cog to run both a time critical task and a non time critical task. That would not be possible for a task that requires an infrequent low latency response.
The problem with interrupts is: it breaks thinking. Ones used to be interrupted, simple solutions no longer are obvious. Set up a counter, read the counter and the system timer now and then, determine number of counts and number of clock and there relation is the frequency. Resume thinking.
I agree that interrupts as implemented in most microcontrollers and microprocessors are relatively complex and can break the chain of thought when writing code. Unless the P2 interrupt scheme has changed drastically from the initial design without me noticing this is not the case for the propeller. What it amounts to is having two programs in the cog, an "interrupt" program that runs as a result of the interrupt and returns to the "main" program that runs the rest of the time.
This is relatively simple to code for yet is a very powerful option for many purposes. In the case of your frequency measurement it would simplify and speed up the code since a polling loop or waitcnt is not required.
How is the P2 method for interrupts any easier to use than interrupts for other processors. It seems to me that the mechanisms are basically the same. What sets the P2 apart is that interrupts are local to a COG so you can have some other COG doing time-critical processing without worrying that it will be interrupted.
Only one interrupt source can be active at any time, which is much easier to deal with than multiple prioritized interrupt sources. Having a simple interrupt allows a cog to run both a time critical task and a non time critical task. That would not be possible for a task that requires an infrequent low latency response.
Ah, I didn't know that. I thought there could be multiple sources active and that interrupts had priorities. Thanks for clarifying.
Edit: I don't think what you're saying is correct. Here is what the current doc says:
Each cog has three interrupts: INT1, INT2, and INT3.
INT1 has the highest priority and can interrupt INT2 and INT3.
INT2 has the middle priority and can interrupt INT3.
INT3 has the lowest priority and can only interrupt non-interrupt code.
The problem with interrupts is: it breaks thinking. Ones used to be interrupted, simple solutions no longer are obvious. Set up a counter, read the counter and the system timer now and then, determine number of counts and number of clock and there relation is the frequency. Resume thinking.
I agree that interrupts as implemented in most microcontrollers and microprocessors are relatively complex and can break the
chain of thought when writing code. Unless the P2 interrupt scheme has changed drastically from the initial design without me noticing this is not the case for the propeller. What it amounts to is having two programs in the cog, an "interrupt" program that runs as a result of the interrupt and returns to the "main" program that runs the rest of the time.
This is relatively simple to code for yet is a very powerful option for many purposes. In the case of your frequency measurement it would simplify and speed up the code since a polling loop or waitcnt is not required.
How is the P2 method for interrupts any easier to use than interrupts for other processors. It seems to me that the mechanisms are basically the same. What sets the P2 apart is that interrupts are local to a COG so you can have some other COG doing time-critical processing without worrying that it will be interrupted.
Only one interrupt source can be active at any time, which is much easier to deal with than multiple prioritized interrupt sources. Having a simple interrupt allows a cog to run both a time critical task and a non time critical task. That would not be possible for a task that requires an infrequent low latency response.
Ah, I didn't know that. I thought there could be multiple sources active and that interrupts had priorities. Thanks for clarifying.
Edit: I don't think what you're saying is correct. Here is what the current doc says:
Each cog has three interrupts: INT1, INT2, and INT3.
INT1 has the highest priority and can interrupt INT2 and INT3.
INT2 has the middle priority and can interrupt INT3.
INT3 has the lowest priority and can only interrupt non-interrupt code.
Oh oh, you are right then, it has changed. That does make it potentially a bit more complicated, however one only has to use the interrupts they need, so the simple single interrupt case is still possible.
The problem with interrupts is: it breaks thinking. Ones used to be interrupted, simple solutions no longer are obvious. Set up a counter, read the counter and the system timer now and then, determine number of counts and number of clock and there relation is the frequency. Resume thinking.
I agree that interrupts as implemented in most microcontrollers and microprocessors are relatively complex and can break the
chain of thought when writing code. Unless the P2 interrupt scheme has changed drastically from the initial design without me noticing this is not the case for the propeller. What it amounts to is having two programs in the cog, an "interrupt" program that runs as a result of the interrupt and returns to the "main" program that runs the rest of the time.
This is relatively simple to code for yet is a very powerful option for many purposes. In the case of your frequency measurement it would simplify and speed up the code since a polling loop or waitcnt is not required.
How is the P2 method for interrupts any easier to use than interrupts for other processors. It seems to me that the mechanisms are basically the same. What sets the P2 apart is that interrupts are local to a COG so you can have some other COG doing time-critical processing without worrying that it will be interrupted.
Only one interrupt source can be active at any time, which is much easier to deal with than multiple prioritized interrupt sources. Having a simple interrupt allows a cog to run both a time critical task and a non time critical task. That would not be possible for a task that requires an infrequent low latency response.
Ah, I didn't know that. I thought there could be multiple sources active and that interrupts had priorities. Thanks for clarifying.
Edit: I don't think what you're saying is correct. Here is what the current doc says:
Each cog has three interrupts: INT1, INT2, and INT3.
INT1 has the highest priority and can interrupt INT2 and INT3.
INT2 has the middle priority and can interrupt INT3.
INT3 has the lowest priority and can only interrupt non-interrupt code.
Oh oh, you are right then, it has changed. That does make it potentially a bit more complicated, however one only has to use the interrupts they need, so the simple single interrupt case is still possible.
Yes, and that is also possible on other MCUs. As I said before, what really sets P2 apart is that there is more than one processor so you can easily setup one or more processors that are not subject to interrupts if you need that to achieve timing predictability.
Yes, and that is also possible on other MCUs. As I said before, what really sets P2 apart is that there is more than one processor so you can easily setup one or more processors that are not subject to interrupts if you need that to achieve timing predictability.
This feels like a real game changer. With 16 cores, independent interrupts on every core, hardware serial comms, and 512k of code space, this chip is going to do incredible things! I can't wait!
3 prioritized interrupts that trigger on selected events
Hidden debug interrupt for single-stepping, breakpoint, and polling
It does have interrupts? So then a memory protection/management unit is possible?
Nope. Not a true, hardware-enforced one, anyhow.
Can you explain the difference between a hardware-enforced interrupt and what the Prop 2 has? I've never heard of such a distinction before.
Prop2 has hardware interrupts. I think he means true hardware memory protection/management. That requires generating an interrupt when a program tries to access an address outside the assigned memory bounds.
Correct. I was typing on my phone, at the time, so I was a bit terse. As you point out, to have real memory protection you need explicit hardware support. Interrupts are usually not enough. On the Propeller, the closest you get is the isolation between the cogs (which is no different than on the P1). As with the P1, the expectation for the P2 is still that you know what all the code is doing and are ensuring up front that it is well-behaved. It's still not intended to support a Linux kernel.
That's not to say that people won't come up with "good enough" schemes. After all, there are a lot more possibilities with the P2 than there were with the P1. For instance, now that adjacent cogs can push data to each other via LUT memory, I wouldn't be surprised to see a sort of VMM where one cog services large memory fetch/store requests for an adjacent cog. This might be preferable to using hub memory because of the isolation from other cogs. Of course, the other cogs can still access the same I/O to the external memory, so using such a scheme would only be for improving design and stability, not for security.
The added cogs, memory, interrupts and other features of the P2 opens up a lot of possibilities. Really looking forward to playing with it even though I don't have a need for it presently.
Don't really want anything as complex as Linux on it, although a scaled down semi-windowing system that handles I/O, networking, data storage, and memory/program loading would be nice. An updated version of one of the current P1 os'es perhaps?
The lack of interrupts on the P1 was something that I didn't get used to. For example, one could do a frequency meter if P1 had interrupts, using a counter and using an external RTC for the interrupts.
Plenty of people have done Frequency Counters on P1 ?
P2 will do frequency with counting even higher precision, not because it has interrupts, but because it has the smart pin hardware to properly capture dT and dC on the same edge, to allow loss-less Reciprocal Counting.
The problem with interrupts is: it breaks thinking. Ones used to be interrupted, simple solutions no longer are obvious. Set up a counter, read the counter and the system timer now and then, determine number of counts and number of clock and there relation is the frequency. Resume thinking.
I understand. However, the fact that P2 is interrupt capable won't hurt your program if you don't (or if you don't want to) use them.
The lack of interrupts on the P1 was something that I didn't get used to. For example, one could do a frequency meter if P1 had interrupts, using a counter and using an external RTC for the interrupts.
Plenty of people have done Frequency Counters on P1 ?
P2 will do frequency with counting even higher precision, not because it has interrupts, but because it has the smart pin hardware to properly capture dT and dC on the same edge, to allow loss-less Reciprocal Counting.
Well, 40MHz frequency counter with a 80MHz micro-controller. Don't you see a problem here?
If you used interrupts, you could even use a 20MHz micro-controller to count up to 100MHz reliably. You really need asynchronous counters as peripherals to the CPU, and you need interrupts to take notice of events. Without them, you'll have to spend cores and no guarantees of precise counts. I've used a PIC for that, just because of the asynchronous counters and interrupts. Then I could use a precise RTC TCXO to mark the second intervals without wasting any precision. That would be needed for the interrupt.
Indeed interrupts are necessary for those who want them, and will be a leverage on the P2, especially when doing signal acquisition. The lack of interrupts on the P1 was something that I didn't get used to.
Ah, the interrupt debate. A recurring theme around here. I have to reiterate my thesis:
Nobody ever needed or wanted interrupts. What they needed was a way to get some code to run when some external asynchronous event happens. Preferably with the minimum latency.
How could we do that ? :
1) Poll some I/O device from a loop in our background processing.
2) Have the CPU suspend the background processing when the event occurs and jump to the event handler code.
3) Have an entire other core running the event handler code. Sleeping in some kind of "WAIT" instruction until the event happens.
How do these compare ?:
1) Polling is inefficient. We have to poll a bunch of I/O in the background loop. Latency is high. The machine cannot sleep. Integrating other peoples modules/libraries/objects is a pain as you have to remember to run whatever polling routine they need, at the right intervals, in your main program.
2) Interrupts are better perhaps, especially if you only have one CPU. Latency is better, still high as the context of the background process has to be saved and restored. Complexity is high as you now get into the world of different modules/libraries/objects fighting over available time. You have to organize priorities and so on. Complexity is high, you still have to integrate the interrupt handler into your main program.
3) Multiple cores is the best. Low latency, there is no background state to save/resotre. Simple, there is no worry about objects fighting over available time. No priorities to juggle, The whole machine can sleep if there are no events happening.
One key point here is that interrupts, on a single CPU machine, make code sharing (objects in the case of the Propeller) more difficult due to integration and performance/timing jitter issues.
Anyone care to point out where my logic is wrong here? As far as I can tell interrupts, even on the P2, are not required unless you are actually going to run out of cores.
I campaigned against interrupts on the P2 on the grounds of adding complexity for the user that just wants to mix and match objects from OBEX and elsewhere. As it stands though any object you create that uses the P2 interrupts can have no timing impact on my program if I use it. So that is OK.
interrupts, even on the P2, are not required unless you are actually going to run out of cores
As cool as it is to have 16 cores, do you dare say that no one will ever come up with a project that requires more than 16 unique tasks? Of course you don't. So there's the flaw in your logic. #3 has one downside: inefficient use of the Propeller's clock cycles.
Also (again with being at work and unable to check the doc directly), does the Prop 2 have a waitXXX instruction for polling any arbitrary (or programmatically configured) event? In the P1 we have the likes of waitpeq which allows the cog to sleep while waiting for our event. But with new hardware peripherals, can I do the same sleep action while I'm waiting for data over the serial bus? If that new waitXXX instruction was not implemented, then we have a power issue.
That's not a flaw in my argument. That just means we need more cores
But you are right. We can run out of cores, cores are big and expensive and power hungry, so being able to multi-task a core with interrupts is the pragmatic solution.
What I missed on the P1 is the ability to wait on multiple different events at the same time. We can wait on multiple pins but what if I want to wait on a pin and a timeout? For example.
What I missed on the P1 is the ability to wait on multiple different events at the same time. We can wait on multiple pins but what if I want to wait on a pin and a timeout? For example.
Good point. I don't remember seeing such a mechanism on the P2 either. Not having a timeout makes waitpeq/waitpne far less useful.
Yes. I always thought the humble UART was the canonical example.
On the Tx side you want to wait on a timer and clock the next bit out;
On the Rx side you want to wait on a pin change for start bit detection.
Then your COG could be asleep in a low power state while nothing is happening.
Presumably on the P2 you can do this with interrupts. Not sure which of those two approaches, interrupt or WAITevent, would produce the best bit rate / power consumption though.
I think one of the things that makes interrupts frustrating to use on other architectures is that they are often (necessarily) used to execute code that's unrelated to the current code that's running. I'm sure this is a natural consequence of traditionally having a very limited number of cores (usually 1) that must be shared.
I suspect the interrupt usage patterns for the P2 will be different. Instead, interrupts will usually be limited to executing code that is related to the current code that's running. In other words, if you have a cog that will conditionally change its behavior based on an external event, interrupts might be the ideal way to handle mutating state from the event. If you have unrelated code that you want to execute, you will use a separate cog.
In this way, I suspect that interrupts will actually make some code much easier to write and maintain. Further, since this feels (to me, at least) like a natural way to use interrupts on the P2, I suspect this will also result in fewer OBEX conflicts than Heater (and others) are predicting. If the interrupts are generally isolated as I describe above, you aren't going to have interrupts messing up the timing of your critical code.
The lack of interrupts on the P1 was something that I didn't get used to. For example, one could do a frequency meter if P1 had interrupts, using a counter and using an external RTC for the interrupts.
...(P1 example provided)....
Well, 40MHz frequency counter with a 80MHz micro-controller. Don't you see a problem here?
No problem at all - your original claim was "one could do a frequency meter if P1 had interrupts"
This example proves that claim was incorrect.
Without them, you'll have to spend cores and no guarantees of precise counts. I've used a PIC for that, just because of the asynchronous counters and interrupts. Then I could use a precise RTC TCXO to mark the second intervals without wasting any precision. That would be needed for the interrupt.
I'm lost here, interrupts are no guarantee of precision, and even a precise RTC TCXO to mark the second intervals is no guarantee of measurement precision either.
What precision can you measure 400Hz to, on that design ?
Interrupts on most MCUs are a source of jitter, so are actually best avoided in the better Frequency Counter designs.
P2 also proves you do not need interrupts for high end Frequency Counter design.
Presumably on the P2 you can do this with interrupts. Not sure which of those two approaches, interrupt or WAITevent, would produce the best bit rate / power consumption though.
I wrote code that did exactly this. I might have even posted it to the forum at some point. Incidentally, this bolsters my prior post. The interrupts are only used to interrupt related code. What you would not want to do is run the interrupt-driven UART code in a cog with non-UART code. That's where the interrupts become a problem.
Of course, the crazy-powerful smart pins make many of these scenarios moot.
I think nothing beats the low latency of using interrupts if the program is well structured. You can have all the cores you want, but you may have a delay dependent on where the polling routine is running. When calling an interrupt, the delay can be always minimal and the response immediate. And that is because the interrupt service routine starts the same way. The frequency-meter example is a good one since you need only one interrupt and the ISR will be simple and quick enough. All it has to do is:
- Read the counter;
- Reset the counter;
- Clear the interrupt.
The main program only has to read the value and display it, in an infinite cycle.
As far as I can tell P2 interrupts are isolated. So that if I introduce your code, some object or library, into my project I don't need to know or care if you use interrupts or not. Safe in the knowledge that these codes are well isolated from each other.
It took me a while to come around to this idea but I think I'm there now.
Speaking of "isolation". I'm still not clear on the impact of the "hub beater" memory access scheme. As far as I can tell it can improve overall performance by allowing COGs to access the HUB if other COGs are not using their turn. But surely that means that your code can modulate the speed of execution of my code in my project? This extra memory bandwidth has to come from somewhere?
Speaking of "isolation". I'm still not clear on the impact of the "hub beater" memory access scheme. As far as I can tell it can improve overall performance by allowing COGs to access the HUB if other COGs are not using their turn. But surely that means that your code can modulate the speed of execution of my code in my project? This extra memory bandwidth has to come from somewhere?
I don't believe this is the case. Cogs access the hub at a fixed rate, regardless of whether other cogs are also accessing the hub. The only difference is that each cog has access to a different hub bank on the same clock cycle. No cog can affect any other cog's access to the hub.
I think nothing beats the low latency of using interrupts if the program is well structured.
I think this is wrong. And it's nothing to do with your program structure.
Consider a traditional single processor machine with 8 interrupt sources. As was typical back in the day. What happens when all those interrupts happen at the same time?
They all have interrupt handler code that needs to be run. You can only run one at a time. Somebody has to wait. If that somebody has a low latency requirement then it fails.
This problem can be alleviated by assigning priorities to the interrupt sources. Then a low latency interrupt can take over CPU time from a lower priority interrupt.
It's a clunky solution. It can be made to work.
But, what of you the add some new code to your system? Code you did not write because you got it from some open source, shared, repository? Which is what the Propeller ecosystem is all about.
How do you know that code does not consume interrupt time. How do you know that code is not going to break the carefully balanced timing of your well structured project?
You do not. It's a mess.
But, with extra cores to run that code you could be happy that all your events get minimal latency and new code will not upset your timing.
You can have all the cores you want, but you may have a delay dependent on where the polling routine is running.
What polling?
In a multi-core system a core can be asleep waiting for some external event to happen. When the event happens it starts immediately working on it. No contexts to be saved and restored. Just do it. See the various "WAITxx" instructions on the Propeller.
When calling an interrupt, the delay can be always minimal and the response immediate.
No. Not if there is a higher priority interrupt being serviced at the time. See above.
And that is because the interrupt service routine starts the same way. The frequency-meter example is a good one since you need only one interrupt and the ISR will be simple and quick enough. All it has to do is:
- Read the counter;
- Reset the counter;
- Clear the interrupt.
Exactly. What if I have a bunch of other interrupts that can block the execution that sequence, because they have higher priority? Then your counter reading is late, your frequency measurement jitters.
Sure you can change the interrupt priorities so that your frequency counter gets minimal jitter. In doing so you may have introduced jitter to some other critical task.
It becomes a complicated, failure prone, hard to debug mess. I have seen it many times.
The great debate goes on. Some things to consider:
Added complexity: Interrupts do not add any complexity if you don't use them. They do add power and flexibility if they are needed, and do so with very little additional hardware.
Latency: Very little latency because unlike older/mundane processors the Prop does not have a lot of registers to save. Only the program counter and status flags.
Jitter and timing problems: There are 16 cogs in the P2 so dedicate cogs to time critical tasks and don't use interrupts on those cogs if interrupts are a problem.
What I missed on the P1 is the ability to wait on multiple different events at the same time. We can wait on multiple pins but what if I want to wait on a pin and a timeout? For example.
This can be done on P2.
If you use a SETQ instruction before a WAITxxx WC instrucrion you can set a timeout value.
If a timeout occurs then C=1 otherwise C=0 means event occurred.
Very handy
What I missed on the P1 is the ability to wait on multiple different events at the same time. We can wait on multiple pins but what if I want to wait on a pin and a timeout? For example.
This can be done on P2.
If you use a SETQ instruction before a WAITxxx WC instrucrion you can set a timeout value.
If a timeout occurs then C=1 otherwise C=0 means event occurred.
Very handy
YAAYYY! As if I wasn't excited enough before. Very cool.
Comments
Indeed interrupts are necessary for those who want them, and will be a leverage on the P2, especially when doing signal acquisition. The lack of interrupts on the P1 was something that I didn't get used to. For example, one could do a frequency meter if P1 had interrupts, using a counter and using an external RTC for the interrupts.
Kind regards, Samuel Lourenço
I agree that interrupts as implemented in most microcontrollers and microprocessors are relatively complex and can break the chain of thought when writing code. Unless the P2 interrupt scheme has changed drastically from the initial design without me noticing this is not the case for the propeller. What it amounts to is having two programs in the cog, an "interrupt" program that runs as a result of the interrupt and returns to the "main" program that runs the rest of the time.
This is relatively simple to code for yet is a very powerful option for many purposes. In the case of your frequency measurement it would simplify and speed up the code since a polling loop or waitcnt is not required.
Only one interrupt source can be active at any time, which is much easier to deal with than multiple prioritized interrupt sources. Having a simple interrupt allows a cog to run both a time critical task and a non time critical task. That would not be possible for a task that requires an infrequent low latency response.
Edit: I don't think what you're saying is correct. Here is what the current doc says:
David Betz beat me to it
Oh oh, you are right then, it has changed. That does make it potentially a bit more complicated, however one only has to use the interrupts they need, so the simple single interrupt case is still possible.
This feels like a real game changer. With 16 cores, independent interrupts on every core, hardware serial comms, and 512k of code space, this chip is going to do incredible things! I can't wait!
Correct. I was typing on my phone, at the time, so I was a bit terse. As you point out, to have real memory protection you need explicit hardware support. Interrupts are usually not enough. On the Propeller, the closest you get is the isolation between the cogs (which is no different than on the P1). As with the P1, the expectation for the P2 is still that you know what all the code is doing and are ensuring up front that it is well-behaved. It's still not intended to support a Linux kernel.
That's not to say that people won't come up with "good enough" schemes. After all, there are a lot more possibilities with the P2 than there were with the P1. For instance, now that adjacent cogs can push data to each other via LUT memory, I wouldn't be surprised to see a sort of VMM where one cog services large memory fetch/store requests for an adjacent cog. This might be preferable to using hub memory because of the isolation from other cogs. Of course, the other cogs can still access the same I/O to the external memory, so using such a scheme would only be for improving design and stability, not for security.
Don't really want anything as complex as Linux on it, although a scaled down semi-windowing system that handles I/O, networking, data storage, and memory/program loading would be nice. An updated version of one of the current P1 os'es perhaps?
Plenty of people have done Frequency Counters on P1 ?
This thread has two, a simple one, and a Reciprocal Counter 0.5Hz ~ 40MHz
http://forums.parallax.com/discussion/123170/propbasic-reciprocal-frequency-counter-0-5hz-to-40mhz-40mhz-now
P2 will do frequency with counting even higher precision, not because it has interrupts, but because it has the smart pin hardware to properly capture dT and dC on the same edge, to allow loss-less Reciprocal Counting.
Well, 40MHz frequency counter with a 80MHz micro-controller. Don't you see a problem here?
If you used interrupts, you could even use a 20MHz micro-controller to count up to 100MHz reliably. You really need asynchronous counters as peripherals to the CPU, and you need interrupts to take notice of events. Without them, you'll have to spend cores and no guarantees of precise counts. I've used a PIC for that, just because of the asynchronous counters and interrupts. Then I could use a precise RTC TCXO to mark the second intervals without wasting any precision. That would be needed for the interrupt.
Kind regards, Samuel Lourenço
Nobody ever needed or wanted interrupts. What they needed was a way to get some code to run when some external asynchronous event happens. Preferably with the minimum latency.
How could we do that ? :
1) Poll some I/O device from a loop in our background processing.
2) Have the CPU suspend the background processing when the event occurs and jump to the event handler code.
3) Have an entire other core running the event handler code. Sleeping in some kind of "WAIT" instruction until the event happens.
How do these compare ?:
1) Polling is inefficient. We have to poll a bunch of I/O in the background loop. Latency is high. The machine cannot sleep. Integrating other peoples modules/libraries/objects is a pain as you have to remember to run whatever polling routine they need, at the right intervals, in your main program.
2) Interrupts are better perhaps, especially if you only have one CPU. Latency is better, still high as the context of the background process has to be saved and restored. Complexity is high as you now get into the world of different modules/libraries/objects fighting over available time. You have to organize priorities and so on. Complexity is high, you still have to integrate the interrupt handler into your main program.
3) Multiple cores is the best. Low latency, there is no background state to save/resotre. Simple, there is no worry about objects fighting over available time. No priorities to juggle, The whole machine can sleep if there are no events happening.
One key point here is that interrupts, on a single CPU machine, make code sharing (objects in the case of the Propeller) more difficult due to integration and performance/timing jitter issues.
Anyone care to point out where my logic is wrong here? As far as I can tell interrupts, even on the P2, are not required unless you are actually going to run out of cores.
I campaigned against interrupts on the P2 on the grounds of adding complexity for the user that just wants to mix and match objects from OBEX and elsewhere. As it stands though any object you create that uses the P2 interrupts can have no timing impact on my program if I use it. So that is OK.
As cool as it is to have 16 cores, do you dare say that no one will ever come up with a project that requires more than 16 unique tasks? Of course you don't. So there's the flaw in your logic. #3 has one downside: inefficient use of the Propeller's clock cycles.
Also (again with being at work and unable to check the doc directly), does the Prop 2 have a waitXXX instruction for polling any arbitrary (or programmatically configured) event? In the P1 we have the likes of waitpeq which allows the cog to sleep while waiting for our event. But with new hardware peripherals, can I do the same sleep action while I'm waiting for data over the serial bus? If that new waitXXX instruction was not implemented, then we have a power issue.
But you are right. We can run out of cores, cores are big and expensive and power hungry, so being able to multi-task a core with interrupts is the pragmatic solution.
What I missed on the P1 is the ability to wait on multiple different events at the same time. We can wait on multiple pins but what if I want to wait on a pin and a timeout? For example.
Irrefutable logic there!
Good point. I don't remember seeing such a mechanism on the P2 either. Not having a timeout makes waitpeq/waitpne far less useful.
On the Tx side you want to wait on a timer and clock the next bit out;
On the Rx side you want to wait on a pin change for start bit detection.
Then your COG could be asleep in a low power state while nothing is happening.
Presumably on the P2 you can do this with interrupts. Not sure which of those two approaches, interrupt or WAITevent, would produce the best bit rate / power consumption though.
I suspect the interrupt usage patterns for the P2 will be different. Instead, interrupts will usually be limited to executing code that is related to the current code that's running. In other words, if you have a cog that will conditionally change its behavior based on an external event, interrupts might be the ideal way to handle mutating state from the event. If you have unrelated code that you want to execute, you will use a separate cog.
In this way, I suspect that interrupts will actually make some code much easier to write and maintain. Further, since this feels (to me, at least) like a natural way to use interrupts on the P2, I suspect this will also result in fewer OBEX conflicts than Heater (and others) are predicting. If the interrupts are generally isolated as I describe above, you aren't going to have interrupts messing up the timing of your critical code.
No problem at all - your original claim was "one could do a frequency meter if P1 had interrupts"
This example proves that claim was incorrect.
Wow, really ? I've never see that claim made before about interrupts, thanks for the chuckle....
Now you get closer, & clearly that is not interrupts at all, but a quite separate hardware feature.
I'm lost here, interrupts are no guarantee of precision, and even a precise RTC TCXO to mark the second intervals is no guarantee of measurement precision either.
What precision can you measure 400Hz to, on that design ?
Interrupts on most MCUs are a source of jitter, so are actually best avoided in the better Frequency Counter designs.
P2 also proves you do not need interrupts for high end Frequency Counter design.
I wrote code that did exactly this. I might have even posted it to the forum at some point. Incidentally, this bolsters my prior post. The interrupts are only used to interrupt related code. What you would not want to do is run the interrupt-driven UART code in a cog with non-UART code. That's where the interrupts become a problem.
Of course, the crazy-powerful smart pins make many of these scenarios moot.
I think nothing beats the low latency of using interrupts if the program is well structured. You can have all the cores you want, but you may have a delay dependent on where the polling routine is running. When calling an interrupt, the delay can be always minimal and the response immediate. And that is because the interrupt service routine starts the same way. The frequency-meter example is a good one since you need only one interrupt and the ISR will be simple and quick enough. All it has to do is:
- Read the counter;
- Reset the counter;
- Clear the interrupt.
The main program only has to read the value and display it, in an infinite cycle.
Kind regards, Samuel Lourenço
Yes. I think you summed that up nicely.
As far as I can tell P2 interrupts are isolated. So that if I introduce your code, some object or library, into my project I don't need to know or care if you use interrupts or not. Safe in the knowledge that these codes are well isolated from each other.
It took me a while to come around to this idea but I think I'm there now.
Speaking of "isolation". I'm still not clear on the impact of the "hub beater" memory access scheme. As far as I can tell it can improve overall performance by allowing COGs to access the HUB if other COGs are not using their turn. But surely that means that your code can modulate the speed of execution of my code in my project? This extra memory bandwidth has to come from somewhere?
I don't believe this is the case. Cogs access the hub at a fixed rate, regardless of whether other cogs are also accessing the hub. The only difference is that each cog has access to a different hub bank on the same clock cycle. No cog can affect any other cog's access to the hub.
Consider a traditional single processor machine with 8 interrupt sources. As was typical back in the day. What happens when all those interrupts happen at the same time?
They all have interrupt handler code that needs to be run. You can only run one at a time. Somebody has to wait. If that somebody has a low latency requirement then it fails.
This problem can be alleviated by assigning priorities to the interrupt sources. Then a low latency interrupt can take over CPU time from a lower priority interrupt.
It's a clunky solution. It can be made to work.
But, what of you the add some new code to your system? Code you did not write because you got it from some open source, shared, repository? Which is what the Propeller ecosystem is all about.
How do you know that code does not consume interrupt time. How do you know that code is not going to break the carefully balanced timing of your well structured project?
You do not. It's a mess.
But, with extra cores to run that code you could be happy that all your events get minimal latency and new code will not upset your timing. What polling?
In a multi-core system a core can be asleep waiting for some external event to happen. When the event happens it starts immediately working on it. No contexts to be saved and restored. Just do it. See the various "WAITxx" instructions on the Propeller. No. Not if there is a higher priority interrupt being serviced at the time. See above.
Exactly. What if I have a bunch of other interrupts that can block the execution that sequence, because they have higher priority? Then your counter reading is late, your frequency measurement jitters.
Sure you can change the interrupt priorities so that your frequency counter gets minimal jitter. In doing so you may have introduced jitter to some other critical task.
It becomes a complicated, failure prone, hard to debug mess. I have seen it many times.
Not when it is displaying the frequency on a vga monitor, reading the location with a GPS, and storing it all on an SD card, all at the same time.
Added complexity: Interrupts do not add any complexity if you don't use them. They do add power and flexibility if they are needed, and do so with very little additional hardware.
Latency: Very little latency because unlike older/mundane processors the Prop does not have a lot of registers to save. Only the program counter and status flags.
Jitter and timing problems: There are 16 cogs in the P2 so dedicate cogs to time critical tasks and don't use interrupts on those cogs if interrupts are a problem.
If you use a SETQ instruction before a WAITxxx WC instrucrion you can set a timeout value.
If a timeout occurs then C=1 otherwise C=0 means event occurred.
Very handy
YAAYYY! As if I wasn't excited enough before. Very cool.