SUMP Compatible ESP32 Logic Analyzer with RLE

[E.U.A.]

Ahahah me too! I am leaving now. Probably will back on 20th. But will play with circuits on vacation also, if I can.

PS: 20Mhz RLE 8 bit encoding is almost ready. Works proper until DMA ring buffer catches RLE encoder block while inspecting 20Mhz clock with jitter...

Happy vacations.
Bests.

[aleroy]

I can confirm strapping GPIO 15 to ground + setting "Core Debug Level" to none works.

Thank You E.U.A. This looks excellent!

Mmmm...so much data ...

[aleroy]

I have a few questions.

I see some elements of cfg.gpio_bus are set to -1 and commented with designations for UART1 RX/TX, SPI flash, etc. Am I correct in assuming those are device specific pins that simply happen to align with the default code assigning inputs to the corresponding array indexes? ...or are those indexes reserved?

If a pin is not defined -1 and left floating, would that cause data errors?
I was trying to test whether I would get the same data through different input pins (sampling the same wire on each defined pin - one at a time). When I connected a pin on ADC1 (32 - 39) I found data one or more of the other ADC1 pins (in addition to the data collected on that pin). Is that due to ADC1, my board, or something else?
I'm new to all this, so it's possible the error is in my understanding, my sampling method, my board, or some other rookie mistake.

On another note...
In attempt to better understand your code---I saw the API Reference mentions routing I2S output directly to the 2 DAC pins. Would that be another option to get around the UART bottleneck? No protocol or buffering getting the way of a raw stream of data. Of course that would add another layer in order to interface with pulseview on the fly....

[E.U.A.]

Hello. Thanks for input. I add pulling GPIO15 down to readme file.

... cfg.gpio_bus are set to -1 and commented ...

because If let say enable GPIO7 for input 7, than ESP32 crash due SPI pins try to communicate with flash while occupied for input. You can select any GPIO pin that you want to use instead of -1 or 7.
Also setting them -1 does not make that pin floating but low...

I don't try to use ADC pins for input but I don't expect any different behavior from them.

About UART bottleneck... is not a bottleneck at all.
SUMP protocol sends data as LIFO; last in first out. Means latest sampled input send to computer first. Yeah it's not sounds logical but the protocol defined like this (probably due it make life easier with FPGAs). So I don't believe if it's good idea to send samples on the fly. Or we probably need to switch another protocol.

Also I2S DAC output is something about generate analog sound output from digital data (AFAIK). Not a good way to send samples to computer in analog form at the digital age. We might be better to use WiFi interface. But currently libsigrok doesn't support OLS over TCP. I made a bug report about it. If they implement, It's easy to switch WiFi or Ethernet interface instead of UART. But that is not really make big difference with current SUMP protocol. Just accelerates of sending stored data.

I am on vacation and Serial2 OLS option doesn't work proper with FTDI232 cable using my laptop somehow. It was really works proper with my main computer. Due this cannot debug the ESP32 while building RLE compression module. Generated samples has 1M data points but have some artifacts, > 10Mbps. Will try to solve it when I return to home.

@ESP_igrr the development board is reached to my home. I will work on it ASAP. Thank you.

[E.U.A.]

Hello all.
I am back. Get to the work.

First of all, RLE code has been published. Well, it has some issues.

RLE is currently only for 1.st channel, which is 8-bit only, well actually 7 bit due RLE bit. But looks working really good.
Currently, code only captures 96 kbytes of RLE buffer, half of it used for value and other half is timing...
With some effort like using second RLE buffer, it's easy to double it since we don't need 120Kb RAW capture buffer anymore.

But code is little became slow when there are to much change at signal, like inspecting > 10 Mhz continuous clock signal. In this scenario code need to write too much values and branching slow down the code. Might using 2 cores for RLE encode solve this issue. Or just need little optimization...

I also write 16bit version, which doesn't included in the code but not actually enabled... I need to test it before.

Also there are weird BUG in DMA ISR routine which is the main reason that RLE encoder is delayed.

Somehow, If code don't writes anything to serial port, than DMA ring buffer is broken, stop at last desc instead of looping back to first one. If I disable this useless code here than DMA ring doesn't work. But writing to serial port, DMA restarts from first desc as it need to be. Why? I don't know. Might be you have an idea @ESP_igrr

And I got WROVER module, thank you for that. I found that, external RAM access is to slow and doesn't support no DMA. I don't think if it's logical try to save raw samples on it, at least for 20Mhz. But might be possible using RLE due lowered bandwidth requirements. But this has to wait proper, more polished RLE code first.

Ah code is little dirty. Many debug lines etc. Will clear most of them.

Thanks!

[E.U.A.]

All RLE encoding is ready.
Works on both 8Bit, ch1 & ch2 and 16Bit modes.
Well... It works pretty good.

Future plans:

• Dynamic buffer allocation. We don't need RLE buffer if RLE is not used. Also not need so big DMA buffer in RLE mode since it just capturing.
• Dual core encoding. Using second core will reduce RLE encoder time and make it more stable. Because it takes ~24k for 2k samples, which is barely enough for 20Mhz with inspecting 10mhz clocks.
• Try to use WROOVER modules PSRAM for increase RLE capture storage.

[jgustavoam]

Hi EUA,

I'm sorry for the lack of my feedback. But after my vacation, I am involved in a complex service to change a USB library used on a Linux system. As soon as possible I will do tests with your project. Thank You.

[jgustavoam]

First Test - promising results!
Congratulations EUA!

I confess that I had a little trouble figuring out how to use the Logic analyzer. But I did!

Summarizing my environment and settings:

ESP32 Dev Kit (38 pins) - Arduino IDE 1.8.10
ESP32 Arduino FW version 1.04
ESP32 Board settings:



In the code of the ESP32_LogicAnalyzer.h file, I made this change:
#define USE_SERIAL2_FOR_OLS 0 // If 0, UART0 = OLS and UART2=Debug (It worked)


PulseView - version 0.4.1 (64 Bits)
Connecting to ESP32 :



I used an Crystal Oscillator of 1.3025 MHz to test Logic Analyzer - connected to pin GPIO4 (Channel 4) :
The frequency reading was almost precise. The 128K Buffer was not found.

[jgustavoam]

If let say enable GPIO7 for input 7, than ESP32 crash due SPI pins try to communicate with flash while occupied for input. You can select any GPIO pin that you want to use instead of -1 or 7.
Also setting them -1 does not make that pin floating but low...

I think the new ESP32-S2 will meet our needs, having 43 GPIOs ! I am waiting for this.

Espressif Announces the Release of ESP32-S2
https://www.espressif.com/en/news/espre ... -wi-fi-mcu

[jgustavoam]

More Tests and suggestions:

IMPORTANT - To get a connection to Pulseview, I used a button connecting the GPIO 15 to the ground. During boot, I press this button (as recommended by ESP_Sprite).

My ESP32 Dev Kit board uses the ESP32-WROOM32 module. So I can use more pins. We know that some pins are reserved for use, and cannot be used. Some are used for connection with Flash memory, for example.

Today I chose 16 pins that I tested, one at a time successfully.

My table of Channels x GPIO is :



I change this table at ESP32_LogicAnalyzer.ino

Code: Select all

 // do not use pins mentioned in the comments. These are reserved

  cfg.gpio_bus[0] = 0;
  cfg.gpio_bus[1] = 4;            // GPIO 1 = UART 0 - TXD 
  cfg.gpio_bus[2] = 12;
  cfg.gpio_bus[3] = 13;           // GPIO 3 = UART 0 - RXD 
  cfg.gpio_bus[4] = 14;
  cfg.gpio_bus[5] = 15;
  cfg.gpio_bus[6] = 16;           // GPIO 6 = Flash SPI SCK
  cfg.gpio_bus[7] = 17;           // GPIO 7 = Flash SPI SD0

  cfg.gpio_bus[8] = 18;           // GPIO 8 = Flash SPI SD1
  cfg.gpio_bus[9] = 19;           // GPIO 9 = Flash SPI SD2
  cfg.gpio_bus[10] = 2;           // GPIO 10 = Flash SPI SD3
  cfg.gpio_bus[11] = 21;          // GPIO 11 = Flash SPI CMD
  cfg.gpio_bus[12] = 32;
  cfg.gpio_bus[13] = 33;
  cfg.gpio_bus[14] = 34;
  cfg.gpio_bus[15] = 35;

This is the signal of test :



EUA , you are correct, the GPIO23 is at 20 MHz, when I select this sample rate.