Add Linux Support?

[kd8bxp]

Subject of the issue

My Apollo3 board is suppose to arrive in the mail today, so I decided to go ahead and setup the Arduino IDE.
I followed the manual install for core.
no examples show in the example list - but there is a space for "examples for Ambiq Apollo3 Evaluation board".
I manually browsed to the ~/Arduino/hardward/SparkFun/apollo3/libraries directory, and selected the example0_compilation, and the example1_compilation
The Ambiq Apollo3 Evaluation Board from my board choices.
when I click on the verify button, I get a Error compiling for board Ambiq Apollo3 Evaluation Board

In file included from sketch/example0_compilation.ino.cpp:1:0: /home/lfmiller/Arduino/hardware/SparkFun/apollo3/cores/arduino/ard_sup/Arduino.h:42:10: fatal error: am_bsp.h: No such file or directory #include "am_bsp.h" ^~~~~~~~~~ compilation terminated. exit status 1 Error compiling for board Ambiq Apollo3 Evaluation Board.

If I switch to any of the other boards in the package "SparkFun Edge" for example and click on the verify button I get this error.

Build options changed, rebuilding all fork/exec /home/lfmiller/Arduino/hardware/SparkFun/apollo3/tools/apollo3_scripts/artemis_bin_to_blob.exe: exec format error Error compiling for board SparkFun Edge.

.exe file is clearly a Windows thing - leading me to believe that Linux isn't supported yet - but when I goto the above directory, I see python scripts.
So I changed the permissions of the scripts, and the exec files to allow for executing.
And get the same error. Which lead me to believe (???)
Did I miss a step in setup somewhere or is Linux not supported yet.

Your workbench

• What platform are you using? Linux Mint 19.1 64 bit, Arduino IDE 1.8.9
• What version of the device are you using? Is there a firmware version? N/A
• How is the device wired to your platform? N/A
• How is everything being powered? N/A
• Are there any additional details that may help us help you?

Steps to reproduce

Tell us how to reproduce this issue. Please post stripped down example code demonstrating your issue to a gist.

Expected behaviour

Tell us what should happen

Actual behaviour

Tell us what happens instead

[oclyke]

Hi @kd8bxp, thanks for the issue!

This is good stuff for us to know - so far we've been only developing the core on Windows. In Windows we cannot be positive that users will have Python3 installed (which we would use to perform actions that are described below), and if they do we probably won't be able to guess where to find it. To get us started as quickly as possible we avoided dealing with a board manager package like the Arduino SAMD core uses, which might allow us to direct installation of additional software. So as a stop-gap solution we have simply converted the Python3 scripts that we use into executable (.exe) files that Arduino can call from the command line.

So you are right, at the moment Linux is not fully supported. However we want to change that!

It sounds like you are able to compile your example into a binary file - is that right? Or perhaps the check that failed occurs before compilation... If that is the case then I'm just assuming that you'll be able to compile since we've had Linux users successfully using the Ambiq SDK and because Arduino supports Linux with the SAMD core.

If that's all true then that means that the main problem on Linux is that we are not running the necessary post-compilation code that performs these steps:

1. converts the binary into an over-the-air update blob
2. converts the ota blob into a wired update blob
3. uploads the wired blob via a USB-serial bridge

What needs to happen is for Arduino to switch its behavior depending on the operating system that it is running on. This kind of feature is described in the Arduino 1.5 3rd Party Hardware Specification.

{runtime.os} - the running OS ("linux", "windows", "macosx") is a variable that we can access within the platform.txt file to determine the current operating system. Similarly we can automatically provide "variants" of the tool definitions that respond to the operating system in use. For example (from SAMD core):

tools.bossac.cmd=bossac
tools.bossac.cmd.windows=bossac.exe

So we should definitely re-write the tools section of platform.txt to be OS-dependent. I'll take a stab at this very soon. After that we have a decision to make about how to support Mac/Linux

1. require the user set a variable that points to the Python3 binary, keeping the core installation manual for now and applicable to anyone
2. require the user to install/move Python3 into a pre-determined location. Cons: just as much work as providing your own path to Python, but can result in duplicates of Python3 and other hairiness
3. Go whole-hog right now and try to develop the board package installation automation.

@kd8bxp Do you have a preference for which option to take in the near-term? I'd lean toward the first, with plans to ultimately pursue option 3.

If you are curious and want to take a shot at any of these methods yourself that would be awesome as well, and we'd welcome the pull request.

[kd8bxp]

@oclyke Thank you for the update, and all the information -

So is the SDK required for use? I didn't install it.
And I do get a compile error when using the Ambiq Apollo3 Evaluation Board
In file included from sketch/example0_compilation.ino.cpp:1:0: /home/lfmiller/Arduino/hardware/SparkFun/apollo3/cores/arduino/ard_sup/Arduino.h:42:10: fatal error: am_bsp.h: No such file or directory #include "am_bsp.h" ^~~~~~~~~~ compilation terminated. exit status 1 Error compiling for board Ambiq Apollo3 Evaluation Board.

The other boards in the package appear to at least compile, but give the error with the exe file.

I think at least in my case python and python3 are both already in the path when I installed them.
(I believe they are both in /usr/bin/) I don't have a problem with option 1, and ultimately moving to option 3.
Option 2 seems like it might end up causing problems in the long term.
Option 1 seems like a good short term plan.

As far as me trying to make a board core work that would be a yikes! While I'm pretty good with making sketches, how the board cores work is still a little (or a lot) outside my range.

I know, and understand the Apollo3 board and this project are new, and I'm good at waiting - I just wasn't sure if I had installed the core wrong, or if I missed something, or if Linux was just not supported.

I'm quite happy at helping with error checking and other issues that might come about.
I know this is a lot of work, and I thank you and the Sparkfun team for working on this, and look forward to when it will work on a Linux box - mean while I'll use a Windows box - yikes! (did I just say that).....

[oclyke]

@kd8bxp As far as your compile error goes you should just pull the latest from this repository. We recently trimmed up our variants a little bit and no longer plan on including an Apollo3 Evaluation Board variant (at least until someone needs it... are you using and Edge or an AP3 EVB?) so chances are good that that variant is just malformed. In case you don't already I highly recommend using GitHub Desktop so that you can use the Open in Desktop button on repos. This makes it extra easy to stay current on repos, which is particularly useful when you're on the bleeding edge of development. (Read: lots of changes in this repo, good to stay in-sync with the latest and greatest :) )

I just got out my laptop (Mac) and I will start testing out option 1. I could definitely use your help to test it out on Linux. I'll give you a shout out when I have something to test. Thanks!

[oclyke]

With commit a5f3e21 you should have access to a proper upload script that works on Mac and Linux. Since this is option 1 that we discussed above you may need to modify the path to Python3 on your machine.

Do this in 'platform.txt'
for me it is tools.ap3Loader.pgm=/usr/local/bin/python3
but for user X it might be tools.ap3Loader.pgm=~/stuff/python3

Anyone reading along for a unix-like OS could try which python3 (or related commands) to get the needed path

Although the script runs, and on my Windows computer the upload is successful, it was unsuccessful on my Mac. I think this is related to these problems:
SparkFun Edge failing on "make bootload" - SFE Forums
SparkFun Edge bootloader problems - StackOverflow

@kd8bxp Can you try this out and let me know how it goes?

[oclyke]

@kd8bxp Have you gotten a chance to try again with the v1.0.0 release in the Arduino boards manager?

If you don't already have it add this link (below) to your Arduino preferences 'additional boards manager URLs:' field
https://raw.githubusercontent.com/sparkfun/Arduino_Boards/master/IDE_Board_Manager/package_sparkfun_index.json

Then open the board manager and search for Apollo3.

[oclyke]

Here's some more data from TomWS on the SparkFun website (tutorial discussion page: https://learn.sparkfun.com/tutorials/artemis-development-with-arduino/discuss#comment-5d0d8b2e6f716d282877fc23 )

Yeah, thanks for the steps. Unfortunately the steps didn't work on my Ubuntu 16.04, Arduino IDE 1.8.5 configuration. After purging anything related to Sparkfun (in IDE preferences), restarting with a fresh copy of the above referenced JSON file, and selecting the Apollo3 install, I finally got to the message (paraphrasing) "Sorry, we don't have the tool chain for your installation"

Actually, the error message is: "Tool arm-none-eabi-gcc is not available for your operating system." Which is really curious since I've been using this tool chain for all my nrf52832 development.

UPDATE: I discovered one problem is that I had another Sparkfun entry in the preferences file, https://raw.githubusercontent.com/sparkfun/Arduino_Boards/nrf5/IDE_Board_Manager/package_sparkfun_index.json and this was overwriting the update with the Apollo3 boards (I didn't noticed that the target file had the same name). Also, I was able to install the tool chain on my Windows7 system, so it must be unique to Ubuntu (maybe a version issue?)

Second and final UPDATE: I spoke too soon about the installation, as soon as I selected the Artemis ATP board I got a slew of error messages: "Invalid library found in C:\Users*****\AppData\Local\Arduino15\packages\SparkFun\hardware\apollo3\1.0.0\libraries\CoreTesting: no headers files (.h) found in C:\Users*******\AppData\Local\Arduino15\packages\SparkFun\hardware\apollo3\1.0.0\libraries\CoreTesting" Then, when I built the basic Blink example (none of the Artemis specific examples show up) I got a bunch of errors related to files not found (this is most likely due to the fact that my user name has a space in it - I've seen this before with other build scripts).

[oclyke]

My response from the same page:

Hi TomWS,

The errors about the invalid library are expected for now and should have no impact on performance.

The toolchain problem is good to hear about - thanks. With the Apollo3 core we are trying to transition from the 2014 arm-none-eabi-gcc tools (which are used in many Arduino cores such as SAMD21 and perhaps NRF) to the 2018 tools. I think there are a couple possible snagging points:

1. Perhaps there is a path name conflict between the two versions of the tools since they both go under directories called 'arm-none-eabi-gcc' at some point. However the 2018 tools installed by SparkFun's package should be under 'packages/SparkFun' instead of 'packages/arduino'
2. In the JSON file we've provided these tools for the host types "i386-apple-darwin11," "i686-linux-gnu," and "i686-mingw32." If Arduino detects your host type as something other than these options I would expect to see an error along the lines of what you presented ("Sorry, we don't have the tool chain for your installation"). We could add copies of the tools with different host names - but we would need verification that they work.
3. The JSON link you were using is based on the 'nrf5' branch of the Arduino_Boards repo, which I don't think is maintained... Or at least I am not sure right now what it is used for. (I.e. can you get both BRF5 and Apollo3 packages from the master branch of the repo?)
4. Can you provide more specifics about which files aren't found when you build 'Blink?'

Let's move this discussion to GitHub. #4

[Merlin04]

I'm getting this "tool is not available for your os" error too. It won't let me install the board into the IDE, and it's preventing me from using my Artemis Nano board. I'm using the latest version of Arduino IDE (1.8.9) on the latest version of Ubuntu with the latest boards package (1.0.1).

[oclyke]

I've just updated the boards manager JSON file in an attempt to fix this. See this commit from the SparkFun Arduino Boards repository.

I added two new host definitions for the "arm-none-eabi-gcc" tool for x86 architectures.

There may yet be more host definitions needed to get full coverage, and it also might be required to actually use binaries specific to those hosts. But let's give this a try as a band-aid solution. Now that the JSON file is updated you should be able to re-try the installation through Arduino boards manager.

Please let me know how it goes, good or bad. Thanks!

[Merlin04]

That allowed me to successfully install and compile a program. In order to get uploading to work, I had to move .arduino15/packages/SparkFun/hardware/apollo3/1.0.1/tools/artemis/linux/artemis_svl/artemis_svl to .arduino15/packages/SparkFun/hardware/apollo3/1.0.1/tools/artemis/linux/artemis_svl/artemis_svl_noroot and create a new file, artemis_svl, with the contents:

#!/usr/bin/fish

pkexec ~/.arduino15/packages/SparkFun/hardware/apollo3/1.0.1/tools/artemis/linux/artemis_svl/artemis_svl_noroot $argv

Otherwise it would say that it couldn't run artemis_svl because "permission denied". Oddly enough, it also did this when Arduino IDE was run with sudo.

But, I've run into a new problem, which I don't think is related to Linux support (but it could be). When I try to upload the code, I see this:

Sketch uses 7352 bytes (0%) of program storage space. Maximum is 960000 bytes.
[At this time the pkexec window opens, I type in my password and press enter]
Connecting over serial port /dev/ttyUSB0...
Unknown BL response

[Merlin04]

Never mind, turns out that I just had to reduce the baud rate down to 460800.

[nseidle]

@Merlin04 - That's really good info to know. We designed the variable rate bootloader just for this situation. Some OSs combined with the CH340x drivers have a variety of max baud rates of adequate baud accuracy. Thanks for letting us know!

[oclyke]

@Merlin04 Thanks for the notes! I just made a patch to the core (v1.0.2) that is intended to make the bootloader tools work out of the box. Can you do a fresh install of the core and try them out? I'd appreciate the results from out 'in the wild.'