Intel® Makers
Intel® Edison, Intel® Joule™, Intel® Curie™, Intel® Galileo
Welcome - This is a Peer-to-Peer Forum only. Intel has discontinued these products but you may find support from other customers on this Forum
9872 Discussions

Arduino Code and Python coexistence

Community Manager


I have a rather complex Arduino C script that does a number of tasks - including calling a Perl script to receive data through the USB port and to display a menu + clock string updated every 10 seconds on a 2.8" LCD, that includes resistive touch features.

Here's a bit more about what happens inside the Perl script: It is a background process (invoked with "&" via a system call) that receives data through the USB port which is connected to an Ethernet dongle. When a certain text string is received, the Perl script will execute a Python program that turns on Pin 3 to sound a buzzer.

The Python script includes mraa and time, and just raises Pin 3 high for 3 seconds. It's a one-instance only background process (also invoked with "&" via a system call from the Perl script).


Once my buzzer sounds, the 2.8" LCD freezes and after that the main Arduino C program remains unresponsive until I reboot. I have isolated the problem to the execution of the first line in the python script - "import mraa".

Running the Perl script alone without any call to the Python script causes absolutely no problems at all.


Can Arduino C code communicating with hardware pins (like display and resistive touch) and Python mraa code (to sound the buzzer) coexist? Any debugging means to help solve this? If not, is there another way to solve this - short of porting all the Perl script into the Arduino C code - how could I sound my buzzer?


1. Running "top" from Linux, I could see that the sketch seems to be stuck for some reason:


206 205 root D 36428 4% 12% /sketch/sketch.elf /dev/pts/0

2. "strace"-ing 206 returned the following endless loop:

ioctl(111, KYRO_IOCTL_OVERLAY_CREATE, 0xbfffdde0) = 1

ioctl(111, KYRO_IOCTL_OVERLAY_CREATE, 0xbfffdde0) = 1

write(105, "\r", 1) = -1 EAGAIN (Resource temporarily unavailable)

write(105, "\n", 1) = -1 EAGAIN (Resource temporarily unavailable)

ioctl(111, KYRO_IOCTL_OVERLAY_CREATE, 0xbfffddc0) = 1

ioctl(111, KYRO_IOCTL_OVERLAY_CREATE, 0xbfffddc0) = 1


3. Another strace (strace -c -p 206) resulted in this:

% time seconds usecs/call calls errors syscall

------ ----------- ----------- --------- --------- ----------------

97.47 0.080704 3 23420 ioctl

2.53 0.002095 1 3035 3035 write

0.00 0.000000 0 1 time

0.00 0.000000 0 1 1 sigreturn

0.00 0.000000 0 1 stat64

------ ----------- ----------- --------- --------- ----------------

100.00 0.082799 26458 3036 total

Apparently, the sketch was still working in the background. I could even see my Serial monitor messages being written (under the syscalls to "write"). So, possibly only the resistive touch of my 2.8" LCD died on me. It must be then that "import mraa" initialized all the hardware pins?

4. The same trace before the python script is ever executed:

% time seconds usecs/call calls errors syscall

------ ----------- ----------- --------- --------- ----------------

100.00 0.069363 3 20292 ioctl

------ ----------- ----------- --------- --------- ----------------

100.00 0.069363 20292 total

5. EDIT - The display also died, since my clock has froze up too. I navigated back to the main page where a clock was telling me if the sketch was running. Once the buzzer sounds, the clock remains frozen forever.

Hmm... back to the drawing board. Although if you have suggestions on what I should, I would really like to hear them.

0 Kudos
4 Replies
Community Manager

Hi Gavinkoh70,



I'd love to help you with your problem, so can you share me your code and scripts? I want to make some tests to try find out the issue.



I will be waiting for your reply.





Community Manager

Python code:

import mraa

import time

import os

import sys

pid = str(os.getpid())

pidfile = "/tmp/"

if os.path.isfile(pidfile):

print "%s already exists, exiting" % pidfile


file(pidfile, 'w').write(pid)

buzzPin = 3

sleepTime = 4

x = mraa.Gpio(buzzPin)






This is straightforward code that creates a one-instance only python script that sounds my buzzer for four seconds exactly.

I know you need some other mechanism for a singleton, so I didn't bother figuring out how to opkg install ("tendo") for it and opted to try pid file locking. However, the occurrence of the event that sounds the buzzer can be as fast as only milliseconds apart, and it seems the often continuous invocation of the python script is causing the Arduino sketch to hang.


1. I commented everything but the first two lines and it crashed! Could importing mraa and time together be the cause?

2. I commented everything but the first line and it still crashed! Could importing mraa be the cause?

Community Manager

I think I may have a way out of a python file that is causing my Arduino sketch to hang. Here is the inkling of a bash script that may just solve this problem:

# !/bin/bash

echo 1 > /sys/class/gpio/gpio12/value # Turn on IO3 or pin 3

sleep 4

echo 0 > /sys/class/gpio/gpio12/value # Turn off IO3 or pin 3

Pin 3 must first be initialized by the Arduino sketch. Clicking the touchscreen shall then turn on the Perl Script which then captures data thru the Ethernet cable attached to my dongle and USB. When a specific message header appears, the bash script is invoked to turn on the buzzer.

For those wanting to learn more (why gpio12 equals pin 3), please see the table on page 8 of this document:

Couple the above code with this boilerplate bash script at: linux - The best way to ensure only 1 copy of bash script is running? - Stack Overflow

No need to use "import mraa" any more. That single python line alone is doing something that it should not be doing.

UPDATE - Solved, as described above.

Community Manager

Hi Gavinkoh70,



That's great, it is good to see that you found another solution.



I'm not sure what is wrong with the python script, but this can help as suggestion in these kind of cases.



Thank you so much for posting the solution, we really appreciate that.