Hi Vasile,
Before testing this I gave this some more thought and had a short look at the
assembly file.
The issue is that as soon at I do any IIC ibrary call from an interrupt
routine, all these routines become 'interrupt routines' if you know what I
mean. I think that means that these routines can no longer be called from a
non-interrupt location like the main program.
For example a non-interrupt routine to transmit something over the IIC looks
like this:
; 102 function i2c_transmit_byte(byte in data) return bit is
l_i2c_transmit_byte
movlb 0
movwf v___data_80
; 104 PIR1_SSPIF = false ; clear pending flag
bcf v_pir1, 3 ; pir1_ssp1if
; 105 sspbuf = data ; write data
movf v___data_80,w
movlb 4
movwf v_ssp1buf
; 108 while ! PIR1_SSPIF loop end loop
l__l524
movlb 0
btfsc v_pir1, 3 ; pir1_ssp1if
goto l__l525
goto l__l524
l__l525
; 113 if SSPCON2_ACKSTAT == low then
movlb 4
btfsc v_ssp1con2, 6 ; ssp1con2_ackstat
goto l__l528
; 114 return true -- okay
movlb 0
bsf v__pic_temp, 0 ; _pic_temp
return
But if you do a call to the same IIC procedure from an interrupt the code
becomes this:
; 102 function i2c_transmit_byte(byte in data) return bit is
l_i2c_transmit_byte
incf v__ri2c_transmit_byte,f
decfsz v__ri2c_transmit_byte,w
goto l__l712
movlp HIGH l__l713
goto l__l713
l__l712
movf v__pic_stkptr+1,w
movwf v__fsr0h
movf v__pic_stkptr,w
movwf v__fsr0l
decf v__pic_stkptr,f
decf v__fsr0l,f
movf v__fi2c_transmit_byte,w
movwf v__ind
l__l713
movf v__pic_temp,w
movwf v___data_80
; 104 PIR1_SSPIF = false ; clear pending flag
bcf v_pir1, 3 ; pir1_ssp1if
; 105 sspbuf = data ; write data
movf v___data_80,w
movlb 4
movwf v_ssp1buf
; 108 while ! PIR1_SSPIF loop end loop
l__l524
movlp HIGH l__l525
movlb 0
btfsc v_pir1, 3 ; pir1_ssp1if
goto l__l525
goto l__l524
l__l525
; 113 if SSPCON2_ACKSTAT == low then
movlb 4
btfsc v_ssp1con2, 6 ; ssp1con2_ackstat
goto l__l528
; 114 return true -- okay
movlb 0
bsf v__pic_temp, 0 ; _pic_temp
goto l__l523
; 115 else
l__l528
; 116 sspcon1_sspen = false;
bcf v_ssp1con1, 5 ; ssp1con1_sspen
; 117 sspcon1_sspen = true;
bsf v_ssp1con1, 5 ; ssp1con1_sspen
; 119 return false -- no response
movlb 0
bcf v__pic_temp, 0 ; _pic_temp
; 120 end if
; 121 end function
l__l523
decfsz v__ri2c_transmit_byte,f
goto l__l715
return
l__l715
movf v__pic_stkptr+1,w
movwf v__fsr0h
movf v__pic_stkptr,w
movwf v__fsr0l
movf v__ind,w
movwf v__fi2c_transmit_byte
incf v__fsr0l,w
movwf v__pic_stkptr
l__l714
return
I think it cannot be mixed. The only solution I can think of is making separate
routines that access the IIC hardware registers directly without a call to any
other - common - routine.
Kind regards,
Rob
________________________________
Van: jallib@googlegroups.com <jallib@googlegroups.com> namens Rob CJ
<rob...@hotmail.com>
Verzonden: donderdag 1 juni 2023 21:01
Aan: jallib@googlegroups.com <jallib@googlegroups.com>
Onderwerp: Re: [jallib] Peripheral hardware and interrupts
Hi Vasile,
Good suggestion. I will give it a try.
Thanks.
Kind regards,
Rob
________________________________
Van: jallib@googlegroups.com <jallib@googlegroups.com> namens vsurducan
<vsurdu...@gmail.com>
Verzonden: donderdag 1 juni 2023 20:58
Aan: jallib@googlegroups.com <jallib@googlegroups.com>
Onderwerp: Re: [jallib] Peripheral hardware and interrupts
Hi Rob,
Perhaps you should disable/enable interrupts within the I2c procedures and not
for the entire main program.
The way you did it, by writing a flag in the ISR and reading it in the main is
correct. If you need less delay between the main execution and interrupt flag
refresh, you should have just one interrupt routine and keep it as short as
possible. Nowadays the JAL libraries are using multiple ISR's which are
controlled entirely by the compiler. This feature does not give too many
options to the user except writing his own procedures for sensitive interrupt
applications instead of using libraries with their own ISR's.
best wishes
On Thu, Jun 1, 2023 at 9:34 PM rob...@hotmail.com<mailto:rob...@hotmail.com>
<rob...@hotmail.com<mailto:rob...@hotmail.com>> wrote:
Hi all,
I have the following issue and I am interested in either your suggestions or if
you encountered the same problem. The example is based on the sample program I
made for the real time clock library DS3231.
The DS3231 has two alarms and uses the IIC interface. The device has an
interrupt line that can be activated when an alarm is triggered. I connected
this line to the external interrupt of the PIC.
The main program read the time and sends it to the serial port. Since the main
program calls DA3231 functions, the IIC interface is used to access the DS3231.
When an interrupt occurs, a register has to be read from the DS3231 to see
which alarm was activated also using the IIC interface of course.
In order to prevent that halfway an IIC transmission initiated by a library
call from the main program, I disable the external interrupt of the PIC at the
start of the main program an enable it again at the end of the main program. In
that way I am sure that the interrupt does not interrupt an IIC transmission
initiated by the main program. There is a delay at the end of the main program,
sufficient for any pending interrupt to be handled.
The problem is that it does not work. The PIC just hangs and does not start.
The only solution I found is setting a flag in the interrupt routine and let
the main program poll this flag and read the register from the DS3231 to check
which alarm was activated. But in this way the whole idea of the interrupt is
gone.
Looking forward to your reactions and suggestions.
Thanks.
Kind regards,
Rob
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
jallib+unsubscr...@googlegroups.com<mailto:jallib+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/679a0f81-03fe-4310-b401-ac69f2d2aeadn%40googlegroups.com<https://groups.google.com/d/msgid/jallib/679a0f81-03fe-4310-b401-ac69f2d2aeadn%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to a topic in the Google
Groups "jallib" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/jallib/13BABaIMXzs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
jallib+unsubscr...@googlegroups.com<mailto:jallib+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qt%3DKi2pGVDwyLkzHmZJAsaX0qkoQPxM-p580W4BC%3DKNMw%40mail.gmail.com<https://groups.google.com/d/msgid/jallib/CAM%2Bj4qt%3DKi2pGVDwyLkzHmZJAsaX0qkoQPxM-p580W4BC%3DKNMw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
jallib+unsubscr...@googlegroups.com<mailto:jallib+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/GVXP195MB163770A10C791A2D2901350EE6499%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM<https://groups.google.com/d/msgid/jallib/GVXP195MB163770A10C791A2D2901350EE6499%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jallib+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/GVXP195MB1637572DBF263871A88FD431E64EA%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM.
