Beautifull! I feel like I now have enough to be dangerous or at least dangerous in a productive, 'hmmm that didn't work but I learned something' sort of way.
Thank goodness for reprogrammable pics!
Thank you,
Hylan
Beautifull! I feel like I now have enough to be dangerous or at least dangerous in a productive, 'hmmm that didn't work but I learned something' sort of way.
Thank goodness for reprogrammable pics!
Thank you,
Hylan
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
And most people don't realize it, but you can have an interrupt on *ANY* pin - sort of. This is handy when you have a switch that simply must be read and it is on port C, for example.
Just run a high-speed interrupt on TMR0 and read whatever pins you want inside the ISR. I typically run a 1mSec interrupt.
A small example of an "interrupt header"
This particular code will increment MasterClock at a 1000Hz rate (1 ms / count). You can read it at any time, although you should either disable INTs when you test it, or only test that it is ABOVE (not equal to) a value, since it is a 16 bit var and can increment in the middle of a PBP read.Code:PreloadH VAR BYTE BANKA SYSTEM PreloadL VAR BYTE BANKA SYSTEM MasterClock VAR WORD BANKA SYSTEM ButtonFlag var BYTE BANKA SYSTEM PreloadH= $D8 PreloadL = $F7 ; 1 mSec@40Mhz T0CON = %10001000 ; Timer ON, no prescaler '---------------------------------- -------------------------------- INCLUDE "DT_INTS-18.bas" ' INCLUDE "ReEnterPBP-18.bas" ; Include if using PBP interrupts ASM INT_LIST macro ;IntSource, Label, Type, ResetFlag? INT_Handler TMR0_INT, MainTimer, ASM, yes ; INT_Handler RX1_INT, GetChar, PBP, yes endm INT_CREATE ENDASM Goto OverInt '---[INT - interrupt handler]--------------------------------------------------- Asm MainTimer movff PreloadH,TMR0H ; Preload depends on clk speed movff PreloadL,TMR0L clrf INTCON,2 infsnz MasterClock incf MasterClock + 1 btfss PORTC,4 bsf ButtonFlag,0 @ INT_RETURN ENDASM OverInt: ButtonFlag = 0 MasterClock = 0 INTCON =%11100000 ; just to be certain! @ INT_ENABLE TMR0_INT Your program here
ButtonFlag.0 will be set any time after someone has pressed a button bringing PORTC.4 to GND. You can read it anytime, then clear it in your main code.
If you have more complicated things to do on an interrupt, you can write it in PBP.
So THERE! mister_e and pxidr84!
Charles Linquist
That's a good setup !
How about switch de-bounce (make sure its a good press)
I use;
if sw not_pressed then out
pause 10 ' or 20 or 50 ms
if sw not_pressed then out
good sw pressed stuff here
don
You often don't need a debounce if you read a switch in software. Hardware is so fast that it can see one push as a bunch of pushes, but software is generally a lot slower and you can use that to your advantage. In the example I gave above, the bit gets set as soon as the first contact is made. If the main loop reads the bit at that time, and then does something that takes 50 mSec, you can clear ButtonFlag at the end of that routine (rather than at the top). The switch will certainly have quit bouncing by then, so the bit won't get re-set by the bounce. This saves 50mSec of waiting.
If things really get "hairy", I do the debounce in ASM. I count the loops that the switch has been down (or up) and only generate a flag when that number of loops has been executed.
My programming style uses PAUSE sparingly, if at all. That is the only way you can get real performance out of a PIC and PBP.
Charles Linquist
Sure, I classify that as slow background process
amgen, you just need to read the switch all the time, keep a reading of the previous(s) and compare them. Depending of your timer rate, you may want to make sure it is hold down for X interrupt. set a flag to say a switch is ready, Once done, and the button being read, you wait Y interrupt before reading another and "publish" it.
Tons of way to do so. But for sure, you don't want any PAUSE in an ISR.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Yes, getting more accustomed to thinking in terms of COUNT rather than time..... although the count is always exactly related to your timing base. Right ? Also brings more into play, Events to do actions (like windows), and more use of GOSUB's.
don
Last edited by amgen; - 23rd August 2011 at 18:17.
Okay, I've been looking at Daryl Taylors interrupt programs as recommended by Steve. I downloaded everything and tested the blinky blinky to make sure it worked. I changed the toggle pin to one on my board with an LED and it worked.
Now I'm trying to figure out how to incorporate this into my program and what terms I can change and what I can't and where it needs to be placed in the program. I don't have anything called a "main" loop for example.
So for example with this sample code:
I understand that the "include" statements go at the top when declaring stuff but I'm not sure where to put the "ASM" sectionCode:LED1 VAR PORTB.1 INCLUDE "DT_INTS-18.bas" ; Base Interrupt System INCLUDE "ReEnterPBP-18.bas" ; Include if using PBP interrupts ASM INT_LIST macro ; IntSource, Label, Type, ResetFlag? INT_Handler INT_INT, _ToggleLED1, PBP, yes endm INT_CREATE ; Creates the interrupt processor ENDASM @ INT_ENABLE INT_INT ; enable external (INT) interrupts Main: PAUSE 1 GOTO Main '---[INT - interrupt handler]--------------------------------------------------- ToggleLED1: TOGGLE LED1 @ INT_RETURN
and the "INT" Interrupt handler commands
I tried a couple things and the blinky blinky always worked but I never got my part of the program to run so it seemed to only stay in the above portion.
Getting closer, I can smell it, but I can't quite see it or taste it.
Thank you,
Hylan
In the example you have posted place your code in the "Main" loop. To start try a PAUSE type blink in the Main loop to seehow ot works.
Dave
Always wear safety glasses while programming.
Bookmarks