Table of Contents

• Scoring and Specs
• SBC Scoring Results
• GPIO’s (1/1)
  • Updated GPIO Table
  • Major GPIO limitations:
• IR (0/1)
• I2C (0/1)
• SPI (0/2)
• UART (1/1)
• Subjective Performance (1/2)
• Ease of Use (1/2)
• Software Updates (1/2)
• Community (0/2)
• Issues
  • Power Issues
  • CMOS Battery
  • eMMC
• Overall (5/14)

Scoring and Specs

Here is a breakdown of the scoring. I’ll cover each section below to describe how I came to the numbers.

SBC Scoring Results

The specifications for the Atomic Pi that I was able to collect are available below:

GPIO’s (1/1)

The main set of IO on the breakout board is the 11 screw terminals that connect off the 26-pin plug on the bottom of the main board. Here we have the following:

• 6x general GPIO pins
  • GPIO1 and GPIO2 also connect to LEDs on the breakout board
• 2x UART (RXD1/TXD1 and RXD2/TXD2)
  • These CANNOT be repurposed

In addition to the main IO block, there are two additional 3-pin blocks on the back of the board. J9 has 2 pins for volume that can be repurposed as general GPIO’s. J10 has another UART (also CANNOT be repurposed).

Schematics here: https://www.digital-loggers.com/enchillada.pdf

I’ll note this again later with documentation, but the GPIO info listed in the official documentation appears to be wrong. The main GPIO documentation (https://download.fosc.space/atomic_pi/guide/html/gpio.html) says that the GPIO’s are on GPIO chip 3, when they are actually on GPIO chip 2. It DOES list global pin numbers that are correct, but modern Python libraries using gpiod use the Chip/Pin combo which threw my testing for a loop.

Updated GPIO Table

The Green and Yellow LEDs are connected to VCC3 (3.3v) and the GPIO through a 1k resistor. Using GPIO1 and GPIO2 as an input is essentially impossible as these GPIO’s will be pulled high at all times.

Major GPIO limitations:

• As noted, UART pins cannot be reused as GPIO
• There are no pull up/pull down options available (can’t say if the hardware itself is capable, there does not appear to be any way to set it using the 5.4 kernel that the Atomic Pi is running). External pull up/down must be used
• Limited numbers – only 8 total GPIO’s can be used
• GPIO1 and GPIO2 are connected to 3.3v via the LEDs which means they are usable for output only.

I am technically passing the GPIO category, since there are 8 usable GPIO’s, but the limitations make it a tough call.

IR (0/1)

Enabling the GPIO UART was relatively simple. The 5.4 kernel has compiled in a patch that exposes the ability to create and delete (although deleting is not recommended) overlays on the fly. This means we just needed to create the DTS files, compile them, then load using the following:

sudo mkdir /sys/kernel/config/device-tree/overlays/{overlay-name}
sudo cat {overlay}.dtbo > /sys/kernel/config/device-tree/overlays/{overlay-name}/dtbo

You can find copy of the DTS files as well as the application script on our GitHub: https://github.com/LearningToPi/learningtopi.github.io/tree/main/files/atomicpi

Applying the overlay was simple, however the receiver would only occasionally pick up the transmitted signal. I was a bit surprised at this but given other issues didn’t see digging deeper as necessary.

I2C (0/1)

The Atomic Pi has no hardware I2C or SPI capabilities. Digital Logger provides a software-based driver that can be used to create I2C or SPI on the limited number of GPIOs. The I2C driver uses a daemon to load overlays based on files located in the /etc/i2c-gpio-custom.d folder. There is an existing bus for the BNO055 sensor built into the board. You can’t use the I2C bus used for the BNO055, so simply create a new file and provide the parameters outlined in the README file. I used pins 476 and 480 for my SDA and SCL pins (creating a new bus 41). Simply restart the board or restart the daemon:

sudo systemctl restart i2c-gpio-custom

The I2C bus shows up, and I’m able to see the device using i2cdetect. I am also able to connect to my 16×2 LCD and write content to the display! However, as soon as I loaded up the system with other tasks (in particular the IR) the number of successful writes to the I2C device plummeted. In the end a 52% success rate was all I could manage with IR enabled. Also note that due to the lack of GPIO’s, I was unable to run I2C and SPI at the same time. The best I could manage was simple GPIO in and out, UART and I2C together.

Please note that even the aged Raspberry Pi 3B+ is able to run the I2C bus with no issues since there is a hardware controller available. I have found numerous posts on the internet of people having success with I2C on the Atomic Pi, so before you call foul, your experience will vary depending on how busy the system is with other tasks. I wouldn’t depend on the software driver.

SPI (0/2)

The SPI driver works exactly the same as the I2C above. The SPI driver is configured using files in the /etc/spi-gpio-custom.d folder. Here you need to provide a bit more info. This includes a bus ID (0), CLK (335), MOSI (329), MISO (336), mode (0), max frequency (500,000), and CS pin (338). Restarting the service or the board will create your SPI bus:

sudo systemctl restart spi-gpio-custom

For reasons unknown this well for my BME280 sensor with no load. Under load I saw that the reads were successful, but the BME280 sensor was reporting my office was below freezing or approaching the boiling point of water. This is most likely due to bits getting flipped or mismatches in the timing. I would say that it is hard to trust your sensor data if you are reading over a software SPI interface.

When attempting to use my DHT22 over SPI (Python dht11_spi for details if this is new for you) was a complete failure. From what I can gather, the software SPI bus is not able to process the data quickly enough.

UART (1/1)

With UART we had great success! There are 3 available HARDWARE UART ports available. Two are available on the main breakout (J1) and one on the debug header (CN10). I left the debug header as a console interface and used UART1 on the breakout.

Traffic between the UART and USB CP2102 ran perfectly in both directions. With IR running I consistently saw 98% success (out of 14760 tests). With IR disabled it went to 100%. I can say that this was a complete success and performs even better than the RPi4B did.

UART was the ONLY test that passed with flying colors.

Subjective Performance (1/2)

This category is a bit open. I have 3 possible values:

• 0: The system is extraordinarily slow. It may be functional, but performance was an issue
• 1: The system works about like we would expect from an SBC. It was not excessivly slow and booted quickly. However, it doesn’t have any “wow”.
• 2: This is reserved for the “wow” devices. So far one device (the Radxa Rock 5B) fits into this category.

The Atomic Pi boots relatively quick. The BIOS POST is certainly slower than UBOOT on an ARM device. Out of the box the Atomic Pi comes with a built-in eMMC that was significantly quicker than a Micro SD Card and gave it a bit of an edge in performance. However, the eMMC failed and left me with SD. I’ll talk about the eMMC under the problems category below.

Ease of Use (1/2)

This wasn’t hard to grade. The software SPI and I2C buses are easy to set up and use. The sysfs driver for the overlays makes adding overlays for IR easy. Since we don’t have the ability to load overlays during the boot process on x86 like we do with ARM this is a must have.

I did have to doc a point for incorrect documentation. Not having correct GPIO Chip / Pin numbers listed for the few GPIOs that are available made using the system significantly more difficult than it should have been.

Software Updates (1/2)

This was a tough category. Given the issues that I have seen of late in the IOT world, any project should be able to be maintained and updated with security patches. On the plus side, as an x86 board, the Atomic Pi can run vanilla Ubuntu or really any other distribution that you want. The DOWNSIDE is that to maintain the “ease of use” we talked about above; you need to run the Digital Loggers kernel and here is where the problem comes in. The kernel is 5.4.30 and doesn’t appear to ever get updated. Digital Loggers GitHub does NOT have a repo for their kernel either.

5.4 is a long-term release, but 5.4.30 is from April in 2020. Since it is July 2023, it seems likely that this isn’t being actively maintained. This leaves you with a choice:

1. Keep the functionality for I2C/SPI and the ability to load overlays
2. Keep your system up to date on a supported kernel

Community (0/2)

I was able to find others that had purchased and used this board, but don’t expect anything like the community available for Raspberry Pi products. There is really only one “community” page here: http://ehxz.tk/atomicpi. There are some downloads available with different Ubuntu / Debian images as well as BIOS files, but that’s really about it. Don’t expect a large community with examples to pull from.

Issues

During setup, testing, or normal usage I ran into a few problems.

Power Issues

I tried using Pi 4B adapters and numerous other 5V power supplies to no avail. I even tried running the power directly into the pins on the bottom of the board (bypassing the breakout). The documentation says to use MULTIPLE pins if powering directly, which made me leery. In the end I ended up using my bench power supply (an EVGA SuperNova 550 ATX power supply).

I did find several other power supplies that would work, but quickly ran into stability issues (Atomic Pi would simply lock up after running for a period of time). Once I had the power sorted out, I had no issues with locking up.

CMOS Battery

Since the Atomic Pi is basically just a small Intel computer, it has a CMOS battery. Mine was dead out of the box and resulted in a reset of the BIOS and clock every time I removed power. I couldn’t find one with a matching plug, so ended up splicing a new battery in.

eMMC

I was happy that the Atomic Pi came with a built-in eMMC. These aren’t typically super fast but are generally way faster than running from an SD card. The downside here is that my eMMC went belly up after a while and stopped being recognized in the BIOS. I followed all the instructions I found on the web and couldn’t get it back working again. Eventually I gave up and reverted to an SD card.

I suppose if I ever decide to use this device long term, I could connect an external USB to eMMC similar to what I do with the Raspberry Pi 4B. SD cards are just not fast enough to run a graphical interface. Headless systems might work well enough, but GUI’s will just slow the system to a crawl.

Overall (5/14)

Overall, I would say that the Atomic Pi performs poorly in most circumstances. There are a few use cases though that I think the Atomic Pi could really shine (particularly given the low price):

• If you MUST have x86 for software binary compatibility
• If you need to run Windows (NOTE: I didn’t test any GPIO / I2C or SPI under Windows)
• If you have a project that needs 3x UARTs and only a couple of GPIOs

Unless you fit in the use cases above, you could probably do better with another system. As I wrap up testing on a range of different platforms, I’ll add a page to compare and contrast the different systems available.

The post Atomic Pi Pros, but mostly Cons appeared first on Learning to Pi.

Latest code is available on GitHub, view the other articles in our load testing series

This project is part 2 of 2 to capture current data for our load testing.  An ESP32 microcontroller will be used as a sender, and this project will cover the SBC device setup to receive. The device will be connected to the ESP32 via USB connected to a CP2102 USB to UART serial converter. At a later point I may add TCP connectivity, but for now we will use a serial interface. The python code will be running on a Raspberry Pi 4B, however since it is basic Python code using a USB serial interface, any computer with Python and a USB port can be used (NOTE: this has been tested on SBC’s running Linux only at this point). 

Commands will be sent, and data received via the USB serial interface. Since we are using our Raspberry Pi 4 in this example, we will be using port /dev/ttyUSB0. The code is written as a Python module that can be installed into your Python virtual environment. The code can be run directly from the command line, or the module can be imported into another project. The end goal is to incorporate the current data into the Python SBC load testing tool (stay tuned!).

Installing the module 

The package is available on PyPi or can be installed manually using the why/tar.gz file in the dist folder.

pip3 install ammeter_logger

Running from the CLI 

After installing the module, from the command line the code can be executed using the following: 

(venv) pi@pi:~/dev/ammeter_recv $ python3 -m ammeter_logger --help 
usage: __main__.py [-h] [--get-config] [--get-status] [--skip-init] [--force-init] [--init-only] 
                   [--sample-interval SAMPLE_INTERVAL] [--capture-time CAPTURE_TIME] [--baudrate BAUDRATE] 
                   [--log-level LOG_LEVEL] 
                   DEVICE OUTPUT_FILE 

Start the ammeter data collector. Requires the sender to be running (provided sender is Micropython for a microcontroller) 
  
positional arguments: 
  DEVICE                Serial device connected to the microcontroller (i.e. /dev/ttyUSB0 
  OUTPUT_FILE           File to save captured data to 
  
optional arguments: 
  -h, --help            show this help message and exit 
  --get-config          (False) Get the configuration from the microcontroller and quit 
  --get-status          (False) Get the current status of the microcontroller and quit 
  --skip-init           (False) Skip initializing the ammeter (not recommended!) 
  --force-init          (False) Force init of the ammeter 
  --init-only           (False) Only initalize the ammeter, print the config and status and quit (implies --force-init)
  --sample-interval SAMPLE_INTERVAL 
                        Set the sampling interval, overrides the config on the microcontroller 
  --capture-time CAPTURE_TIME 
                        Set the max time to capture before stopping, overrides the config on the microcontroller 
  --baudrate BAUDRATE   (115200) Set the baudrate for the serial interface 
  --log-level LOG_LEVEL 
                        (INFO) Specify the logging level for the console 
(venv) pi@pi:~/dev/ammeter_recv $ 

Most of the options are self-explanatory. You must specify a device (I.e. /dev/ttyUSB0) and a csv file to log your data to. If the sensor has not been initialized, the initialization will run first. This needs to be done with no load to get a solid baseline. After initialization is complete, the sampling can be run for a number of seconds specified. Below are some examples that can be used: 

CLI Example: Get Microcontroller Configuration

(venv) pi@pi:~/dev/ammeter_recv $ python3 -m ammeter_logger /dev/ttyUSB0 out.csv --get-config 
2022-06-15 16:20:07,410 - root - INFO - AmmeterRecvSerial: /dev/ttyUSB0: 115200: 8N1: Starting backgroup ammeter read. 
Current Config: {'interval': 50, 'timeout': 30, 'init_timeout': 30, 'pins': [{'pin': 32, 'name': 'sensor1pin32', 'baseline': 2884}]} 

CLI Example: Get Current Microcontroller Status

(venv) pi@pi:~/dev/ammeter_recv $ python3 -m ammeter_logger /dev/ttyUSB0 out.csv --get-status 
2022-06-15 16:20:33,899 - root - INFO - AmmeterRecvSerial: /dev/ttyUSB0: 115200: 8N1: Starting backgroup ammeter read. 
Current Status: {'status': 'READY', 'timeout': 0, 'noinit_pin': None} 

CLI Example: Initialize the microcontroller sensor

(venv) pi@pi:~/dev/ammeter_recv $ python3 -m ammeter_logger /dev/ttyUSB0 out.csv --init-only 
2022-06-15 16:22:28,026 - root - INFO - AmmeterRecvSerial: /dev/ttyUSB0: 115200: 8N1: Starting backgroup ammeter read. 
Waiting for ammeter to initialize. {'status': 'READY', 'timeout': 0, 'noinit_pin': None} 
Waiting for ammeter to initialize. {'status': 'INITIALIZING', 'timeout': '30', 'noinit_pin': None} 
Waiting for ammeter to initialize. {'status': 'INITIALIZING', 'timeout': '28', 'noinit_pin': None} 
Waiting for ammeter to initialize. {'status': 'INITIALIZING', 'timeout': '26', 'noinit_pin': None} 
… 
Waiting for ammeter to initialize. {'status': 'INITIALIZING', 'timeout': '4', 'noinit_pin': None} 
Waiting for ammeter to initialize. {'status': 'INITIALIZING', 'timeout': '2', 'noinit_pin': None} 
Current Config: {'interval': 50, 'timeout': 30, 'init_timeout': 30, 'pins': [{'pin': 32, 'name': 'sensor1pin32', 'baseline': 2782}]} 
Current Status: {'status': 'READY', 'timeout': 0, 'noinit_pin': None} 

CLI Example: Start the logging

(venv) pi@pi:~/dev/ammeter_recv $ python3 -m ammeter_logger /dev/ttyUSB0 out.csv --capture-time 30 
2022-06-15 16:23:30,004 - root - INFO - AmmeterRecvSerial: /dev/ttyUSB0: 115200: 8N1: Starting backgroup ammeter read. 
Starting data collection.  Collection will run for 30 seconds.  You can stop at any point and write the captured data using CTRL+C. 
Waiting for logging run to complete.  Last amp read: -0.03868132.  Current status: {'status': 'RUNNING', 'timeout': '30', 'noinit_pin': None} 
Waiting for logging run to complete.  Last amp read: -0.03142858.  Current status: {'status': 'RUNNING', 'timeout': '29', 'noinit_pin': None} 
Waiting for logging run to complete.  Last amp read: 0.06285715.  Current status: {'status': 'RUNNING', 'timeout': '27', 'noinit_pin': None} 
… 
Waiting for logging run to complete.  Last amp read: -0.0410989.  Current status: {'status': 'RUNNING', 'timeout': '5', 'noinit_pin': None} 
Waiting for logging run to complete.  Last amp read: 0.029011.  Current status: {'status': 'RUNNING', 'timeout': '3', 'noinit_pin': None} 
Waiting for logging run to complete.  Last amp read: 0.003223445.  Current status: {'status': 'RUNNING', 'timeout': '1', 'noinit_pin': None} 
Writing log to file out.csv... 
Writing complete. 

Importing and using the module 

The code can also be imported into another project. This will be used as a part of our Python SBC load testing. The ammeter_logger module will be used to capture amperage data while other load tests are running, This will allow us to map power usage to each of our tests. 

from ammeter_logger import AmmeterRecvSerial 
ser = AmmeterRecvSerial(device=’/dev/ttyUSB0’, baudrate=115200) 

Since the AmmeterRecvSerial class inherits the serial.Serial class, any paramter available in the serial.Serial class can be use. See the pySerial project for details on supported parameters. 

Cabling

Since we used a CP2102 in our ADC Current Sensor Project [LINK], for this project we need only to connect the serial port on the CP2102 to a USB port on the device that will be collecting the data. The CP2102 will appear as a USB serial interface. 

For logging amperage data during the boot of an SBC or microcontroller, we will use a Raspberry Pi 4B to collect the data, however any device running a modern version of Linux with a USB port will suffice (I have not tested the Python code on Windows or Mac). 

For logging amperage data during the load test (keep an eye on our load testing [LINK] series for more), we will connect the USB port of the CP2102 directly to the device we are load testing. This will allow our load testing package to collect amperage data for each phase of testing in real-time. 

Breakdown of the code 

The AmmeterRecvSerial extends the serial.Serial class since all of our communication will be using the serial bus. This allows us to add just the functions we need that are specific to the microcontroller current sensor. 

AmmeterRecvSerial.__init__(…) 

The init function pops the logger parameter before calling the serial.Serial init function using the “super().__init__(*args, **kwargs)” call. This will pass all parameters (other than the logger) to the base class to initialize the serial device. All serial parameters supported by serial.Serial like device, baudrate, stop bits, etc can be passed to the AmmeterRecvSerial class. 

AmmeterRecvSerial.ammeter_report() 

The report function returns the actual data that was collected. The report will be returned as a dictionary that consists of the following:

{ 
	‘start’: (datetime object representing the start time of the data), 
	‘stop’: (datetime object representing the stop time of the data), 
	‘data’: [ (list of data entries that were received) 
		{ 
			‘received’: (EPOCH time the data was received), 
			‘name’: (name of the sensor from the microcontroller), 
			‘ticks’: (number of microseconds from the start reported by the microcontroller), 
			‘current_amps’: (latest reading, not averaged), 
			‘last_reads’: [(list of readings that were used for the average)], 
			‘average’: (average amperage from the list of reads above) 
		}, 
		… (repeat for all received data points) 
	] 
} 

If you would like to export to CSV, you can take a look at the write_log_data function in the __main__.py file. This function is used to export the data when calling the module directly using “python3 -m ammeter_logger …” 

(property) AmmeterRecvSerial.ammeter_status() 

The status property will clear the currently cached status and query the microcontroller for an updated status. The data will be returned as a dict with the following: 

{ 
	‘status’: (string showing the current status: RUNNING, NOINIT, INITIALIZING, READY) 
	‘timeout’: (number of seconds remaining in initialization or run if applicable else 0), 
	‘noinit_pin’: (if status is NOINIT, reports the input pin that isn’t initialized, else None) 
} 

(property) AmmeterRecvSerial.ammeter_initialized() 

Returns a True / False after querying the microcontroller for a status. 

(property) AmmeterRecvSerial.ammeter_running() 

Returns a True / False after querying the microcontroller for a status. 

(property) AmmeterRecvSerial.ammeter_ready() 

Returns a True / False after querying the microcontroller for a status. 

(property) AmmeterRecvSerial.ammeter_config() 

Returns the configuration from the microcontroller in the following format: 

{ 
	‘interval’: (read interval in milliseconds) 
	‘timeout’: (timeout for reading data in seconds) 
	‘init_timeout’: (timeout for initializing the ADC sensor and creating the baseline) 
	‘pins’: [ (list of pins to read data from) 
		{ 
			‘pin’: (pin number on the microcontroller) 
			‘name’:  (friendly name to use for the sensor on this pin) 
			‘baseline’: (baseline ‘0’ calculated after the initialization) 
	] 
} 

(property+setter) AmmeterRecvSerial.ammeter_interval() 

The property and setter can be used to get the currently configured read interval and to set a new read interval. After setting the interval, the setter will check the interval from the microcontroller to ensure that the configuration was accepted. True is returned from the setter if the value was successfully applied, false if not. 

AmmeterRecvSerial.ammeter_init() 

Requests the initialization to run on the microcontroller. This is intended to get a zero baseline, so there should be no load on the sensor prior to running the initialization. The initialization will run for the ‘init_timeout’ length in seconds from the configuration (see above). 

AmmeterRecvSerial.ammeter_start() 

Requests the microcontroller to start the read. Once the read is started, the microcontroller will start returning data at each read interval that the receiver will need to record and store. The microcontroller does not maintain any data beyond the last few reads needed to create an average. 

AmmeterRecvSerial.ammeter_stop() 

Requests the microcontroller to stop any read currently in progress. The microcontroller may take 1-2 read intervals to stop and return the final stop message. 

AmmeterRecvSerial.ammeter_current() 

Requests the microcontroller to perform a single read. The single read will still make multiple reads based on the configuration, will discard the highest and lowest value, then average and return the result. 

AmmeterRecvSerial._ammeter_read() 

This is an internal use function that runs as a thread to check the serial ports input queue every 100ms for received data. 

AmmeterRecvSerial._ammeter_parse_read_line() 

This is an internal use function that will parse any data that has been received on the serial port. This function will parse the return data to determine what type of message was received, then store the data. 

The post Python ADC Current Logger (ammeter_logger) appeared first on Learning to Pi.