tools/gpio/gpio-sloppy-logic-analyzer.sh
Source file repositories/reference/linux-study-clean/tools/gpio/gpio-sloppy-logic-analyzer.sh
File Facts
- System
- Linux kernel
- Corpus path
tools/gpio/gpio-sloppy-logic-analyzer.sh- Extension
.sh- Size
- 8888 bytes
- Lines
- 247
- Domain
- Support Tooling And Documentation
- Bucket
- tools
- Inferred role
- Support Tooling And Documentation: tools
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
#!/bin/sh -eu
# SPDX-License-Identifier: GPL-2.0
#
# Helper script for the Linux Kernel GPIO sloppy logic analyzer
#
# Copyright (C) Wolfram Sang <wsa@sang-engineering.com>
# Copyright (C) Renesas Electronics Corporation
samplefreq=1000000
numsamples=250000
cpusetdefaultdir='/sys/fs/cgroup'
cpusetprefix='cpuset.'
debugdir='/sys/kernel/debug'
ladirname='gpio-sloppy-logic-analyzer'
outputdir="$PWD"
neededcmds='taskset zip'
max_chans=8
duration=
initcpu=
listinstances=0
lainstance=
lasysfsdir=
triggerdat=
trigger_bindat=
progname="${0##*/}"
print_help()
{
cat << EOF
$progname - helper script for the Linux Kernel Sloppy GPIO Logic Analyzer
Available options:
-c|--cpu <n>: which CPU to isolate for sampling. Only needed once. Default <1>.
Remember that a more powerful CPU gives you higher sampling speeds.
Also CPU0 is not recommended as it usually does extra bookkeeping.
-d|--duration-us <SI-n>: number of microseconds to sample. Overrides -n, no default value.
-h|--help: print this help
-i|--instance <str>: name of the logic analyzer in case you have multiple instances. Default
to first instance found
-k|--kernel-debug-dir <str>: path to the kernel debugfs mountpoint. Default: <$debugdir>
-l|--list-instances: list all available instances
-n|--num_samples <SI-n>: number of samples to acquire. Default <$numsamples>
-o|--output-dir <str>: directory to put the result files. Default: current dir
-s|--sample_freq <SI-n>: desired sampling frequency. Might be capped if too large.
Default: <1000000>
-t|--trigger <str>: pattern to use as trigger. <str> consists of two-char pairs. First
char is channel number starting at "1". Second char is trigger level:
"L" - low; "H" - high; "R" - rising; "F" - falling
These pairs can be combined with "+", so "1H+2F" triggers when probe 1
is high while probe 2 has a falling edge. You can have multiple triggers
combined with ",". So, "1H+2F,1H+2R" is like the example before but it
waits for a rising edge on probe 2 while probe 1 is still high after the
first trigger has been met.
Trigger data will only be used for the next capture and then be erased.
<SI-n> is an integer value where SI units "T", "G", "M", "K" are recognized, e.g. '1M500K' is 1500000.
Examples:
Samples $numsamples values at 1MHz with an already prepared CPU or automatically prepares CPU1 if needed,
use the first logic analyzer instance found:
'$progname'
Samples 50us at 2MHz waiting for a falling edge on channel 2. CPU and instance as above:
'$progname -d 50 -s 2M -t "2F"'
Note that the process exits after checking all parameters but a sub-process still works in
the background. The result is only available once the sub-process finishes.
Result is a .sr file to be consumed with PulseView from the free Sigrok project. It is
a zip file which also contains the binary sample data which may be consumed by others.
The filename is the logic analyzer instance name plus a since-epoch timestamp.
EOF
}
Annotation
- Atlas domain: Support Tooling And Documentation / tools.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.