Warning

Work in progress, see To-do section for details.

picOOscilloscope

Simple do-it-yourself oscilloscope using Raspberry Pico and touch display made for my dad.

Hardware

Microcontroller: Raspberry Pi Pico
Display: 4'' TFT SPI ST7796 480x320
Display driver: ST7796(S)
Touch chipset: XPT2046

Microcontroller pins usage

Pin	GPIO	Notes
1	0	Reserved for UART0 TX
2	1	Reserved for UART0 RX
3	GND	Ground
4	2	SPI0 SCK, used for display & touch (shared)
5	3	SPI0 TX (MOSI), used for display & touch (shared)
6	4	SPI0 RX (MISO), used for display & touch (shared)
7	5	Chip select for the display
8	GND	Ground
9	6	Reset for the display & touch (shared?)
10	7	Register select (Data/Command) for the display
11	8	Chip select for the touch
...
21	16	S0 control for 74HC4052 for channel 2 (see below for details)
22	17	S1 control for 74HC4052 for channel 2 (see below for details)
23	GND	Ground
24	18	S0 control for 74HC4052 for channel 1 (see below for details)
25	19	S1 control for 74HC4052 for channel 1 (see below for details)

Analog front-end

Based on Scoppy (other closed source Pico oscilloscope) analog front-end examples, including FSCOPE-500K Rev 4e.

The front-end this project uses the more complex, dual channel with 4 voltage ranges, portection, 10X probe compatibility, input impedance of 1M||22pF, etc. Simulation using CircuitJS was created, for fun and exploration of the idea. Thanks to that, one can easily understand how the voltage is shifted. It uses two 74HC4052 dual 4-channel analog switch/(de)multiplexer; I even recreated the 74HC4052 inside the simulation too (custom compontent). Basically, the compontent takes 2 digital inptus from the microproessing, which allow for selecting pair of resistors: for voltage division and shift.

Range ID	Min voltage	Max voltage	S1	S0
0	-5.872 V	5.917 V	0	0
1	-2.152 V	2.497 V	0	1
2	-1.120 V	0.949 V	1	0
3	-0.404 V	0.585 V	1	1

Display hardware fix

An issue was reported to the library for controlling the display (and touch) for weird behaviour of display and touch SPI bus sharing misbehaving, resulting in visual gliches affecting last draw instructions right before switching SPI to talk with the touch controller. It turned out, the display was affected by a hardware bug. Explanation, origin and workaround (hardware modification) for the bug are described in TFT_eSPI issues by Bodmer (maintainer of the library). The proposed modification was applied as workaround in this project: shorting one of diodes on the display board.

Software

Environment: PlatformIO inside VS Code

Framework: Arduino (earlephilhower version)

Two main versions of Arduino core for Raspberry Pico exist: One from PlatformIO team, using ArduinoCore-mbed; and other, Arduino-Pico aka earlephilhower version.
The used version seems to support more stuff (like EEPROM library), and also allows using RP2040 C SDK.
I dislike it a bit, but required for the display library.

Library TFT_eSPI was used to support the display, with the touch support built-in.

General idea

Used processor RP2040 has 2 CPU cores and 12 DMA channels. ADC can be configured using round-robin to switch between channels and takes samples to special FIFO queue, and DMA then can take those samples to more proper buffer. This buffer will be scanned for fulfilling triggers by process on CPU 1, meanwhile CPU 0 will be responsible for setting everything up and operating UI on the display, including graphing the data.

User interface

There is single graph or split graphs displyed on left, and buttons for configuration and various features.

Notes

Aside from below, you might want to visit also:

./test/embedded/README.md for notes about testing on Pico using PlatformIO with Arduino-Pico core and ThrowTheSwitch Unity testing framework - there were few gotchas.

ADC

Without overclocking, ADC uses USB PLL clock with is 48MHz. The ADC apparently needs 96 clock cycles for sample conversion. See RP2040 datasheet at chapter 4.9. for ADC details.

Sample rate? Depending on frequency:

fastest: 48MHz / 96 = 500 kS/s (without overclocking)
slowest: 48Mhz / 65536 = 732.421875 S/s
slowest rounded: 48Mhz / 48000 = 1000 S/s

Time between samples?

fastest 1/500KHz = 2us (without overclocking)
slowest: 1/732.421875Hz = 0.00136533333s (a uneven bit over 1.3ms)
slowest rounded: 1/1000Hz = 1ms

Total recording time? Assuming 40'000 samples:

fastest: 40'000 / 500KHz = 0.08s = 80ms
slowest: 40'000 / 1000Hz = 40s

Graphing

Prefered voltage lines for graphs (symetrical by 0V):

Range 0: 0.00, 1.00, 2.00, 3.00, 4.00, 5.00, 6.00 V
Range 1: 0.00, 0.50, 1.00, 1.50, 2.00, 2.50 V
Range 2: 0.00, 0.25, 0.50, 0.75, 1.00, 1.25 V
Range 3: 0.00, 0.10, 0.20, 0.30, 0.40, 0.50, 0.60 V

To-do

Graph!
- Initial code is here, but it doesn't work (yet)! Time to debug...
  - Write few tests: Generate some predicatable patterns into the samples buffer and try figure out what is going on...
- Logging would be nice to have to allow some debugging...
  - Browse few of those, figure out categories/features
  - Create and fill the table with comparsions
  - (Unlikely) Figure how to adapt my own logging approach
  - Choose one of the approaches and stick with it for the project
  - ... did nice write up at earlephilhower/arduino-pico#2066
- Or, go and analyse it part by part
- Or, actually debug it with second Pico? :monkaHmm:
UI
1. Offset (płynnie; z możliwością trzymania itd; na razie bez limitów i guess)
2. Menu od próbkowania itd, osobny przycisk albo przycisk
  - pewnie trzeba pogrupować, może: root, topLevelMenu, samplingMenu, triggeringMenu etc.
  - może pasuje poprawić Group
  - przy okazji pomyśleć co zrobić z bombelkowaniem przyciśnięcia, w szczególności jak się nakładają elementy, w przyszłości może być np. prompt czy alert albo coś innego co zasłania graf czy inne przyciski.
3. Sampling menu
  1. (patrz TODO w root.cpp)
Default values & persist with EEPROM
Make it work ;)

Some reusable code for interactive logging:
- Prompt for user to do action using the touch display to pass/fail.
- Use watchdog to exit tests that hang-up/end up in infinite loop or something.
Positive-only ranges, at least for graphing; maybe automatic if no negative voltage is detected.
Consider moving graphing stuff to separate namespace
Consider using lower-level graphical functions to draw graph parts
Try fix touch issues
- limit button hitbox?
- detect jumping/deformations, maybe Z jumps around?
User Interface inputs:
- Channels: CH1, CH2 (single graph), CH1+2= (separate graphs, stacked on top of each other), CH1+2- (both on single graph)
- Time-base (multiple levels, +/- buttons) aka "horizontal scale"
- Horizontal position
- Voltage-base aka "vertical scale"
- No vertical position - channels selection takes care of it if we assume only up to 2 channels
- Trigger:
  - Channel: CH1, CH2 or both
  - Mode:
    - None/Free running
    - Positive/Negative Edge (voltage rises/falls through set level within set time frame)
    - Positive/Negative Pulse (pulse up/down to at least set level of at least set width)
    - Positive/Negative Glitch (pulse up/down to at least set level of less than set width)
    - Logic AND/NAND/OR/NOR/XOR ?
  - Some modes are parameterized
    - Level: (V +/-)
    - Width: (time +/-)
  - Repeat: ON/OFF/1 (1 == "Next", for next single capture when not repeating)
  - Hold off (time +/-)
- Sample rate? Lower = less detail, longer data
  - Technical
  - Can be derived from time-base somewhat
  - With enough memory seems like more detail is more important anyway, especially because max sample rate isn't that high anyway.
  - On other hand, maybe we can make ADC work with lower resolution/accuracy, but more speed (tradeoff)
- ...
- Interesting read/watch:
  - https://www.tek.com/en/documents/primer/oscilloscope-systems-and-controls
  - https://www.youtube.com/watch?v=1b3ivEZo7hw&list=PL2XuMA5AwNUznkBE46tcZAF3p5Edxgm-z&pp=iAQB
User Interface outputs:
- Voltages (max/min/avg)
- Frequency, Duty
- ...
Watch https://www.youtube.com/watch?v=rDDiPzJpI18 , try to understand "unofficial" speeds
Multi-language support, most likely configured on compile time
- Polish - including speical characters outside ASCII (custom fonts or fixing by overlapping characters/pixel drawings)
- English
Overclocking?
Generating reference signal
- See datasheet 2.15.6.3. "Configuring a GPIO output clock"
- Or use some timers based generator
- Maybe PIO generator?
Read https://raspberrypi.stackexchange.com/questions/143394/improving-sampling-frequency-of-raspberry-pi-picos-adc-pin-to-sample-at-frequen
If ADC2 (free pin) & ADC3 (required board modding) were to be used, they would also share the SAR ADC unit so also the sample rate (max 500kS/s divided by 4; at least by official clock speeds)
If external ADCs were to be used, they would require separate mini-drivers to be written; Then, they should be aggregated into single controller. User would have control over sampling frequency (and other settings like clock) per ADC-unit (which can be shared by multiple channels). Changing the frequency or desired capture time window might require changes across all other ADC-units, to make it all fit with given memory.
- Let's say we have 2 CH ADC (Pico) with max 500kS/s (split between channels) and 1 CH external ADC with max 1 MS/s, and total 100kB memory for sampling data. Memory should be split between ADCs to have them record the same window of time. When changing sampling rate, other ADC sampling rate should change proportionally OR the time windows need to shorten. Or simply show error unless user fix settings to have it fit.
Consider external fast ADC
Other interesting projects related to Pico/Oscilloscopes:
- https://github.com/ngscopeclient/scopehal/
- https://github.com/ela-project/elascope/
Consider support for logical channels
Consider integrating new touch related code to into TFT library (refactor & create pull request):
- Could reduce memory usage tiny bit of us (no unused built-in code & calibration)
- Would require more testing, at least more rotations etc., but also other devices - which we don't have any at the moment.
- By the way, library could use more examples with touch along the way, like saving calibration settings to EEPROM, hand-writing with smart lines, maybe simple paint etc.
- Macros could be used to provide options (dynamic deadband error limit and other valid-touch filtering parameters).
Unit tests :^)
- Unit testing documentation in PlatformIO
- Unity Assertions Reference
- Basic unit testing in PlatformIO articles
- Consider refactoring some code into private libraries.

againpsychox / picooscilloscope Goto Github PK