Some of the Stamp models (BS2p/pe/px) have a special mode and special statements (POLLxxx) to provide for faster response to some hardware events, but it's still not interrupts. On the other hand, it's rare for a project using a Stamp to need them and the absence of interrupts generally simplifies programming.
The Propeller also does not have interrupts. It does have 8 independent processors on the chip, so you can assign one or more to tasks that require very rapid response. It's actually faster and more reliable than using interrupts as long as you have a free processor to assign to a task.
I have considered situations where a system reset could act like a "poor man's interrupt". For instance, a bump switch on a robot could trigger a hardware reset, which starts running the software from the beginning. So your software must start with the code you want to run "on interrupt", and then afterwards jump to the main portion of the program, never to return to the beginning until reset again. You would lose all data in RAM, but you can restore fixed initial values and you could recover data previously written to EEPROM. Might be a potential workaround for some situations, though not a viable substitute for a real interrupt.
when I tried to do a search on this question before posting it I came up with nothing - but when I posted the question a number of previous posts came up, one of which answered the question perfectly! Maybe I did something wrong in my advanced search.
alanfw
Posts: 3
Comments
Some of the Stamp models (BS2p/pe/px) have a special mode and special statements (POLLxxx) to provide for faster response to some hardware events, but it's still not interrupts. On the other hand, it's rare for a project using a Stamp to need them and the absence of interrupts generally simplifies programming.
The Propeller also does not have interrupts. It does have 8 independent processors on the chip, so you can assign one or more to tasks that require very rapid response. It's actually faster and more reliable than using interrupts as long as you have a free processor to assign to a task.
I have considered situations where a system reset could act like a "poor man's interrupt". For instance, a bump switch on a robot could trigger a hardware reset, which starts running the software from the beginning. So your software must start with the code you want to run "on interrupt", and then afterwards jump to the main portion of the program, never to return to the beginning until reset again. You would lose all data in RAM, but you can restore fixed initial values and you could recover data previously written to EEPROM. Might be a potential workaround for some situations, though not a viable substitute for a real interrupt.
-Phil
when I tried to do a search on this question before posting it I came up with nothing - but when I posted the question a number of previous posts came up, one of which answered the question perfectly! Maybe I did something wrong in my advanced search.
Alan
That's an interesting observation. Do you remember which search terms you used?
BTW, welcome to the Parallax Forum!
-Phil
Of course, my old Commodore 64 booted up "instantly" compared to a modern PC. But "that don't make it better" !