It should be noted that this Edison is running Ubilinux not Yocto, my apologies for not including that in the initial post
This message was posted on behalf of Intel Corporation
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.
GPIO #182 is one which is used by PWM. Are you sure you preconfigured pin muxing on the board to have this pin output as GPIO?
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.
No, you didn't get my point. You need to set mode 0 to that pin before you upload and run any MCU program.
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: 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.