Interrupts are unstable

Discussion in 'UDOO NEO' started by lmarmisa, Mar 17, 2017.

  1. lmarmisa

    lmarmisa New Member

    Joined:
    Mar 17, 2017
    Messages:
    2
    Likes Received:
    0
    I have developped a program for detecting IR signals. The program is written with the Arduino IDE and works really fine (7x24 during weeks) in ESP8266 and Arduino. I have a long experience with C language, Unix/GNU Linux and real time systems (about 30 years).

    But this is not the case with Udoo Neo. I believe that Udoo Neo Cortex M4 is not stable at all. And incredibly all the UDOO Neo system is down when I try to run my program on Cortex M4!!!. A few seconds and all the system (Linux included) becomes inaccesible!!!. Why?.

    Interrupts are unstable for sure. Maybe other functions too.

    I would like to know if there is a way to run reliably firmware on the Cortex M4. And, of course, I would need to use interrupts there.

    I have searched an answer to the problem but I was not able to find anything useful about it.

    Sorry. I am disappointed with UDOO Neo. I consider that it could be and excellent platform from the hardware point of view but the software is poor.

    Any help will be appreciated.

    Regards,

    Luis
    ...

    #define PIN 2

    ...

    void miInt() {
    ...
    }

    ...

    void setup() {

    pinMode(PIN, INPUT_PULLUP);

    ...

    attachInterrupt(digitalPinToInterrupt(PIN), miInt, CHANGE);

    ...
    }
     
    Last edited: Mar 17, 2017
  2. waltervl

    waltervl UDOOer

    Joined:
    Dec 12, 2015
    Messages:
    2,314
    Likes Received:
    580
  3. jas-mx

    jas-mx Active Member

    Joined:
    Dec 31, 2013
    Messages:
    407
    Likes Received:
    118
    To be frank to do anything useful with the board (in my opinion) you should really develop using FreeRTOS or MQX on the M4 side. It will give you a better insight in the processor architecture and capabilities because it doesn't follow the traditional architecture of an MCU like most Arduino platforms. For example a number of the peripherals require semaphore type access to ensure the A9/M4 don't collide. This is further complicated by fact that clock trees are shared. Another constraint (partly a hardware design decision for neo) is that the memory bus is shared between processors which means the 2 cores have to arbitrate access, so if your not careful its possible to slow the M4 down. If you take these factors into account then coding for the M4 is much more complicated than coding against a traditional cortex M4. Unfortunately these type of factors don't resonate with users of the board when selecting it as a development platform.
     
    Last edited: Mar 17, 2017
  4. lmarmisa

    lmarmisa New Member

    Joined:
    Mar 17, 2017
    Messages:
    2
    Likes Received:
    0
    Thanks for you very useful information. Very much appreciated.

    According to your comments, I have decided to adapt my design to the undesired circumstances.

    First of all I have disabled the m4 cortex adding a command like this to the file /etc/rc.local:

    /usr/sbin/udoom4ctl disable

    I have decided to use an ESP8266 as alternative to the m4 cortex. This device is connected to my LAN by wifi and the communication with the python program running on udooneo is based on sockets.

    KIDDING MODE ON - Of couse this a temporary solution until udooneo works as expected :p - KIDDING MODE OFF

    Best regards,

    Luis
     

Share This Page