UART Interrupts during I2C Interrupt

[PCM programmer]

[Jamby]

Oh dear! I didn't know that's possible to do in such a way.
I tried to simulate the circuit and i saw that the RCIE bit in PIE1 register was resetting when it entered in SSP interrupt, but after you said that, I've checked and I saw that I've set wrong the register address.
I'll try this solution ASAP.
Thank You.

EDIT:
It does PERFECTLY works.
I would like to know the difference between your solution and a more "readable" solution like this:
Can I just check the kbhit function?

[PCM programmer]

I was trying to show the general case. But you're right, these two lines
produce equivalent ASM code:

[RF_Developer]

Some important points: "As a 8bit PIC, it only "supports" one Interrupt a time". Being an 8 bit PIC has nothing to do with it. All single core processors, indeed practically all processors (each core in a multi-core chip are processors in their own right) can only only ever do one thing at a time. Interrupts are point events, they happen at a time, they do not spread over a time interval. Unfortunately your comment only shows that you don't really understand interrupts fully yet.

Interrupts are hardware events. When an external device, be it a built-in peripheral such as the UARTS, I2C or whatever, or something external to the PIC generates an interrupt it is merely raising a hardware flag that says it needs servicing in some way. UARTS raise interrupts when they receive characters, or detect errors or have completed sendind of a character. The receive interrupt, RDA in CCS, means the UART has received a character and it needs to be dealt with.

When an interrupt is raised and the firmware is configured to deal with it, in other words there is a suitable ISR routine and interrupts are turned on for this source and globally, then the processor, with help from CCS interrupt handling code, saves whatever its was doing and starts, after a short but not insiginificant time, running the ISR code. By default interrupts are disabled while running ISRs, and reenabled automatically by CCS interrupt handling code after the user's ISR has finished. Interrupts CAN be turned on while in ISR code. This is NOT a good idea. You'll helplessly confuse CCS's interrupt handling code, which is not designed to be re-entrant. I have, a long time ago, on a 16C74, had re-interruptible ISR code. BUT that was in assembler where I had full control of the processor context. It enabled half decent software transmit only UART code (as the hardware designer had thoughtfully not bothered to connect the RS232 to the hardware UART pins) to run while updating an LCD (no controller, just IO lines). To to this I had to make the lengthy LCD update ISR re-interruptible for about 2/3 of its code. I write this to illustrate it is possible, but absolutely NOT recommended for CCS C.

As always, the recommendation for ALL ISRs is to make them as short and as fast as possible. Its entirely possible to have several interrupts running on a single PIC. What you need to remember is that interrupts are hardware events that generally have a limited time window. They are thus realtime events: service them quickly and efficiently. Interrupts that occurs while interrupts are disabled are not "lost", they are simply delayed. The point is to delay them as little as possible.

Your UART RDA ISR is OK. It simply buffers incoming data. Its your I2C ISR that's got the problem. Really with an I2C slave you need to have everything that you need to send ready and waiting, buffered up somewhere. Its not as bad as an SPI slave however, at least with I2C the slave can hold up the transfer. Never the less, you really need to have everything ready rather than wait around for it to come in from elsewhere. As you've found, if waiting for it in an ISR involved waiting for other ISRs to run, as in your code, then you've got a big problem. Its a form of deadlock and its been around as long as interrupts have.

Your I2C ISR will run for every byte in the I2C transaction. You need that to run totally independantly of the serial data transfer. Your I2C stuff should only ever attempt to transfer data when there is a complete buffer full of data waiting for it. AND you'll need to double buffer your data to allow you to receive new serial data while transmitting the last complete dataset by I2C. All this is standard computing stuff; such interrupt driven double buffering of data has been around since the early 1960's. You may need to alter your I2C protocol to include a "Data not ready" response to be used when there is not a full buffer of data ready and waiting.

To sum up: make you transmit only send if there is a complete buffer of data. Use double buffering. Ensure ISRs are short and don't have to wait for anything.

RF Developer

[Ttelmah]

I was going to post something similar, but you beat me to it.

Add the comment, that this sounds like a perfect job for one or more 'flags'. Single bit boolean variables, which the PIC can test/set in a single instruction. You could have a flag saying 'RS232_packet_to_be accepted', which is normally 'false', then just set it in the I2C ISR, when the particular event occurs that you want to start the RS232 transfer. In the RS232 code, just ignore characters, till this flag goes 'true'. Then perhaps another 'RS232_packet_complete', set when the packet is complete.

You need throughout, also to remember that nothing is perfect. Characters sometimes _will_ get lost or corrupted. This is why systems that rely on character 'counting', are potentially dangerous. Code that sits waiting in an ISR for a number of characters to arrive, will sometimes go wrong. If instead the arrival of 'xx' characters sets a flag signal, then in the main code, you can test a timer, and if this does not happen within a period of time, institute recovery procedures. Much harder to do if you are sitting in an ISR...

Best Wishes

[Jamby]

[RF_Developer]

Simple: buy a bigger PIC.

RF Developer.

[Jamby]

[asmallri]

The PIC18F supports two separate hardware priorities. When a normal (low priority) interrupt is being processed, the PIC18F ONLY disables the low priority interrupt. A high priority interrupt can happily interrupt a low priority interrupt handler.

PIC24 and above support multiple hardware priority interrupts and without doubt provide far more flexibility in this regard.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[RF_Developer]

"Do you think that if it was possible, I wouldn't have already bought a bigger PIC to accomplish this?"

Judging by the vast majority of people who come to this forum, yes, I think that you may well have not thought of using an alternative PIC. Many haven't even read the datasheet for the device they are using, and/or have only the very barest grasp of C. A lot have no concept of how interrupts work.

You came on here and made it clear you were unclear as to what an interrupt was as compared to an interrupt service routine. Maybe that was/is a language difficulty... maybe not. Your use of English is of sufficient a level to make me think language is NOT the issue, or at least not the main issue.

Even after carefully describing the difference and making some of the implications clear, you just brush those aside and move your goal posts, by saying that you have already fixed your hardware implementation and that's not going to change.

You then, in the next sentence, tell us you are using a very amateur and frankly fault prone method, which makes me think more than ever you are not experienced enough to adopt a suitable engineering solution, i.e. to pick hardware capable of doing the job, instead you're insisting on a firmware fix to your problem.

OK, I think your best way of dealing with this is to abandon C altogether and assembler, then you'll have total control of the processor. It'll take you more effort of course, but its much more likely that you'll get a satisfactory result. Maybe you need to forget interrupts altogether and go for a completely polled solution, with a very tightly looping main loop. Controlling a single UART and I2C is straightforward enough to do in assembler, a polled implementation may well work in C come to that.

As a general note, just because the PIC can do something. that doesn't mean CCS C must be able to implement the same functionality. I'm thinking here of certain PWM operations which need extra peripheral initialisation that is not covered by CCS's PWM setup functionality. Also ALL interrupt functionality is not covered by C, its all done by extensions, which vary from compiler to compiler, so its entirely reasonable to expect some unusual functionality, and nested interrupts ARE unusual, not to be easy or possibly even supported by CCS C, or any other compiler come to that.

I've tried to help all I can. I won't comment further on this.

RF Developer