AppLab Does not start - Linux

Development Tools App Lab
1

I haven't purchased an UNO Q board yet but thought I would have a look at the App Lab IDE. I download from the software page on the arduino.cc website gave me version 0.2.0 in a tar.gz file. The file contains a single file called arduino-app-lab which I am assuming is an appimage executable file.

When I run the file, all it does is open an empty application window:

image
image819×664 6.36 KB

If I run it from a terminal window I get just a single console message:

$ ./arduino-app-lab
Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal

I thought it may take a while for something to happen so I left it for a while and went to make dinner and came back some 20 minutes later, but nothing had changed and still only the same one message in the terminal console.

UPDATE: I left it for a total of a couple of hours but still no change.

Does App Lab need a UNO Q plugged into the PC to start?

I am running on MX Linux 23.6 whch is a Debian based distro and xfce desktop.

IDE2 - Select Other Board
2

Just a quick update. I tried running AppLab 0.2.0 on my laptop which runs the same operating system. I got the same message in the terminal, but the app window actually showed me something:

image
image953×636 24.9 KB

At least this looks like the software is trying to do something, and this does answer the question: it DOES need an UNO Q to be connected before it will load the IDE. That is frustrating as it means one can't at least have a look at what's on offer in the app before buying a UNO Q.

Of course, this does not explain why it starts with a blank screen on the tower PC?

3

Hi @BitSeeker,

The App Lab requires an Uno Q to function: all the development tools, examples, and user projects are actually stored on the board itself. This is because the Uno Q can also be used in stand-alone/single board computer mode while connected to a display and keyboard/mouse combo via a USB-C hub.

4

Interesting thanks. I wasn't aware of that. Kind of a "buy before you try" philosophy then, that seems to have more in common with the Qualcomm than it does with the Arduino brand. How much can be stored on the board with just 2Gb RAM when the Linux footprint must be taking up the best part of that already? I would be interested to see a df -h output after the relevant updates have been made to make it work properly from someone who has one. I haven't seen any 4Gb boards available anywhere yet? I am still very much on the fence about buying one and this is not very encouraging.

Of course, if that's the case, then App Lab must have to download everything from the board to the PC, every time you connect? Isn't that going to take longer and longer the more projects you have stored on it?

This still doesn't explain why I am getting only a blank screen on my tower PC? I presumably should get the "NO DEVICE" message at least? There doesn't appear to be much in the way of messages in the terminal window or logs to go on either in order to be able to diagnose the problem. Was hoping it was a known issue with a known solution.

5

Hi @BitSeeker

This is the status of the storage and RAM on the board, with an example running and with all the necessary tools and resources for the App Lab installed. The board comes with an image already set up and may only need updates.

$ sudo df -h
Filesystem       Size  Used Avail Use% Mounted on
udev             845M     0  845M   0% /dev
tmpfs            175M  1.7M  173M   1% /run
/dev/mmcblk0p68  9.8G  6.7G  2.7G  72% /
tmpfs            871M   12K  871M   1% /dev/shm
efivarfs         128K  2.2K  126K   2% /sys/firmware/efi/efivars
tmpfs            5.0M     0  5.0M   0% /run/lock
tmpfs            871M   56K  871M   1% /tmp
tmpfs            1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
/dev/mmcblk0p69  3.6G  606M  2.9G  18% /home/arduino
/dev/mmcblk0p67  488M  113M  375M  24% /boot/efi
tmpfs            175M   48K  175M   1% /run/user/103
tmpfs            1.0M     0  1.0M   0% /run/credentials/getty@tty1.service
tmpfs            1.0M     0  1.0M   0% /run/credentials/serial-getty@ttyMSM0.service
tmpfs            175M   44K  175M   1% /run/user/1000
overlay          9.8G  6.7G  2.7G  72% /var/lib/docker/overlay2/69aa16302de9d074c8a0134289da3523850308d50eb9891406f043ba1dcddfc3/merged

$ sudo free -h
               total        used        free      shared  buff/cache   available
Mem:           1.7Gi       920Mi       145Mi        76Mi       839Mi       820Mi
Swap:          870Mi        45Mi       824Mi

No, the App Lab for Desktop uses the USB-C port or SSH to exchange relevant commands with the board.

It might depend on the udev rules configuration, as other users reported in other threads.

Enjoy!

6

Ah, Ok, so this has 9.8G allocated to the root partition and 3.6G allocated to /home/arduino, and a bit for EFI. In addition there is 2GB RAM (1.7G available it seems) for runtime RAM. Perhaps some of that is shared for video.

According to the specs the UNO comes with 16GB eMMC storage which I didn't realise but it has no SD card slot. That looks about right but its a shame about the SD card slot as I guess that precludes any means (at present at least) of upgrading the storage? Whether that might that be possible via those high density connectors on the bottom only time will tell.

I wonder what would happen if another user was created? Would it spilt/share the /home/arduino partition or simply create a user without a home directory...

I see also that there are already two user accounts present. One must be root and the other arduino.

Very interesting to see how the storage is allocated. Thank you.

Interesting also to note that is has ssh as that presumably means it could be run headless. Can it substitute for a Raspberry Pi? Not convinced of that just yet.

Regarding AppLab, I checked and added the recommended UDEV rule and rebooted:

SUBSYSTEM=="usb", ATTR{idVendor}=="2341", ATTR{idProduct}=="0078", MODE="0666", GROUP="plugdev"

This made no difference. Also ran it with sudo and getting exactly the same. No sure why it would work on one computer and not the other....

7

Sorry, not sure if you are talking about storage to the MCU or MPU...

MPU - you can plug in SD, memory sticks and the like into a USB HUB to get
extra storage... I have not tried that yet

MCU - You can connect up an SD Adapter to the SPI pins. Once they integrate
in an approved Pull Request

With this fix, @Merlin513 was able to get SDFat to run.
More information on the thread:

2 Likes
8

Yes, saw that thread about adding an SD Adapter to the MCU. I would expect SPI to work the same as it does on any other MCU. Shame about the performance.

It was adding storage to the MPU and the Linux installation that I was thinking of. Didn't really think about plugging a memory stick into a USB hub being a possibility, but yes if that works, then it would certainly be an option. I was hoping that maybe in time it would be possible to add NVME M.2 drives via those expansion ports on the bottom.

9

My UNO Q has finally arrived. I took it out of the box and connected it to the PC via a USB-A to USB-C cable. The power ON LED lit up and the matrix display showed the animated Arduino logo. After a few seconds this changed to a heart that shows 4 beats every second or two.

The no.2 LED is lit blue. The no.3 LED next to it is flashing once per second (amber I think).

I fired up App Lab 0.3.0 and its still displaying a blank application window exactly as in my OP, just with the updated version number. Running lsusb does show the following output:

Bus 003 Device 017: ID 2341:0078 Arduino SA Uno Q - uno-q

So the board has been identified correctly.

Why does App Lab not see it? Why is it still showing a blank app window?

This is all that I see when I start it from a terminal:

$ ./arduino-app-lab
Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal

Nothing more.

I do have the following udev rule installed:

$ cat 51-arduino-uno-q.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="2341", ATTR{idProduct}=="0078", MODE="0666", GROUP="plugdev"

My username is a member of the plugdev and dialout groups.

Anyone have any ideas as to why App Lab will still not start?

10

I just spent the last couple of hours setting this thing up in SBC mode. The good news is that the desktop appears and App Lab runs directly on the UNO. I have updated it to 0.3.0 and also updated the Linux system. I also ran the blink sketch successfully, although I was surprised how many files that downloaded.

It would be nice if I can get AppLab to run on my tower PC....

11

This gets stranger....

The tower PC is set up to tripple boot between two versions of Linux and Windows 10. I booted it into the Linux Mint partition. This has not been updated in a while. I downloaded and ran AppLab and it did exactly the same - showed a blank application window. I updated Mint and ran the AppLab again. Still no change.

So I am not asking myself, since this does not appear to be an OS specific issue, it is a hardware problem? The arduino.cc help page is not that specific. Apparently it just needs a PC, UNO Q and USB-C cable. This computer doesn't have a USB-C port so I am using a USB-A to USB-C cable and it is plugged into the high speed USB port, but could it be that the PC MUST have a USB-C port?

12

Does the fault also occur if you run Arduino App Lab on your Windows machine?

If by hardware, you mean the UNO Q, I don't think so.

It seems more likely it is a problem with the system environment or the Arduino App Lab software. The reason I say this is because if there was a hardware problem we would expect to see the "Waiting for a board to be connected" state as shown in the screenshot you shared in post #2. That is the state we would expect if the software was fine but there was a problem with the board hardware (e.g., a bad USB cable or socket) which prevented the ports of the board from being discovered by Arduino App Lab.

The blank window state is unexpected. This indicates that for some reason Arduino App Lab isn't getting to the state where it tries to discover the ports of the connected UNO Q board.

I'm going to ask you to provide some additional information that might help us to identify the problem.

:red_exclamation_mark: This procedure is not intended to solve the problem. The purpose is to gather more information.

Please do this:

  1. Start Arduino App Lab if it is not already running.
  2. Press the Ctrl+Shift+F12 keyboard shortcut (Command+Shift+F12 for macOS users).
    The "DevTools" window will open.
  3. Select the "Console" tab in the "DevTools" window.
  4. Right-click (Control-click for macOS users) on the main panel of the "DevTools" window.
    A context menu will open.
  5. Select "Clear console" from the menu.
    The existing content will be cleared from the console panel.
  6. Switch to the Arduino App Lab window.
  7. , just as you did before.
  8. Switch back to the "DevTools" window.
  9. Right-click (Control-click for macOS users) on the main panel of the "DevTools" window.
    A context menu will open.
  10. Select "Copy console" from the menu.
    This will copy the logs recorded in the console panel to the clipboard.
  11. Open a reply here on this forum topic by clicking the "Reply" button.
  12. Click the <CODE/> icon on the post composer toolbar.
    This will add the forum's code block markup (```) to your reply to make sure the error messages are correctly formatted.
    Code block icon on toolbar
    Code block icon on toolbar390×118 4.25 KB
  13. Press the Ctrl+V keyboard shortcut (Command+V for macOS users).
    This will paste the copied logs into the code block.
  14. Move the cursor outside of the code block markup before you add any additional text to your reply.
  15. Click the "Reply" button to publish the post.
1 Like
13

I was working on that while you posted. Booted into Windows. Downloaded and installed the Windows version of AppLab and then ran it. This is what I got:

applab
applab1010×762 22.8 KB

This is the sort of thing I was expecting to see in Linux. I THEN connected the UNO Q and a minute or two after it had started up i got:

applab-unoq
applab-unoq1009×761 18.9 KB

After a while it also added a network option. I clicked on the USB option and then got a warning about the board firmware being out of date. The Linux distro and AppLab on the UNO Q are already updated, so this must be another firmware specific step that needs to be done.

I didn't go any further with it just yet, but this shows that AppLab does apparently run properly in Windows 10 on this computer and therefore the PC hardware is capable of running AppLab. Windows is also able to correctly detect the UNO Q.

Given that it failed on both flavours of Linux and worked on Windows, that means it must be a problem with the Linux version.

I then switched back to Linux and read your post. I the followed your instructions and tried Ctrl-Shift-F12 to open the DevTools Window and this is what happened:

image
image1026×795 7.8 KB

I tried it a couple of times just to be sure. I also tried a "blind" copy and paste, but it picked up nothing unfortunately.

BTW, I checked and libwebkit2gtk-4.1-0 is already installed, but can't help thinking that this problem might be related to some other missing dependency.

14

I have found a workaround to run AppLab on Linux in the interim. It does require networking to be set up and the SSH server to be enabled on the UNO Q. SSH can be enabled by entering as per this document by entering the command below. This can be done either by connecting with adb or opening a terminal while in SBC mode and typing:

arduino-app-cli system network-mode enable

It takes a couple of minutes to run, but one completed, one can connect by typing in a Linux terminal on the PC:

ssh -X arduino@192.168.1.100

where the IP address is the actual address of the UNO Q. This can be determined by typing:

ip addr

in the adb shell or terminal on the UNO Q in SBC mode.

After opening an SSH session from the PC to to the UNO Q, all one needs to do is type:

app-lab

followed by Return at the command prompt. After a short while, AppLab will appear on the Linux PC. It is of course running on the UNO Q, so any downloads and saving of files will be performed on the UNO Q.

Its rather bit slow and a bit clunky, but it does seem to work, at least with the basic sketches that I tried.

I also found that I can then open a file manager Windows (Nautilus, Thunar etc on Linux) and type sftp://192.168.1.100, where the IP address is the IP of the UNO Q and view files on the UNO Q and copy them to the PC and vice versa.

Of course, ideally I would like AppLab running natively on the Linux computer, but I just wanted to mention that this seems to work in the meantime.

15

Thanks for taking the time to post an update with your findings!

Note that this is always the case with Arduino App Lab. The Arduino App Lab application itself runs on the host computer, but all components of the Apps you are developing using Arduino App Lab are stored in the filesystem of the UNO Q, and compiled by the microprocessor of the UNO Q.

So if you are seeing a performance difference when using Arduino App Lab via your workaround, as compared to when you are able to run it normally on your Windows machine, that difference is related to something other than the fact that downloads and saving of files are being performed on the UNO Q.

1 Like
16

Yes it is absolutely. Downloads and saving perform just as they would in SBC mode, but since AppLab is running on the UNO Q CPU rather than the faster PC one, and its display data has to be transferred via the SSH network connection to the PC for display on the PC screen, that is bound to impact performance. However, its not too bad all things considering, although one does have to have a bit of patience. It should be borne in mind that I have not tried any complex sketches or using bricks just yet.

17

I think I have a possible idea what might be going on here.

Given the type of artefacts I was seeing here, I have been looking at the graphics drivers. There seemed to be not a lot in common between MX Linux and Linux Mint. Both versions of Linux are using X11 rather than Wayland, but while MX Linux is using the Nouveau driver, Linux Mint runs a native Nvidia driver. As it hadn't been updated in a while, I upgraded Mint to the latest version (2.2 Zara), but that made no difference. On checking, I noted that the Nvidia driver had not been updated and an upgrade did not seem to be possible. I checked on the Nvidia compatibility site and found that 470 was the latest version I could use, but there were several later versions available.

I then downloaded and booted the latest version of MX Linux (25) from a USB stick. That also uses X11 and Nouveau, but later versions of various libraries. No change.

At this point I had the idea that maybe the problem is the graphics card hardware. The card is a now fairly old Quadro K4200 and having suich an older model perhaps explains why Nvidia recommends an older version of the driver package. Perhaps support for this card is no longer available in the latest versions?

To determine whether the problem is the hardware, my next step was to test in a virtual machine, because here, graphics support is provided indirectly via an emulation layer. I created and installed an MX Linux 25 virtual machine and after the installation was complete, tried running AppLab. Well, it started up normally. This meant that regardless of whether it is accessed via the open source Nouveau driver or the native Nvidia driver, the problem appears to be the graphics card. The only snag when running in the virtual machine is that although AppLab detects the UNO Q, it is unable to connect to it so it would seem that this is not a viable way of working with it.

It looks like I am going to have to upgrade the graphics card. I saw a GTX1050 on the used market in a shop yesterday. It was affordable and hopefully should fit into the case. It can also make use of the latest Nvidia driver (v580). Its a shame because I was given a GFX1060 a while back, but it had a bit of pipework sticking out of it that prevented it from fitting into the case, so I ended giving it to a mate.

What was curious of course, was that AppLab ran perfectly fine in Windows 10, so I booted into the Window 10 partition and checked what driver it was using. Turns out it was using the "Microsoft Basic Display Driver". It wasn't using an Nvidia driver at all. Not surprising, since I don't really use Windows anyway.

18

Well well well.

While we were out earlier I picked up a GTX1660 graphics card. This is somewhat newer than the GTX1050 that I was originally considering. When I got home I swapped the cards and booted into Linux Mint. The first task was to upgrade the Nvidia driver from 470 to 580 which had to be done manually:

apt install nvidia-driver-580-open

After the installation was complete, the PC was re-booted to load the new driver. This was the moment of truth - I fired up AppLab and finally it worked.

I then booted into MX Linux. I didn't have to do anything there. The Nouveau driver just recognised the new card automatically. I fired up AppLab and it started up normally. I then connected the UNO Q which was detected. AppLab then alerted me to the fact that version 0.3.2 was now available so I accepted the updates and am now running that version. I can finally run Arduino AppLab on my Linux PC!

Let me just mention here that I had already been considering an upgrade of the graphics card for some time anyway and already had the funds available to buy one. This problem, after having excluded all other possibilities and being sufficiently convinced of an otherwise unresolvable driver/hardware issue following some considerable troubleshooting, simply expedited matters. However, had that not been the case, it is unlikely that I would have gone out and purchased one just to satisfy AppLab. I am not therefore, by any means suggesting that anyone with this (or similar) issue can or should fix it by upgrading their graphics card. As always, methodical troubleshooting should be carried out first to determine the likely cause.

Curiously, this is the first time that I have experienced this kind of problem with any application, except perhaps with Safari on my old iPad, but said iPad is much older than this Quadro card. Whether this AppLab problem is the result of an issue with the card hardware itself or the older version 470 Nvidia driver, I don't know, but probably the latter. Might it have been possible to fix this in the driver software? Possibly. One would first have to understand what the problem actually is, which might take hours analysing. There is also the fact, that support for this card was no longer available in later drivers, so this probably would have been a futile effort anyway.

However, it is noteworthy that apparently Arduino AppLab is using some graphics feature that either the card hardware or the driver were incapable of delivering and therefore requires a more modern graphics card than the Quatro K4200 that was originally installed in this PC. The inevitable conclusion that one has to arrive at is that evidently, AppLab may not run on a PC running a Linux operating system and that has an older graphics card. It may run on Windows using the Microsoft Basic driver, but obviously with the reduced capability of that driver.

1 Like