I'm running into an issue that after a short while the Arduino seems to hang, and doesn't write any values to the serial port anymore. My linux part keeps on reading, but reports there is nothing to read. In the Arduino program I do check whether there is enough writeable buffer on the Arduino serial port, but it seems that the entire program hangs. This leads me to the question if there are stability issues in the Arduino part. The program itself is fairly simple, it reads a switch, and if the state changed it will update the leds and write that change to the serial. As I don't see a led change anymore it must be hanging somewhere. After a reboot it works for a couple of minutes. The worrying thing is that when I used the web based IDE I thought I ran into similar issues, I could use the Arduino for a short while and then it needed a reboot as it did not seem to respond anymore.
Serial output is very critical. I had it failing when I made a small typing error which passed the compiler. I just made a sample program a couple of days ago because of all the serial issues and I did not get it to fail. What also could help is a small delay(10) after a read end before the serial.write
After some -semantically the same- changes it has been running all night. I wish I could somehow know what was wrong earlier so I can prevent it in next projects.
There is a possibility to do a m4 debug through uart2 but I don't have a serial to USB converter to read it with my PC. http://www.udoo.org/docs-neo/Hardware_&_Accessories/UART_serial_ports.html I also have no idea if it would display errors
Actually, I think that Arduino porting here is not stable enough, sometimes I have to upload 2-3 times to make the program run while the sample programs work well. So be prepared for waiting the porting libraries (in months) or you have to code buy yourself.
Top men debugging is possible on the uart2, you also have to set an extra define in the sketch http://www.udoo.org/docs-neo/Arduino_M4_Processor/Debugging.html Just wondering if you can hardwire this uart2 to uart6 so you can read it from the linux side of the Neo?
I'm experiencing lots and lots of unstabilities. Simple programs like turning a led on and off stop to work after a couple of uploads, the Arduino doesn't respond, even the built in led doesn't work. When I declare pins for output, do a digitalWrite it may or may not work. If I switch the pin to a different port, they often work. If after a while I go back to the old pin, that pin just works fine again. It is getting rather frustrating, and for now I'm binning my second purchase until I find out better what is going on.
I never have these kind of issues. I don't use PWM though. I also only use the Arduino IDE on the Neo Linux side.
I vented my frustration after this program didn't get uploaded to the Arduino, which I wrote when my previous program seemed not to work at all. #define PIN 10 #define LED_BUILTIN 13 #define INTERVAL 5000 void setup() { pinMode(PIN, OUTPUT); pinMode(LED_BUILTIN, OUTPUT); } #define BLINK 32 void loop() { digitalWrite(PIN, HIGH); digitalWrite(LED_BUILTIN, HIGH); delay(BLINK); digitalWrite(PIN, LOW); digitalWrite(LED_BUILTIN, LOW); delay(INTERVAL - BLINK); } I did some changes with INTERVAL and BLINK, and then no results with uploading whatsoever. The last few experiments did work though...
#define is not a preferred method for defining constants, see also https://www.arduino.cc/en/Reference/Define See also the next quote from this page: This can have some unwanted side effects though, if for example, a constant name that had been #defined is included in some other constant or variable name. In that case the text would be replaced by the #defined number (or text).
Yes better use static const unsigned int ... This is why I do not like arduino. It is c++ they are using, but they always try to hide it. Gesendet von meinem FP2 mit Tapatalk
I fail to understand why if I define const int LED_OUTSIDE = 10; it actually responds to pin 11, while in my previous test I defined 10 and the same led, same board responded to pin 10......
So one reason maybe somewhere in the arduino code one defined LED_OUTSIDE as global variable this can lead to such a fun. This is why I suggested static. Which creates a namespace. So this is crude C world. Gesendet von meinem FP2 mit Tapatalk
And there is a big in RC1 ( and perhaps earlier) were pin 10 and 11 are changed. So writing to pin 11 was setting hardware pin 10. To make it all easier In the just released Udoobuntu RC2 this should be fixed (not tested by me yet).
According to this manual http://www.udoo.org/docs-neo/Arduino_M4_Processor/Use_more_digital_pins_on_M4.html the arduino pin mapping is defined in the arduino platform code so this should be independent of UDOObuntu. Good to know about the pin mapping issue Gesendet von meinem FP2 mit Tapatalk
You are so right . Due to the fact I rarely use UDOObuntu I forgot about this Gesendet von meinem FP2 mit Tapatalk
@waltervl Let me know if you find it fixed... I downloaded the RC2 yesterday and when nothing seemed to boot I discarded it, not wanting to go deeper into the rabbit hole.
I just installed RC2 (download from Sourceforge), it booted nicely and the pin 10/11 swap issue is solved!
I haven't been able to run Arduino->Serial->Linux stable for more than 24 hours... The code is actually quite simple, and I do check if there is room available on the serial stream, so if there would be an error on the Linux side, it should never block, should it?
