[POLL] UDOO NEO's Arduino - your feedback about it

Hi folks,
recently we've done some updates to UDOO NEO's Arduino, as you may have noticed. We also released UDOObuntu 2 for UDOO NEO with the updated Arduino Board Manager included.
At this point we'd like to gather your general feedback on UDOO NEO's Arduino to make a point.

 

Come on guys, fill in this poll!
@Andrea Rovai Perhaps an idea to add a [poll] prefix to the title.

 

Good idea @waltervl! I've just added a [POLL] prefix to the title. And thanks for upping the post!

 

Only 6 votes now....... :-(

 

I won't be able to vote as I'm not even able to use the main CPU correctly with the Linux kernel.

 

Meaning? Please specify the problem, so we can help you. Better if you open a new thread about this problem, so not to go OT

 

I've already specified the problem here and it appears also here.

 

You mean with your custom Linux kernel, not with our Linux kernel, do you?
Your links redirect to:

1. Boot on a custom Linux ---> as said before, we can only support UDOObuntu and Android as OS.
2. UDOObuntu Minimal ---> as said before, we are not going to write the documentation for UDOObuntu Minimal too.

 

I try to use your official Linux kernel. The only custom part is the rootfs (user space) and it works perfectly (built with Buildroot).

UDOObuntu is useless for IoT and embedded applications, this is way to heavy. I don't want to use my card PC like any desktop PC, that's silly. UDOObuntu Minimal could be a good alternative if it fully support the hardware, which is not the case.

The best solution to build exactly what I need is to build your kernel that should fully support the hardware and put a custom rootfs on it like I did with the previous kernel. That worked fine but that one is too old to support Device Tree.

 

@cyrilf this has nothing to do with Arduino part but what about yocto? http://www.udoo.org/forum/threads/openembedded-yocto-on-udoo-boards.2965/

 

Thanks @waltervl. I'm seriously thinking of using Yocto as it now supports Qt5 better than Buildoot.

 

The low number of people participating in this Forum Thread and pool should send a message...

 

Some positive feedback first: The possibility to cross-compile for M4 on a decent computer and to upload and debug from there (FOTA) is definitely a step in the right direction.
Besides that maybe some constructive feedback/criticism: A Microcontroller / microprocessor combination makes sense, if time sensitive tasks (quad encoders, motor/servo control, sensor sampling) can be offloaded to the microcontroller and the microprocessor does more high-level stuff. Note that for the former not speed is decisive, but controllable jitter and/or predictive response to input. If the later is not possible on the Neo, a good part of the rationale for a M4/A9 combo falls essentially flat, and you're probably better off with a four-core Raspberry and do everything on the microprocessor cores. So consequently the first thing I intuitively expected to appear was a port of one of the timer interrupt libraries and then maybe a servo and a encoder lib and some general interrupt examples? However, existing code in this direction is still somewhat alarmingly thin, which is for many projects I had anticipated to do on Neo essentially a deal-breaker. The second issue I have is with respect to the work-flow for the M4 on Neo: My first attempt to do something useful with the Neo (roughly nine months ago) failed miserably because A9<-->M4 serial debugging was frustratingly quirky, and furthermore compiling on the Neo was waaay too slow for anything else then 10-lines of code. Well, after this initial encounter the two Neos where left for months in the drawer, and only the recent possibility to cross-compiling motivated me to have a second look at this. Rather quickly it became apparent, that the issues with the serial port A9/M4 have remained really tiresome. Half of the time I do not know if my code is buggy, or if the debugging code hangs the M4 up. And that means normally: "Reboot the Neo time" and that gets old very very quickly. So I started debugging the M4 instead over Serial0 (seems way more robust), but for my little project I wanted to control dynamixel servos with the M4 of the Neo and thus need Serial0 for this. So it is back to debug/log over the M4/A9 serial, which makes porting the dynamixel libs really frustratingly tedious. I had this up and running after one day on an Arduino Due, but on the Neo... I looked into serial debugging of the M4 over UART2 but it seems that this requires switching to MQX entirely (?), at least I couldn't dig up any useful info on how to do that. Anyway, long story short: Each time I pull the Neo out of the drawer to actually do something fun with it, I rather quickly stumble into one or the other frustrating issue, which renders simple things into a major undertaking.

 

That was a good post. I feel the same way. I come back here every few weeks to see if the Arduino Libraries and the current advertised capabilities are reliable.

Here is one idea for the Udoo Team. Would you consider a KickStart campaign to improve the software / BSP for your boards starting with Neo then x86? That way you may be able to hire some software engineers with enough time to get NEO more useful. I wonder how many people are buying it after reading the feedback from us like the ones here. Getting us happy ultimately will help you sell more.

Don't take me wrong, I would like to help you help me. I would put another US$20 to help if I knew it was dedicated to support software/BSP; if we have a list of priorities, a timeline, and a commitment to periodically status to complete them.

My feeling is that the Udoo Team always move the next cool hardware leaving the previous versions without totally functional software. Then People move on to platforms that have a better ecosystem to support the boards. IMO, people rather spent time working on their projects vs, making the Udoo products work.

Thanks,
-Jack

 

I wonder if the 2 people that voted in this option can explain their rational

> UDOO NEO's Arduino is surprising, I'm more than satisfied

And the 6 that voted here

> UDOO NEO 's Arduino is good, I am satisfied.

How are you using the NEO? Just to learn Linux? Is it working in a project?

Thanks,
-Jack

 

I bought the Neo to learn Linux and to play around with Arduino. I had some experience with Arduino Uno but as a mechanical engineer I have ample programming skills.
I see that Udoo team took a deep dive into the NXP/Freescale experiment of combining an A9/M4 processor. NXP has a propriety RTOS named MQX that should make a Arduino from the M4. So a lot is experimental. Issues could be a problem in the board package, could be a bug or undocumented feature of MQX. We all are still learning here.

I hope Udoo team will keep on supporting the Neo (no sign of them not doing it) and keep improving the Arduino part of the Neo. The Linux part is less relevant because knowledge is out there in the community. See for example OpenEmbedded/Yocto.
The problem is a stable Arduino part.

I already made a topic with known issues and not really a lot has improved. Learning more from the architecture it has to with timers and interrupts. They differ from the normal Arduino Atmel architecture. And even more due to the A9/M4 connection.

But in order to improve the quality of the Arduino libraries we can help the Udoo team by submitting proper documented issues. From the Udoo team we need to have the commitment. Where are those libraries you promised us a long time ago? Why are the issues we submitted not yet solved?

Why put a lot of effort in Android when the Neo can only handle 1 app? Or solve that issue (display driver?) too. Only support Linux and you have more time to support Arduino.
Edit: topic to known Arduino issues:http://www.udoo.org/forum/index.php?posts/20029

 

Nice!

I agree that if the Udoo Team would focus, they may have a better chance to get the open items closed.
I still love the idea of the Neo Board, just if the software would come along.

I hope the Udoo Team sees these kinds of comments as trying to help. We could just move on and not look back. Lots of options popping-up out there. But, we are here. Some of us more than others. I would imagine that if we see the Udoo Team more engaged and committed to NEO, people would stick around.

I am assuming a software resources to work on NEO would go a long way ...

-Jack

 

The original Udoo (i have two quads) had for it's time serious power on the application processor side and a mature microcontroller. Although it was held back somewhat by the Linux part, and is borderline somewhat too big and too heavy for embedded/mobile/robotic/UAV apps, it was and is a seriously interesting concept. However, somewhat heavy, large and power hungry.
For me the NEO was intended as a "lightweight" complement for faffing around with robotics. To be used for projects, when the footprint of udoo quad is just one size too large and that are more geared towards hardware control, than towards the domain of GP-application processors.
Compared to competing platforms in that power/weight/size envelope my hopes for the NEO was that it opens some more possibilities than Arduino Yun (and meanwhile Tian) on the microprocessor side (which lack a bit grunt for camera work) and adds microcontroller features that for example Raspberry Pi, Beagle & others do not have. However, the differentiator to these platfoms for Neo are really IMHO the (at this point in time still potential) microcontroller features.
What the A9 side is concerned, indeed, the open source community can make up for a lot of lack of support. I also salute the UDOO team to have acknowleged that the interest of the community of running a full fledged OS on a single core is somewhat lackluster and provides meanwhile a headless build. So the A9 side is IMHO slowly mature enough to carry on by itself. )In addition: Folk that wants to do more application heavy stuff moved on to the more mature RP3 anyway.)
However, this looks substantially different on the M4 side: Apparently NXP does not allow you to release the modified source code of the MQX libs for the Neo. So what the M4 is concerned, the magic words "the open source community ..." will at the end of the day not do the trick. Either the M4 libraries come from Udoo team, or that part of platform has to considered an interesting experiment, which is in stage one of being abandoned.
Which would leave us with a 1GHz single core microprocessor only. And that gentlemen, is IMHO in this date and time not worthwhile sustaining an entire ecosystem for.

 

For me the Neo sparked my interest in the Arduino eco system. I also have a Quad, but I do not use the Arduino part on that; it is running a display to control my home. [thanks @graugans]

The Neo's box states 'OpenSource Arduino Uno compatible SBC', but I soon found out it wasn't really. It already started with simple things like pin 10 & 11 being swapped in the Arduino environment, and me not being able to easily connect a 4x7 display. For the latter UDOO has released a new library, but I'm a bit afraid to connect components that are more complex than buttons and leds. I don't want to spend my time debugging stuff I do not understand nor have my interest.

Eventually I purchased a Arduino Mega, which I use first to find out how the component works, and then I might try it on the Neo.

Another thing that could be improved is the documentation. I can see that the UDOO team has really tried to provide good documentation, but that doesn't mean I understand it. It kind of seems to assume that I already are familiar with all Linux, Arduino and M4 concepts, which I am not.

For me it is exactly the other way around, I have lots of programming experience, it flows through my veins as a manner of speaking, but hardware....

[ADDED]
A combination of a full Linux and an Arduino is great though. I use the Arduino for what it is good at: reading and writing 'hardware', and the Linux part in combination with Java to create complex logic with that.

 

@Maurice for sure there's much room for improvement in the documentation, but could you please some more hints on how to refine and what to specify in order to get a better comprehension?
For what concerns Arduino-compatibility, we're aware that many libraries aren't ported for UDOO Neo, and we're doing our best to give support and extend the Arduino capabilities.