Constructive criticism

Official Hardware UNO Family UNO Q
1

Continuing the discussion from Are there any Uno Q in North America?:

Yes, unfortunately I have one of these Q units. I had a horrible experience buying it (pre-order) direct from Arduino store. If you buy it from Digikey or like vendor you may have a MUCH MUCH better experience in USA/NA.

I have many things that I don’t like about the experience, its very reminiscent of 10 years ago with UDOO. The shopping experience was poor, the first setup was poor, and the ALPHA level code lasted many years, I hope that’s not true here.

I have watched others wrestle with the flashing of the code and the very confusing language, not sure if that’s qualcomm or somebody else responsible, so I feel better that its not just me:

1.) I understand how factory fresh code sometimes needs a fix, but the setup of having to go dig up a jumper on a $50 USD board, a very low cost part, was super annoying. By the time you figure out how to flash it, I found it exhausting.

2.) most of the examples assume you bought a bunch of other arduino boards to use with examples, not quite as mature as one would hope given the premium pricing

3.) the whole app lab experience has many pitfalls, very confusing language of what is being updated/upgraded, false starts with incomplete details of what precisely is being done.

4.) simple issues like blink are very difficult, to get my head around, I am not a javascript programmer, so I cannot tell if the bridge and javascript are necessary to see simple serial output.

5.) I even tried using gemini AI to work some examples and it found the documentation very hard to decipher, until you break out the schematics for the RGB LED business. The AI got itself all tied in knots about which RGB LED is controlled by what paths, it would tell me that the MPU controlled it, but that did not align with the behavior of debian not being fully booted. it was 4x more difficult than it needed to be. The applab was a big disappointment.

6.) I am huge fan of the concept, but my first foray has to stick to QWIC connectors for sensors as that does not have the 1.8Vdc MPU risk.

7.) No roadmap for use of the high speed busses on the back feels like this maybe a very long time coming to product maturity. But that’s the fun of a bleeding edge product right?

8.) I am also keen to discover any method to drill the resource loads. adding debian packages seems risky, but htop seems to be as good as it gets, unless my “debian appliance” be safe mode is overly cautious.

9.) and for goodness sake, test the applab with dark mode. Many/most dialogs are unreadable due to color issues.

All remarks meant as constructive criticism, not meant to be insulting.

2

Agree, app lab is very rudimentary for now. But I found a solution for me at least. After initial setup and wifi working I switch to Visual Studio Code with Remote SSH extension. Apps are then managed from shell by "arduino-app-cli" command.

3

I took the approach of working through examples in the user manual first. The simplest examples there work through arduino sketches and essentially use only the default Python code. No Javascript.
Only after that did I start looking at examples that make use of both modified Python code controlling the Arduino sketch. With simple examples one can get an idea of how the bridge between Python (MPU) and Arduino sketch (MCU) is used.
The Javascript is used in applications that also use a web interface. On the examples that have a web interface the javascript is actually run from within the browser on what ever machine is accessing the web interface. If you are having any trouble getting your head around how other things work on the UNO Q I suggest one might want to delay getting into examples that also have the web interface. Well that is what I am doing for the most part because this is one more level of complexity. It is interesting but it will likely be easier to tackle once one has mastered what is going on between the MPU and MCU without also bringing a web browser into it.

4

I suggest that one view googles AI with a lot of suspicion when it comes to the UNO Q. I do not think the AI is good at making distinctions between different Ardinuo UNO boards. I expect the examples and documentation from Arduino will improve with time. Bugs in AppLab are being fixed. These forums have lots of questions and answers. Over time it should become more clear to Arduino what documentation needs to be added and which parts need to be clarified.

5

I agree it is a good idea to start out with the QWIC connector and the standard UNO connectors on top of the board. The connectors under the board should likely be left alone until more information is made available. I fully expect that eventually some useful plug in boards will become available for various types of expansion. Time will tell.

6

I expect boards will become available to add micoSD expansion and who knows what else. If they can develop these things in phases then they can start to recoup some costs of initial development before they sink more money into development. As a guess it would seem the obvious stuff to add would be sensors and displays that already exist at reasonably low cost because of the needs of the cell phone industry. I imagine one can already use many existing shields for things that do not require the higher speed.

7

cool alternative feedback(s),I appreciate the sharing. One issue I am struggling to find documentation, is serial comms. I have worked with uControllers from many vendors. I am so sick of super heavy resource hog IDE’s unless I have no choice, and I want a cli streamlined workflow, I often have 3 panes up, where one pane is vi/makefile tool, another pane is a monitor tool and the 3 maybe btop/htop/debugger etc. I use arduino-cli and makefiles so I can do the same work

q-serial-pic.txt (963 Bytes)

q-serial-pic2.txt (371 Bytes)

flow whether it be an ESP Arduino/PlatformIO/ESP-IDF variant, Arduino from Uno to Portenta, and others. I am also a very experienced unix person. In my efforts to achieve this workflow on “Q” I am very frustrated, largely due to expected serial port definitions that I have been unable to find thus far. The total beginner instructions for ssh/adb/how to power a usb hub, that is there, and that’s great. I am familiar with how the portenta uses RPC bridging to connect MCU←→MPU. I understand all this. but a combo sketch with helloworld/blink is failing to produce the results as I expect them. I use serial.begin/println and expect to see that output on a particular port (unclear which one) I use serial1.println (and again where), I see there is 3.3v/5Vdc tolerant legacy arduino pins, ok gotta find that ftdi connector. I see and understand that If i want to see MPU output I gotta get a 1.8vdc TTL to usb dongle (ok i’ll buy one eventually) and those pins are on the header NICE, no idea how they instantiate on the CPU host is it /dev/ttyHS2 and with no device connected it’s not instantiated is my guess. Fine skipping that one, I see /dev/ttyHS1 and that seems to work with my monitor script by a complex set of ssh/stty/tio and/or TERM defs that allow me to do that from my host. I see /dev/ttyMSM0 and /dev/ttyGS0 perhaps one of those is the target. I poke in the simplest code that uses the monitor object, ok now I gotta go write a python script to use the monitor app. Is this where I need to use arduino-app-cli, or do I have to have a python script then forward the messages from my code out the USB gadget interface (GS0). a simple diagram or some example code that does this next level of complexity has eluded my attempts to search the site for shreds of evidence. Since I have the current Q with just 2gigabooties of ram, I abandoned trying to solve these riddles in SBC mode, i just have the Q hooked directly to my dev host. I know its early in dev cycle, but I find it statistically improbable that I am the first to hit this “friction”. I am willing to share my sketch, makefiles, all the CLI wezterm multiplexing, and even special ssh configs if that would help someone else, I can sanitize them and would be willing to share. I am not doing anything except blinking and putting out some “old-school debugging” text. I have not yet attempted to use openocd or complex debugging yet. It is just simple println stuff. Apologies if I left out some bits. attached are some crude ascii art versions of me trying to document what I think is going on. There is something fundamental I am missing, i just don’t know where to get the data, so in parallel with trying to reverse engineer it, I share the friction in hopes of a.) finding an answer in parallel and b.) perhaps help create some documentation/example/inspiration for my “simple” test run of the platform :):scream:

I just noticed there are some examples in the legacy IDE, maybe I try some of those and be able to get a clue, (thanks dano if that’s where you meant) I had not noticed those before, i just saw the applab examples prior. In my head, the pre-sales stuff made me kinda think the Q architecture as similar to that of the Firmata way of doing things, but on steroids with the cellphone side(MPU) driving the display and become more standalone (like the classic ultrasonic radar with Processing) . I have used LattePandas, Udoos and other combo SBC/uControllers before. I think I am simply stuck on syntax and labeling/picturing the components clearly. TTFN

8

Yeah, I just don’t have many shields around ATM. Nor do I have any 1.8V level translators, or a 1.8v TTL serial cable. So I just gotta head to my storage locker and dig up some grove/qwiic/stemma pigtails before I can try sensors, so my experimentation is kinda limited to streamlining my workflow for a bit.

9

Thanks for the ideas. I try and use arduino-cli and makefiles as much as possible, but I really find the vscode way of doing things painful on my hands, the cmd palette hates me. LOL. I really liked it when vscode allowed you to decouple the terminal and have multiple instances, but I have since graduated to using terminal apps with varying degrees of success. For the Q I have been using wezterm with its multiplexing, but wezterm is no kitty when it comes to theming. I see promise, but the homebrew binary for wezterm is quite old, and the nightly has most of same problems. I switch dev platforms about every 2 years to stay current, my previous hop was win10 and there vscode was pretty ok, but with WSL2 vscode and ssh extensions were a lot better than many other tools, the whole wayland thing kinda made a real mess of it. If you are into masochism, try vscode on a raspberry pi 2. Wahoo that now that’s an experience . Ciao