Dear senior assemblers.. nned ur hlp regarding pic16f876a timers..

betwixt said:

You are starting to get there!
You are actually duplicating some of your code, if you move "NO_INT" to above the previous "MOVF PCLATH,W" you can remove everything after the first RETFIE.

However, you still miss the point about what interrupts are for and the first line "GOTO ISR" should not be there as it simply jumps to the next instruction. Unless you are very sure PORTC,5 is going to change faster than TMR1 rolls over, you shouldn't use the loop inside the ISR either.

That is correct. A subroutine is called from within your program, an interrupt is triggered by some hardware event. In your program, that event is TMR1 rolling over. It means that whenever it rolls over, regardless of where the program is running at the time, an immediate call to address 4 is made. Inside the PIC the difference is that a 'call' instruction saves the address of the next instruction to be executed on the stack so that when you 'return', it continues from after the call. An interrupt is similar except that as well as the address being saved to the stack, the interrupts are also disabled. That is because on PIC16 devices you can't interrupt a running interrupt. When you use RETFIE it is like a normal 'return' instruction but it also re-enables any interrupts again.

It might be possible to do it that way, it depends on your program but the safe way is to use that specific code using swap instructions. The reason is that because an ISR can be triggered at any time, it is essential that AFTER the ISR has finished (after the retfie), things carry on as before. If you change W, PCLATH or the STATUS register in the ISR code they will still be different when the main code resumes and that could have bad consequences in your program. Using the swap method rather than movwf does not change any of the bits in the STATUS register so it helps to preserve them before returning.

Brian.

Click to expand...

betwixt said:

You ARE using a hardware interrupt - By enabling the GIE and TMR1IE bits you are enabling TMR1 interrupts. That's why I don't think your original code would work. Every time TMR1 rolled over it would make the program jump into the middle of your LCD initialization values!

Interrupts are incredibly useful things but many people are frightened of them. You can almost think of the ISR as being a second program running independently of the main code, in fact multi-tasking works on exactly that principle.

You can only place one code at any address in memory so no, you can't add more ISRs at 0x0004. The PIC16 processors only have one level of interrupt to cater for all sources so it is up to your code inside the ISR to look at the interrupt flags and see what caused it. That's why I highlighted the green lines in post #17, they check the interrupt came from Timer1 by looking at the TMR1IF bit. If more interrupts are enabled, you have to check the flags for each one and take the appropriate action to service it.

Before going further, your original post was for measuring pulses from a Hall effect device, the ultrasonic measurement wasn't mentioned at all. Can you clarify exactly what is needed and if possible show a schematic so we can see how you have wired to the port pins.

Brian.

Click to expand...

KlausST said:

Hi,

Interrupts are very versatile.
I assume in the past 20 years I did not a single microcontroller project without interrupts.
In our latest STM32 project we process
* 3 UARTS at the same time, (PC communication, multiple periferal device communication, printer)
* 7 ADC channel sampling (7 x 600Hz, filtering, min, max, alarm)
* I2C communication ( data archivation on EEPROM)
* SPI (countinous display update, PLD communication, extended IOs, one task every 1ms)
* timer interrupts (software click, tasks scheduler, pusbutton input,...)
All tasks "run at the same time", every task runs continously, no task is stopped nor paused...
And in main loop there is a control loop running perfectly every 10ms.

It sonds like heavy processing power is needed.... but the processor is sleeping about 95% of time.

It's really impressive how much processing power a microcontroller can provide if one avoids "busy waits"....

Klaus

Click to expand...

thats awesum bro, seems the main code is only waiting for any change accured in the diff hw interrupts and as any change is fount or any event is found the code calls the related isr and gets service by it, stores the values and goeas again in main code loop for chking other changes.. right???

Click to expand...

betwixt said:

The schematic is incorrect and incomplete.
What I suggest you do is this:
1. disconnect D0 - D3 from the LCD, just leave those pins on the LCD disconnected, it has internal pull-up resistors.
2. connecting VEE to ground will probably make all pixels turn on at once. Connect VEE to the center pin of a 10K potentiometer with one end to VSS and the other to VDD. this will let you set the contrast properly.
3. Connect your Hall device to RB0, you can use that to trigger an interrupt each time a magnet passes the sensor.
4. You need a crystal and loading capacitors between OSC1 and OSC2. The crystal frequency affects the timer speed and hence the values needed to program it so please tell us what the frequency is. I suggest 4MHz with 22pF capacitors at each end to VSS.
5. You MUST add decoupling capacitors, I suggest 100nF and 10uF in parallel across VSS and VDD. Place them as close to the PIC as you can.

Talking to the LCD is easy. It is the same as using 8-bit data but you need slightly different initializing values and for the data you split the 8-bits into two 4-bit chunks, send the high 4 bits first, raise the lower the 'E' pin then send the low 4 bits.

The ISR can handle the timing interrupts from TMR1 and the external interrupts from RB0 leaving the main code to update the LCD.

Brian.

Click to expand...

it doesn't need all wires be setup to work properly,

Click to expand...

KlausST said:

Hi,


Yes, sadly.
Thus some urgent connections may be forgotten in the real circuit..
And here in the forum discussion we never know whether the OP connected them or not.

--> for forum discussions please post the exact and complete schematic you want to discuss about

Klaus

Click to expand...