4 Replies Latest reply on Sep 22, 2016 4:26 PM by Intel Corporation

    Arduino Code and Python coexistence

    gavinkoh70

      BACKGROUND

      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).

       

      PROBLEM

      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.

       

      QUESTION

      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?

       

      THREAD UPDATES

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

      PID     PPID     USER     STAT     VSZ     %VSZ     %CPU     COMMAND
      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
      BLAH BLAH BLAH
      

       

      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.

        • 1. Re: Arduino Code and Python coexistence
          Intel Corporation
          This message was posted on behalf of Intel Corporation

          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.

          Regards,
          Leonardo

          • 2. Re: Arduino Code and Python coexistence
            gavinkoh70

            Python code:

            import mraa
            import time
            import os
            import sys
            
            pid = str(os.getpid())
            pidfile = "/tmp/buzzer-on.pid"
            
            if os.path.isfile(pidfile):
                print "%s already exists, exiting" % pidfile
                sys.exit()
            file(pidfile, 'w').write(pid)
            
            buzzPin = 3
            sleepTime = 4
            
            x = mraa.Gpio(buzzPin)
            x.dir(mraa.DIR_OUT) 
            x.write(1)
            time.sleep(sleepTime)
            x.write(0)
            
            os.unlink(pidFile)
            

            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.

             

            UPDATE:

            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?

            • 3. Re: Arduino Code and Python coexistence
              gavinkoh70

              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: https://www.google.com.sg/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwje9JmgyKLPAhVC5WMKHUW4BI4QF…

               

              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.

              • 4. Re: Arduino Code and Python coexistence
                Intel Corporation
                This message was posted on behalf of Intel Corporation

                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.

                Regards,
                Leonardo