I have seen this question or a question similar asked here a few times, however I have not actually found it answered.
I am trying to use the MCU to toggle one of the GPIO pins (using the breakout board). The documentation for the MCU (https://software.intel.com/en-us/creating-applications-with-mcu-sdk-for-intel-edison-board Creating applications with the MCU SDK for the Intel® Edison board: Overview | Intel® Software) specifically references using the Arduino board, which I am not using. I have tried toggling pins using the following code, yet the pin does not toggle.
# include "mcu_api.h"
# include "mcu_errno.h"
gpio_setup(182, 1); //should be J17-pin1 on breakout
I understand I could use the mraa library, but for my application I will need to utilize the MCU to toggle some pins.
In the documentation there is a section for loading the MCU SDK scripts onto the board, however, in the Linux sdk it does not contain those scripts and looking at the init_DIG it only works with a few GPIO pins and appears to be just for the arduino board. Are these scripts needed to be able to control the GPIO via the MCU?
We would like to let you know that we don't support the Ubilinux OS. This OS is supported by the EmutexLabs support team, however, I'm not sure if they still have an active Community for Edison.
If you want to go back to Yocto, we'll be here to help.
I repeated these exact same steps with Yocto and was able to successfully get it working. Not that it helped much, the read time is still incredibly slow. After spending some time with the Edison I understand why Intel has dropped the project.
Are you talking via the /sys/class? Setting the direction, etc? I tried that however was still unsuccessful.
If you are talking about setting the gpio_setup(....) That was done as well, but still without success.
I believe the issue has to do with actually uploading code to the MCU (I could be wrong), as even when I tried the most basic of MCU programs (logging statements etc) there is no response on the ubilinux edison. The only difference between the two setups I've tried was the OS, so I'm unsure what the yocto system is doing to actually push the code to the MCU.
Correct with the mmapped gpio write I was able to switch at around the same speed you mentioned, but the max read reliable speed (if I remember correctly) was around 100us. I tried using an interrupt as well, but since it's just a software interrupt it ends up functioning at the same around 100us (as this appear to be the speed of the loop). This is why I was hoping to be able to use the micro-controller built into the Edison. As you would think it would be operating as a normal micro-controller, but it doesn't appear to be. I should note that with the MCU I was able to get the read speed down to 10us, HOWEVER, that was with nothing else running and the second another process starts up the read speed tanks. Why another process starting up on the main CPU affected the MCU I have no idea but it did.
In the end I just ditched the Edison entirely, while the promise of a full OS with an MCU allowing for more low level operations sounds amazing. From all of my trials and failures with it, it looks like Intel oversold its capabilities. In the end I ended up just using an Arduino, while it didn't have the Linux OS I wanted at least with it I can interact with the hardware I need to. Intel EOLing the Edison made the decision fairly easy as well...
You can replace linux with a PREEMPT_RT version. I have tried to make that easy here: https://github.com/htot/meta-intel-edison/tree/dizzy-rt GitHub - htot/meta-intel-edison at dizzy-rt
I think the idea to have a dual core processor @ 500MHz AND a 100 MHz microcontroller is fantastic combination. Still in many cases you would want the MCU to do real time data acquisition and communicate that back to the CPU for processing. I think the channel used for that on the edison needs a bit of work.
And of course the processing still needs to be done 'on time', so I would say the PREEMPT_RT kernel should have been used by default.
Also, the RTOS for the MCU was promised to be supported by the Windriver cloud environment for Rocket, but that never happend. Instead everybody (including Windriver) is moving to Zephyr, and for some reason (signed blob) we can't use Zephyr on Edison. That is clearly a mistake.
Nevertheless I think the Edison is a fantastic machine, with some rough edges that need just a bit of work. Right now work being done by 0andriy is related to getting acpi support working, x86_64 already working. At a suitable point in time I'll try to get an image building with PREEMPT_RT on a recent kernel.