With interrupts, don't forget the software overhead... I mean instructions to save and restore registers (which we do not really have), vector tables, etc. These all take away the very limited code space we have in a cog (496 longs).
If you want to run interrupts like back in the dark ages (i.e. before the prop) then dedicate a cog to it! I am sure you can work an easy way. Remember, a lot of the requirements for interrupts like when a character is assembled in a UART and needs to be read before it is overwritten simply does not exist in the prop. The cog takes care of this, and a whole lot more inside that cog is possible, including an almost unlimited buffer space in hub if that is what you want. You just need to think differently - it really is simpler, not harder, so don't overcomplicate the solution here!!!
I feel compelled to comment/rant(?) that at what point does an idea that helped spark the original Prop become a potential bottleneck to its future success?
I think I've learned from one of the threads on how the Prop came about, that -not- having interrupts was one of the fundamental goals. That has been done, and successfully enough that its sales among others have allowed for the R&D of Prop II. Congrats.
However I've been off the board for a couple of months, and just read that Parallax went ahead and launched Parallax Semi. Obviously Parallax wants to expand and grow, and is targeting more business/industry related entities.
Most of the folks who work at Parallax Semi's newly targeted customer base grew up with, went to school with, and now program on interrupt-based procs.
I really fail to see how demonizing interrupts as obsolete/dark ages/basically the stupid way of doing things is in any way going to help Parallax entice these existing HW developers to give the Prop/II more than a once-over.
"Hey, come buy our stuff and stop doing things the stupid way. Thats so 1990's..."
In fact, I just checked and even Parallax seems to have figured out that might not be the way to sell themselves. There is no mention of Interrupts, or their absence thereof, on the "Our Multicore Concept" page. Why has the main selling point of the Prop gone missing from arguably THE most important page of a new business venture? Is it just a coincidence?
I think too many Prop'ers going overboard at the drop of a hat on the evils of interrupts and the Ultimate Wonderfulness of non-interrupt is starting to veer into a weird cultish type thing.
I can see where someone who has worked for years in the industry and is truely happy to not have to use interrupts may not want to see any changes to what has been up until now a good thing.
But seriously now, some of the replies to 4X5 seem to be almost purposely disingenuous merely to avoid saying anything possibly good about interrupts. Some of the replies are as absurd as you going in to buy a nice 8-core machine this Christmas, and finding out that "oh, well yes you do in fact get 8 cores, but one of them is used for interrupts/polling, and another is used entirely by the keyboard".
Not -having- to do interrupts is great, but that does not in any way mean that having an option to use them is bad.
As I asked in opening, at what point does a foundational point of a project become a potential limiter on future success?
This is someone's baby, and they are absolutely entitled to do as they see fit.
I'm simply of the opinion that interrupts are fundamental to most if not all current HW designers.
In my non-scientific sample of engineers, not having interrupts is hands down the biggest barrier to acceptance or further interest in expending any time to investigate further.
And before someone says thats fine, we don't need them anyways, consider the fact that Parallax has invested at least some sort of time, capital and resources to attract these very people.
And it is these people who could potentially make or break a future Prop III via Parallax Semi's success in attracting their interest.
Sorry for the rant, not directed at anyone in particular; but I would like to see Parallax Semi succeed. And if there is a way to add interrupts as an option, I think standing on principle in this respect is cutting off one's nose to spite one's face.
I don't see a real need for interrupts in the Prop. As long a spare cog is available it can run a tight polling loop, and respond as quickly (or quicker) than an interrupt service routine could. The only real case where an interrupt could be useful is if all the cogs are in use, and there is a need to provide a low-latency service routine. I don't believe that happens in most applications, but I could be wrong.
I don't think the lack of interrupts will scare away commercial developers. It may take them a while to understand how to program the multiple cogs efficiently, but the lack of interrupts shouldn't be a problem.
I try to stay out of the interrupt threads because they always end up with the cultist saying that anyone that uses interrupts is a neanderthal and might as well just go play with the Arduino kids, but...
The recurring reason given is that a cog can be dedicated to servicing the "interrupt" type task, so true interrupts are not needed. However, in a lot of cases the main program still needs to be aware that the "interrupt" occured. For example the main program still needs to do something with the character that the "UART" cog just received. In this case the "UART" cog took care of receiving the character, but the main program still MUST POLL some hub location to see if the "UART" received a character.
I feel compelled to comment/rant(?) that at what point does an idea that helped spark the original Prop become a potential bottleneck to its future success?
At what point does the introduction of a major architecture change kill a product?
This thread was/is a solicitation of input to a question that Chip had brought up during his talk at UPENE. During the ongoing development of the Prop II, the issue had come up about adding buffers to various parts of the chip architecture and the impact it would have on clocking and or instruction cycles. From this, he had posed the original question. There are fabrication and design issues constraining the features and at this point in the process, there isn't much room for additional features.
Adding support for interrupts as an option is a fundamental architecture change that would blow the doors off of the fabrication and production constraints and probably render the Prop II an impossibility. (This is all based on what I've read and heard from Chip...not my no-existent knowledge as a IC designer/fabricator). Adding interrupt vectors, prioritizers, context switching support, etc. to make interrupts an option is a major internal architecture change that the Prop II would not survive.
Through this entire thread, the responses and discussion has been amongst (sometime passionate) propellerheads and not anyone from Parallax. Everyone has opinions about the hardware they develop on some good, some bad, most passionate to some degree. There's a vast body of Propeller knowledge that has presented an alternative view to using interrupts and how to address traditional interrupt situations with a non-interrupting architecture. If the options are usable in a new adopters application or design style, great, if not then the Propeller may not be someone's best choice for a solution.
If you truly want a response from Parallax Semiconductor as to their decision to not adopt interrupts, then the question needs to be asked of them, not their users or at least posted in the Parallax Semiconductor forum. I don't think Parallax has said
"Hey, come buy our stuff and stop doing things the stupid way. Thats so 1990's..."
Fans have expressed their opinions as to how they work without interrupts and how they think it is a better way to do things in many cases or how they have worked around not having interrupts.
The fundamental idea is that given enough hardware that can process things in
parallel there no need for interrupts. For any and every possible external (or
internal) asynchronous event there can be a hardware element just waiting to
deal with it. And importantly able to deal with it without any effect whatever
on everything else that is going on in the system.
Logically interrupts are not required, they have only ever been there to make the illusion of the above parallel scenario on non-parallel hardware. At the cost of determinism.
Now to what degree the Propeller fulfills that ideal is open to debate which
seems to be what is going on here. Perhaps the Prop could do with more cores,
or deterministic threads for many applications in order to remain interrupt
free. Perhaps those of us with a downer on interrupts argue the case too
strongly. Perhaps wasting a 32 bit core on a keyboard is nuts.
In my non-scientific sample of engineers, not having interrupts is hands down
the biggest barrier to acceptance or further interest in expending any time to
investigate further.
I think those engineers in your sample are being particularly closed minded and
dumb. I would really like to have a word with them.
At risk of being lynched I have to point out that Parallax is not alone. There
is at least one other MCU manufacturer that promotes the ideal of multi-core,
multi-threaded (in hardware) interrupt free systems. And having some success.
Whilst their MCUs do actually support interrupts the whole thing set up to use
"event driven" programming. One never has to use or worry about interrupts.
Said MCU manufacturer will remain nameless here as usual.
Those engineers in your sample are denying themselves a fascinating world of
opportunities. Assuming of course that the Prop and similar MCUs are actually
suitable for their applications w.r.t. speed, memory, power consumption etc.
The problem with polling is that you then need to then need to weave the polling
throughout the code.
No you don't "need" to. Weaving polling code throughout your code is probably
the worst way to do it. From a purely aesthetic software engineering point of
view it's ugly, unreliable, unmaintainable, unpredictable, brittle etc etc. For
example it might require some code that is plodding it's way through some
calculation to check a totally unrelated input every time around a loop and
then call some unrelated function to deal with it. Yuck.
What I had in mind and tried to describe was something much more organized.
1) A timer triggers processing to commence every 1ms (say) from a waitcnt (say).
That processing then calls in turn all the functions that are under it's
control.
2) All of those functions are written in such away that they return
pretty soon (<< 1ms).
3) The system is put together such that ALL those functions
are done before the next 1ms.
4) Then we can sleep (waitcnt) for the next 1ms "tick"
It is quite possible to ensure all is done in less than 1ms as
you know the execution time of all the parts involved. There are systems where
the compiler will tell you the execution time and hence that you are meeting
the timing requirement. On the Prop you probably have to count instructions
cycles manually.
One of those functions may be, from your example, the thing that detects the
hydraulic RAM limit input going active and does something about it. Another
might be that guy plodding through some long winded calculation.
The former task may not have a loop just a quick few instructions to do the
check and perform the action.
The later task may not have completed its calculation entirely in the time you
have allocated it but in this system must return anyway. That's not good you
say. Well it's OK. He just has to remember his current state and return. When he
is called again on the next 1ms tick he can resume from the last position in
the calculation and do a bit more.
With this kind of program architecture different functionality is clearly
separated into different functions and modules. The timing of everything is
known and under control. Very neat and orderly. Much easier to see and prove
what is going on than randomly scattering polling statements around the code.
Your description of how to deal with timed processing is precisely how my multi-threaded scheduler works.
Except:
1) the timer is variable, set by the next-to-run thread, with one usec resolution.
2) the functions are forced to return in 10 or so usec, or what ever latency you can tolerate.
3) all active threads are processed piece-meal (very simple interleaving) as resources are available.
4) the cog is "waitcnted" until the next thread needs to run, dropping power consumption to a very low level.
That is how I have dealt with a "polling" type of alternative to interrupts, and it works verrrrry well. That said, there are still things I could improve with a very simple one-level interrupt based on a "int-on-pin" and "int-on-cnt"..
For those who say it is stupid, or not required, or just plain backwards and "old", their needs may be much simpler,and just are not aware of what my needs are.
I squeeze a LOT out of each cog.... helping some on the forum with projects that have run out of cogs, principally due to multiple "wait" instructions, and my scheduler saves their bacon.
Evenso, I still wish I had a simple interrupt available to use.........or not.
I really fail to see how demonizing interrupts as obsolete/dark ages/basically the stupid way of doing things is in any way going to help Parallax entice these existing HW developers to give the Prop/II more than a once-over.
Very important point. Thanks.
It is not good for Parallax or Propeller growth to be so fanatic about the lack of interrupts.
Propeller people know how to deal with this technically, and everyone else can learn if they like.
However there are far fewer Propeller people in the world than not. So, let's "give it a rest" here.
If you want to start another interrupt thread, go ahead.
Discussing the merits and disadvantages of interrupts for Propeller on this forum is generally futile.
thanks and in the main I agree with you.
I actually could care less if the Prop were to get interrupts, I don't see myself exceeding available resources to need them.
Some of the hoop jumping as regards the capabilities/usefulness of interrupts seemed a bit odd coming from what until now has seemed like one of the most level-headed forums I've ever been on.
In the end if there is not an interrupt capability built into the Prop II then the market will not get a chance to decide.
Because if it isn't there then certain sections of the market will not consider the Prop II , where as if it implemented then the market can use the Prop II and then decide to use interrupts or not.
It will come down to whether implementing the design of interrupts on the Prop II would stop some fantastic incredible new features on the Prop II , and then it would be a weighing of which features would be more worthwhile.
An interrupt handler is possible to add for Propeller for SPIN or LMM type programs.
Edge triggered no-miss hardware interrupts can be emulated using a COG counter.
There are software design trade-off's to get this functionality though.
Please move further interrupt discussions to another thread.
I agree, however I thought I'd beat that like a dead horse already.
I had a whole paragraph relating Prop to async processing that I deleted from my reply to Heater.
To be blunt, it hasn't been overly successful there, and hard to say how far Parallax and The Other will get in a simlar vein now.
Not having interrupts is unique and interesting, but seems more like a solution looking for a problem that few people seem to be complaining about nowadays.
Who knows though, there may be enough momentum with existing and occasionally new customers to fund Prop through v3/4/etc.
As long as Parallax can find a profitable niche, then they don't need to sell millions. But I'm sure they'd like to.
Please return to the main point of the thread. What clock speed/execution pipeline combo is best for us? 100/3 or 160/5. Perhaps somebody can explain the ramifications for each choice as we best understand it?
Seems to me the simplest resolution for this is for someone to write an interrupt module to run on a single cog and upload it to OBEX.
Then those people who still think in terms of interrupts can migrate to the prop using methodologies that they're familiar with. Then, given time they'll naturally stop using it.
Quick poll:
How many people have learned a second language only to try and write code using the exact same constructs and methods of your first?
__red__,
Interesting analogy, interrupts and languages.
Some time ago programmers started getting organized in their work. Block structured languages were one result. The GOTO was pretty much banned as it encouraged unstructured, hard to understand/maintain code. It was realized that GOTO was logically not necessary if your language supported "if", "for", "while" etc.
Now modern programmers are continuing the job of getting organized. They would prefer "event" driven programming and hardware that supports it, hopefully with lots of parallelism. They see that an interrupt is a GOTO. But much worse because it is not even under the control of your code when it occurrs!!! interrups should be "considered harmful" like the GOTO. Interrupts are logically not necessary.
The only reason interrupts have slipped through the net for so long is that the hardware did not offer any help in getting rid of them.
And that's all I have to say on that.
__red__,
Interesting analogy, interrupts and languages.
Some time ago programmers started getting organized in their work. Block structured languages were one result. The GOTO was pretty much banned as it encouraged unstructured, hard to understand/maintain code. It was realized that GOTO was logically not necessary if your language supported "if", "for", "while" etc.
Now modern programmers are continuing the job of getting organized. They would prefer "event" driven programming and hardware that supports it, hopefully with lots of parallelism. They see that an interrupt is a GOTO. But much worse because it is not even under the control of your code when it occurrs!!! interrups should be "considered harmful" like the GOTO. Interrupts are logically not necessary.
The only reason interrupts have slipped through the net for so long is that the hardware did not offer any help in getting rid of them.
And that's all I have to say on that.
So you prefer cooperative multitasking to preemptive multitasking?
The UPEC (Chicagoland) thread (I believe) stated that a couple of plausible timelines were mentioned during Chip's presentation (I think), but no one has come forth to provide any more details, likely because it was somewhat speculative (turns out this chip-designing business is rather difficult). Either that or all the attendees were sworn to secrecy with a promise of early silicon. Hmm...if I were in the conspiracy-concocting business, I'd be wondering why the "squeaky wheels" that normally request info have all seemingly stopped clammoring for more instruction set details (the silence is deafening, though perhaps I missed a post). Anyway, the latest on a "timeline" from someone within Parallax that I can recall was a post with words to the effect of, "...in the not too distant future," which, while not as exciting as "in the near future," gives reason to be hopeful, at least for the faithful (myself included (pass me another cup)). Wikipedia's entry on Parallax (the company, not the entry on the Propeller chip), has the Propeller 2 expected for release "by 2011," though perhaps they're using a more precise calendar than most of the world, being Wikipedia and all. But I've still got breath to hold.
Anyway, it's rather obvious to me that Parallax is a bit frustrated at having suggested various timeframes in the past only to see them slip away due to unforeseen complexities and perhaps added chip functionality (as they make very admirable efforts to operate with integrity). And we all know that they are more resource-constrained than the so-called "big guys." As such, I'm guessing that they've decided to cut back on such updates until they have more certainty, much as they'd like to keep us as informed as possible. However, perhaps the pendullum has swung a bit too far in the keeping "mum" direction (we're big boys and girls and can handle some delay). Still, with all the crazy lawsuits these days, perhaps they don't want to provoke a time-consuming legal battle with a company that might interpret their best-guess projections as contractual promises. As for me in my own life, I've kind of gotten used to the fact that things often take me about three times longer than I initially expected. On the other hand, often, a lot of progress is made in a short time with concentrated effort. So, we can guess that that's what is going on within Parallax right now--lots of continuing concentrated effort. Having said all that, I'd still be more than happy to read the latest hearsay, rumors and projections, both from within and outside Parallax. However, I know, ROM (no "e") was not built in a day, and patience is a virtue. Anyone? National Enquirer?
There was a secret meeting of the "clan". It was so secret that even those in attendence didn't know they were there, nor what was said
Back to reality... it will arrive when it arrives and we will all get to hear about the features and instruction set when those in the know get the time to inform us.
"She'll be coming 'round the mountain when she comes." Sorry, I had to get a quote in there, too (and it matches Cluso's comment). It seems you guys with your well-selected quotes say more in a phrase than a couple of paragraphs. Nicely done! Eh, any quips about pots and boiling water? Anyway, I've placed an order for my clan propeller beanie so that I can attend the next super-secret meeting (even though I won't know that I'm in attendance). Anyway, I was pleased to see the interrupt discussion interrupted with inqueries about timing.
Very interesting...I keep checking all the time for updates...it looks like a very exciting product and I have always enjoyed hearing about the progress...
It claims All variations are in volume production, with prices beginning from $5.74 for the STM32F407VET6 with 512 Kbytes of Flash and 192 Kbytes RAM in the LQFP100 package, for orders of more than 1,000 units.
tho no one seems to have stock yet...
There is a good looking STM32 F4 Discovery Kit (STM32F4DISCOVERY), priced as low as $16.-$19
This has the 1MF 192KR 100p variant.
Comments
If you want to run interrupts like back in the dark ages (i.e. before the prop) then dedicate a cog to it! I am sure you can work an easy way. Remember, a lot of the requirements for interrupts like when a character is assembled in a UART and needs to be read before it is overwritten simply does not exist in the prop. The cog takes care of this, and a whole lot more inside that cog is possible, including an almost unlimited buffer space in hub if that is what you want. You just need to think differently - it really is simpler, not harder, so don't overcomplicate the solution here!!!
I'm sure you're right and that after I spend more time with the propeller and spin I'll come to realize that interrupts aren't useful.
In many instances it's just a couple lines of code added to oft-called subroutines.
I think I've learned from one of the threads on how the Prop came about, that -not- having interrupts was one of the fundamental goals. That has been done, and successfully enough that its sales among others have allowed for the R&D of Prop II. Congrats.
However I've been off the board for a couple of months, and just read that Parallax went ahead and launched Parallax Semi. Obviously Parallax wants to expand and grow, and is targeting more business/industry related entities.
Most of the folks who work at Parallax Semi's newly targeted customer base grew up with, went to school with, and now program on interrupt-based procs.
I really fail to see how demonizing interrupts as obsolete/dark ages/basically the stupid way of doing things is in any way going to help Parallax entice these existing HW developers to give the Prop/II more than a once-over.
"Hey, come buy our stuff and stop doing things the stupid way. Thats so 1990's..."
In fact, I just checked and even Parallax seems to have figured out that might not be the way to sell themselves. There is no mention of Interrupts, or their absence thereof, on the "Our Multicore Concept" page. Why has the main selling point of the Prop gone missing from arguably THE most important page of a new business venture? Is it just a coincidence?
I think too many Prop'ers going overboard at the drop of a hat on the evils of interrupts and the Ultimate Wonderfulness of non-interrupt is starting to veer into a weird cultish type thing.
I can see where someone who has worked for years in the industry and is truely happy to not have to use interrupts may not want to see any changes to what has been up until now a good thing.
But seriously now, some of the replies to 4X5 seem to be almost purposely disingenuous merely to avoid saying anything possibly good about interrupts. Some of the replies are as absurd as you going in to buy a nice 8-core machine this Christmas, and finding out that "oh, well yes you do in fact get 8 cores, but one of them is used for interrupts/polling, and another is used entirely by the keyboard".
Not -having- to do interrupts is great, but that does not in any way mean that having an option to use them is bad.
As I asked in opening, at what point does a foundational point of a project become a potential limiter on future success?
This is someone's baby, and they are absolutely entitled to do as they see fit.
I'm simply of the opinion that interrupts are fundamental to most if not all current HW designers.
In my non-scientific sample of engineers, not having interrupts is hands down the biggest barrier to acceptance or further interest in expending any time to investigate further.
And before someone says thats fine, we don't need them anyways, consider the fact that Parallax has invested at least some sort of time, capital and resources to attract these very people.
And it is these people who could potentially make or break a future Prop III via Parallax Semi's success in attracting their interest.
Sorry for the rant, not directed at anyone in particular; but I would like to see Parallax Semi succeed. And if there is a way to add interrupts as an option, I think standing on principle in this respect is cutting off one's nose to spite one's face.
I don't think the lack of interrupts will scare away commercial developers. It may take them a while to understand how to program the multiple cogs efficiently, but the lack of interrupts shouldn't be a problem.
The recurring reason given is that a cog can be dedicated to servicing the "interrupt" type task, so true interrupts are not needed. However, in a lot of cases the main program still needs to be aware that the "interrupt" occured. For example the main program still needs to do something with the character that the "UART" cog just received. In this case the "UART" cog took care of receiving the character, but the main program still MUST POLL some hub location to see if the "UART" received a character.
C.W.
At what point does the introduction of a major architecture change kill a product?
This thread was/is a solicitation of input to a question that Chip had brought up during his talk at UPENE. During the ongoing development of the Prop II, the issue had come up about adding buffers to various parts of the chip architecture and the impact it would have on clocking and or instruction cycles. From this, he had posed the original question. There are fabrication and design issues constraining the features and at this point in the process, there isn't much room for additional features.
Adding support for interrupts as an option is a fundamental architecture change that would blow the doors off of the fabrication and production constraints and probably render the Prop II an impossibility. (This is all based on what I've read and heard from Chip...not my no-existent knowledge as a IC designer/fabricator). Adding interrupt vectors, prioritizers, context switching support, etc. to make interrupts an option is a major internal architecture change that the Prop II would not survive.
Through this entire thread, the responses and discussion has been amongst (sometime passionate) propellerheads and not anyone from Parallax. Everyone has opinions about the hardware they develop on some good, some bad, most passionate to some degree. There's a vast body of Propeller knowledge that has presented an alternative view to using interrupts and how to address traditional interrupt situations with a non-interrupting architecture. If the options are usable in a new adopters application or design style, great, if not then the Propeller may not be someone's best choice for a solution.
If you truly want a response from Parallax Semiconductor as to their decision to not adopt interrupts, then the question needs to be asked of them, not their users or at least posted in the Parallax Semiconductor forum. I don't think Parallax has said Fans have expressed their opinions as to how they work without interrupts and how they think it is a better way to do things in many cases or how they have worked around not having interrupts.
A very good rant:)
The fundamental idea is that given enough hardware that can process things in
parallel there no need for interrupts. For any and every possible external (or
internal) asynchronous event there can be a hardware element just waiting to
deal with it. And importantly able to deal with it without any effect whatever
on everything else that is going on in the system.
Logically interrupts are not required, they have only ever been there to make the illusion of the above parallel scenario on non-parallel hardware. At the cost of determinism.
Now to what degree the Propeller fulfills that ideal is open to debate which
seems to be what is going on here. Perhaps the Prop could do with more cores,
or deterministic threads for many applications in order to remain interrupt
free. Perhaps those of us with a downer on interrupts argue the case too
strongly. Perhaps wasting a 32 bit core on a keyboard is nuts.
I think those engineers in your sample are being particularly closed minded and
dumb. I would really like to have a word with them.
At risk of being lynched I have to point out that Parallax is not alone. There
is at least one other MCU manufacturer that promotes the ideal of multi-core,
multi-threaded (in hardware) interrupt free systems. And having some success.
Whilst their MCUs do actually support interrupts the whole thing set up to use
"event driven" programming. One never has to use or worry about interrupts.
Said MCU manufacturer will remain nameless here as usual.
Those engineers in your sample are denying themselves a fascinating world of
opportunities. Assuming of course that the Prop and similar MCUs are actually
suitable for their applications w.r.t. speed, memory, power consumption etc.
No you don't "need" to. Weaving polling code throughout your code is probably
the worst way to do it. From a purely aesthetic software engineering point of
view it's ugly, unreliable, unmaintainable, unpredictable, brittle etc etc. For
example it might require some code that is plodding it's way through some
calculation to check a totally unrelated input every time around a loop and
then call some unrelated function to deal with it. Yuck.
What I had in mind and tried to describe was something much more organized.
1) A timer triggers processing to commence every 1ms (say) from a waitcnt (say).
That processing then calls in turn all the functions that are under it's
control.
2) All of those functions are written in such away that they return
pretty soon (<< 1ms).
3) The system is put together such that ALL those functions
are done before the next 1ms.
4) Then we can sleep (waitcnt) for the next 1ms "tick"
It is quite possible to ensure all is done in less than 1ms as
you know the execution time of all the parts involved. There are systems where
the compiler will tell you the execution time and hence that you are meeting
the timing requirement. On the Prop you probably have to count instructions
cycles manually.
One of those functions may be, from your example, the thing that detects the
hydraulic RAM limit input going active and does something about it. Another
might be that guy plodding through some long winded calculation.
The former task may not have a loop just a quick few instructions to do the
check and perform the action.
The later task may not have completed its calculation entirely in the time you
have allocated it but in this system must return anyway. That's not good you
say. Well it's OK. He just has to remember his current state and return. When he
is called again on the next 1ms tick he can resume from the last position in
the calculation and do a bit more.
With this kind of program architecture different functionality is clearly
separated into different functions and modules. The timing of everything is
known and under control. Very neat and orderly. Much easier to see and prove
what is going on than randomly scattering polling statements around the code.
Your description of how to deal with timed processing is precisely how my multi-threaded scheduler works.
Except:
1) the timer is variable, set by the next-to-run thread, with one usec resolution.
2) the functions are forced to return in 10 or so usec, or what ever latency you can tolerate.
3) all active threads are processed piece-meal (very simple interleaving) as resources are available.
4) the cog is "waitcnted" until the next thread needs to run, dropping power consumption to a very low level.
That is how I have dealt with a "polling" type of alternative to interrupts, and it works verrrrry well. That said, there are still things I could improve with a very simple one-level interrupt based on a "int-on-pin" and "int-on-cnt"..
For those who say it is stupid, or not required, or just plain backwards and "old", their needs may be much simpler,and just are not aware of what my needs are.
I squeeze a LOT out of each cog.... helping some on the forum with projects that have run out of cogs, principally due to multiple "wait" instructions, and my scheduler saves their bacon.
Evenso, I still wish I had a simple interrupt available to use.........or not.
Cheers,
Peter (pjv)
It is not good for Parallax or Propeller growth to be so fanatic about the lack of interrupts.
Propeller people know how to deal with this technically, and everyone else can learn if they like.
However there are far fewer Propeller people in the world than not. So, let's "give it a rest" here.
If you want to start another interrupt thread, go ahead.
Discussing the merits and disadvantages of interrupts for Propeller on this forum is generally futile.
thanks and in the main I agree with you.
I actually could care less if the Prop were to get interrupts, I don't see myself exceeding available resources to need them.
Some of the hoop jumping as regards the capabilities/usefulness of interrupts seemed a bit odd coming from what until now has seemed like one of the most level-headed forums I've ever been on.
The market will ultimately decide.
In the end if there is not an interrupt capability built into the Prop II then the market will not get a chance to decide.
Because if it isn't there then certain sections of the market will not consider the Prop II , where as if it implemented then the market can use the Prop II and then decide to use interrupts or not.
It will come down to whether implementing the design of interrupts on the Prop II would stop some fantastic incredible new features on the Prop II , and then it would be a weighing of which features would be more worthwhile.
Edge triggered no-miss hardware interrupts can be emulated using a COG counter.
There are software design trade-off's to get this functionality though.
Please move further interrupt discussions to another thread.
I had a whole paragraph relating Prop to async processing that I deleted from my reply to Heater.
To be blunt, it hasn't been overly successful there, and hard to say how far Parallax and The Other will get in a simlar vein now.
Not having interrupts is unique and interesting, but seems more like a solution looking for a problem that few people seem to be complaining about nowadays.
Who knows though, there may be enough momentum with existing and occasionally new customers to fund Prop through v3/4/etc.
As long as Parallax can find a profitable niche, then they don't need to sell millions. But I'm sure they'd like to.
Edit- Sorry, enough on interrupts I agree.
Then those people who still think in terms of interrupts can migrate to the prop using methodologies that they're familiar with. Then, given time they'll naturally stop using it.
Quick poll:
How many people have learned a second language only to try and write code using the exact same constructs and methods of your first?
It's the same principle.
-Phil
Interesting analogy, interrupts and languages.
Some time ago programmers started getting organized in their work. Block structured languages were one result. The GOTO was pretty much banned as it encouraged unstructured, hard to understand/maintain code. It was realized that GOTO was logically not necessary if your language supported "if", "for", "while" etc.
Now modern programmers are continuing the job of getting organized. They would prefer "event" driven programming and hardware that supports it, hopefully with lots of parallelism. They see that an interrupt is a GOTO. But much worse because it is not even under the control of your code when it occurrs!!! interrups should be "considered harmful" like the GOTO. Interrupts are logically not necessary.
The only reason interrupts have slipped through the net for so long is that the hardware did not offer any help in getting rid of them.
And that's all I have to say on that.
So you prefer cooperative multitasking to preemptive multitasking?
C.W.
Yes, What is the status of the Prop II???
Are we going to see one by Christmas? by UPEW 2012?
Anyway, it's rather obvious to me that Parallax is a bit frustrated at having suggested various timeframes in the past only to see them slip away due to unforeseen complexities and perhaps added chip functionality (as they make very admirable efforts to operate with integrity). And we all know that they are more resource-constrained than the so-called "big guys." As such, I'm guessing that they've decided to cut back on such updates until they have more certainty, much as they'd like to keep us as informed as possible. However, perhaps the pendullum has swung a bit too far in the keeping "mum" direction (we're big boys and girls and can handle some delay). Still, with all the crazy lawsuits these days, perhaps they don't want to provoke a time-consuming legal battle with a company that might interpret their best-guess projections as contractual promises. As for me in my own life, I've kind of gotten used to the fact that things often take me about three times longer than I initially expected. On the other hand, often, a lot of progress is made in a short time with concentrated effort. So, we can guess that that's what is going on within Parallax right now--lots of continuing concentrated effort. Having said all that, I'd still be more than happy to read the latest hearsay, rumors and projections, both from within and outside Parallax. However, I know, ROM (no "e") was not built in a day, and patience is a virtue. Anyone? National Enquirer?
-Phil
Back to reality... it will arrive when it arrives and we will all get to hear about the features and instruction set when those in the know get the time to inform us.
(my reply is MHz matters!)
http://www.eetimes.com/electronics-news/4227973/ST-adds-Cortex-M4-devices-to-STM32-portfolio
This part claims 168MHz, and from my reading, can clock the 32 bit timers at 168MHz.
They also mention 10.5 MBaud UARTS and 42 MBd SPI ports
It claims
All variations are in volume production, with prices beginning from $5.74 for the STM32F407VET6 with 512 Kbytes of Flash and 192 Kbytes RAM in the LQFP100 package, for orders of more than 1,000 units.
tho no one seems to have stock yet...
There is a good looking STM32 F4 Discovery Kit (STM32F4DISCOVERY), priced as low as $16.-$19
This has the 1MF 192KR 100p variant.
3 page brief on the Starter Board is here:
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/DM00037955.pdf
All this surely means Prop II has to be 160+MHz (and 5 V-tolerant I/Os too ? ) ?