Who says Propellers don't have interrupts???
mindrobots
Posts: 6,506
Every time I sit down to do anything with a Propeller, I seem to get interrupted! Often to the point of abandoning my Propeller plans!
Chip, can you remove that feature from the P2 before it goes to silicon??
Chip, can you remove that feature from the P2 before it goes to silicon??
Comments
You need to adjust your personal interrupt priority settings. Just give the Prop2 tasks priority over all these insignificant other tasks, like day-work, family, eating, sleeping ...
Andy
That is too funny.
C.W.
LOL
This kind of interrupt should be resolvable with using some high voltage for a moment...
Andy
As far as I know one thing that cats really hate is interrupts.
Ergo, cats love Propellers
Of course the other thing that cats like is warm places. That might not be so good in this context.
One of the best ways to generate IC killing static electricity is to rub plexiglass and a cat together. Here we have all three in close proximity !
Yeah, CW brought tnat up too. I'll have to break that habit before bad things happen. Now I'm worried too!
My cat should be quite proficient in P2 PASM as I find myself talking out load about bugs I'm chasing. or the very popular Using this technique has solved many problems!
Cheers
Brian
One option could be to liberally apply this to your cat...
So far, one out of one veterinarians recommend Static Gaurd for cats. Cool!
What would happen if each cog were re-designed with an interrupt? Just wondering.
Just an opinion here, but there is no need for them when you have 8 processors. There are enough for most jobs, so that each can stay focused on one task, eliminating the need for an interrupt.
Interrupts are an ugly hack to get a single processor appear to be many. Interrupts give rise to all kinds of complexity in having to worry about latencies, priority levels etc, which are all removed if you actually have many processors.
Now that we have hardware scheduled threads with the ability to wait on events interrupts are even less desirable.
As a huge bonus not having interrupts makes code sharing and reuse, for example by the use of Spin objects in the OBEX, much much easier.
I could go on but this has been discussed at extreme length on these forums for years already.
What Heater said.
With eight cogs, each of which can run up to four tasks, there really is no need for hardware interrupts.
Having said that, if you want interrupts, they are trivial to implement in software.
Set aside a cog as an "interrupt handler"
have a simple loop, that checks pins, and calls an "interrupt handler" when the pin changes.
Presto, interrupts.
Don't want to use a whole cog?
Run the "interrupt handler" as a task.
You'll still get a lower interrupt latency than many mcu's that support interrupts, with far less complexity, and far higher predictability.
Nope, no technical reason other than Chip chose not to have interrupts. It is a little interesting to see how many people dislike interrupts but do like their preemptive multitasking.
Isn't being redundant a sufficient technical reason not to do something?
I agree, those who favour preemtive scheduling but dismiss interrupts seem rather self-contradictory. A preempt is an interrupt after all.
But, it's a scheduled interruption, and not one of many that may compound at inopportune times.
"The Propeller does not have a hardware interrupt facility at the core of its architecture however it is able to simulate a hardware interrupt in many ways giving it a "soft" interrupt facility. With this soft interrupt facility, you can implement preemptive (interrupt driven) functionality."
If you look at other processors, the MSP430 in this case, you see interrupts are at the very core of the architecture.
The Propeller has no such functionality described in hardware.
Another fact that contributes to the basic philosophy of the Prop that Chip has stated many times and that we've settled on during the P2 community design process. The Propeller gives you the features in hardware you need to construct more complex functions or features that aren't in the hardware. Typical soft peripheral drivers are done through bit banging and polling but it is certainly possible to use the pins and WAITPxx instructions to implement something that appears to be interrupts.
With the preemptive multi-threading, there still aren't hardware interrupts, down deep, the hardware is still made to poll something under software control and then generate something the looks like an interrupt to trigger the thread context switch. Yes, it's a preemption(interrupt) to the thread but there is not hardware interrupt happening.
It's all part of the beauty of our 500 instruction RISC architecture!!
minrobots, I love it
I suspect we won't be seeing that on the PII product brief though.
Frankly, I was surprised at the CHK*** text support instructions.
Then, after overcoming surprise, I was pleased.
As they did not require a lot of logic, and there was room in the instruction set, they are a great way of saving memory.
Sure, writing the equivalent subroutines is trivial - but passing the register is not, so unless one was permanently dedicated, using such instructions saves at least one long per use.
That adds up quick
Due to memory limitations, I look forward to even more instructions that will save memory
Yes of course, that's it. Just redefine the acronym RISC = Rich Instruction Set Computer.
That can go on the PII product brief along with "32 bit, 8 core, hyper-threaded architecture". The definition of "RISC" can be in very small print at the bottom of the page
Works for me.
But seriously, I love that the p2 is still assembly language centric, but with a healthy helping of compiler-assist instructions.
Just think of the extra helper instructions as a built-in libpasm.a
The P2 has a RISC base set of instructions augmented by a special set of advanced instructions that (a) perform DSP style instructions such as multiply, divide, cordic, and (b) perform multiple instructions within a single instruction, and (c) perform special instructions for things such as stacks, extended call and return instructions, and (d) perform additional miscellaneous instructions.
The RISC instructions are the older P1 Instructions, with some minor differences.