Wondering, last week, I was doing some captures of SPI data, and kept loosing the data at the start of the capture?
I was trying out about 6 different approaches on how to use Zephyr on an Arduino UNO Q to solidly fill an ST7796 with a color, to see how I might be able to increase the SPI throughput.
Did something change in this last release (or two)? As I don’t remember hitting these limits before when doing similar captures.
I finally figured out I needed to change the buffer size
I don’t think anything changed with this, but we’ll check.
Also, it’s worth mentioning that memory used by digital channels and protocol analyzers is dependent on the density of data recorded.
For example, recording 9600 baud UART or I2C will sip memory. These types of signals can easily be recorded for hours or even days with fairly low memory usage.
The digital sample rate is not a factor. We only store the transitions in the digital data in memory, so only the number of transitions recorded is relevant.
High Speed SPI (e.g. > 1 MHz clock) can consume memory very quickly by comparison. Also, the protocol analyzers, which also consume memory proportionally to the amount of results decoded, will often consume memory many times faster than the raw digital data itself.
If you’re used to not worrying about the buffer limit, but then try recording some 10 MHz SPI traffic that has high utilization, you may find yourself reaching the default 3 GB memory limit in a matter of seconds. We do a lot of stress testing with high speed SPI data for this reason.
The parallel analyzer is generally the only protocol analyzer that’s worse. we have users recording 10 MHz+ parallel ADC busses, which burns through memory even faster.
To be honest, the buffer limit in Logic 2 really needs work. It’s main purpose was to just make sure that the software wouldn’t run the system our of RAM, which was a serious problem with Logic 1. In the case of Logic 1, we invested quite a bit in trying to handle the case of actually running out of RAM, but it would only take action once allocations started to fail, at which point things start to behave in unpredictable ways.
Really what we need is functionality that does the following:
Sets easy to understand expectations for the user about realistically how long they can record for. (this includes explaining that digital utilization affects memory usage, and shows examples w/ slow, medium, and high speed digital signals)
Offers a way for the user to just disable the limit, because the limit isn’t realistically calculable (Best case it’s approximately total RAM size + free disk space, worst case, the app will crash as soon as physical memory is exhausted, even if Logic 2 is only holding a small fraction of it)
Not crash, and instead gracefully handle running out of memory.
We’re running into this even more now with Logic MSO, especially since w/ all 4 channels enabled, the 1B sample units have more hardware buffer than the default software buffer, creating a pretty terrible experience by default. We’re going to improve this soon.
