DSO Quad Logic analyzer application

Excellent work. The main functions work as it is necessary. There is a small problem with memory dump. If to make a choice of this point, there is a red screen. The memorydmp file is created. This file can’t be removed from a flash card (there is no access) or can’t be read, only a disk format.

Oh well, the DSO Quad’s original BIOS is not very good at removal of files or maintaining the FAT tables.



If it bothers you, just install AlterBIOS and you should be fine.

It is result with AlterBIOS.

If to reformat a disk, in the bottom line “Memory dumped to memory.dmp”. But it changes nothing. Again created file isn’t removed.

Excuse. I already got confused when that changed. I managed to read and remove the file. Now all all right.

Good day. Immediately apologize for my English, it is a translation of Google

My DSO is coming. Looked what software it is and found your program. Which I really liked. But as I see it lacks a certain functional.

Suppose that we have written bit sequence protocol I2C, This canal is standardized, so why would not immediately show how its data are transmitted.

In the program you need to do two additional menus. Namely configuration (where you can choose the data protocol wakes I2C, Uart, Spi …) and analysis. Analysis of field is used to not record an upload program while recording.

Suppose recorded what realties tone sequence. Stop the program. Chosen configuration -> Data Protocol -> Configure options (such as it is Uart baud rate, stop bit …). Then click on the button and the program analysis analyzing the recorded signal is output bit values, and data packet in HEX format.

For example (from the hand painted main principle)

[attachment=1]logic_collapse.jpg[/attachment]

And so on for each type of data.

It is also desirable to provide in the Configuration tab, which is the type of the configuration wizard, where you can describe your ducts data that will be analyzed signal. Suppose protocol RC5
[attachment=0]rc5dwg1.jpg[/attachment]
the user setting the necessary parameters. Such as duration, the change in the signal, and the time intervals was able to create a template for the analysis of the received signal. A parser to decode.

Would have made a very flexible signal analyzer

There is also a desire to attach a MicroSD card (there is a thought as it sunk into, if you’re interested too share) so that was enough for all applications and records of its configurations.



forward to criticism …

Sure. Someone just needs to program that

But who would have helped with that, I don `t know this programming language. away mou only offer testing and the concept of signal processing

I feel a bit silly for this but… I can’t figure out how to use the app. I’m trying to use it to debug an SD card library that I’m writing but nothing I do affects the signals being displayed. I can use the -/+ adjustment to zoom in and out, but moving the probe connected to Channel A from ground to Vcc (3.3V) and back to ground again does nothing.



Thanks,

David



–EDIT–

FOUND IT! Turns out, it doesn’t work so well in x10 mode. I should have known that…

Also, now that I’m using this… wow. Just… wow. This app is AMAZING. I can’t believe I have this kind of functionality AND an oscilloscope for $200 USD. The memory effeciency of your app is excellent - I love how sitting idle watching lines not change doesn’t take up any memory, therefore no triggers are needed. Just record it all! BRILLIANT!

Thanks

Further use has shown a bug. I believe it’s related to high-frequencies. I’ve taken a snapshot of the memory dump for you:





While attempting to debug a MAX3232 chip (coms were running at 9600 baud), I was getting a very high-frequency signal. I’ll ignore the “Why?” and just say, something was wrong. While reading this signal (I believe it was approaching the MHz range if not surpassing) it would periodicaly die and produce the above memory dump (as opposed to freezing and me forcing it to do a memory dump).



Let me know if there’s more information I can provide.



David

Upon reading the “oh noes” at the top, it looks like the ADC FIFO can’t be read fast enough, which would make sense since the signal was so fast. Would a better approach be to send a warning message to the user “Warning: ADC FIFO has overflowed. Output may not be accurate”, rather than forcing a restart?



If this was your plan but you haven’t had time to implement it, I might be willing to help you out with that. I have a bit of experience with TI’s LM4F series of M4 chips, so I ought to be able to help out some with an M3.

Yeah, that is correct. The way the signal capture is implemented now is a very big hack, because at the time the FPGA tools were not available.

My real plan is to implement the capture on the FPGA side.



In fact, I already have a FPGA image capable of doing this, and also a test program:

<LINK_TEXT text=“https://github.com/PetteriAimonen/QuadP … /LOGIC.FPG”>https://github.com/PetteriAimonen/QuadPawn/blob/master/Programs/LOGIC.FPG</LINK_TEXT>

<LINK_TEXT text=“https://github.com/PetteriAimonen/QuadP … iccap.pawn”>https://github.com/PetteriAimonen/QuadPawn/blob/master/Programs/logiccap.pawn</LINK_TEXT>



It should be pretty simple to integrate it. Just need to copy over some of the FPGA access code from QuadPawn and replace the signal capture part in the logic analyzer (it’s currently in main.cc). It should allow overflow-free capture up to the 4096 sample FIFO, including RLE encoding.



So why haven’t I integrated it yet? Two reasons: no time, and I have something even better in the works. The FPGA should be able to also further compress the data, which would increase the capacity and speed up display drawing. However, it is difficult…



If you can help with integrating the current version of FPGA capture, it would be very useful.

Hi jpa…



First another round of thanks for your excellent work on the DSO - I too have found your Logic Analyser a handy tool.



But on to the point… I’ve been trying to build on your fpga and pawn extensions and am finding that decreasing the sample-rate leads to overflow of the sample buffer - rather the opposite of my guess!



I wonder if you could give some indication of what’s happening in the fpga mod?



Cheers!

The block is meant to only work at 72 MHz. This is because I want to use the memory bus synchronously (it’s easier to design and to debug). This means that because the CPU always runs its memory bus at 72 MHz, the FPGA also has to run at 72 MHz. Because of the RLE coding, the samplerate should not be that important - but it could still be divided on the FPGA side if necessary.



The VHDL code is here, btw:

<LINK_TEXT text=“https://github.com/PetteriAimonen/dso-q … pport/fpga”>https://github.com/PetteriAimonen/dso-quad-logic/tree/fpga_support/fpga</LINK_TEXT>

Brilliantly generous - time to scrape the rust off my verilog and get stuck in!

Better scrape off your VHDL also unless you want to start from stratch



The verilog code from seeed is quite crappy, I wouldn’t base anything off it.

I’m finding that when two channels have an edge at the same time, I’m only getting one edge reported in the recv buffer ( first two channels hung on a single line).



I suspect this might be something to do with the edge-matcher VHDL but can’t quite see what’s wrong… Will keep digging but wondered if anyone had seen/solved this already? Or have you found this perfectly fine and I need to dig deeper into the software handling?

Hmm, so you are seeing:



1000 A0 B0 C0 D0

1001 A1 B1 C0 C0



Isn’t that exactly what should happen, the signals change at the same time => they are reported on the same line?

Hello,

has anyone tried the LogicAnalyzer on DSO Quad HW2.72 ??



thx