plastic-scanner / db2.x-firmware Goto Github PK

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

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

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.

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.

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

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?

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.

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

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?

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.