yang/logicanalyzer
1
0
Fork 0
mirror of https://github.com/JasonYANG170/logicanalyzer.git synced 2024-10-19 05:22:07 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

fix: Typos

Browse Source
This commit is contained in:
Chris Swan 2022-07-05 09:01:40 +01:00
parent 5110b910f7
commit 644d4b6410
No known key found for this signature in database
GPG Key ID: 27D8DC55ACC34C2E
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
README.md
View File

@ -14,13 +14,13 @@ Additionally to the hardware the logic analyzer also includes a powerful softwar
## About logic analyzers and triggers
A logic analyzer only cares about logic states of lines, so without thinking much about it you may think that any microcontroller using DMA channels that read GPIO values would be more than enough, but that is the "easy" part of a logic analyzer, the problem comes when you need to trigger the captures based in GPIO states and you want also to have data captured previously and aftetr the trigger happens.
A logic analyzer only cares about logic states of lines, so without thinking much about it you may think that any microcontroller using DMA channels that read GPIO values would be more than enough, but that is the "easy" part of a logic analyzer, the problem comes when you need to trigger the captures based in GPIO states and you want also to have data captured previously and after the trigger happens.
For that, you need to compare the read values from the GPIOs check if the pin or pins values match the requested trigger and you must do it as fast as you want to capture, so for example, the most basic comparison will at least consume 3 or 4 instructions, if each instruction is 1 to 4 cycles (more or less, I'm thinking in ARM processors) then you will use up to 16 cycles to read a sample, so you would need a 1.6Ghz CPU to sample at 100Msps.
So, how the heck the pico is able to achieve this? Well, the key are the PIO units, these units are a wonder, they are coprocessors explicitly dessigned to handle IO, it uses a very restricted and deterministic assembler (only nine instructions that each take a single cycle to execuet) but extremely efficient, so efficient that with only two instructions is possible to create a loop that captures GPIO data up to 30 bits and redirects the program flow based in the status of one of these GPIOs.
So, how the heck the pico is able to achieve this? Well, the key are the PIO units, these units are a wonder, they are coprocessors explicitly designed to handle IO, it uses a very restricted and deterministic assembler (only nine instructions that each take a single cycle to execute) but extremely efficient, so efficient that with only two instructions is possible to create a loop that captures GPIO data up to 30 bits and redirects the program flow based in the status of one of these GPIOs.
Of course there are some limitations, that two-instruction loop can only change the execution flow based on a GPIO pin, it can't branch based on a pattern (using only two instructions) but as we have more than one unit (each pico has two units and each unit has four state machines, so you can run in parallel up to 8 programs) we can abuse a bit the system and create a sepparate trigger program that notifies the capture program using a pin, that's why GPIO0 and GPIO1 are shorted.
Of course there are some limitations, that two-instruction loop can only change the execution flow based on a GPIO pin, it can't branch based on a pattern (using only two instructions) but as we have more than one unit (each pico has two units and each unit has four state machines, so you can run in parallel up to 8 programs) we can abuse a bit the system and create a separate trigger program that notifies the capture program using a pin, that's why GPIO0 and GPIO1 are shorted.
The analyzer described here has three trigger modes: edge trigger, fast pattern trigger and complex pattern trigger.
@ -36,7 +36,7 @@ If you want more info about the triggers check the PIO code in the source as the
## Schematic
The base schematic is only the Pico with a short between GPIO0 and GPIO1 but I have designed a PCB for convenience, it has been designed to mantain trace legths so no glitch may happen because propagation delays (at 100Mhz it should not be a problem, but in marginal cases if there is a noticeable trace length difference some picoseconds of delay can be introduced and change the analyzed values).
The base schematic is only the Pico with a short between GPIO0 and GPIO1 but I have designed a PCB for convenience, it has been designed to maintain trace lengths so no glitch may happen because propagation delays (at 100Mhz it should not be a problem, but in marginal cases if there is a noticeable trace length difference some picoseconds of delay can be introduced and change the analyzed values).
![Schematic picture](Schematic1.jpg?raw=true "Basic schematic")
@ -60,15 +60,15 @@ To build the firmware you need to have an environment configured for Pico develo
## The software
Before designing my own analyzer I have used some cheap chinese analyzers and all usee the same software, OLS, OpenBench Logic Analyzer, and to be honest, I don't like it. So, I have implemented my own binary protocol (more info in the firmware code) and visualization software.
Before designing my own analyzer I have used some cheap Chinese analyzers and all use the same software, OLS, OpenBench Logic Analyzer, and to be honest, I don't like it. So, I have implemented my own binary protocol (more info in the firmware code) and visualization software.
![Software picture](Software1.jpg?raw=true "Software main screen")
This is a .net desktop program for Windows (if I have enough requests I may plan to create a .net MAUI version that runs in Windows/MacOS/Linux) which allows you to visualize the capture data, highlight sampling ranges, name channels extremely fast, export the captured data preserving the capture settings and ranges, implemnts protocol analyzers (and a very easy system to include your own ones) and so on.
This is a .net desktop program for Windows (if I have enough requests I may plan to create a .net MAUI version that runs in Windows/MacOS/Linux) which allows you to visualize the capture data, highlight sampling ranges, name channels extremely fast, export the captured data preserving the capture settings and ranges, implements protocol analyzers (and a very easy system to include your own ones) and so on.
![Software picture](Software2.jpg?raw=true "SPI analysis")
For now I have already implemented a SPI protocol analyzer but I plan to implement also I2C, RS-232 and system bus analyzers (for old computers, 16 address bits and 8 data bits). In any case, with little knowledge of C# you can add your own protocol, which makes the program capable of analyze propietary protocols.
For now I have already implemented a SPI protocol analyzer but I plan to implement also I2C, RS-232 and system bus analyzers (for old computers, 16 address bits and 8 data bits). In any case, with little knowledge of C# you can add your own protocol, which makes the program capable of analyze proprietary protocols.
The capture interface is straight and self-explanatory, and the software preserves your last settings, can import settings from exported captures and allows you to re-issue a capture without having to go through the configuration process.