I noticed an unusual error following an upgrade to MRAA 0.9.0
Summary: In MRAA version 0.9.0 of GPIO the isrExit() function returns a status of "Invalid Handle" (integer value 5);
- Noticed the error after an MRAA upgrade from 0.7.2 to 0.9.0. The operating system was not upgraded.
- If the GPIO setPriority function is executed by the application, then there is NO "Invalid Handle" status returned by the isrExit function.
- In version 0.7.2 there was no error status returned.
- Configure_edison –-version returns 159
Has anyone noticed the same?
arfoll do you know why are we having issues with version 0.9.0? Am I missing something or am I doing something wrong?
I'm confused as to why setPriority() from common would change anything. Can you give us a small example of the code?
@Intel_Peter - if you find a bug put it in as a github issue on github.com/intel-iot-devkit/mraa - I'll look at it ;-) Node.js is being a pain as people are taking 0.12.x from AlexT's repo and that's not compatible with the binaries we generate on iotdk.intel.com. The blink js example didn't use to work if you copy and pasted it in the node.js interpreter (but would from a file), that's fixed now.
@Intel_Peter - if you find a bug put it in as a github issue on github.com/intel-iot-devkit/mraa - I'll look at it ;-) Node.js is being a pain as people are taking 0.12.x from AlexT's repo and that's not compatible with the binaries we generate on iotdk.intel.com. The blink js example didn't use to work if you copy and pasted it in the node.js interpreter (but would from a file), that's fixed now.thank you for illuminating me, that explains a lot!
Thank you for illuminating me arfoll, that explains a lot!
I am developing in C and C++ using the native development platform on the Edison platform. I too downloaded MRAA version 0.9.0 from the intelgalactic platform (folder 2.0) in order to be consistent with the online documentation (http://iotdk.intel.com/docs/master/mraa/ mraa: Main Page). My preference would be to work with the development team to resolve (if it is indeed a bug). I've not ruled out an issue with my development environment.
I also was surprised to discover the behavior of the setPriority () function. I stumbled across this behavior as I was adding functionality to an application I am developing. My thought was that perhaps the setPrioity function was setting some information that was overlooked when the original interrupt service routine (isr) was created. By the way, there were no entries related to this issue in the journal and I had set it to the most detailed level. I would be happy to pull together a small example. I trust C would be acceptable. It will take me a few days pull this together.
In the meantime, if you have questions don't hesitate to ask.
I have a demonstration application, in C++, that consistently demonstrates the problem on my unit. The code is about 350 lines. Is there a preferred way to provide you with the code. Also was planning on providing the terminal output and the journal file. Is there any other information you would find useful?