Over the past few weeks I've asked multiple questions about the stability and compatibility of the Arduino part of the Neo. I'm starting to believe more and more that it is quite unstable and isn't as Arduino compatible as I would like it to be. About the stability: I notice that after a 'few', and I don't know how many exactly, USB deployments from an external ide to the M4 the board does not seem to pick up the new program any more. Resetting sometimes helps, sometimes doesn't. Each time I reset the board the connection to the board is lost, and I need to re-ssh if I want to keep an eye on the serial output. A very big annoyance. Another stablity issue is which I seem to have with my simple 4x7 segment display, I think I should be able to download any Arduino library, and not have to spend my entire day trying to debug a library, nor having the need to dig up the specifications in order to try to create a library of my own. Although UDOO Neo has sparked my interest in Arduino programming I would certainly not recommend this board to anyone just starting out with Arduino. The Linux part seems to be okay though. Addition: Rebooted the board for multiple times now, removed /var/opt/m4/m4last.fw, re-started Arduino IDE, stood on my head, did a rain-dance, invoked the powers of the universe, but it refuses to even start the 'hello world' (blink led 13).
I can confirm the observation of an unstable Arduino operation. My UDOO board freezes about every third time when I upload an Arduino sketch using the local Arduino IDE in the Ubuntu X-Desktop. It is very annoying to be forced to reset the whole UDOO frequently to be able to develop and run Arduino sketches. Please improve the Arduino part and give us a stable development environment !!
@kay, I'm using an Arduino (clone) now too, and the experiences with that are much better. Altough I can use my Neo for a simple project, I think in the future I'm better of using a Arduino (clone) and a separate Linux board such as the Pine 64. Only downside of that is that you have two boards, requiring more space. Edit: forget that last specific suggestion:
It’s relatively easy to pick up a few thousand ARM chips, hire an EE for a month or two to produce a single board computer, and find a contract manufacturer in China. The hard part is getting the software working, getting the documentation together, and fostering a community that isn’t stumbling in the dark trying to get this board to work. This is where the Pine64 fails. The forums are a mess right now, and the comments on the Kickstarter campaign aren’t much better. Kinda like here!
Tip: If you have serial print commands in your sketch have the Neo Arduino IDE serial monitor open during compiling. It helped me a lot. When using an external Arduino IDE (eg on your own PC) then the serial monitor is not working so you have to find another way to be sure Serial print commands are not blocking the serial line. Perhaps start minicom -D /dev/ttyMCC on the Neo?
@waltervl Unfortunately the 'hanging neo' has no relation with using Serial. I've had numerous hangs in small programs that didn't have any Serial usage at all.
How about libraries you are using? BTW did you see this manual page about porting libraries, I stumbled upon it today: http://www.udoo.org/docs-neo/Arduino_M4_Processor/Porting_Libraries.html
@Maurice, is this not extremely annoying, buying a combined Linux/Arduino board to get the advantage of analog and digital realtime data capture and control plus a Linux platform to do the high level processing and end up with a malfunctioning device ??? I have several Raspberries and Arduinos in my workshop but I was thrilled by the idea of putting both together with a seamless on board communication, additional sensors, increased precision, Bluetooth and WiFi. I still hope they can fix the problem for the Neo :-(.
Neither. btw, the page you are referring to was put up in response to my customer request. But that is not the solution. The technical support guys will now purchase a display themselves and hopefully find out the problem. Even more, I hope they'll be able to document it so next time it is easier to do so yourself.
I just compiled and uploaded 10+ times and had no errors. I used my own programs, bare minimal example, blink example, fade example, changed blink example a couple of times.
Wierd. I wish I could have such a constant success. Using my Mega 2560 now, and not experiencing hangups is nice.
FWIW, my board also responds erratically to firmware upload requests. I'll try gather some diagnostics once I got some time, and file an issue at https://github.com/ektor5/udooneo-m4uploader/issues (if that's the right place). Edit: Done. https://github.com/ektor5/udooneo-m4uploader/issues/1
I'm running into the same issues and have even tried to debug the M4 via UART2 but have been completely unable to get anything out of the UART at 9600 or 15200 and at 3v and 5v. Incidentally the only way I was able to get my M4 to take any sketch again was to completely wipe the SD card and reload it. Doesn't make a lick of sense why though. Any thoughts or ideas?
I can empathize with all who are having problems with the Ardunio side. I don't think the UDOO team really thought how Ardunio could be ported to a heterogeneous architecture because it completely different (the M4 is so dependent on the A9) to a simpler mcu. Furthermore Ardunio makes many assumptions about the mcu architecture which don't apply to the M4, therefore these require workarounds which in some cases are crudely implemented and convoluted to use for a end users experience.
Newsflash! In the next Udoobuntu version the serial connection with Arduino will be updated. http://www.udoo.org/forum/index.php?posts/20205
Well the first update did not solve the /dev/ttyMCC reliability but last week some changes were made by the Udoo team that seems to improve things a lot.
