photo by square wave, a period equal to two.
more complex signals will have a different picture, completed yet this mode will show some examples. (low - black, the higher the level of the lighter, and so to White) like the TV
This sounds all intriguing. However, where is chip’s code?
Medically it qualified as eksgibitsianizm or narcissism .
No profit to me nor to others.
He seems to be playing in a game “Look what I have implemented! Like it? Then implement it yourself! I will not share it with you!”. What to think about him everybody can decide himself/herself.
I liked the idea of his “VIDEO” mode (“function for finding the period”), so I probably implement it or something similar when I have some free time.
For now I’m busy working on my own version of firmware. At first I just wanted to fix few bugs in marcosin’s version, but unfortunately after compilation with gcc it didn’t work properly, and there was too many warnings and problems anyway, so I decided to rework everything in my own git tree (cloned from github.com/tmbinc/dsoquad ) by writing relatively small patches, looking at marcosin’s work as useful reference or example. Of course, when I’m done (probably take few weeks because of limited free time), I will share my version with everybody (including my git tree - the source code).
Thanks a lot, Liss
So, I’m sure, there are more adequate people than chip
In a short while I’ll share a USART INT plugin.
I understand chip´s point of view. I think all of us can have your point, and accept it or not accept it, but it is not the case to offend someone, only because you don´t accept your point of view.
Some things marcosin implemented are awesome, like using all the display to view the signal. Maybe someday chip will share his firmware.
I also downloaded the Jack changes to Single mode operate correctly, and is extremely useful.
On another thing, currently I used my DSO to get all parameters to a small DC motor, to do the model on Matlab. I used the DSO Quad and a signal generator, but all the software and hardware can be implemented on DSO. Im new to programming, but is some programmer want to add this funcionality, I can share all the steps.
Sorry I did not see your code or you, unlike me, not only sources but also the work of not shown?
или вы просто тот кто любит все нашару?
Being an advocate for open SW, I always share my sources and in the very near future will upload my plug-in for USART.
я кажется знаю одного такого деятеля на Казусе…
I often use small motors in my projects, but I did not think yet about using DSO Quad for a task like this. So please share your idea in details. I do not promise anything yet, but if the idea is practical and useful (from my point of view) I will implement it (after finishing all other things I have planned to fix/add in the firmware, I mentioned them in my previous two posts).
// offtop ON
Ну как-же без русских-то ?!?! facepalm 
// offtop OFF
marcosin: Thank U for your work. But what about FPGA ver 2.6? Why do U use ver 2.22?
Kabron advice, solve this problem first before you start making your plugin
viewtopic.php?f=22&t=2584
and tell us what would make your plugin
you is not the first who promises plug-in, one has already promised to the decoder spi 
I have no problem
I began it just for fun firstly, then decide to realize my ComPort sniffer(done some years ago with PIC), but realize that it’s impossible to use hardware USART to work with digital channels. So, now it just as is: initialization, ISR, some subs. Everything works. May be will be interesting for somebody. Also may be used for debug purposes.
try checking the triggering on >115.2 for rare (1 per 1sec) packages.
for better visualization packages should differ from each other, for example swap 0x55 / 0xAA
I was not able to do so, some of my changes do not work properly on 2.6.
chip,
I have just upgraded my dso to newest official fw (2.52, 1.51) and then to your APPv2.53. Many bugs are fixed (scaling for example) and I am very happy about it, you’ve done an outstanding job.
But there still are some annoying bugs:
- Trigger problems in single mode. When timing is set below 200us/div, trigger works only like one fifth of the times.
- Annoying trigger problems above 10ms/div range: window is very narrow compared to memory depth and there is nothing on screen while it is still going through memory somewhere far away from window. My suggestion would be to simple up the sample rate, so that screen would display like 50-75% of whole memory depth.
- Timescale change problems. In v2.52 and below, there was a ridiculous bug, where you change 2ms/div to 1ms/div and signal length changes only like 10%. Now, it seems, you’ve done a workaround and simply clear signal data on timescale change. This needs to be fixed, as signal zooming is one of main features of a DSO.
Anyway, I am very disappointed by seeedstudio and their DSOQuad, as it is untrustable and unusable with current firmware. Even would like to get my money back.
It’s a good thing there are people like chip and others, that give us hope it will be useable one day.
Not my case at all. I’m working with hardware USART.
create it in the FPGA?
It’s a question or suggestion?
I’m talking about hw USART1 in STM32 chip, which is routed to CN7 connector.
this is a guess. it would be more comfortable to use cn3 or cn4. but unfortunately there are problems with the time constant of input circuits
I’m not well familiar with the FPGA itself, used resources, organization etc.
As promised, here’s my USART1 plugin. It works on interrupts, u’ll see echo typed characters on the serial line after launching.
Also I made some additions to help place the application code in any Flash partitions.
These are for IAR IDE.
Usart.zip (3.79 KB)