Multiple interrupts as handled by libraries right know are generating incontrolled jitter to any timing sensitive applications. Unfortunately almost nothing can be done....except grouping everything in one interrupt carefully controlled.
On Sun 20 Feb 2022, 5:27 PM Rob CJ <rob...@hotmail.com wrote: > Hi Kiste, > > Thanks for your reply. I thought that it would work when disabling the > interrupt but I did not think of what you said about variable reuse. That > could have been the problem. The current I2C procedures wait for a transfer > to be completed and the PIC is always the master so that should be OK. > > I agree with you better not to do this in an interrupt so I keep it as it > is. > > Kind regards, > > Rob > > ------------------------------ > *Van:* 'Oliver Seitz' via jallib <jallib@googlegroups.com> > *Verzonden:* zondag 20 februari 2022 09:26 > *Aan:* jallib@googlegroups.com <jallib@googlegroups.com> > *Onderwerp:* Re: [jallib] Can you call a procedure from a main program > and an interrupt? > > Hi Rob, > > it is possible to call a procedure from both the main program and from an > interrupt alternately, but I would try to avoid that, it's... I'd call it > dangerous. > > As jal is not reentrant, you have to make absolutely sure, that no single > part of any procedure is running twice in any case. (The only exception I > know of are the multiplication/division functions which are safe to be > called from an interrupt while running in the main program, but those are > not seen as functions to the user anyway) That means, that if you use e.g. > a print procedure inside the interrupt, you also have to disable interrupts > each time you're using a similar print procedure in the main program. All > decimal print procedures use the same background code, so in this sense, > they're "the same procedure" and need to be surveyed not to run from both > the main program and the interrupt at the same time. > > And, you should compile with --no-variable-reuse, as the compiler is > probably not aware of procedures being called from an interrupt. > > Can be that you obeyed that rule by disabling interrupts when using I2C in > the main program. But then, there's hardware involved. You need to make > sure that the hardware is idle and in a reset, initialized state each time > before enabling interrupts. I'm not so familiar with the I2C peripheral to > decide if that's a problem. And, also all devices on the I2C bus need to be > reset and initialized each time the interrupt is enabled. > > I do prefer handing over the alarm to the main program via volatile flag > bit. > > Greets, > Kiste > > Am Samstag, 19. Februar 2022, 09:58:53 MEZ hat rob...@hotmail.com < > rob...@hotmail.com> Folgendes geschrieben: > > > Hello all, > > Some time ago I made a library for the clock IC DS3231. This library is > part of Jallib release 1.7.0. > > This IC has an I2C interface and is capable of handling two alarms. When > an alarm is activated an interrupt is generated. > > Reading the alarm flag from the IC also uses - of course- the I2C > interface but the I2C interface is also used by the main program. > > I thought that if I would disable all interrupts when calling the I2C > routines from the main program and only enable it while not used by the > main program that I could call the same I2C routines from the interrupt > routine and so be able to read the alarm flag from the IC to see if alarm 1 > or alarm 2 was activated. > > Unfortunately this did not work. > > I thought that when an interrupt is called some info is saved and after > the interrupt restored but I also thought that I could then call any > routine from the interrupt as long that I am certain that no I2C transfer > was active (which should be since the interrupt is disabled when the main > program is using the I2C routines). > > Any ideas why this does not work? Am I missing something? > > What the current sample program does is just setting a global flag in the > interrupt routine and the main program polls this flag and then reads the > alarm flag of the IC via I2C but this undermines a bit the use of the > interrupt. > > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jallib/ff12f63c-0d1d-4897-8ca4-511869ab68c0n%40googlegroups.com > <https://groups.google.com/d/msgid/jallib/ff12f63c-0d1d-4897-8ca4-511869ab68c0n%40googlegroups.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/1119054585.183229.1645345612576%40mail.yahoo.com > <https://groups.google.com/d/msgid/jallib/1119054585.183229.1645345612576%40mail.yahoo.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/DB6P195MB0183CD0D3367C17A1072C127E6399%40DB6P195MB0183.EURP195.PROD.OUTLOOK.COM > <https://groups.google.com/d/msgid/jallib/DB6P195MB0183CD0D3367C17A1072C127E6399%40DB6P195MB0183.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/CAM%2Bj4qvnuFoKr6LGHCctevkYN_2%3DE%2B5zkkh8gqc3uSW0m68BZA%40mail.gmail.com.
