- #SAINSMART OSCILLOSCOPE ASSEMBLY FULL#
- #SAINSMART OSCILLOSCOPE ASSEMBLY SOFTWARE#
- #SAINSMART OSCILLOSCOPE ASSEMBLY CODE#
Obviously more experimentation needed on my part. The 240kHz mode is shown in the second two. "Normal" mode is shown in the first two attachments. It also invokes a completely different GPIF setup for the fifo. As noted previously, it seems to be capable of running indefinitely without dropout, but have yet to do the experiment to confirm. It does not show up on the sainsmart software, but it seems to invoke a 240kHz sampling mode when you select the slowest timebase settings.
#SAINSMART OSCILLOSCOPE ASSEMBLY CODE#
To close off one question mark (and perhaps open another ) That 94(0A) code you see is the mystery mode. More as I find it out.Ī quick reply to donut6: Yes those codes match up nicely, thank you. But again, would not need to do that on a 120.
#SAINSMART OSCILLOSCOPE ASSEMBLY FULL#
They connect the write signal to the RAM and the buffer full signal into an arduino. yet! I have tacked two wires to the pcb, I sweated a bit on that. Not sure there is much point going in there with a soldering iron. First thing I would do is to see how much the hardware differs from other designs (links somewhere in this thread).
I expect it uses the GPIF state machine, and are really going to need some level of circuit schematic. That is not to say that the 120 is going to be easy. No keep with the 120 guys, I wish I had brought it instead.
As to the hardware we are discussing, again I would not recommend the DDS140, the CPLD is still a complete black box to me, and if I can it will stay that way. There are plenty of code examples out there too. It seems about the only game in town for simply moving large amounts of data of USB. END EDIT Except for the 200M single channel :-//mode, which I have not checked, I think the 140 always sends both channels, even with only one selected. And note that it changes state machines dependant on that input parameter. I now know for example that the 94 command is perhaps the most dangerous of all the DDS140 commands:- it reloads the GPIF state machine and transfers its input parameter to Port A for some reason yet to be determined. I really need to review your mega post more carefully and document more clearly the DDS140 codes. As you have been saying, data just comes out of the thing when it wants to. EDITAnd Doctormord:- finally looked at your wireshark trace for the DDS120, these really are very different machines. And as per Doctormords comment "Indeed, it always sends data from both channels, as i'd shown some posts before", interrupt mode puts no obligation on the host to actually read the data. Where XP and the app spend the next 94mS, I do not know! And in agreement with Ganzuuls comment note interrupt, not iso! This I have checked with the start up parameters in the firmware. This gives each (DDS140) block of 2¹? bytes a transit time in of around 6mS. Maximum theoretical throughput is then 3x1024x8x1000 or a bit less than 24Mbps. These are re-assembled by the host into a complete message. Against the USB 2 standard, it can send up to 3 interrupt packets (each up to 1024 bytes) in each of the 8 available microframes that make up a millisecond. Initial negotiation between host and FX2 permits the FX2 to send interrupt packets. My reading of it and USB standards are as follows (but I need to check for fundamental differences between the DDS120 and 140). I think that the DDS120 and 140 are very different beasts, excepting that they both seem capable of continuous running at 240ksps (Thanks to both of you on that one) Ganzuul. On the DDS140 the device itself does not notice that it has a buffer full until the 50 command prods it into checking, when the data comes flooding out again.
#SAINSMART OSCILLOSCOPE ASSEMBLY SOFTWARE#
When I stop/start the trace, all the software in the PC does is stop sending 50 (status) commands. At that rate there appears to be no data loss (TBC) However the display software is useless! So continuous data logging at 240ksps looks as though it may be possible after all on the DDS140. At these slowest of rates, the data capture rate rises to 240ksps and the hardware buffer full flag (C.6) never registers full. except when I switch the timebase right down to 500mS or 1 Second. What I said about data capture on that device remains true, nearly! As I wind the timebase down, the sampling rate goes down from 100M, 10M, 625k and finally 39k. It is clear that the scope firmware is pretty random:- I see the same stuff as you some of the time and not others, and I do not think it is us! A couple more little snippets, both DDS140 of course. " 100% agree Guys: You have posted loads, which I will read more thoroughly in the morning, I need some sleep. "if this is simply the state the software was in when time ran out for the dev.
0 kommentar(er)
