Hi Nico, Using interrupts to read the state of push button is generally a bad idea because of button bouncing. It means that the button during transition from stable low state to stable high state will generate a very fast (kilo hertz) square wave. The interrupt will try to execute many times on every rising edge. There are many solutions for this under "push-button debouncing". I understand that this circuit is just for tests. Anyway bouncing will influence the test. There is a confirmed issue with interrupts handling on UDOO neo board.
@Andrea Rovai is sharing *.diff files related to MQX sources a violation of the agreement between UDOO and Freescale?
I have just tried to push the reset button, all leds turn off, and then it come back as before (blue & yellow lighted on my first UDOO, and only blue on my second UDOO). Without interrupt the result is the same for yellow and blue leds. My mistake, I put 10µF capacitor on my real mounting, but I forgot it on my test mounting, I have just tested after adding this capacitor on my previous posted mounting, and the result is the same
Hi guys, @matib12: here is the link to the diff: https://github.com/UDOOboard/udooneo_mqx41_patch It may be not updated, we are updating it today.
@Nico The following part could be a problem (also the other signal part): pinMode(startSignal, INPUT); digitalWrite(startSignal, HIGH); It should be replaced with pinMode(startSignal, INPUT_PULLUP);
I have just tried, and the result is the same. I was thinking that INPUT + digitalWrite HIGH did the same as INPUT_PULLUP... I will use INPUT_PULLUP instead now
Blue and Yellow always should go on (if interrupt is not working) as you pulled Start- and StopSignal high at startup.
interrupts should be better with the latest update (sudo apt-get update & upgrade)! Interrupt on CHANGE should work now, and reliable. Can someone check?
At today interrupt () and noInterrupt () are not supported because the hardware doesn't support them. As written here, you can use interrupts on any digital pin, so you can attach an interrupt as you'd usually do with attachInterrupt (). Otherwise you can use attachInterrupt () and detachInterrupt () one by one. We're looking for a software solution to enable them however.
@waltervl I made the test with a fresh udoobuntu-udoo-neo-desktop_2.0rc2 immediately updated with apt-get. Then I simply run the software I need. (It should be a PPM decoder for scale models) Code: #define Serial Serial0 #define pin8 8 volatile unsigned long pos; volatile int diff = 19586, diff_1, diff_2, diff_3, diff_4; volatile int interg_diff, tempvar; volatile int count; // debug void startISR1() { count++; diff = (int)(micros() - pos); if(diff > 2500) tempvar = 0; pos = micros(); if(diff > 900 && diff < 2500){ switch(tempvar){ case 0: diff_1 = diff; tempvar++; break; case 1: diff_2 = diff; tempvar++; break; case 2: diff_3 = diff; tempvar++; break; case 3: diff_4 = diff; tempvar++; break; } // if(tempvar == 3){ // tempvar = 0; // } } } void setup() { pinMode(pin8, INPUT); pinMode(13, OUTPUT); Serial.begin(115200); attachInterrupt(pin8, startISR1, CHANGE); delay(22); // wait for at least one ISR excecution } void loop() { delay(1200); Serial.print("D-Dold: "); Serial.print(diff_1); Serial.print(" "); Serial.print(diff_2); Serial.print(" "); Serial.print(diff_3); Serial.print(" "); Serial.println(diff_4); Serial.println(count); } As before the interrupt just detached (it was enough to reattach it) now the whole board hangs up (A9 included). Indeed before it hangs up the interrupt excecutes 5000 times. Before the last update it was max 100 times. Which log can I share to help?
I'm using cross-compilation. Today I updated BSP of my Arduino IDE. I obtained much better result. Below I paste working piece of the PPM decoder. Code: #define Serial Serial0 #define pin8 8 volatile int counter; volatile unsigned long pos, pos_imm; volatile int diff = 19586, diff_1, diff_2, diff_3; volatile int tempvar; volatile int count; // debug void startISR1() { count++; diff = (int)((pos_imm = micros()) - pos); if(diff > 1500) tempvar = 0; pos = pos_imm; if(diff > 480 && diff < 1010){ switch(tempvar){ case 0: diff_1 = diff; tempvar++; break; case 1: diff_2 = diff; tempvar++; break; case 2: diff_3 = diff; tempvar++; break; } if(tempvar == 3){ tempvar = 0; } } } void setup() { pinMode(pin2, INPUT_PULLUP); pinMode(pin3, INPUT_PULLUP); pinMode(pin4, INPUT_PULLUP); pinMode(pin5, INPUT_PULLUP); pinMode(pin6, INPUT_PULLUP); pinMode(pin7, INPUT_PULLUP); pinMode(pin8, INPUT); pinMode(pin9, INPUT_PULLUP); pinMode(pin10, INPUT_PULLUP); pinMode(pin11, INPUT_PULLUP); pinMode(pin12, INPUT_PULLUP); pinMode(13, OUTPUT); Serial.begin(115200); attachInterrupt(pin8, startISR1, RISING); delay(22); // wait for at least one ISR excecution } void loop() { delay(1200); Serial.print("D-Dold: "); Serial.print(diff_1); Serial.print(" "); Serial.print(diff_2); Serial.print(" "); Serial.println(diff_3); Serial.println(count); } Pulse length measurement performed by the code give result from 480 to 1000 microseconds. In reality the pulses are twice longer. Did you modify some clock divider? I must test microsecods().
@matib12 here are the changes in the source http://www.udoo.org/forum/index.php?posts/20427 I believe a saw a clock resolution change somewhere. Edit: It is probably this one: https://github.com/UDOOboard/arduino-board-package/commit/3f6fe92776a22e8c0731d4f03e0cdc0d8f01581f
@Andrea Rovai : I have just tested the new version (with a fresh install) using the code I have posted before (using pin 10 & 11 for interrupt instead of 6 & 7). And interrupts make my udoo freeze, but it may be due to my UDOO boards problems (pin 6 & 7 does not work anymore on my first board, and 7 on my second board), so if anyone can try it to confirm or not this problem it would be great.
I confirm the issue. I described it in my previous post. I've found the problem on my board which doesn't have problems with IO ports.
Hi there, Seems like you're not updated with the last kernel version, this commit should have fix that: https://github.com/UDOOboard/linux_kernel/commit/42ce6e4576f153af576b3babf6d8e6ee9b6af7e2 What kernel are you using? Could you please share the output of `uname -a`?
@ektor5 : Here is uname -a message before running apt-get upgrade Code: Linux udooneo 3.14.56-udooneo-02021-g724c68a #3 SMP PREEMPT Thu Jul 21 12:26:41 UTC 2016 armv7l armv7l armv7l GNU/Linux After running apt-get upgrade : Code: Linux udooneo 3.14.56-udooneo-02022-g658e2cb #4 SMP PREEMPT Wed Jul 27 13:35:58 UTC 2016 armv7l armv7l armv7l GNU/Linux But the freeze error is still here
My uname -a gives: The kernel is a recompiled from the git source and default configuration but without MCC support. Thanks to @ektor5 for pointing out the commit. In the source files I compiled there are no changes solving the problem. I will examine why the source I have is not up to date and subsequently recompile it.
The fix is made in dts files, so you need to reboot and make sure you are using the right dts (maybe you're using a custom one with dtweb). To see if you are loading the right dtb: Code: ls /proc/device-tree/soc/aips-bus@02000000/*/m4-reserved-pin should return: Code: /proc/device-tree/soc/aips-bus@02000000/gpio@020a8000/m4-reserved-pin /proc/device-tree/soc/aips-bus@02000000/gpio@020ac000/m4-reserved-pin /proc/device-tree/soc/aips-bus@02000000/gpio@020b0000/m4-reserved-pin
@ektor5 The result of Code: ls /proc/device-tree/soc/aips-bus@02000000/*/m4-reserved-pin is as you predicted. On the other hand I modify the device tree (through the tool available via remote desktop) because I need the access to the 9-axis sensors from M4.