Closed gweep closed 8 years ago
Standby... I was creating a stripped down version of my sketch to demonstrate the problem. When I removed my LCD display code and switched to the serial monitor. The problem went away. So still up in the air about the incompatibility. Could be my LCD library. that is triggering the problem with the interrupts... Now need to test the LCD with the interrupts alone...
I've definitely encountered similar issues when trying to use interrupts, and I'm also fairly certain that the limitation is in the Wire library. Due to that, I'm going to tentatively mark this as a wontfix, but I'll be glad to assist you to work around it if I can.
Without seeing your particular code, it's hard for me to make specific recommendations, but I can give you some general tips. Any updates to the Si5351 that you wish to do in an interrupt should be tracked in a volatile variable, and then actually implement those changes to the Si5351 in loop(). This is how I do tuning with a rotary encoder and it works quite well. As long as you don't need to update very quickly, this should be an acceptable way to do things. Feel free to link me to some code if that doesn't work or isn't applicable, and perhaps I can give further pointers. Good luck.
I’ve managed to do a major re-write.. resulting in better code. So far it seems that the si5351 is stable if I call its setup function prior to any interrupts AND that my one and only call to set its frequency is in the main loop and between a set of “detachInterrupt” and “attachInterrupt” statements for every hardware interrupt that I am using.
I’ve also figured out that the code that I have been using to run the LCD display uses a software delay which is completely disrupted by hardware interrupts. So bad news on both fronts. For the time being I’ve switched to a more common LCD display that does not use special software.
Thanks Mike, AB2TS
On Mar 12, 2016, at 20:06 , Jason Milldrum notifications@github.com wrote:
I've definitely encountered similar issues when trying to use interrupts, and I'm also fairly certain that the limitation is in the Wire library. Due to that, I'm going to tentatively mark this as a wontfix, but I'll be glad to assist you to work around it if I can.
Without seeing your particular code, it's hard for me to make specific recommendations, but I can give you some general tips. Any updates to the Si5351 that you wish to do in an interrupt should be tracked in a volatile variable, and then actually implement those changes to the Si5351 in loop(). This is how I do tuning with a rotary encoder and it works quite well. As long as you don't need to update very quickly, this should be an acceptable way to do things. Feel free to link me to some code if that doesn't work or isn't applicable, and perhaps I can give further pointers. Good luck.
— Reply to this email directly or view it on GitHub.
Glad you figured it out. Best of luck with your project!
Been searching for an I2C library to replace the Wire library. Need a solution that does not prevent me from using my own hardware interrupts. Would prefer to use a hardware interrupt to detect a keydown.
I was hoping that SoftWire or SoftwareWire would do the trick, not sure if they use interrupts. But I have not been able to convert the si5351.cpp and si5351.h code files so that they will compile, let alone try them in my own code.
Any thoughts? I've been using the Si5351Arduino library on a Pro Mini and an UNO.