SX Sim question

basicstampede

I am experimenting with SX Sim and have a·question.

What is the blue progress bar located immediately to left of register 0F to FSR with words "Undo" below?
I noticed that when I click on Walk, it slowly fills upward and until it fills up about 2/3 way, the Simulator is looping back and forth between source codes

PROGRAM Start······ &
Start:

even though there is no source code between those two statements.

Why is it looping back and forth when there is no source code?

This is the file I am experimenting with.· It is same as the file JonnyMac suggested.· I changed the ISR by adding statement RTCC=255 so that next High to Low transition will invoke ISR again.

basicstampede

For for some strange reason, the simulator puts value FE (254) into RTCC (even though the last statement in ISR is RTCC=255).
Why?

JonnyMac

I know I'm repeating myself, but you should download and read the SX/Sim documentation if you're going to use SX/Sim. Those docs can be found in a sticky thread at the top of this forum.

SX/B generates its start-up code and puts at the Program START directive (the purpose of the Program directive is to locate the start-up code; the label that follows is where to jump to after). What you're seeing is the everything being initialized and the memory cleared before it drops to the Start label. Once all the memory is cleared and IOs setup you'll see the program drop to Start. Be patient and you'll see this.

And you're wrong about the last statement in your ISR setting to 255. You've setup the RTCC to increment on the 1->0 edge. When that happens and the RTCC rolls over from 255 to 0 you enter the interrupt and then you set the RTCC to 255. Then the interrupt code executes the RETURNINT statement which, in this case subtracts 1 from the present RTCC value; 255 - 1 = 254 ($FE). Had you not inserted the manual manipulation of RTCC everything would have worked as expected (because 0 - 1 rolls under to 255). In effect, you've changed the RETURNINT value to 2. Lesson: it's usually not a good idea to manipulate the RTCC register inside the ISR; let RETURNINT take care of it.

BTW, the original program I posted works exactly as you asked: it enters the ISR on any 1->0 transition of the RTCC pin. Hook it up and try it. Or, run it in SX/Sim -- that proves that it works, too.

basicstampede

JonnyMac, thank you. You are right. Your code works as I wanted.

But in my defense, I was only trying to put the RTCC in the same state that you did at beginning of the program (or so I thought).

You wrote "Then the interrupt code executes the RETURNINT statement which, in this case subtracts 1 from the present RTCC value; 255 - 1 = 254 ($FE). "

Why is that? Why does RETURNINT subtract 1 from RTCC value? If it wasn't for this forum and helpful folks like you, how would one have find out about this?

Thanks.

JonnyMac

Oi vey.... I should have been more precise. Let me see if I can explain RETURNINT the way I understand it.

In SX/B, RETURNINT is used to reload the RTCC with the desired number of cycles for the next interrupt. When using periodic interrupts with the rate parameter SX/B takes care of the OPTION register and the value for RETURNINT for us. Easy-peezy.

In this program, where everything is being done manually, we are giving RETURNINT a value -- this is the number of RTCC cycles we want before the next interrupt; in this case, just one so that the next 1-->0 edge on the RTCC pin fires the ISR. Here's the rub; RETURNINT generates code that modifies the present RTCC value such that it will fire when we want it to. Since the RTCC is presently at 0 and we want to fire in one cycle we subtract 1 from the RTCC; the result is -1 or 255. On the next RTCC input this bumps to zero and triggers the interrupt.

Here's why we have to modify the present value of the RTCC. What if we're running a periodic interrupt every 100 cycles but the interrupt code takes 30 cycles from top to bottom? Since the RTCC is being updated by the system clock when we get to RETURNINT its value is 30. Do the math:

New RTCC = 30 (present RTCC) - 100 (desired # of cycles) = -70 (cycles before the next ISR fires)

We don't use negative so the RTCC is actually reloaded with 186 (256 - 70 = 186); by doing this the interrupt is fired every 100 RTCC cyles.

So... when I said that RETURNINT subtracts 1 from the RTCC, it's only when the cyles parameter is set to 1.

This is not beginner's stuff -- and you should spend some time with it. How would you find out about this stuff? Read the SX docs, the SX/B help file, download Al Williams's book, buy Guenther's book. Spend some time coding WITHOUT panicking and turning to others for help -- that's really the best way to learn.

pjv

Hi Jon;

Also, as a side point, please remember that when one does a DIRECT write to RTCC (that is not the same as a write via RETIW) that the RTCC locks up for 3 (I think thats the number ?) cycles. I think this is a pipeline issue.

Cheers,

Peter (pjv)

JonnyMac

Thanks, Peter, I didn't know that.

pjv

Hi Jon;

One further point in dealing with the RTCC.... I indicated above that DIRECT writes to the RTCC temporarily lock it up, but it would have been more correct to say ANY writes to the RTCC. And what is significant here is that a BIT TEST such as SB or SNB instruction are indirect writes in the form of READ-MODIFY-WRITE, and they also will lock up the RTCC.

So, come to think about it now, the only instructions that will not lock it up are direct READ instructions such as MOV W,RTCC or TEST RTCC. Not sure about others.

Also I am not sure if the SX-SIM cycle counter handles this properly......

Anyhow sorry to be ranting about this, but it could be important to some users who want to mess with the RTCC.


Cheers,

Peter (pjv)

Guenther Daubach

Hi all,

the blue progress bar indicates the "fill level" of the undo-buffer (up to 1000 instructions can be un-done/re-done in SXSim). In the next version, this will be replaced by a simple numerical indicator. Thus, it is no longer necessary to have MSCOMMCTL.OCX installed on the PC running SXSim.

Concerning the cycle counter, I must admit that I did not know about the temporary RTCC lockups, so SXSim does not handle such exceptions properly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

Bean

Gunther,
I did some research into this and it depends on the prescaler value, how many cycles are "missed".
I did a search, but I cannot seem to find the thread I wrote about it.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"A government big enough to give you everything you want, is big enough to take away everything you·have."·· Thomas Jefferson

"It is our choices, Harry, that show what we truly are, far more than our abilities."·Dumbledore from Harry Potter

www.iElectronicDesigns.com

·

Guenther Daubach

Bean,

thanks for the info. Let me see if I can find it, and how to implement it in SXSim.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

Bean

Here is the original thread http://forums.parallax.com/showthread.php?p=708045

Okay by experiments here is what is works out to be: 
If the prescaler is 1:8 or higher, the instruction that modifes RTCC is one count. 
If the presclaer is 1:1, the instruction that modifies RTCC is three counts. 
If the prescaler is 1:2 or 1:4, the instruction that modifes RTCC is five counts. 

Seems weird, but that is how it works in my experiments. What I did was get the interrupt rate to be the same when I modifed RTCC and when I didn't. If the resulting rate was the same, the calculation must be correct.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"A government big enough to give you everything you want, is big enough to take away everything you·have."·· Thomas Jefferson

"It is our choices, Harry, that show what we truly are, far more than our abilities."·Dumbledore from Harry Potter

www.iElectronicDesigns.com

·