Setting up Arduino IDE to test a clone from Arduino_Apollo3 github repository

Development Boards Artemis
1

I’ve spent a couple of days trying to beat this thing into submission, and instead have just beaten my head against the wall… LOL. I’m trying to test the code that Nate Seidle developed for the internal temperature sensor issue. So far, I’ve been unable to find the right set of steps to get this fully working. I pinged stephenf about it via PM, and he suggested opening a thread, so that everyone can benefit (and he’s right), so here we go…

I’m hoping to find out the steps I’m supposed to take to do this? I have to imagine that there’s an easier/smarter way, but I’m not that smart, or my Google-fu is weak… LOL

Here’s what I’ve tried… I’m on a Mac, so paths mentioned here look different than Windows, and potentially linux.

First, I downloaded Nate’s branch from Github as a ZIP file. After some time and several dead ends, I found a couple different ways to get the IDE to recognize it (either as a separate board, in my ~/Documents/Arduino/hardware dir, or by replacing SparkFun/hardware/apollo3/1.0.30 with the repository in the ZIP file).

Of those two methods, with the first, it looks like I’d have to uninstall the SparkFun board library - the compiler finds the 1.0.30 library first and tries to use it to compile the code. This fails because Nate’s new getTemperature() isn’t declared/defined in the 1.0.30 boards library.

The second method makes it further after I make the change to platform.txt that Nate recommended in the issue (it doesn’t find the compiler, otherwise), but fails to compile Nate’s new Example4 because the pin A3 isn’t declared. Obviously, something’s missing that lives in the main library or something. I have “RedBoard Artemis” selected as my board - pin A3 is supposed to be defined and mapped to pad 19 on the Apollo3 in that board variant (per the variant’s variant.cpp file). I can try selecting another board, potentially (the ATP was Stephen’s suggestion - since all the pads are mapped, there) - I’ll have to set this version back up on my system to try that.

Finally, I’ve set up the GitHub desktop, and pulled a clone of Nate’s branch to my local system in the ~/Documents/Arduino/hardware location, but the filesystem structure in the branch is wrong for that location - I’ll have to massage it to work, which isn’t really correct action for a code branch (not that I’m going to do a pull request from there, but it does make the Git stuff get messy on my end.

Ideally, someone has a clue as to what I’m doing wrong? :smiley: I’m not expecting to be spoon fed - I just can’t seem to find the right docs or forum posts that tie it together for me and explain what my workflow should be to make this work.

2

well… it is indeed not as easy you want it… and with only downloading the “core” it is missing out on other stuff (like BLE).

Personally having spend a lot of time on internal temperature, I have created a “simulation” of the Nate’s code will work on 1.0.30 release.

But first some background :

An Apollo3 chip internal temperature is calibrated or NOT. I have 2 edge boards and 1 ATP Artemis. Only the ATP is calibrated. The calibration information is stored in the chip and as you open the ADC for the first time after reset/reboot, that data is read into the library. It is called trim-data. If the Apollo3 chip is NOT calibrated, the library will apply default trim-values. An important remark with the default trim-values " These default values should result in worst-case temperature measurements of ±6 degrees C." The trim-data (default or calibrated) is used by initializing fTrims as Nate did and then call am_hal_adc_control(). However on user level you do not know whether the Apollo3 was calibrated or not…

In the attached sketch, which can be run on 1.0.30, I am simulating the approach as Nate has implemented. BUT now you can see whether the Apollo3 is calibrated or not. As stated my 2 edge boards are NOT calibrated. One board, using the default trim-values, is providing temperatures close to the environment (measured with an external meter) another is 4 to 5 C off. That is still within the +/- 6 C but not what I would hope for. The ATP Artemis (calibrated) is also very close.

Uploading attachments to a post on this forum is half a nightmare ( Sparkfun : PLEASE WHEN WILL UPLOAD BE FIXED ?? IT IS JUST SETTING THE PARAMETERS CORRECT ON THE SERVER !!! )

To use the attached temp.txt : rename the temp.txt to temp.ino and then open in the IDE

Once opened in Arduino IDE press cntrl + F :

in find: press [

replace with : {

NOW select : replace all

FINALLY you can compile

temp.txt (3.89 KB)

3

Hi, Paul - thanks - only issue that I had was that your find/replace also affects the arrays :slight_smile: Yeah, the Apollo3 on my RedBoard Artemis is calibrated, and it’s returning answers reasonably close to actual - it’s off by a couple degrees C vs ambient, but that’s inside tolerances and might accurately reflect the temp “under the hood” of the chip shield. Depending on the release for Nate’s code, I might incorporate your example into my code temporarily.

That said… yeah, I get it’s not a straightforward process to get things set up for use in the IDE. IS there a way? Or does it essentially look like hacking the existing library temporarily with the code diffs to test, and then restoring them to original form - and then replicating those changes to a clone/branch from github?

I don’t mind having to go through some heuristics to make things work, I’m just having trouble finding out what those heuristics should be! For instance, what does someone like Nate have to do to test these things? In the GitHub issue, stephenf mentioned testing Nate’s code - Stephen, how’d you set things up to do it?

4

Nate is now closing the gap with add a new library call getTemperature(). It was not available in the Arduino version before, while calculation was able in the AmbiqSuite SDK. Until the next release release of the Arduino library you can use the ‘simulated’ approach that I provided, as in essence it is exactly the same calculation of the library but performed but now in the sketch. The only advantage on the ‘simulated’ approach is that on user level it is indicated whether the Apollo3 was calibrated or not.

5

Paul, I get that - and thanks again.

I’m asking a larger question, though, not just focused on this one issue.

6

Nathan Seidle gave me some help via email, and that enabled me to figure it out. Here’s the steps I followed to get a working clone of the Arduino_Apollo3 repository that I can use from within the Arduino IDE!

  • navigate all the way to the board version folder in the main Arduino library (for Mac OS, this was ~/Library/Arduino15/packages/SparkFun/hardware/apollo3/1.0.30)

  • delete the contents of a board version folder, but keep the folder

  • cloned Arduino_Apollo3 to that folder - that created an Arduino_Apollo3 folder under 1.0.30, which the Arduino IDE doesn’t like

  • moved the Arduino_Apollo3 folder up one level

  • moved the contents of Arduino_Apollo3 to 1.0.30

  • GitHub desktop then complains that it can’t find the clone - repointed it to the 1.0.30 folder

  • restart Arduino IDE

Now, I can switch the Nathan’s adc_temperatureSensor branch, and fetch that code, and I can test his new Example4 directly. It works!

Hopefully, this will help someone else avoid this issue in the future, too!

7

A good discussion to be having - it would indeed be great to have an established process for testing new branches. To test them, I have been downloading the entire core as a zip, unzipping it and replacing the contents of C:\Users\steph\AppData\Local\Arduino15\packages\SparkFun\hardware\apollo3\1.0.30 with the contents of the zip.

Dave, I can’t quite follow your instructions. Ie. what do you mean by “Arduino_Apollo3” folder? Do you mean a board variant folder instead of a version folder? (could you reference actual paths for each step?)

8

Ah, sorry. So, when I do the clone, it creates a folder named after the repository and then pulls the repository down to that folder as the root. An unfortunate side effect of the GitHub desktop on Mac OS is that I can’t point the local destination to a folder that already has contents, so I have to pick the (empty) 1.0.30 folder. The clone process creates the Arduino_Apollo3 folder under there. Then I follow the other steps to get the code to the right spot, and make the GitHub desktop happy.

Hopefully, that makes more sense?

9

Here’s my approach which has always worked well for me:

  1. download arduino core via Arduino boards manager (to prepare directory structure)

  2. delete contents of the version directory (i.e. delete contents of Arduino15/packages/SparkFun/hardware/apollo3/1.0.x)

  3. clone the github repo into that directory so that platform.txt is contained directly by the version directory (i.e. Arduino15/packages/SparkFun/hardware/apollo3/1.0.x/platform.txt exists) (this can be done fairly easily using either command line git or GitHub Desktop)

Now you can perform version control directly on the version of the core that is utilized by Arduino. Some files are updated on every build and some (in my experience) may require a restart of the IDE.

P.s. I do not use the “local” hardware installation location. Just go right to the main area utilized by arduino. Here’s a potentially helpful link: https://arduino.github.io/arduino-cli/p … ification/