¶ Flashing Firmware to a Board
¶ Configure
Before you can flash the firmware, you need to configure the firmware. See Firmware configuration.
The configuration file you create must be named
Configuration_local.hpp
¶ As a User
¶ Download OATFWGUI
Download the latest release of OATFWGUI, unzip and run:
- Windows:
OATFWGUI_Windows.bat - Linux:
OATFWGUI_Linux.sh- Override the python interpreter by setting
PYTHON(i.e.PYTHON=/usr/bin/python3.10 ./OATFWGUI_Linux.sh) - This creates a local python virtual environment in
.venv_OATFWGUI. If there's an error during the first run, delete that folder to have the script try again.
- Override the python interpreter by setting
OATFWGUI requires an active internet connection!
¶ Using OATFWGUI
- Select the firmware version you'd like to install from the dropdown (either a released version, or the latest "develop")
- Click "Download" button to download that firmware version
- Select your board type from the dropdown
- Click "Select local config file" and select the
Configuration_local.hppfile you previously created - Click "Build FW"
- Wait for the firmware to be built
- The first time this can take a while because it needs to download all the library dependencies
- Select the serial port that your mount is connected to from the dropdown
- Optionally check the "Upload anonymous statistics" checkbox to give the devs some data about your configuration as well as a rough geo-location (location is IP based and rounded to 0.5° lat/lon)
- We really appreciate this! We use this data to prioritize features/bug fixes
- We really appreciate this! We use this data to prioritize features/bug fixes
- Click "Upload FW" to upload to the board
Note that if you are using the ESP32, you have to press and hold the reset button on the board until the programming starts.
If you have the capacitor mod, you need to remove it in order to flash the board.
If you encounter a firmware error (or bug), the logs are stored in the logs directory.
¶ Other software
Software packages like the ASCOM driver and OATcontrol can be used to control the mount after the firmware is flashed. See Software for more details.
¶ As a Developer
Visual Studio Code the PlatformIO is the simplest way to get a development environment.
¶ Install
¶ Visual Studio Code with PlatformIO
Download and install Visual Studio Code. Then install Platform IO from the Extensions Tab in VSCode. Once you open the OpenAstroTracker folder (File > Open Folder), the rest happens automatically.
¶ Build
You should build the version for your board after making the edits described above.
- Click on
PlatformIO(the little alien head) in the left sidebar. - Click
Project Tasks. - Select the board you are using from the list of supported environments (boards)
- Click
General>Build.
¶ Upload/Flash
After the above Build step has succeeded, you'll need to send the built firmware to your board. This is called Flashing.
- Click on the
Uploadcommand (right below to theBuildcommand used above) - Same warnings from above apply
Linux users that cannot select the port might have to disable or delete bltty as this has priority over The arduino IDE
¶ Firmware Debugging
The system does not allow very high level debugging (like stepping through code with a debugger). The firmware does have a number of logging output flags to aid you in determining what the mount is doing. But, and it's a big but, this logging is output on the serial port and thus breaks the Meade protocol (since instead of the command response that an app might be expecting, it gets debug spew).
This means that realistically, the only way to debug something is to connect the OAT to a monitor (terminal) and issue Meade commands manually. The Arduino IDE actually has a pretty easy to use and reliable monitor, you just hit CTRL+SHIFT+M and it will open a window that you can use to issue commands and see the logging output. You do have to configure the port and board before opening it, though.
The debugging is controlled in the firmware through a compile-time flag (so that the large number of debug strings and the formatting calls are not in the release/non-debug build) called DEBUG_LEVEL and it is defined in your local configuration file (the config generator puts it at the bottom). By default, it is set to DEBUG_NONE, which means no logging will be created and apps can use the OAT via the Meade protocol.
There are a number of flags that can be used to control the level and category of debug output. Take a look at the bottom of Constants.hpp for details.
You'll need to re-compile and re-flash the board before you can view the debug log in the monitor.
¶ Output debug info on a separate serial port
One can utalize a USB to TTL device to output the debug info on a separate serial port, here is an example of what you need to define in configuration_local.hppwhile debugging MKS v 2.1 board.
// Debug settings
#define DEBUG_LEVEL (DEBUG_INFO)
#define DEBUG_SEPARATE_SERIAL 1
#define DEBUG_SERIAL_PORT Serial2
#define DEBUG_SERIAL_BAUDRATE 115200
¶ Firmware Meade Features
The firmware implements a (large) subset of the Meade LX200 GPS protocol. Additionally, it adds a lot of extension functions that can query and control aspects specific to the OAT.
The Meade Command Index is a page that lists all available command. That page is autogenerated.