picOOscilloscope
Simple do-it-yourself oscilloscope using Raspberry Pico and touch display made for my dad.
Hardware
Microcontroller: Raspberry Pi Pico with RP2040
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, protection, 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 component). Basically, the component takes 2 digital inputs from the microprocessing, 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 glitches 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)
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 displayed 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.
Debugging
Debugging Raspberry Pi Pico is pretty easy in PlatformIO.
- Get extra Pico board and flash it with picoprobe firmware.
- Wire it up properly.
- Only single line is required to be added to
platformio.ini file: debug_tool = cmsis-dap; but you might want to see other options in docs.
- From now on you can add breakpoints and just go Run and Debug > PIO Debug and play around!
- To debug tests, you add extra line to
platformio.ini, like debug_test = embedded/interactive/ui/app/test_VoltageGraph. Note to self: make sure to delete/comment it before committing to Git, or if you want to go back to main application code.
- In my case, I was able to skip connecting the two cables for UART0 since I use USB serial port (default with Arduino-Pico). Of course, it requires both debugger Pico and target Pico be connected to USB, and you might need to specify which port is which. If you get
Error erasing flash with vFlashErase packet error, disconnect both boards, connect debugger first, then target, and start the debugging again. The USB behaviour while generally working might be acting up if you place breakpoints along the way.
- See more PlatformIO docs about debugging.
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
Preferred voltage lines for graphs (symmetrical 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 predictable patterns into the samples buffer and try figure out what is going on…
- Crashes on moving offset?
- Logging would be nice to have to allow some debugging…
- Or, go and analyze it part by part
- Or, actually debug it with second Pico? :monkaHmm:
- UI
- Offset (płynnie; z możliwością trzymania itd; na razie bez limitów i guess)
- 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.
- Sampling menu
- (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. It’s not that easy:
- 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:
- 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 special 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:
- 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 :^)
评论