...interrupts on the Propeller. Quite easy to do. Take one of them 8 cores and think of it as a interrupt handler....So what am I supposed to miss here?
Thing is there are people who absolutely can't stand the idea of wasting a whole CPU on handling some tiny piece of code that does not get triggered very often. So they want their interrupts as well as many cores. Or perhaps they are stuck in the past and think interrupts is the only way to program.
The Prop was designed to be free of the complications of interrupts and be used exactly as you say.
Given the benefits of not having interrupts I'm happy to trade of some silicon for it. With P2 and 16 cores there is even less reason to want interrupts, you have another 8 "interrupt handlers" ready to wait on your events!
Given the benefits of not having interrupts I'm happy to trade of some silicon for it. With P2 and 16 cores there is even less reason to want interrupts, you have another 8 "interrupt handlers" ready to wait on your events!
Some times it's easier on a single cog to just use an interrupt. But if there is a spare cog available it could just sit there and monitor a pin or a timing event, and then set a flag that is checked periodically by the main cog.
...and then set a flag that is checked periodically by the main cog.
And there you have hit upon a problem with the whole idea.
For example a driver COG, like a serial receiver, may well be using WAITxxx on a pin or a timer to do it's work. Like an interrupt routine. So far so good.
But now we have the "main cog" having to poll the output of the driver COG. We have moved the polling up stream a bit from the driver polling for bits on the line to the main program polling the driver for bytes.
The main cog may call someSerialPort.read() and now that read function has to loop polling the someSerialPort for incoming data.
What we would like here is a means for a process in a COG to WAIT on data or a signal from another COG. That removes the polling and allows entering a low power do nothing state on calling read() until the signal is received.
Currently we can only do this via signalling on pins.
I don't know what anyone else wanted in the way of interrupts, but what I had in mind is much simpler than even the basic interrupt system on the Z80. It would be a very simple cog only interrupt that would be easy to implement.
nterrupts need some things.
One thing is a context save of some sort. Could be a stack or register bank, or instruction to write state somewhere...
The only context it would need to save would be the address to return to in the currently executing code.
Need a trigger of some sort and means to configure it.
Two consecutive cog registers that would hold a pin mask and the current pin states. The interrupt code would be executed when the state of the pins changes. This could be part of the smart pins if done on the P2.
A vector to handle the target alternative execute path.
The “enable_interrupts” instruction would set that up. The s and d fields would be pointers to the pin mask and the beginning of the interrupt code.
Honestly, I much prefer the ability to start cogs at given addresses and without reloading them.
Then the interrupt becomes a software construct and there are no unplanned execution paths.
And that would be the default behaviour of the cog. Until you enabled the interrupts cogs would behave exactly as they do now.
And that seems to be the differentiator. On a P1 all execute paths are planned, known. The last design discussion on P2 was also that way.
Write a block of code and know what it will do.
The egg beater HUB complicates this some, but I'm not sure just how that will play out yet. Nobody does, until Chip gets the first image sorted.
If this type of simple interrupt was added to the P2 or an enhanced P1 that would still be the way it would be unless the interrupts were enabled. Even when the interrupts are enabled the code would have to be short and simple. After all, there is not that much room for code in a cog.
I am still confused why people missing interrupts on the Propeller. Quite easy to do. Take one of them 8 cores and think of it as a interrupt handler. WAITPNE uses a mask. While waiting the COG does not use much power. If you need timed events independent of pin changes use a counter and some unused pin.
Event occurs, cog wakes up from WAITPNE and - well - is your interrupt handler you have to write on any other system also. So what am I supposed to miss here? And I still have 7 other independent cores running.
On a multicore chip a interrupt does not need to interrupt the main program at all. It (the task needed) just needs to be done,
Maybe some 'interrupt' object in the OBEX?
Enjoy!
Mike
It's not really about missing interrupts or wanting to interrupt the main code. Yes, a cog can be dedicated to handling interrupts, but that pretty much ties the cog up for that one task, and using it for multiple interrupts is slow. Fine for a lot of things, but not for what the cogs do best.
Basically I agree with Dave Hein's post that adding a simple interrupt to each cog would make the cogs more powerful, and a lot of the other posts asking for interrupts seem to be along similar lines.
In two projects I had all 8 cogs in use and still needed to add 27 lines of pasm code to deal with a signal that came at somewhat random times but needed a very low latency response. Had several cogs with enough free space and time for the new pasm code until I added the polling calls into the existing code. I did manage to fit it in by juggling code around the cogs but a simple cog interrupt would have made the task trivial.
You did not need an interrupt. What you needed was another COG to handle that little low latency event. Which can't have been all that low latency else you would not have been able to combine it with other COG code.
Yes, I know it's a waste of a 32 bit CPU. This is 2015. That CPU is almost nothing, a spec of sand. Sadly the P1 only has 8. The P2 will have 16. Who knows what the future brings?
You did not need an interrupt. What you needed was another COG to handle that little low latency event. Which can't have been all that low latency else you would not have been able to combine it with other COG code.
Yes, I know it's a waste of a 32 bit CPU. This is 2015. That CPU is almost nothing, a spec of sand. Sadly the P1 only has 8. The P2 will have 16. Who knows what the future brings?
Yep, when we get to having one cpu per I/O pin I agree that interrupts are not needed. Until then they would be of some benefit.
Basically I agree with Dave Hein's post that adding a simple interrupt to each cog would make the cogs more powerful, and a lot of the other posts asking for interrupts seem to be along similar lines.
Correct, a COG is actually ALU plus RAM, and represents a significant amount of silicon. (and power)
Best not to waste RAM you paid for, just because the ALU cannot make use of it.
Yes, I know it's a waste of a 32 bit CPU. This is 2015. That CPU is almost nothing, a spec of sand. Sadly the P1 only has 8. The P2 will have 16. Who knows what the future brings?
COGs are nowhere near a spec of sand yet. They consume significant die and power, and there are only 8 or 16 available. Each COG has cost you close to $1, more than a great many small micros out there.
Truth is you paid for the system, it's nature, silicon, etc... right along with its ecosystem of shared code.
I think bundling a few cheap chips together, along with code to make that mess work is very expensive and not all that easy to reuse, debug, and so forth.
A Prop, by comparison, is a great deal, and part of why it is a great deal is its nature and the implications that has on its ecosystem.
This is precisely why many of us do not want that nature changed.
Energy waste is very real, no matter how many you use, and your argument of 'Who cares' is only valid until your design grows to need 9+ COGS. (example given in #158)
Price is only 'don't care', to those working in low volumes.
Quite serious small MCUs are now sub 50c in moderate volumes.
Truth is you paid for the system, it's nature, silicon, etc... right along with its ecosystem of shared code.
I think bundling a few cheap chips together, along with code to make that mess work is very expensive and not all that easy to reuse, debug, and so forth.
A Prop, by comparison, is a great deal, and part of why it is a great deal is its nature and the implications that has on its ecosystem.
This is precisely why many of us do not want that nature changed.
Agree 100% with your great deal argument, but can't help wondering at the opposition to a change that adds capability without changing or taking away from what is already there.
Adding interrupt capability to something like the Propeller may be cheap, but it's not free. A couple of instructions have to be added (enable / disable interrupts). A small bunch of logic has to be added to manage this ... disable interrupts once one is acknowledged, double buffer the enable so there's time for a return from interrupt to occur (JMPRET), This all has to be integrated with the pipeline. Typically an instruction has to be forced in the next fetch cycle, probably a fixed JMPRET. Some kind of logic has to be created to generate the interrupt from either masked I/O pin state changes and/or a timeout ... something like WAITPNE/EQ and WAITCNT. You wouldn't be able to use WAITPNE/PEQ or WAITCNT with interrupts enabled unless there was some fancy bookkeeping in the interrupt routine or special hardware. Where does the interrupt return, particularly if the WAITPNE/EQ or WAITCNT condition is satisfied during the interrupt routine? I'm sure this can be managed, but is it worth the added complexity?
... I'm sure this can be managed, but is it worth the added complexity?
The interrupt topic forked from the original talk about being able to use wasted CPU cycles, and how the Time-Slicing in an earlier P2, would make "interrupts" very easy to manage.
I gave an example of a hard time-slices MCU that made it to silicon. ( and I think, had interrupts too )
P2 is certainly going to be smarter around event handling, with timeouts on waits, and smarter pins.
Smart pins may even allow a "quasi-interrupt" structure, where a common wait can be HW low power, then exit-wait on more than one event, execute that code and come back to check and execute the queued event.
Combine that with a timeout flag, and you have code that reacts quickly to events, but can also run some larger code that takes longer than one timeout to complete.
This "quasi-interrupt" may not react quite as quickly as a conventional MCU interrupt, but it can cover a great many application with the right Smart Pins.
If users need faster reaction times than a conventional MCU interrupt, a dedicated COG can deliver that.
... If users need faster reaction times than a conventional MCU interrupt, a dedicated COG can deliver that.
Right. P1 has 8 of them and P2 hopefully 16. So just use one of them as Interrupt controller. Even on P1 waitpne and friends can check for multiple interrupt pins at once while in low power state.
This cog then can either handle the need job by itself or 'outsource' it via mailbox to a another cog and returning to its idle state.
Not doable on any single core.
And you still have other execution engines working in parallel without interruption while your interrupt gets handled by the handler and eventually dispatched to some other parallel process.
For what exactly do you need a interrupt again?
I do love the propeller for its unorthodox way of doing things. The main plan on it is to use parallel execution instead of a interrupted single core computation. Why you want to press this back into the mainstream, boring, complicated mess of interrupts and hardware registers for dedicated SPI, Hyper-bus, Quad-whatever?
It's not what the propeller is. Sure. Dedicated hardware for protocols and interrupts are what the mainstream MCs are doing. Almost all of them. If you think you need this in your life, do it. Use a PIC, ARM, Pentium, whatever. Why can't you let the propeller do it differently?
Why are you constantly voting for dedicated HW support for whatever protocol, interrupts and other 'mainstream features' when the main goal of @chip on the propeller was to NOT have those things in the first place?
NOT having dedicated hardware and NOT having interrupts and NOT having tons of HW-registers and Data Sheets and different Versions of the same stupid chip because of different HW and pins is exactly what the Propeller is about.
If you remove that from the propeller (or add, depending on view) it is not a propeller anymore but just another MC like all of the other ones.
Why you want to press this back into the mainstream, boring, complicated mess of interrupts and hardware registers for dedicated SPI, Hyper-bus, Quad-whatever?
? A good memory interface does not detract from the Prop, quite the opposite, in fact.
QuadSPI is an industry standard, and cheap.
Software banging everything simply fails energy efficiency tests, as well as fails Speed tests.
If dedicated hardware confuses you, and is somehow anti-prop you'll be very confused by the Smart Pins Chip plans. (and you must be confused by the existing Counters too, more dedicated hardware...)
Yes, those smart pins are dedicated hardware.
( I guess you can always simply not use any of that ? )
Counter may be 'dedicated Hardware' but not bound to a specific protocol or specific pins. In one way you could say them counters are predecessors of them upcoming smart pins. Independent units performing a parallel subtask. If you had chosen Video out, I may have had to agree, even if it is usable for fast SPI out also. But you didn't.
As of what them smart pins will do or not do? Nobody knows really. Not even @Chip I guess. They are still work in progress. It is a continuation of the base propeller concept. Each pin gets its own execution unit. More like a state machine I guess. Hopefully usable for a lot of different things and not just as UART or QuadSPI.
So it is not dedicated Hardware but more general orientated Hardware.
One of the main point of the propeller is that, thru software devices' you can use the same chip for various different projects one of them, not 50 different ones. Need to drive 32 Servos? Doable. see Duanes code and examples. Need 16 UARTs? Doable. Even used by NASA in space. 4 sd cards with one prop? no problem. See RAISD. Multiple VGA and or TV screens? Sure. I can go on here but you get the point I guess.
Dedicated HW for say Hyper-bus is lost for you as a programmer if you do not need Hyper-bus. A cog used for Hyper-bus communication can be used for other things if you do not need Hyper-bus. Even more. If in five years some warp-bus is the now new way to go, some smart *** will write a PASM driver for it using the same cog used for Hyper-bus.
What I like to bring across is that it is more important to be able to generate precise signals with fast timing programmable in software in opposite to have fixed HW bound to a specific protocol like (quad)SPI,UART,USB,TCP/IP, whatever.
That is where the propeller shines. Soft devices. I am pretty eager to see @Chips first incarnation of them smart pins. What a brilliant Idea. 16 parallel running cogs AND independent parallel running subsystems for each pin. How cool is that.
Anyone still missing single core execution and interrupts?
Interrupts can be forgotten. The closest we came was the 4-way threading and that probably won't be revisited even for a Prop3 design. One of it's limits, and this is a biggie, was the size of CogRAM, this has already been addressed earlier in this topic but JMG keeps ignoring the point of ISR's/tasks all needing space in the Cog. Another limit is amount of extra engineering required to allowing the threads to be visible to HubExec and be even slightly efficient. That one was giving Chip a real headache.
The Prop is targeted at being slim with plentiful cores. If it's design changed tact to be a typical bloated CPU it would be just another multi-core processor.
Hardware assist is more up for grabs I'd say. I'm no fan of one-job-only special "IP" blocks ... but generic solutions that can be used for these jobs is all good with me.
Also, the Prop is not aiming to be a computational design. It is not competing for maximal FLOPS or whatever. Another variant of this is the Prop isn't aiming for most FLOPS per watt either.
I am pretty eager to see @Chips first incarnation of them smart pins. What a brilliant Idea. 16 parallel running cogs AND independent parallel running subsystems for each pin. How cool is that.
Yes, Smart Pins should be cool, by all means call them "independent parallel running subsystems" if you like
Hardware assist is more up for grabs I'd say. I'm no fan of one-job-only special "IP" blocks ... but generic solutions that can be used for these jobs is all good with me.
.. and all good with Chip too - which why Smart Pins are coming.
Look forward to them being as general as possible, in the true Prop philosophy.
.. and all good with Chip too - which why Smart Pins are coming.
Look forward to them being as general as possible, in the true Prop philosophy.
Cool
I must admit, I was happy to go with whatever came of the earlier Prop2 design - whatever Chip thought could be done. I remember being very enthusiastic towards the hardware threads on the basis that combo drivers could be engineered around them very effectively. And later on when Chip was struggling to fit them to HubExec I was still supportive even though I didn't see great value in them being visible at that level.
That was, of course, back when only 8 Cogs were in the mix.
Comments
You have said very succinctly what I and many others have been saying for years. For example in this very thread recently http://forums.parallax.com/showthread.php/159928-Is-it-time-to-re-examine-the-P2-requirements?p=1315473&viewfull=1#post1315473
Thing is there are people who absolutely can't stand the idea of wasting a whole CPU on handling some tiny piece of code that does not get triggered very often. So they want their interrupts as well as many cores. Or perhaps they are stuck in the past and think interrupts is the only way to program.
The Prop was designed to be free of the complications of interrupts and be used exactly as you say.
Given the benefits of not having interrupts I'm happy to trade of some silicon for it. With P2 and 16 cores there is even less reason to want interrupts, you have another 8 "interrupt handlers" ready to wait on your events!
I wrote this driver for Omnia Creator's spin interface library.
For example a driver COG, like a serial receiver, may well be using WAITxxx on a pin or a timer to do it's work. Like an interrupt routine. So far so good.
But now we have the "main cog" having to poll the output of the driver COG. We have moved the polling up stream a bit from the driver polling for bits on the line to the main program polling the driver for bytes.
The main cog may call someSerialPort.read() and now that read function has to loop polling the someSerialPort for incoming data.
What we would like here is a means for a process in a COG to WAIT on data or a signal from another COG. That removes the polling and allows entering a low power do nothing state on calling read() until the signal is received.
Currently we can only do this via signalling on pins.
I don't know what anyone else wanted in the way of interrupts, but what I had in mind is much simpler than even the basic interrupt system on the Z80. It would be a very simple cog only interrupt that would be easy to implement.
The only context it would need to save would be the address to return to in the currently executing code.
Two consecutive cog registers that would hold a pin mask and the current pin states. The interrupt code would be executed when the state of the pins changes. This could be part of the smart pins if done on the P2.
The “enable_interrupts” instruction would set that up. The s and d fields would be pointers to the pin mask and the beginning of the interrupt code.
And that would be the default behaviour of the cog. Until you enabled the interrupts cogs would behave exactly as they do now.
If this type of simple interrupt was added to the P2 or an enhanced P1 that would still be the way it would be unless the interrupts were enabled. Even when the interrupts are enabled the code would have to be short and simple. After all, there is not that much room for code in a cog.
It's turtles all the way down.
Every time somebody says "give me an interrupt to run an interrupt handler code", I say "give me a CPU that can wait on the event and run that code".
How many external events should an MCU like the Propeller be able to respond too? That is how many CPU's it should have.
It's not really about missing interrupts or wanting to interrupt the main code. Yes, a cog can be dedicated to handling interrupts, but that pretty much ties the cog up for that one task, and using it for multiple interrupts is slow. Fine for a lot of things, but not for what the cogs do best.
Basically I agree with Dave Hein's post that adding a simple interrupt to each cog would make the cogs more powerful, and a lot of the other posts asking for interrupts seem to be along similar lines.
In two projects I had all 8 cogs in use and still needed to add 27 lines of pasm code to deal with a signal that came at somewhat random times but needed a very low latency response. Had several cogs with enough free space and time for the new pasm code until I added the polling calls into the existing code. I did manage to fit it in by juggling code around the cogs but a simple cog interrupt would have made the task trivial.
I'm really not an advocate for interrupts on the Propeller, but it's good to understand how people see it differently.
Exactly.
You did not need an interrupt. What you needed was another COG to handle that little low latency event. Which can't have been all that low latency else you would not have been able to combine it with other COG code.
Yes, I know it's a waste of a 32 bit CPU. This is 2015. That CPU is almost nothing, a spec of sand. Sadly the P1 only has 8. The P2 will have 16. Who knows what the future brings?
Yep, when we get to having one cpu per I/O pin I agree that interrupts are not needed. Until then they would be of some benefit.
PS 8.5uSec to respond.
Best not to waste RAM you paid for, just because the ALU cannot make use of it.
COGs are nowhere near a spec of sand yet. They consume significant die and power, and there are only 8 or 16 available. Each COG has cost you close to $1, more than a great many small micros out there.
Truth is you paid for the system, it's nature, silicon, etc... right along with its ecosystem of shared code.
I think bundling a few cheap chips together, along with code to make that mess work is very expensive and not all that easy to reuse, debug, and so forth.
A Prop, by comparison, is a great deal, and part of why it is a great deal is its nature and the implications that has on its ecosystem.
This is precisely why many of us do not want that nature changed.
Energy waste is very real, no matter how many you use, and your argument of 'Who cares' is only valid until your design grows to need 9+ COGS. (example given in #158)
Price is only 'don't care', to those working in low volumes.
Quite serious small MCUs are now sub 50c in moderate volumes.
Agree 100% with your great deal argument, but can't help wondering at the opposition to a change that adds capability without changing or taking away from what is already there.
I gave an example of a hard time-slices MCU that made it to silicon. ( and I think, had interrupts too )
P2 is certainly going to be smarter around event handling, with timeouts on waits, and smarter pins.
Smart pins may even allow a "quasi-interrupt" structure, where a common wait can be HW low power, then exit-wait on more than one event, execute that code and come back to check and execute the queued event.
Combine that with a timeout flag, and you have code that reacts quickly to events, but can also run some larger code that takes longer than one timeout to complete.
This "quasi-interrupt" may not react quite as quickly as a conventional MCU interrupt, but it can cover a great many application with the right Smart Pins.
If users need faster reaction times than a conventional MCU interrupt, a dedicated COG can deliver that.
Right. P1 has 8 of them and P2 hopefully 16. So just use one of them as Interrupt controller. Even on P1 waitpne and friends can check for multiple interrupt pins at once while in low power state.
This cog then can either handle the need job by itself or 'outsource' it via mailbox to a another cog and returning to its idle state.
Not doable on any single core.
And you still have other execution engines working in parallel without interruption while your interrupt gets handled by the handler and eventually dispatched to some other parallel process.
For what exactly do you need a interrupt again?
I do love the propeller for its unorthodox way of doing things. The main plan on it is to use parallel execution instead of a interrupted single core computation. Why you want to press this back into the mainstream, boring, complicated mess of interrupts and hardware registers for dedicated SPI, Hyper-bus, Quad-whatever?
It's not what the propeller is. Sure. Dedicated hardware for protocols and interrupts are what the mainstream MCs are doing. Almost all of them. If you think you need this in your life, do it. Use a PIC, ARM, Pentium, whatever. Why can't you let the propeller do it differently?
Why are you constantly voting for dedicated HW support for whatever protocol, interrupts and other 'mainstream features' when the main goal of @chip on the propeller was to NOT have those things in the first place?
NOT having dedicated hardware and NOT having interrupts and NOT having tons of HW-registers and Data Sheets and different Versions of the same stupid chip because of different HW and pins is exactly what the Propeller is about.
If you remove that from the propeller (or add, depending on view) it is not a propeller anymore but just another MC like all of the other ones.
Quite confused!
Mike
QuadSPI is an industry standard, and cheap.
Software banging everything simply fails energy efficiency tests, as well as fails Speed tests.
If dedicated hardware confuses you, and is somehow anti-prop you'll be very confused by the Smart Pins Chip plans.
Yes, those smart pins are dedicated hardware.
( I guess you can always simply not use any of that ? )
Counter may be 'dedicated Hardware' but not bound to a specific protocol or specific pins. In one way you could say them counters are predecessors of them upcoming smart pins. Independent units performing a parallel subtask. If you had chosen Video out, I may have had to agree, even if it is usable for fast SPI out also. But you didn't.
As of what them smart pins will do or not do? Nobody knows really. Not even @Chip I guess. They are still work in progress. It is a continuation of the base propeller concept. Each pin gets its own execution unit. More like a state machine I guess. Hopefully usable for a lot of different things and not just as UART or QuadSPI.
So it is not dedicated Hardware but more general orientated Hardware.
One of the main point of the propeller is that, thru software devices' you can use the same chip for various different projects one of them, not 50 different ones. Need to drive 32 Servos? Doable. see Duanes code and examples. Need 16 UARTs? Doable. Even used by NASA in space. 4 sd cards with one prop? no problem. See RAISD. Multiple VGA and or TV screens? Sure. I can go on here but you get the point I guess.
Dedicated HW for say Hyper-bus is lost for you as a programmer if you do not need Hyper-bus. A cog used for Hyper-bus communication can be used for other things if you do not need Hyper-bus. Even more. If in five years some warp-bus is the now new way to go, some smart *** will write a PASM driver for it using the same cog used for Hyper-bus.
What I like to bring across is that it is more important to be able to generate precise signals with fast timing programmable in software in opposite to have fixed HW bound to a specific protocol like (quad)SPI,UART,USB,TCP/IP, whatever.
That is where the propeller shines. Soft devices. I am pretty eager to see @Chips first incarnation of them smart pins. What a brilliant Idea. 16 parallel running cogs AND independent parallel running subsystems for each pin. How cool is that.
Anyone still missing single core execution and interrupts?
Enjoy!
Mike
The Prop is targeted at being slim with plentiful cores. If it's design changed tact to be a typical bloated CPU it would be just another multi-core processor.
Hardware assist is more up for grabs I'd say. I'm no fan of one-job-only special "IP" blocks ... but generic solutions that can be used for these jobs is all good with me.
I almost felt I was alone here.
Enjoy!
Mike
Alone? Hey, I'm here too you know
Yes, Smart Pins should be cool, by all means call them "independent parallel running subsystems" if you like
.. and all good with Chip too - which why Smart Pins are coming.
Look forward to them being as general as possible, in the true Prop philosophy.
Cool
I must admit, I was happy to go with whatever came of the earlier Prop2 design - whatever Chip thought could be done. I remember being very enthusiastic towards the hardware threads on the basis that combo drivers could be engineered around them very effectively. And later on when Chip was struggling to fit them to HubExec I was still supportive even though I didn't see great value in them being visible at that level.
That was, of course, back when only 8 Cogs were in the mix.