PIC Interupts

[pittuck]

Hi i was pondering:

I am working on a i2c interface for some wireless stuff i have got. What i want to do is interupt on a i2c event which is all well and good.

But stopping comms to the wireless units will muck things up a bit, so i want to dissable the interupts, GIE and PIE to zero [i think]

But what i want to know is, after i re enable interupts and there has been a i2c event, will it go to the interupt from there??

I would think so, but i am unable to test as i need the current setup of pic i am using for testing some other wireless units, and taking apart / re modeling will mean having to put it all back together again in a couple of days...

Many thanks,

- Martyn

 

[williB]

Hi i was pondering:

I am working on a i2c interface for some wireless stuff i have got. What i want to do is interupt on a i2c event which is all well and good.

But stopping comms to the wireless units will muck things up a bit, so i want to dissable the interupts, GIE and PIE to zero [i think]

But what i want to know is, after i re enable interupts and there has been a i2c event, will it go to the interupt from there??

I would think so, but i am unable to test as i need the current setup of pic i am using for testing some other wireless units, and taking apart / re modeling will mean having to put it all back together again in a couple of days...

Many thanks,

- Martyn

after i re enable interupts and there has been a i2c event, will it go to the interupt from there??

I may be wrong ,but i believe Dissabling interrupts does just that --they are dissabled..

 

[Nigel Goodwin]

Hi i was pondering:

I am working on a i2c interface for some wireless stuff i have got. What i want to do is interupt on a i2c event which is all well and good.

But stopping comms to the wireless units will muck things up a bit, so i want to dissable the interupts, GIE and PIE to zero [i think]

But what i want to know is, after i re enable interupts and there has been a i2c event, will it go to the interupt from there??

I would think so, but i am unable to test as i need the current setup of pic i am using for testing some other wireless units, and taking apart / re modeling will mean having to put it all back together again in a couple of days...

As far as I'm aware disabling interrupts doesn't stop the relevent interrupt flag being set, so as soon as you re-enable them it 'should' generate an interrupt.

As a matter of interest, why are you wanting to generate an interupt from an I2C event?.

 

[williB]

Hi i was pondering:

I am working on a i2c interface for some wireless stuff i have got. What i want to do is interupt on a i2c event which is all well and good.

But stopping comms to the wireless units will muck things up a bit, so i want to dissable the interupts, GIE and PIE to zero [i think]

But what i want to know is, after i re enable interupts and there has been a i2c event, will it go to the interupt from there??

I would think so, but i am unable to test as i need the current setup of pic i am using for testing some other wireless units, and taking apart / re modeling will mean having to put it all back together again in a couple of days...

As far as I'm aware disabling interrupts doesn't stop the relevent interrupt flag being set, so as soon as you re-enable them it 'should' generate an interrupt.

As a matter of interest, why are you wanting to generate an interupt from an I2C event?.

lol glad i included my disclaimer lol
it shouldent be too hard to test though..

 

[pittuck]

well the protocol i am working on for the wireless communications can be set to a mode which sends out the data every 10ms (or whatever the user wants) so the pic will be tied up sending / recieving information to worry about other stuff...

Also its very convienient to handle the MSSP from a interupt. The only drawback is that if i am clocking out one of the 9 data bytes to the wireless device for sending and then suddenly an interupt occours and changes the data then it could be very bad indeed with data mixup.

Basically the device creates a packet containing the following:

8 bit pre-amble
8 bit address
x many bits of data
16 bit CRC check

to a maximum of 256bits (total)

But the reliability is never going to be 100% so u either send it out 3 or 4 times and wait for a ACK signal, or continually send data.

I will do some more research :?

 

[williB]

check into the PIC18F6585 .

 

[Nigel Goodwin]

well the protocol i am working on for the wireless communications can be set to a mode which sends out the data every 10ms (or whatever the user wants) so the pic will be tied up sending / recieving information to worry about other stuff...

Also its very convienient to handle the MSSP from a interupt. The only drawback is that if i am clocking out one of the 9 data bytes to the wireless device for sending and then suddenly an interupt occours and changes the data then it could be very bad indeed with data mixup.

Basically the device creates a packet containing the following:

8 bit pre-amble
8 bit address
x many bits of data
16 bit CRC check

to a maximum of 256bits (total)

But the reliability is never going to be 100% so u either send it out 3 or 4 times and wait for a ACK signal, or continually send data.

I will do some more research :?

That explained the radio side (but I was already happy with that), but what about the I2C side - what is it doing?, and is the PIC configured as an I2C slave?.

 

[Oznog]

well the protocol i am working on for the wireless communications can be set to a mode which sends out the data every 10ms (or whatever the user wants) so the pic will be tied up sending / recieving information to worry about other stuff...

Yes disabling either the global interrupt or the individual enable (SSPIE) will still allow the flag to be set, and as soon as the interrupt is reenabled the part will react to the flag and jump to the interrupt vector. We do that all the time to preserve integrity of time-critical pieces of code or sometimes to prevent an interrupt from clobbering shared data while it's being manipulated elsewhere.

I am not sure what you're saying with your problem. Now be aware that one interrupt does not preempt another unless you're using priority interrupts (available on only some of the more recent parts), which creates a high priority interrupt vector which can preempt a low priority (but not another high priority, there are only two levels). So if something HAS to happen exactly when a 10mS timer expires, you can make it a high priority interrupt.

An interrupt routine should not take very long. This is just good coding practice.

 

[pittuck]

ok

I am using a 16F88 (eventuallt a 16LF88 cause its used at 3.3V) as a i2c slave.

There are 2 internal buffers, one can be read from and one can be written to. The one which can be written to is the output buffer, after it has been written to that data will be sent and depending on whats the slave is configured to do it will send in 3-4 bursts or continuasly. But if halfway through sending the 4th byte in the buffer a i2c event changes the buffer contents it will mean the data send is 'corrupt'.

I am not using a full version of the c compiler, i will probably re-write it in assembler using the compilers output as a guide later. Anyhow it is limited to 1k program code. I have not got very far into writing the code and am at 260 words. Otherwise i would buffer the buffer and put the new data into a new sending buffer at the end of the main loop.

The reading of data from the slave is what the unit has received. Although the system i am using is not completly i2c, there is another 'line' which acts as a flag to tell everything else there is data, it is not needed to be connected but it makes things easier when using it only to have to check the status of the one line rather than a while i2c routine, would also enable the master to 'interupt' on new data and retive it from the slave.

But thanks for your help, i now know what i want to do is possible, and after my m8 sends me his wireless units to test i can start playing with the i2c stuff again.

 

[Nigel Goodwin]

ok

I am using a 16F88 (eventuallt a 16LF88 cause its used at 3.3V) as a i2c slave.

There are 2 internal buffers, one can be read from and one can be written to. The one which can be written to is the output buffer, after it has been written to that data will be sent and depending on whats the slave is configured to do it will send in 3-4 bursts or continuasly. But if halfway through sending the 4th byte in the buffer a i2c event changes the buffer contents it will mean the data send is 'corrupt'.

I am not using a full version of the c compiler, i will probably re-write it in assembler using the compilers output as a guide later. Anyhow it is limited to 1k program code. I have not got very far into writing the code and am at 260 words. Otherwise i would buffer the buffer and put the new data into a new sending buffer at the end of the main loop.

The reading of data from the slave is what the unit has received. Although the system i am using is not completly i2c, there is another 'line' which acts as a flag to tell everything else there is data, it is not needed to be connected but it makes things easier when using it only to have to check the status of the one line rather than a while i2c routine, would also enable the master to 'interupt' on new data and retive it from the slave.

You still haven't explained what the I2C master is?, and as it's 'not completely I2C' I'm wondering if you're not making things far more complicated than they need to be?.

 

[pittuck]

at the moments its either a pc (parrallel port) or another PIC (18F452)....

 

[Nigel Goodwin]

at the moments its either a pc (parrallel port) or another PIC (18F452)....

Then why do anything remotely I2C?, it's far easier (and shorter) to use an asyncronous serial protocol - and the PIC (if it's got a hardware USART) can generate interrupts when a character is received if required.

As I see it I2C is only of use if you're using specific I2C chips (like 24C16 etc.), otherwise it far more complicated than you need for most purposes, and doesn't really give any advantages.

But I would imagine that you could probably do it without interrupts at all by a little thought as to what is actually required.

Perhaps you would like to tell us exactly what you are trying to do?, and we could make suggestions as to how it could best be done.

 

[pittuck]

well the hardware usart madule of the 18F452 is used, so i would have to do it in software.

Ok, well eventually i am going to get some pcb's made so i can plug the modules into wherewver i need em.

i2c is fine, i mean i have slave and master routines working.