yang/logicanalyzer
1
0
Fork 0
mirror of https://github.com/JasonYANG170/logicanalyzer.git synced 2024-11-23 20:16:29 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'master' of https://github.com/gusmanb/logicanalyzer

Browse Source
This commit is contained in:
Agustín Gimenez 2022-07-08 17:34:40 +02:00
commit 64e2a0c656
1 changed files with 20 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
README.md
View File

@ -14,15 +14,15 @@ Additionally to the hardware the logic analyzer also includes a powerful softwar
## About logic analyzers and triggers ## 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. 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 in 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 describd here has three trigger modes: edge trigger, fast pattern trigger and complex pattern trigger. The analyzer described here has three trigger modes: edge trigger, fast pattern trigger and complex pattern trigger.
The edge trigger uses a single program, that's the basic version that uses only two instructions, runs up to 100Msps and the triggering is synchronized with the captures. The edge trigger uses a single program, that's the basic version that uses only two instructions, runs up to 100Msps and the triggering is synchronized with the captures.
@ -36,7 +36,7 @@ If you want more info about the triggers check the PIO code in the source as the
## Schematic ## 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") ![Schematic picture](Schematic1.jpg?raw=true "Basic schematic")
@ -56,19 +56,19 @@ There are two PCBs, one for the analyzer and other for the level shifter.
## Building the firmware ## Building the firmware
To build the firmware you need to have an environment configure for Pico development, but if you don't have it don't worry, the releases include the UF2 file, so you only need to start the Pico in program mode, drop the UF2 file to the Pico drive and that's it, you have a Logic Analyzer ready to be used. To build the firmware you need to have an environment configured for Pico development, but if you don't have it don't worry, the releases include the UF2 file, so you only need to start the Pico in program mode, drop the UF2 file to the Pico drive and that's it, you have a Logic Analyzer ready to be used.
## The software ## The software
Before designing my own analyzer I have used some cheap chinesse 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") ![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") ![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. 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.
@ -94,9 +94,9 @@ This will open the region creation dialog where you can choose a name for your r
![Region picture](Highlight3.jpg?raw=true "Highlight") ![Region picture](Highlight3.jpg?raw=true "Highlight")
If you want to delete a region press on the numeric bar over a highlighted region and it will be deleted. Regions are also exported If you want to delete a region press on the numeric bar over a highlighted region and it will be deleted. Regions are also exported with captures.
## Adding custom protocolo analyzers ## Adding custom protocol analyzers
To add a new protocol analyzer you need to create a .net 6.0 assembly that references the LogicAnalyzer assembly and implements at least one class based in "ProtocolAnalyzerBase". Basically you will provide a list of settings to present to the user and then you will implement an analysis function that returns analyzed channels. To add a new protocol analyzer you need to create a .net 6.0 assembly that references the LogicAnalyzer assembly and implements at least one class based in "ProtocolAnalyzerBase". Basically you will provide a list of settings to present to the user and then you will implement an analysis function that returns analyzed channels.
@ -104,5 +104,13 @@ Each analyzed channel will specify a list of segments where data is overlayed (t
--- ---
## About Sigrok and the custom app
I have been reading some comments about why create my own application and why not use Sigrok as it would have been developed faster. First of all, the full project including firmware, PCB's and Windows client took me less than a week of development, I have been creating Windows apps for more than 20 years and it takes me less time to implement a rendering system, plugins and so on than implementing a third-party driver :)
In any case, my main reason to not consider to use sigrok is because I tried to use it with some cheapo analyzers and on my machines it simply would not run, I'm not sure if some component that I use for development is incompatible with it but on my three machines it crashed, in one machine it does not open at all and on the other two I had random crashes when I tried to capture data.
In any case, I will try to get it running in one of my development machines and if it works I will check how complex would be to create a driver for it.
---
Have fun! Have fun!