Hacking the Rigol DHO800/900 Scope

[ejeffrey]

Are you talking about Unicode?  That has nothing to do with C vs C++.

No. C++ has its own format to store and handle text strings.

That's just... not true at all.  I don't even know what you are talking about.

[norbert.kiszka]

Are you talking about Unicode?  That has nothing to do with C vs C++.

No. C++ has its own format to store and handle text strings.

That's just... not true at all.  I don't even know what you are talking about.

So what's this: https://www.geeksforgeeks.org/cpp/strings-in-cpp/ ?

It's get even much worse in the Android NDK.

Did You ever tried to see compiled C++ code in Ghidra or any other deaasembler/decompiler?

If the C++ would be same as fast or faster than C, C it wouldn't be so popular to this day.

I ask one more time, why the most of the operating system kernels and other internals are written in C instead of "better" C++?

[ejeffrey]

So what's this: https://www.geeksforgeeks.org/cpp/strings-in-cpp/ ?

It's a C++ class that is comprised of a field and a character buffer containing (usually) ASCII data.  "Converting" to a C string is a no-op.  It's not a different encoding or anything.

And as I said, C++ strings are often faster than equivalent C code.  Because the length field is included you avoid extraneous calls to strlen(). For instance to concatenate two C strings, you have to call strlen on both before you allocate or check the destination buffer.  With c++ string class you just add two integers.  Even just strcpy has to be checking every block it reads for null values before writing to the destination.  Copying a c++ string turns into plain memcpy which is considerably faster.

Yes you can do a lot of this in C.  It won't be quite as fast, but more importantly that's not how C is written and it's not how C libraries expect strings to be passed.

[norbert.kiszka]

So what's this: https://www.geeksforgeeks.org/cpp/strings-in-cpp/ ?

It's a C++ class that is comprised of a field and a character buffer containing (usually) ASCII data.  "Converting" to a C string is a no-op.  It's not a different encoding or anything.

And as I said, C++ strings are often faster than equivalent C code.  Because the length field is included you avoid extraneous calls to strlen(). For instance to concatenate two C strings, you have to call strlen on both before you allocate or check the destination buffer.  With c++ string class you just add two integers.  Even just strcpy has to be checking every block it reads for null values before writing to the destination.  Copying a c++ string turns into plain memcpy which is considerably faster.

Yes you can do a lot of this in C.  It won't be quite as fast, but more importantly that's not how C is written and it's not how C libraries expect strings to be passed.

You just repeated yourself. As I said already, You don't have to call strlen in C multiple times. Checking null byte doesn't make it slower, because in each loop iteration You need to check condition if You need to break or not yet - doesn't matter what exact byte You have to check. But making this condition based on null is faster, because You use same memory location, instead of two.

Speaking about memory. You said class. So there is a at least one object. This object after compilation is a nothing else than malloc (which is not called directly, but instead unnecessary wrapper is used without any reason), which is passed to every method (function in the machine code) - which makes it even slower.

Im pretty sure You didn't tested in reality and You didn't tried to modify compiled code - after those two it's perfectly clear why C is faster and why it's so popular to this day.

Most of the C++ and Java users are like a sect or a Jehovah's Witnesses. Huge confirmation bias - no mater what proof You will provide, it will be always worse at each try.

[baciocco]

Everyone’s debating whether C or C++ is faster… Meanwhile, my Visual Basic “Hello World” finishes before you guys even finish compiling. 😎

[Fungus]

Speaking of the bad code, there are a lot of people using too much try-catch blocks and other C++ things, which ends up as a much slower app than it should be.

You haven't understood the single most powerful feature of C++ - stack unwinding ("RAII").

Try-catch isn't fro null pointer exceptions, it's for freeing all the temporary memory allocations when you're six functions deep in a complex file parser and you have an unexpected end of file.

(or things like that)

Checking all the error return codes and freeing your C strings would be a bug-prone mess in that situation. Lines of code could easily double.

[baciocco]

I don’t really understand much about coding, but I imagine that low-level code is usually more efficient than high-level code.
The problem is that you really need to know how to use it properly.
I guess a program written in C or C++ would still be less efficient than one written in assembly, for example — but the real issue is how hard it is to write and maintain.
That’s probably why, over time, programming languages became more high-level — from C to C++, C#, Java, and so on.

[gerbay]

C/C++ code written for superscalar processors is more efficient than assembly code. A compiler can optimize parallel pipelines to a degree that assembly programming cannot.

C/C++ code compiled by a good compiler runs more efficiently on superscalar processors than code written in assembly language.

Nowadays, even microcontrollers have parallel pipelines. For example, ARM Cortex-M7s.

[eurofox]

C/C++ code written for superscalar processors is more efficient than assembly code. A compiler can optimize parallel pipelines to a degree that assembly programming cannot.

C/C++ code compiled by a good compiler runs more efficiently on superscalar processors than code written in assembly language.

Nowadays, even microcontrollers have parallel pipelines. For example, ARM Cortex-M7s.

That is the reason why RISC processors are invented, they are dedicated for compiler code, of course you can program them in assembly but due to the restricted instruction set it is not optimal.

[gerbay]

You're talking about something different. What I'm talking about is that on superscalar processors, compilers can generate code that makes highly optimized use of parallel pipelines. It's very, very difficult for an assembly programmer to do this at the compiler level. Therefore, C/C++ code can be much more efficient for these architectures. This is different from whether the processor is RISC or CISC.

[Fungus]

I don’t really understand much about coding, but I imagine that low-level code is usually more efficient than high-level code.

Only for small tasks.

Real speed these days comes from algorithms and data structures, being able to massage and reorganize your code after profiling it. C++ absolutely destroys C there.

It's also much faster to write, you're not constantly re-implementing linked list, by hand, etc.

C just doesn't scale well, either. You simply run out of names for functions after a while, or have to start putting type names in the functions themselves. Objects/classes flip things around and associate function names with their data. You can have as many functions called "add()" as you have objects (more, actually) so the brain load (number of things you have to remember about your code six months from now) is much smaller in C++.

[eurofox]

​The meaning of superscalar processors is that they in one cycle execute multiple instructions but not all ARM CPUs are superscalar processors and I don't know if the CPU used in our Rigol 800/900 is from this type.
We should open another discussion about the C and C++ compiler because it is far from the hacking of the Rigol 800/900 series of oscilloscopes.

[Fungus]

We should open another discussion about the C and C++ compiler because it is far from the hacking of the Rigol 800/900 series of oscilloscopes.

It's a discussion that's been going on since the 1990s.

I'll just go back to my earlier assertion:

My question for C programmers is, "why don't you write everything in assembler?"

Whatever they answer I then say, "...and that's the reason I use C++ instead of C".

(Note: I started in hexadecimal and went  hexadecimal -> assembler -> C -> C++ )

[gabiz_ro]

That topic become x vs y.
Let's go back to DHO series

[mrisco]

I just realized that Rigol has copied the modified user interface I created for the DHO800/900 series in their “Limited Edition” oscilloscopes, the MHO98 and MHO900. As Charles Caleb Colton said: "imitation is the sincerest compliment".

https://www.batterfly.com/shop/en/articoli-blog/rigol-mho900-presentazione



And they are using the full screen bottom bar from @AndyBig

[bkw]

"GPL is not a legal license in the sense that one could be sued for not following it."

What the what? Exceedingly incorrect sir.
Someone somewhere failed horribly for you to be left with this impression.
The whole point of the GPL is exactly and explicitly to employ the very same legal machinery and principles of ownership and copyright that protects commercial software and literature and artwork, to protect free software.

Breaking the GPL is absolutely breaking a real law just exactly like violating any other copyright.

Something like say quickbooks has terms governing your right to use it. The terms are you have to give them money, you can't redistribute any copies, you for damned sure can't *sell* copies, etc.

Gnucash also has terms. They are different terms, but they are the terms, set by the author(s), using the exact same legal machinery and principles as any other intellectual property.

It doesn't matter if you are violating quickbooks terms or violating gnucash terms, all that matters is that you are violating the copyright of the material.

Merely, probably no one has the time or money or motivation to go after someone violating gnucash copyright because it would be a lot of effort and essentially no reward, unless the offender is making a lot of money from it, like if it turns out quickbooks is actually the one stealing gnucash code. So, sure, probably you will usually *get away* with it, but that is just getting away with it. You can absolutely get sued at any moment, if anyone with an interest in the violated code simply finds out about it and decides it's worth their time to persue it.

[dzebrys]

look at the knobs, all-same fronthaul as dho series, just silverish shining.
this potentially means Norbert could push DHO further into stable 800Mhz/4GS/500Mp/100Mhz AGF
looking forward to Dave's teardown

[eurofox]

look at the knobs, all-same fronthaul as dho series, just silverish shining.
this potentially means Norbert could push DHO further into stable 800Mhz/4GS/500Mp/100Mhz AGF
looking forward to Dave's teardown

​Next week I will get my gold shiny oscilloscope with all options enabled with no need of hacking.
I sold my 924S.

[harha]

Hi Norbert
Your crack works great !!
You mention you have made a gel file to return the machine back to original    setup---where can i get it ??.
Regards
Hardy

[kd7eir]

Hi Norbert
Your crack works great !!
You mention you have made a gel file to return the machine back to original    setup---where can i get it ??.
Regards
Hardy

It should be right where you downloaded the regular file.

[eTobey]

Its quite a shame, that the enduser is essentially doing quite a bit of work for the product, that the enduser PAID FOR. And receiving NOTHING for it. At least i did not receive a single cent for quite a few hours i spent, figuring out bugs and try to make Siglent aware of it.

I just realized that Rigol has copied the modified user interface I created for the DHO800/900 series in their “Limited Edition” oscilloscopes, the MHO98 and MHO900. As Charles Caleb Colton said: "imitation is the sincerest compliment".

Have you been paid for the work?

[mrisco]

Have you been paid for the work?

Of course not, although I do not lose hope that I will receive a MHO98. 

[Randy222]

Wow, this thread has legs.
I think I left it back on page 60 or so.
I still have one of the Andy hacks installed.
Has Rigol released anything stable as of late?

[mrisco]

It has been released, better than the MHO98 interface in your DHO800/900 device!

Features :

• Full Screen mode with informative bottom bar and clickable elements
• Special A(ction) button to launch the DHO Actions application
• Included a configurable DHO Actions panel that allows to execute SCPI commands, launch applications (Python scripts with PyDroid) and open web pages in the default browser.
• Included DHO visor, allows to display the screen streaming in scaling mode.
• Unlocks extended decoders like LIN, FlexRay, I2S, 1553B
• All DHO series have bandwidth unlocked to 250MHz and Memory depth up to 50M
• Ultra Power Analyzer unlocked for all DHO series
• Enabled advanced settings in XY mode with real functions.
• Compact unified Horizontal bar, Trigger bar and Channel widgets
• Dock/Undock of the Result Bar
• Compact Result / measurements bar with optimized rendering
• Probe attenuation in channel widget
• Trigger coupling indicator
• Better rendering of the chanel scale labels, so they can be readed always no matter what the back color is.
• Automatically show date-time at boot if it is valid
• Start menu settings button allows to open Android system settings
• Fixes alignment of visual elements, color and transparency corrections
• Better UI organization for improvement of screen size utilization
• Code enhancements, removed extra logging for better general performance
• Fixes for bugs reported by the community
• Normal and System versions

[eTobey]

How stable is the Rigol running with Android? Does it get sluggish at some time, or does it crash sometimes?