Lab 1a
The Artemis Board
The overall purpose of the lab was to set up the Artemis Nano—the microcontroller our future work will rely on—and familiarize ourselves with the process of writing, understanding, and uploading code. Conveniently, the Nano is programmable via the Arduino IDE, so it was a simple matter of downloading the Sparkfun Apollo3 board support pack (version 1.1.2) with libraries and code snippets relevant to the Nano.
Theoretically, this lab could be easily accomplished by plugging the board into your laptop’s USB port, selecting the correct serial port in the Arduino IDE for the code to be uploaded to, and uploading the various code examples, but that wasn’t my experience. My first Artemis Nano wasn’t allowing code to be uploaded to it.
If I tried uploading through the wchusbserial port, I would get the error “Artemis SVL Bootloader Target failed to enter bootload mode. Verify the right COM port is selected and that your board has the SVL bootloader.” Trying the usbserial port didn’t result in a better outcome, and instead showed the error “Artemis SVL Bootloader /dev/cu.usbserial-1410 is currently open. Please close any other terminal programs that may be using /dev/cu.usbserial-1410 and try again.” even though running lsof | grep on both the cu and tty.usbmodem ports showed no other programs using it.
After referencing this forum post I uninstalled the WCH drivers and reinstalled the CH340 drivers, but it made no difference—the device was still being recognized but not accepting uploads. Other posts, such as this one, recommended changing the baud rate to either 460800 or 115200 to make sure that the baud rate negotiation would ultimately be accepted by the board, but that also didn’t work. I ended up continually getting the error “Artemis SVL Bootloader Target failed to enter bootload mode. Verify the right COM port is selected and that your board has the SVL bootloader.” which led me to believe that the chosen SVL bootloader wasn’t on the board. Attempts to burn SVL onto the Nano using the default ASB bootloader were futile and using the ASB bootloader to program the board didn’t do much better. Ultimately, it was concluded that my board was faulty and I had to get a new one.
Thankfully the new Artemis Nano I received was fully functional and I was able to easily upload the Blink, Serial, analogRead, and MicrophoneOutput programs to the board. All of these programs were written in the Arduino-style C .ino files, where a function called setup is run once as soon as the board is powered/reset and another function named loop runs over and over again forever.
The Blink program accessed the onboard LED as an output and blinked it every other second. This can be seen in the video below:
Once the Blink program was confirmed to be functioning, the next step was to interact with the Serial port. Based on user input, various messages were printed to the Serial port, as seen in the following video:
Next up was to run analogRead, a program that sets one of the analog pins as an input and prints up its internal temperature. The base temperature of the board was around 32℃ and I was able to get it up to a little over 34℃.
The last example program to run was MicrophoneOutput. This accessed the pulse density microphone (PDM) on the board and analyzed frequency data using FFT to output the loudest frequency bin. I personally had a lot of fun testing this out.
The final step of lab 1a was to write a program that would light up the onboard LED when you make a noise and turn it off otherwise. I relied heavily on the MicrophoneOutput example, with this particular code snippet being the main logic I implemented:
Serial.printf("Loudest frequency: %d \n", ui32LoudestFrequency);
if (ui32LoudestFrequency > 0) {
digitalWrite(LED_BUILTIN, HIGH);
} else {
digitalWrite(LED_BUILTIN, LOW);
}
To prove that this code could run when the Nano was plugged into both the computer and the external battery, I took these videos:
Overall, this lab was a simple way to interact with the Artemis Nano and Arduino IDE to get the ball rolling for the rest of the semester. Even though the path to the finish line was longer than expected, the software and hardware debugging I had to do taught me even more about the board, so I’m excited to put my knowledge to use.