What if I _need_ an interrupt?

pacman · 2009-10-29 23:12

If I had a spin program running and one of the buttons is a 'reset' command.

Reset may not be the correct term..it's more of a 'return to start conditions'. This involves setting outputs to the 'start position' and re-establishing communications. I'm pretty sure this means I can not just drop power to the prop, or hit the 'power reset pin' I need the device to return to a known pre-defined state.

I was thinking a separate cog running 'return to start conditions' that when it picks up input X it cogStops all the others and then cogStarts them again. Each separate cog would have it's own 'startupstate' routine..

Does a cogstop stop a stop strait-away? (The problem I see is that if I'm running FullDuplexSerial in one of the cogs and I'm waiting for a communications timeout then does the cog still wait before stopping or is it immediate?

I'm sure the answer is painfully obvious (when you know how) but I've looked in the manual and can't see the "CrashCogNOW" command.

Perhaps I'm mis-thinking the problem?

Suggestions please...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
=================
The future is in our hands.
Which way to the future?
=================

localroger · 2009-10-29 23:25

I just had this problem. I built a unit to relay some device inputs to a computer via ethernet. The ethernet and some timeouts and stuff are configured by plugging a serial terminal in in place of one of the instruments, and settings are saved in the oversized EE (like the settings object, but simpler and leaner). Then, when you make changes, everything needs to be re-initialized.

Since I still had over 10 unused I/O pins, I just wired one of them to the reset pin with a pullup resistor. Works like a charm and requires only one DIRA statement to pull the trick.

ericball · 2009-10-29 23:28

COGSTOP (unlike COGINIT/COGNEW) is immediate. (Well, it's a HUB instruction so that's 7-22 cycles in PASM + SPIN overhead, but that's a close to immediate as you're gonna get.)

Anyway, the way I'd do it is to have the main cog start up all of the other cogs, then start watching that reset button. When the button is pressed, it can then cogstop (or invoke the "stop" method) & cogstart eveything.

If you really wanted to be harsh, you could just cogstop all of the cogs except for the one running the reset watcher.

This also assumes all of the methods are "restartable" and don't do tricky things like re-using the HUB-RAM occupied by PASM code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

Peter Jakacki · 2009-10-29 23:31

From the manual:

COGSTOP (CogID )
• CogID is the ID (0 – 7) of the cog to stop.
COGSTOP stops a cog whose ID is CogID and places that cog into a dormant state. In the
dormant state, the cog ceases to receive System Clock pulses so that power consumption is
greatly reduced.

This means that any cog can stop any cog (including itself) and that this is not dependent upon what the other cog is doing as the System clock from that cog is removed, the cog just stops.

The answer to your question though is probably not so simple as it is always application specific. Are there any variables you need that are stored in a cog's memory? Maybe the reset button can be handled by the cogs that need to know so they can tidy up and than after a short delay to make sure everything is settled you can "reset" the program.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

lonesock · 2009-10-29 23:37

@localroger:

Here is the PASM code I use to reset the prop when needed:

reset_the_prop
              mov tmp,#%1000_0000
              clkset tmp

Saves a pin

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

localroger · 2009-10-30 00:57

Thanks Jonathan, that's something I never would have thought of. Well maybe not until I've been propping for another year or four. You just saved me a jumper and resistor to be added to future PropRPM's, and as you say a pin on any tight future projects.

SamMishal · 2009-10-30 04:30

lonesock said..

reset_the_prop
              mov tmp,#%1000_0000
              clkset tmp

Lonesock,

Is this a secret implementation in PASM for the REBOOT Spin command?

I looked in the manual but there is no PASM equivalent to the REBOOT spin command.
So is setting the Clk to the %1000_0000 a SECRET way to do the rebooting?
This is not mentioned anywhere in the manual!!!

Regards

Samuel
·

Andrey Demenev · 2009-10-30 04:52

SamMishal said...
This is not mentioned anywhere in the manual!!!

It is. See "CLK register" section

lonesock · 2009-10-30 05:25

Andrey Demenev said...

SamMishal said...
This is not mentioned anywhere in the manual!!!

It is. See "CLK register" section

When I was looking through the SPIN interpreter code (anybody know why it was the "Pnut" Interpreter?), I was trying to figure out what was going on in the CLKSET code. I looked it up in the manual, and behold, the reset functionality. Strange place to put it, but hey, it works

Jonathan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

BradC · 2009-10-30 05:27

lonesock said...
(anybody know why it was the "Pnut" Interpreter?)

I believe that was one of the names the chip was known by during it's gestation period.

Incidentally, the interpreter code is gold for anyone looking for some advanced tricks in PASM, or a better understanding of why the interpreter does what it does.

The interpreter was my sole documentation when I was writing a compiler. It's all in there in gory detail [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?

MagIO2 · 2009-10-30 07:17

Just some additional notes:

Depending on the devices attached to the propeller it could be better to not being to harsh. For example if one COG is in the middle of writing something to EEPROM a reset or even a COGSTOP would cause inconsistencies in data.

You should also consider that a COGSTOP causes all ports used by the COG are set back to inputs. In some cases it might be desirable to hold the state as it is at least.

Maybe you have a mixed setup and it's OK to COGSTOP COG 1 anytime, for COG 2 it's important to keep the used output pins in the state they are and COG 3 should be allowed to finish it's job before it's terminated (or terminates itself).

StefanL38 · 2009-10-30 15:52

another idea to get a stop as fast as possible

if an external clock is used instead of the chrystal you could interrupt the clock-signal and a watch-dog which is refreshed from the clock-signal
starts the reset

just a quick thought not knowing if this is possible and useful

best regards

Stefan

pacman · 2009-10-31 00:04

MagIO2 said...
Just some additional notes:

Depending on the devices attached to the propeller it could be better to not being to harsh. For example if one COG is in the middle of writing something to EEPROM a reset or even a COGSTOP would cause inconsistencies in data.

You should also consider that a COGSTOP causes all ports used by the COG are set back to inputs. In some cases it might be desirable to hold the state as it is at least.

Maybe you have a mixed setup and it's OK to COGSTOP COG 1 anytime, for COG 2 it's important to keep the used output pins in the state they are and COG 3 should be allowed to finish it's job before it's terminated (or terminates itself).

I'm lucky, in that I don't do any of that 'hard' stuff (like write to eprom) for this unit.

Basically I set a series of outputs dependant on what I read serially and the status of a couple of buttons. The one thing that _is_ required was a 'panic' button that when pushed returned the unit to a known 'safe' state. I hadn't realised that a COGSTOP would input all pins (so thanks for the pick-up).

I think the idea of COGSTOPing some and ".restart"ing others is the way to go.

Thanks to all for the help and insight...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
=================
The future is in our hands.
Which way to the future?
=================

What if I _need_ an interrupt?

Comments