Timeline for Writing SSPBUF from variable in I2C slave protocol in PIC18
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 24, 2017 at 1:13 | vote | accept | Chocksmith | ||
| Jan 23, 2017 at 22:38 | answer | added | Ken | timeline score: 1 | |
| Aug 15, 2016 at 10:22 | history | edited | Chocksmith | CC BY-SA 3.0 |
added 394 characters in body
|
| Aug 15, 2016 at 10:16 | comment | added | Chocksmith | Gábor, two questions: 1) When you say it is a design error do you refer to my program or to the PIC itself? I disable interruptions and clear SSPIF in the ISR. In my last version I disable the SSPIF in the beginning instead of the end of the ISR. No difference... Same error. 2) You stopped using only XC8 or the PIC itself? I am very unhappy with this kind of things that have been happening and your 15 years experience is important to me. | |
| Aug 13, 2016 at 22:43 | history | tweeted | twitter.com/StackElectronix/status/764593197389676544 | ||
| Aug 13, 2016 at 11:31 | comment | added | Gábor Móczik | bitsmack: It is a design error, if you enable an intertupt and you do not handle it in the ISR. It is indeed hangs up the MCU, but in PIC you can not clear "any other still pending" flags. In general, usually can not clear the flags either, most flags are cleared automatically if you clear the cause that turned the flag on. For example, writing something to a buffer, in a "buffer empty" condition will clear the buffer empty flag automatically. | |
| Aug 13, 2016 at 11:22 | comment | added | Gábor Móczik | Does not help you out, but these are the usual sucks nowadays with XC8 compiler. I have several code that worked perfectly, tweaked for ten years before the XC8 era, and now I always spending hours pulling my hair with some non-understandable problem. My 15 years of experience in PIC does not worth anything this way. This is why I completely stopped using Microchip things. | |
| Aug 12, 2016 at 11:26 | comment | added | Chocksmith | rdtsc, I did. Does not work. I've edited the answer and included option 4. I still do not understand and do not consider my workaround as a definitive solution. | |
| Aug 11, 2016 at 18:47 | comment | added | rdtsc |
Try volatile unsigned char a = 0x01;
|
|
| Aug 11, 2016 at 0:27 | answer | added | Chocksmith | timeline score: 1 | |
| Aug 10, 2016 at 23:57 | comment | added | bitsmack | I don't see anything obvious, but I hope that someone else will! You should certainly be able to use a variable to feed SSPBUF. As you say, it wouldn't be very useful otherwise. | |
| Aug 10, 2016 at 23:44 | comment | added | Chocksmith | Good point. This is a hidden bug. It is not interfering now because on my setup there is no other interruption possible. I will fix it. Tks! Let me know if you have any other comment that help me to sleep at night. I've been working on this for days. | |
| Aug 10, 2016 at 23:41 | comment | added | bitsmack |
Not a solution, but an unrelated hint: When verifying that the interrupt was caused by I2C (if (PIR1bits.SSPIF != 1)), you don't clear any interrupt flags. If the interrupt was, in fact, caused by some other interrupt source, then the ISR will be called again immediately, forever...
|
|
| Aug 10, 2016 at 23:36 | review | First posts | |||
| Aug 11, 2016 at 6:38 | |||||
| Aug 10, 2016 at 23:32 | history | asked | Chocksmith | CC BY-SA 3.0 |