General > General Technical Chat
The Rigol DS1052E
rct:
--- Quote from: EEVblog on April 08, 2010, 10:58:59 pm ---I think it's not very feasible that there is a technical difference between using USB or serial.
--- End quote ---
I may not know much about hardware, but that's a bad assumption when it comes to software. I can see many ways that the code paths in the firmware between handling serial input and USB input can be different. Even forgetting that, the byte stream the computer sends to the scope can be very different depending on whether it is line based or character based.
Unless the terminal emulator has been set into a line buffered mode, every character typed will be sent as it is typed. So if you type *, I, D, X, <backspace>, N, ?, <newline>. It is up to the rigol to interpret the backspace, erase the X and leave the pointer there. It doesn't do that, so the input buffer contains *IDX<BackSpace>N?. When it tries to interpret that it will be considered an invalid command and be ignored (doesn't match the stored string). If you type *IDN?<return><newline>, it will also ignore the input as not valid (again the string compare that it is likely doing doesn't match)
Here's a test you can do to see how the "parser" is behaving. First disable local echo, so it doesn't mislead you about what you are sending to the scope. When you type a command like *IDN? to the scope and hit alt-010 to get a newline, after the response text, the cursor goes down one line and does not return to the left edge of the screen since there is no carriage return. To see that the scope's serial parser will add happily control characters to the parameter buffer try entering :IO:TEST testing<return><newline>. The scope will echo "testing", a carriage return, and a newline, so the cursor should now be on the left in column 0. If you have local echo off, the carriage return came from the rigol, showing that it was part of the input buffer that was echoed back. Now type :IO:TEST abc<return>testing<newline>. You will see testing. (the abc if the cursor was started column 0 was echoed but was written over on the screen by "testing". The carriage return was stored in the middle of the buffer.
So using a terminal emulator (especially with local echo turned on) it's entirely possible people could be writing very long strings like :INFO:MODEL DS1052<bs><bs><bs>1102e<bs>D<cr><bs>
I just checked the video, you don't say you can't hit backspace while typing. Of course during the video you typed the strings perfectly.
So You should probably warn people they can't make any mistakes while typing these commands. I suppose one thing people could do would be to type the commands into Notepad, verify they are correct and then very carefully copy & paste one line at a time I don't see a line buffered or "cooked" mode for hyper terminal.
I can't think of a safe way to abort the command entry once you've started typing. The safest thing I can think of is to enter the newline to end the command early so it will be a short string and then start over, *without* rebooting the scope until the bad input has been corrected.
dimlow:
well, i just confirmed that long strings are not the problem. As my scope is buggered, i just set my serial and model no to 123456789123456789123456789123456789123456789123456789
*idn? responds with
Rigol Technologies,123456789123456789123456789123456789123456789123456789,123456789123456789123456789123456789123456789123456789,00.02.02.02.00
but the system info screen now shows model as 123456789123456789123456789123456789123456789123456789
and the serial no surprisingly is now showing DS10000001
if i do another *idn? after a reboot i still get the same as above, so im now thinking the serial that is displayed on screen, is not stored as a string but is decoded from the string you send it. but still that string is stored and retrieved from memory when you do *idn? or :info:serial?
long sting lengths dont seem to be the problem here, i think maybe it has something to do with my scope crashing whilst setting the model or serial no, pretty sure its nothing to do with string lengths
EEVblog:
--- Quote from: rct on April 09, 2010, 12:06:53 am ---
--- Quote from: EEVblog on April 08, 2010, 10:58:59 pm ---I think it's not very feasible that there is a technical difference between using USB or serial.
--- End quote ---
I may not know much about hardware, but that's a bad assumption when it comes to software. I can see many ways that the code paths in the firmware between handling serial input and USB input can be different. Even forgetting that, the byte stream the computer sends to the scope can be very different depending on whether it is line based or character based.
--- End quote ---
I was assuming that Rigol would simply implement a standard USB to serial converter in there somewhere, and use the serial interface (from RS232 or USB) as the lowest common denominator interface. From a design point of view that would reduce the need to code two entirely separate serial interfaces. But I have not looked into this at all, so they could very well be entirely different beasts.
Dave.
EEVblog:
--- Quote from: rct on April 09, 2010, 12:06:53 am ---So You should probably warn people they can't make any mistakes while typing these commands.
--- End quote ---
I've added a note to the blog page. It's not possible to update the video.
--- Quote ---I can't think of a safe way to abort the command entry once you've started typing. The safest thing I can think of is to enter the newline to end the command early so it will be a short string and then start over, *without* rebooting the scope until the bad input has been corrected.
--- End quote ---
FYI
I actually had several attempts at it before I got it to work, I accidentally pressed ENTER and backspace etc too several times, and even switched the unit off half way through. Several times it model number would not stick after the reboot.
But like I said, I had no issues at all, hence there was no warning in the video as there did not appear to be any risks at the time. And maybe there still isn't any risk, perhaps it's something else entirely as Dimlow suspects?
Dave.
rct:
--- Quote from: dimlow on April 09, 2010, 12:43:22 am ---well, i just confirmed that long strings are not the problem. As my scope is buggered, i just set my serial and model no to 123456789123456789123456789123456789123456789123456789
--- End quote ---
I think all that proves is that there is no bounds checking in the way the command is implemented, and that the string is read out as a string with a terminator (probably null) instead of a fixed length.
I think the question is now that a long string has been written has any of the scope's behavior changed? (after a reboot)
The affect of writing the longer string depends on how the flash/nvram memory is organized and updated. If that was a fixed string size it overwrote something immediately after it. If the flash is organized as say a list of null terminated attribute value pairs that gets completely rewritten as a whole unit, it might not cause any issues if there is enough free space in the flash. If there wasn't enough extra space possibly something could fall off the end.
We'll know a lot more if anyone determines a method for reading the contents of the flash/nvram. Maybe with a bus pirate... but that's a different blog...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version