plastic-scanner / db2.x-firmware

Firmware for the DB2.X (development board) of the Plastic Scanner project

DB 2.x - Firmware

This is the firmware repository for the DB2.X (development board) of the Plastic Scanner project. More technical information is in the docs and general information about project on our website.

Requirements

Firmware runs on DB2.x (tested on DB2.1), powered by Arduino. Requires PlatformIO, a cross-platform embedded development toolset. See installation instructions here it can be as easy as one-click-plugin-installation (PlatformIO IDE).

In order to build and upload the firmware to DB2.x, connect the board to computer and find the Build and Upload buttons in the PlatformIO IDE OR use the following commands:

$ pio run -t upload 		# build and upload fw image

The compiled firmware image is placed in .pio/build/<board>/firmware.hex.
Compilation options can be tweaked in platformio.ini file (see build options).

Usage

Connect your DB2.x to your laptop, build and flash the firmware and open the serial console with $ pio device monitor or your favourite app (e.g Putty, screen, minicom, picocom...). Enable local echo in order to see commands you're typing by adding --echo to command above, or pressing CTRL+T followed by CTRL+E while running it.

User can send commands like this:

> scan

which outputs a full scan, 8 values, one for each LED.

See app/main.cpp at setup() function which commands are defined or type help to list all commands.

Development

Feedback on architecture and implementation is welcome. Firmware currently controls an Arduino, which "talks" to an ADC chip and a LED driver, communicating via the serial interface. In directory app are the main sources, test is for unit tests (which needs much more love and actual tests), drivers contains custom drivers for componments on board.

NOTE about drivers: at the moment we're using a third party library for the ADC, listed in platformio.ini at [lib_deps], with sources located in .pio/libdeps/uno/. However, we hope to soon implement a custom, simpler driver for it which will be located in drivers/ads1256.

db2.x-firmware's Issues

Make line-ending configurable

Now we can handle receiving of all possible line-endings (LF, CR, CRLF), but outputting stuff is still only the arduino-default-way (CRLF) and not configurable. Turn this into a configurable, "deterministic" setting.

Multiple prompts are printed in same line

The command prompt > is duplicated sometimes. Reshape the way of handling prompt into something nicer + partly related to #1

Add support for AS7341 in firmware

Someone proposed adding a color sensor to get more information about the plastic sample. we settled on the AS7341 (thanks Loki!), for testing we bought the Adafruit breakout board. The DB2.1 already has a QWIIC connector so assembly is simple, we just need to implement it in the firmware! This can be as simple as adding the example code to the platformIO environment

Write a simple(r) driver for the ADS1256

I believe that a small, custom driver for the adc would make the code smaller, simpler and more to the point for our use-case.
We could be consistent with the style - not doing anything in constructor, simplify and shorten function names, combine waitDRDY + scan into one function call, etc.

Crashes when overloaded with "scan" commands

A python scripts that spits out scan commands in a loop, without any delays, will crash the firmware after couple of seconds.

Include version information, print on boot

Now, it is not possible to know which "version" of firmware are we running.

Feedback on overall FW architecture, implementation, style

Feedback from experienced firmware engineers would be amazing! What is well done, what can be improved? What conventions am I breaking or unaware of? How to make code more human-readable and simple? How can I document, explain it better?

Unit tests

Currently there's almost no unit tests in place. What should we test? How?
One thing I can think of - "bombing" the cli (command line interface) with commands and seeing when and why it freezes. Another thing could be measuring adc values and checking if they are in a reasonable range?

Add license information

Hello!

I found your project from https://hackaday.io/project/185532-plastic-scanner

Could you please add information about the license of this repository — is it allowed to copy, change and use the code in any purpose?
It would be great to see any popular open source license.

ADC readings return negative value in "full darkness" (sensor covered)

Probably due to the hardcoded voltage reference. No need to use voltage anyways, implementing custom ads1256 driver and using adc samples direclty should fix the issue.