Freq and Interrupt

Rsadeika

I thought I had the freq and interrupt concept under control, but I am running into some problems. I have listed below the IR remote control program.

Basically, the problem is, when I change the device freq in the program to anything but 4Mhz, the program does not work as expected. I make a special effort to make sure all the settings are correct, i.e. freq is correct sellection for the oscillator type., and so forth.

My· general understanding is that in non time critical interrupts, the freq can be changed without any problems in the program. In the interrupt below, I thought that changing the device freq to, lets say, 8Mhz should not have any affect, but it does, the progran does not work. It seems to me that the interrupt below is one of those non time critical applications. So now I am completely lost. At a later date I am going to try to implement an IR LED, as a VP along with the IR detector,·for communications purposes, that will be time critical, so I need to figure out the problem at hand.

Any help or advice would be appreciated.

Ray


*******Code******
' =========================================================================
'
'·· File...... XGbot.SXB
'·· Purpose...
'·· Author.... R Sadeika
'·· E-mail....·
'·· Started...
'·· Updated...
'
' =========================================================================

'

---

' Program Description
'

---

'

---

' Device Settings
'

---

DEVICE········· SX28, OSC4MHZ, TURBO, STACKX, OPTIONX
FREQ··········· 4_000_000

'

---

' IO Pins
'

---

·IR· var rc.0
'

---

' Constants
'

---

· Power con 21
· ChUp· con 16
· ChDn· con 17
· VolUp con 18
· VolDn con 19
'

---

' Variables
'

---

cmdCode··VAR·Byte···' IR command code (7 bits)
cmdWork··VAR·Byte···' work space for cmd byte
bitCount·VAR·Byte···' track bits received
bitWidth·VAR·Byte···' measure bit width
flags··VAR·Byte
rxCmd··VAR·flags.0···' receiving command
rxBit··VAR·flags.1···' measuring bit width?
hasCmd··VAR·flags.2···' command code available
temp1··VAR·Byte···' subroutine work vars
temp2··VAR·Byte
temp3··VAR·Byte

'

---

· INTERRUPT
'

---

ISR_Start:
· ASM
··· JB··· hasCmd, ISR_Exit···' exit if holding command
··· JB··· rxCmd, Check_Bit···' receiving now?
··· JB··· IR, ISR_Exit····' exit if IR line idle
Start_Packet:
··· SETB· rxCmd·····' set rx flags
··· SETB· rxBit
··· CLR·· cmdWork····' clear work vars
··· CLR·· bitWidth
··· CLR·· bitCount
··· JMP·· ISR_Exit
Check_Bit:
··· JNB·· IR, Update_BitWidth···' still in bit?
··· JNB·· rxBit, ISR_Exit···' in idle period?
··· CLRB· rxBit·····' no, clear bit flag
··· CJA·· bitCount, #0, Test_DBit··' start or data bit?
Test_SBit:
··· CJA·· bitWidth, #74, Next_Bit··' proper start bit?
··· CLR·· rxCmd·····' no, reset
··· JMP·· ISR_Exit
Test_DBit:
··· CLC
··· RR··· cmdWork····' prep for next bit
··· CJB·· bitWidth, #34, Next_Bit··' "1" bit?
··· SETB· cmdWork.6····' yes, set it
Next_Bit:
··· CLR·· bitWidth····' clear for next bit
··· INC·· bitCount····' update count
··· CJB·· bitCount, #8, ISR_Exit··' done?
··· SETB· hasCmd····' set available flag
··· MOV·· cmdCode, cmdWork···' copy work to output
··· CLRB· rxCmd·····' clear rx flag
··· JMP·· ISR_Exit
Update_BitWidth:
··· INC·· bitWidth····' else inc width
··· SETB· rxBit·····' refresh in bit flag
· ENDASM
ISR_Exit:
· RETURNINT 104································

' =========================================================================
· PROGRAM Start
' =========================================================================


'

---

' Subroutine Declarations
'

---

· LED1 sub
· ProcessCode sub
· Stop sub
· GoFore sub
· GoBack sub
· LF sub
· LB sub
· RF sub
· RB1 sub
'

---

' Program Code
'

---

Start:
· ' initialization code here
· PLP_A = %0000·····' pull-up unused pins
· PLP_B = %00000000
· PLP_C = %00000000····' make LED pins outputs
· OPTION = $88·····' interrupt, no prescaler

Main:
· IF hasCmd = 0 THEN Main···' wait for new code
· ProcessCode
· hasCmd = 0
·
· GOTO Main
end
'

---

' Subroutine Code
'

---

ProcessCode:
· IF cmdCode = Power then Stop···· 'Power = Stop
· IF cmdCode = ChUp then GoFore
· IF cmdCode = ChDn then GoBack
· IF cmdCode = VolUp then LED1
· IF cmdCode = VolDn then LED1
· IF cmdCode = 0 then LF
· IF cmdCode = 3 then LB
· IF cmdCode = 1 then RF
· IF cmdCode = 4 then RB1
return
Stop:
· HIGH rc.3··· 'Wire 5 Red···· LS M1
· HIGH rc.2··· 'Wire 6 Yellow· LS M1
· HIGH rc.1··· 'Wire 7 Black·· RS M2
· HIGH rc.0··· 'Wire 8 White·· RS M2
return
GoFore:
· LOW rc.3···· 'Wire 5· LS· LOW = 0
· HIGH rc.2··· 'Wire 6· LS· HIGH = 1
· HIGH rc.1··· 'Wire 7· RS
· LOW rc.0···· 'Wire 8· RS
return
GoBack:
· HIGH rc.3··· 'Wire 5· LS
· LOW rc.2···· 'Wire 6· LS
· LOW rc.1···· 'Wire 7· RS
· HIGH rc.0··· 'Wire 8· RS
return
LF:
· LOW rc.3
· HIGH rc.2
return
LB:
· HIGH rc.3
· LOW rc.2
return
RF:
· HIGH rc.1
· LOW rc.0
return
RB1:
· LOW rc.1
· HIGH rc.0
return
LED1:
· HIGH rc.1
· pause 2000
· LOW rc.1
return
·

Bean

Um, IR reception IS a timing critical application.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module"·available from Parallax for only $28.95 http://www.parallax.com/detail.asp?product_id=30012

"SX-Video OSD module"·available from Parallax for only·$49.95 http://www.parallax.com/detail.asp?product_id=30015

Product web site: www.sxvm.com

"Sometimes it is better to remain silent and be thought a fool, than to speak and remove all doubt."
·

Rsadeika

Thanks Bean. Now I am in really big trouble. So, I guess the IR receiver pulses or synchronizes at 38kHz, or am I back to pulse rate of the remote control, the 2.4 ms stuff. I hope I am on the right track with this train of thought. Man do I hate this engineering math.

Thanks

Ray

Paul Baker

Ray, cant you modularize the code so that you automatically compile correctly based of the FREQ directive? Im pretty sure there is a compile time constant _FREQ or something similar, or at the very least you can define a constant and derive all your time critical values based off the constant. That way you have to only change at most two locations in you program and have it work for any oscillator frequency.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Guenther Daubach

Maybe, this is trivial stuff but I think I might place it here:

The FREQU 4_000_000 directive does only control the clock frequency that is applied to the SX during a debugging session, or when you select the "Run-Run" option from the IDE. As soon as you remove the SX-Key, the clock frequency either depends on the component externally attached to the OSC1-OSC2 pins, i.e. a resonator, or a crystal, or on a clock souce feeding some externally generated clock signal into the OSC1 pin, or on the SX-internal clock generator.

Your code example contains the DEVICE OSC4MHZ directive, i.e. the SX-internal clock generator will be activated, no matter if you have a crystal, a resonator, or an external clock generator attached to the OSC pins. The internal clock generator's frequency depends on the values of an internal resistor, and an internal capacitor, thus it is not very precise, and it is further influenced by the supply voltage and the ambient temperature.

Maybe that this is the reason why your program does not work as expected. Please try to use an external 4 MHz resonator or crystal instead.

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

G

Rsadeika

The program that I have above works as shown. What I am trying to do is run the program at a new device freq of 50Mhz, the program does not work as expected. My reasoning is that the IR detector is not time critical, so changing the device freq should not have any affect. So, when I changed the freq to 50Mhz the program did not respond as expected. Since the program did not work, I have to consider Bean's suggestion, that it is time critical.

Now I am trying to do some backwards math, using the 104 cycles to see if I can come up with a new number to plug in. I am using the formula that is shown in the SX/B help file. If I ever figure this out I may have to do a spread sheet, so all I have to do is plug in values and get the answer.

Thanks
Ray

Peter Verkaik

104 cycles @ 4MHz =
26 cycles @ 1MHz =
1300 cycles @ 50MHz =
163 cycles @ 50MHz 1:8 prescaler

regards peter
·

Rsadeika

Thanks Peter for the values table, when I started to test, it did not work, because I did not·catch on to ·the key word prescaler. I·focused in on that·and now it works.

The way that I arrived at the values are:
I solved for the missing value, ISR rate.
Freq / prescaler / ISR Rate = Cycles
· 4·· /····· 2·······/···· X····· = 104
·X = .01923 This value is of importance, but I have not figured out how, this is a key point.

The values in the working program are:
Freq - 4Mhz
RETURNINT 104
OPTION $88 This seems to be the key, no prescaler.

So, for a 50Mhz value:
Freq / prescaler / ISR Rate = Cycles
·50· /······ 2····· / .01923·· =· 1300
Since the Cycles can only be a number between (0 - 255), you have to work it down by using the proper prescaler, in this case 1:8 works. You could also have used a 1:16 prescaler, as long as the resulting number comes in between (0 - 255).
Freq - 50Mhz
RETURNINT 163
OPTION $82 This uses a prescaler

The other key point that I do not understand is the use of the PSA value. In the original program the PSA value that is used is 1, in order to make the program work at the higher Mhz values a PSA value 0 has to be assigned. I guess what I do not get is PSA = 1, divide rate on RTCC is 1:1, PSA = 0, prescaler is assigned to RTCC. This is pretty confusing, how do you determine when to use PSA 0 or 1.

In brief, how does the .01923 value fit into the picture, and how to determine the proper use of the PSA value, are questions that could use some explanation.

I hope this helps some of the other beginers, and I hope I did not make any glaring mistakes in the write up.

As I start to add other VPs, this could become even more confusing, so I need some kind of methodology for all of this.

Some explanations would be appreciated.

Thanks

Ray
·

Peter Verkaik

I always insert this in my assembler sources

·; Setup option register.
·;

---

setup_option

RTCC_ON····· =·%10000000·;Enables RTCC at address $01 (RTW hi)
························ ;*WREG at address $01 (RTW lo) by default
RTCC_ID····· =·%01000000·;Disables RTCC edge interrupt (RTE_IE hi)
························ ;*RTCC edge interrupt (RTE_IE lo) enabled by default
RTCC_INC_EXT·=·%00100000·;Sets RTCC increment on RTCC pin transition (RTS hi)
························ ;*RTCC increment on internal instruction (RTS lo) is default
RTCC_FE····· =·%00010000·;Sets RTCC to increment on falling edge (RTE_ES hi)
························ ;*RTCC to increment on rising edge (RTE_ES lo) is default
RTCC_PS_ON···=·%00000000·;Assigns prescaler to RTCC (PSA lo)
RTCC_PS_OFF· =·%00001000·;Assigns prescaler to WDT (PSA hi)
PS_000······ =·%00000000·;RTCC = 1:2, WDT = 1:1
PS_001······ =·%00000001·;RTCC = 1:4, WDT = 1:2
PS_010······ =·%00000010·;RTCC = 1:8, WDT = 1:4
PS_011······ =·%00000011·;RTCC = 1:16, WDT = 1:8
PS_100······ =·%00000100·;RTCC = 1:32, WDT = 1:16
PS_101······ =·%00000101·;RTCC = 1:64, WDT = 1:32
PS_110······ =·%00000110·;RTCC = 1:128, WDT = 1:64
PS_111······ =·%00000111·;RTCC = 1:256, WDT = 1:128

··mov·w,#RTCC_PS_OFF···· ;setup option register, add options required
··mov·!option,w

This lets me set the option register in a descriptive way.
The prescaler is assigned to RTCC or WDT. In your case it must be assigned to RTCC.

regards peter

Paul Baker

Ray you know that 0.01923 is 1/52, so your formula can be simplified to Freq(in MHz)*52/Prescaler. The compiler is capable of doing math equations at compile time, page 70 of the SX-Key Development manual (version 2.0) discloses the comands availible, __SX_FREQ is the compile time constant for the frequency set by the FREQ directive. So you could define something like RTC_ADJ = __SX_FREQ/1_000_000 *52 /PSCALE. You can also emit a warning if RTC_ADJ > 255 or even figure out a way to set PSCALE based on RTC_ADJ needing to be < 255. Then use RETURNINT RTC_ADJ in your code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Peter Verkaik

Ray,
Your formula should be
Freq / prescaler / ISR Rate = Cycles
· 4·· /····· 1·······/···· X····· = 104
·X = .03846·and this is your IR frequency in MHz

regards peter

Rsadeika

Freq / prescaler / ISR Rate = Cycles
· 4·· /····· 1·······/···· X····· = 104
·X = .03846·and this is your IR frequency in MHz
So, since the OPTION uses PSA 1, prescaler is assigned to WDT (no prescale), and divide rate on RTCC is 1:1, that is why you are using the 1 number.

Now, everything in the formula is expressed in MHz (apples = apples), the .03846 can be expressed in KHz by multiplying by a 1000 (K) which gives the familliar 38.46KHz. It looks like the riddle has been solved (for me anyways), the value in the ISR Rate is 38.46KHz expressed in Mhz. I will re-test this by choosing the correct PS2,PS1, and PS0 values with no prescale.

It is staring to look like their is quite a few ways to skin the cat. Thinking ahead, to add a UART VP could be a little tricky, since the ISR Rate is a fixed value at this point. This should be an interesting exercise.

Thanks

Ray

PJMonty

Ray,

I have to ask because I am curious - what lead you to believe that IR communication was not a time critical application?

Thanks, PeterM

Rsadeika

Peter,

What is lacking in your question is, compare and contrast LOL. Your gut feeling is correct, I know nothing about electronics. Over the past couple of years, that I have been delving into this, the accumulation of my·knowledge can be summed up in, a capacitor is like a small battery; a resistor is like a filter, allowing specified amounts to get through; a transistor is like a·one way sphincter, and an LED has to be protected with a resistor, otherwise it has a·quick death·. If you ask me anything about·how to use these in a circuit, my answer is, DUH.

Now, that I have laid out my defense, I derived my concept from the examples, on the pbasic side, in the design and use of an IR led, and IR demodulator circuit for object detection. In that example, for firing the IR LED,·the code uses a pulseout command which stipulates the use of 38Khz, or any other KHz value that you want to use. For the IR demodulator side, either input command·can be used, or if you use the pulsin command, you DO NOT SPECFY a corresponding Khz value. That led me to believe that the demodulator itself was doing the synchronization. The only thing that was necessary was to get the value, which is presented in its complete size, not a bit at a time,·and put it into a variable. This is the logic that I used to try and·solve, incorrectly, the problem that was at hand.

I still have not given up on my·project, even though I have had some major setbacks. I will probably turn out to be the oldest guy on this forum trying to learn something new. But, that is life. In regards to posts, I do not mind terse questions and answers, but I find no use in patronizing equivalence.

Thanks for the interest.

Ray

gibbman

Good for·you, Ray. But you may have some competition from me on the age thing...

Jim

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
In the end, it seems that it's all about getting the LEDs to blink....

PJMonty

Ray,

To be honest, my gut didn't have an opinion on your state of electronics knowledge. I'm just trying to get inside your head. Text being a limiting format for getting intent across, I hope you understood that I was curious, not trying to poke fun at you. I figured if I could understand the thought process, I might be able to help you understand how to look at the problem differently. Half the battle in life is not the knowledge you already have acquired, but the way you look at things when confronting a problem not covered but your existing knowledge.

Thanks, PeterM