SetInt Off problem in simulating 14M code.

[Odessa]

If you try to simulate the following code for the 14M, you will receive a syntax error for the SetInt Off command line. I am not sure why that error is coming in, and have also tried setting an interrupt prior to turning it off in the code, and that changes nothing. In fact, the code can be made as simple as possible (see further below), and the same problem occurs.

Testing:
SetInt OFF
Gosub Test1
SetInt %00000100,%00000100
Goto Testing

Test1:
Pause 1000
Return

Interrupt:
Return

_________________________________

Problem also occurs for simplest instance of code:

SetInt %00000000,%00000001
SetInt Off

Interrupt:
Return
________________________


I have tried changing the masked bits and their/or their values, but that has no effect. I also tried configuring the simulator for an 08M, taking consideration when setting and masking, of which pins could actually be examined for interrupts, and got the same result.

I notice when using the Quick Syntax checker within the Help feature of the simulator, the SETINT command is listed within the commands, but not shown to apply to the 14M. The SETINT command is not the problem when simulating, though; it is the SETINT off command.

If this issue can be resolved, I have an additional question. The Picaxe manuals stipulate that interrupts can only occur for inputs 0-2 on the 14M. If these pins are first converted in code to portC inputs (3-5), can they then still be used as interrupt pins?

Thanks in advance for any help, Odessa.

 

[westaust55]

SetInt Off problem in simulating 14M code

I tried you code

Testing:
SetInt OFF
Gosub Test1
SetInt %00000100,%00000100
Goto Testing

Test1:
Pause 1000
Return

Interrupt:
Return

in the PE V5.2.2 simulator with the PICAXE selected as 28X1 and then as 14M and finally as the 30M.

In all cases syntax check came up as:
"Syntax check successful!

Memory used = 19 bytes out of 256"

 

[Odessa]

Ok, Westaust55, I'm using PE V5.1.5, so maybe that's the difference. I will try to download the version you have and see if I can reproduce your success.

Assuming I do, do you know the answer to the question I also posted in my original post on this thread? It is repeated here for convenience:

If this issue can be resolved, I have an additional question. The Picaxe manuals stipulate that interrupts can only occur for inputs 0-2 on the 14M. If these pins are first converted in code to portC inputs (3-5), can they then still be used as interrupt pins?

I will report back here regarding the editor upgrade, and whether that solved it for me, too. Initially, I suspect it will.

Thanks much, Odessa

 

[Odessa]

Verdict is in: newest Picaxe Editor solved the SetInt Off problem. Moral of the story is to upgrade more often. In the past, how often have new versions of that Editor been released? Maybe every 6-12 months?

Only remaining question in this thread is whether PortC inputs 3-5 can be used as interrupts on the 14M. Anybody know that answer?

If nobody knows it, I will eventually simulate it and report the answer back here.

Thanks, Odessa.

PS By the way, I removed the previous version of PE from my hard drive prior to installing this newest version. Does anyone know if that was actually necessary, or does the new PE exe code take existing installations into account and remove them as part of the new installation?

 

[westaust55]

Verdict is in: newest Picaxe Editor solved the SetInt Off problem. Moral of the story is to upgrade more often. In the past, how often have new versions of that Editor been released? Maybe every 6-12 months?

Only remaining question in this thread is whether PortC inputs 3-5 can be used as interrupts on the 14M. Anybody know that answer?

If nobody knows it, I will eventually simulate it and report the answer back here.

Thanks, Odessa.

PS By the way, I removed the previous version of PE from my hard drive prior to installing this newest version. Does anyone know if that was actually necessary, or does the new PE exe code take existing installations into account and remove them as part of the new installation?

Wrt your question,
Checks I have done in the PE indicate that, for example, references to physical leg 6 as input pin1 and also portc pin4 can be used interchangable without affecting use of the SETINT command.

Re your PS query:
The PE is upgraded at somewhat random intervals as a groups of bugs are resolved or enhancements made and as new PICAXE chips become available.
Forum member from Rev Ed, Technical, usually posts when a new version is available.

 

[SilentScreamer]

I believe 5.3 is coming out some time this month with the release of the X2's but I can't mind the thread which said it so I might have made it up

You'll also find a patch below the main download to update an existing installation. Though I prefer to do a clean install regardless.

 

[westaust55]

I believe 5.3 is coming out some time this month with the release of the X2's but I can't mind the thread which said it so I might have made it up

You'll also find a patch below the main download to update an existing installation. Though I prefer to do a clean install regardless.

Yes Techncial did state that 5.3.0 was to coincide with the X2 chips in response to a question I raised about the Manual 2 even back at Rev 6.6 stating it is related to PE V5.3.0.

From older Rev 6.6:

Please see section 1 of the manual (‘Getting Started&#8217 for installation details and tutorials. This manual was prepared using version 5.3.0 of the Programming Editor software.

Maybe the illusive brackets for X1 and X2 parts for use in Maths will also eventuate . . .

 

[Odessa]

Ok, guys, thanks for the heads up on the upcoming PE upgrade....

Regarding my remaining question on this thread, I simulated the following code, which operates on leg 5 as: 1) Input 2; 2) PortC 5 as input; and 3) PortC 5 as output and the code simulated with the interrupt operating as expected, no matter where in the Standby loop the interrupt actually was generated.

Standby:
DirsC=%00000000
SetInt %0000100, %00000100
Goto Standby


Interrupt:
If Pin2=1 then
High PortC 5 Endif
Return

Interestingly enough, the following code shows that leg 5 can even generate an interrupt while configured as an output.

To see this in effect, step simulate this code and cycle at least once completely through the Standby loop, then when on the Pause command, take input 2 high, generating the interrupt. You will see that once the interrupt is serviced and execution returns to the standby loop, the interrupt is generated again immediately, although leg 5 is now an output.

Standby:
Pause 1000
SetInt %0000100, %00000100
DirsC=%00000000
Goto Standby

Interrupt:
If Pin2=1 then
High PortC 5 Endif
Return

Without further testing, would it be reasonable to assume this capability extends to the other two pins on the 14M which are simultaneously output configurable and interrupt maskable? Or, is this just a quirk of the simulator and actual 14M operation would not generate the interrupt with leg 5 set to an output?

Odessa

 

[hippy]

Be careful when simulating code in esoteric situations like this to determine what a physical PICAXE will do. While both should match, how the physical PICAXE behaves is the definitive statement of reality which the simulator should then follow.

In this case it appears the simulation matches what the physical 14M does. This is because those Port C pins 3, 4 and 5 are what the PICAXE reads as 'pin0', 'pin1' and 'pin2' and as the three lsb's of the 'pins' variable which are checked for by SETINT. Those Port C pins are inputs by default so setting them as inputs explicitly doesn't change anything as far as the PICAXE firmware is concerned.

When Port C is made output, the PICAXE still reads what is coming back in on the very same pins ( see the PICmicro datasheet for details of how the I/O pins are constructed in silicon ), so setting Port C pin 5 high also makes input 'pin2' high which causes the SETINT to trigger the interrupt.

Also be careful when using real hardware and this behaviour because you need to ensure, if you make what is nominally an input into an output, that it doesn't short a high input to a low output or vice-versa - The simulator does not include a 'letting the magic smoke out' simulation

I cannot think of many cases where using an output to force an interrupt like this is useful in practice, but one place is in measuring execution times of instructions. The period between one interrupt and the next, before and after an instruction to be timed, should have a consistent latency time. With some work it should be possible to generate a pulse which lasts the length of that period only around the instruction being tested. Being able to progammatically turn the interrupt on and off beats wiring the interrupt pin to +V but would still require some tricky programming to not lose the advantage gained.

 

[Odessa]

"I cannot think of many cases where using an output to force an interrupt like this is useful in practice..."

First off, thanks for taking the time to verify the simulator against the actual 14M for this application oddity.

Next, most subtleties like this don't have immediately apparent applications, but this one is a gem to stash away for a rainy day.

Finally, one thing is to try and consider constructive ways to apply this subtlety, but another is to consider those potential applications where this could be an unexpected disadvantage. One of those occurs when a pin is intended to operate both as input and output in a given circuit, but the designer might never expect that an interrupt assigned to the pin while operating as an input might also be affected while it functions as an output. Employing low-pin-count PICs to minimize cost considerations in high volume applications often requires multiplexing pin functions, so this oddity, if unexpected, could unpleasantly surprise while testing designs like those.

Odessa