• Content Count

  • Joined

  • Last visited

  1. I have been looking into both the Macronix and Micron flash chips over the last few days to understand their similarities and differences, and I have a pretty good idea now about which functions work the same, and which work differently between the two chips. For what it's worth, these are my findings. I hope it may be of use. The following commands work the same: READ ( 03h), no dummy cycles between address and data. DREAD (3Bh), needs 1 dummy write (8 cycles) between address and data. FREAD a.k.a. FAST READ (0Bh), needs 1 dummy write (8 cycles) between address and d
  2. Hi Atilla, Thanks for trying. On my side, I tried with Adept Runtime 2.20.2, and I still see the same behavior. To be able to properly debug, I wrote a C program that can be used to test the behavior, see here: On my Linux system, with 2 AnalogDiscovery 2 devices connected, I get this: $ ./dwf_openflag_issue list SN:210321AD644B --> 0 SN:210321AA214B --> 0 Next, I open two terminals and open both devices, using './dwf_openflag_issue SN:210321AD644B' and './dwf_openflag_issue SN:210321AA214B', respectively. The p
  3. On the two machines I tested, I have been using version 2.19.2 of the adept runtime. I'll be back in the lab early next week, upgrade the package, and re-run the test.
  4. Hi Attila, Thanks for the info. Nice to understand what's going on behind the curtain with the shared memory, it helps me to understand the issue. > However a stuck flag does not prevent an app to connect to a device. Are you sure? My test suggests that it does prevent re-opening by another process. I have four devices open, and kill one; it is then still listed as "in use". When I try to open that same instrument after the kill, I get: error (1): 'The device is being used by another application.\nDevice programming failed.' Best, Sidney
  5. Hi, We have a measurement setup with multiple Analog Discovery 2 units hooked up to a single Linux computer. The AD2 units are used by separate processes. If multiple processes have opened AD2 devices, and one of them terminates without explicitly calling 'FDwfDeviceClose' (e.g. due to a hard KILL signal), that device remains unavailable, i.e., FDwfEnumDeviceIsOpened() returns 1 in its pfIsUsed parameter, even though the device is not in use anymore. The only way I found to make such a device available for use again is to terminate all other programs that control an AD2 dev
  6. Ok, found the problem after reading this post, which described sort-of similar problems: If I install the latest beta version (3.13.22 beta) the DD devices work as expected (generated frequency within ~ 10 ppm). Also, the input side (sampling an externally generated clock) is much more stable. So it seems to be a firmware bug in the current 'official' release which is fixed in the beta. Hopefully a new official release will be out soon.
  7. Hi all, I am seeing an issue on multiple Digital Discovery devices, where the timing precision is off by over a percent (where I'd expect 10—100ppm, at least 2 orders of magnitude better). The problem can be seen most easily by having the device generate a simple 50% duty cycle clock on one of its output pins, e.g. 1 kHz. On two different Digital Discovery devices I tested, the scope reports a frequency of below 990 Hz. The signals otherwise look as expected (good level, stable, good edges) apart from the bad frequency behavior. I confirmed the measurement with a high-quality Ke
  8. Thanks, that works like a charm! I am now limited by the OS's handling of USB, I think, which means I can set DC values at up to 1 kHz (or slightly below if the OS is busy), and settling time is < 100ns. That exceeds the performance we'll be needing with some margin to spare. Great.
  9. Hello, i am trying to use an Analog Discovery 2 in a Python-based control system. Specifically, I want to use its first analog output channel to set a control voltage, based on some (independent) sensor, approximately like this: CHANNEL1 = 0 while True: x = get_sensor_value() v = 0.1 * (x - 2.0) analog_discovery.setvoltage(CHANNEL1, v) I want to do this as fast as possible; and I want the transition of the AD's channel 1 voltage to be glitchless and as-fast-as-possible. I tried two approaches: - Keeping the channel IDLE, and manipulating the offset of the Carr
  10. Thanks for the answer, indeed it is no big deal to save this state myself. I was mostly just curious if there was a solution. I will write an email with my comments about dwf.h. Thanks a lot for your assistance.
  11. I tested the solution with the new beta, this works -- thanks a lot, it saves us a lot of hassle. It is necessary to set the "OnClose" parameter before doing the open. Am I correct in understanding that the "OnClose" parameter is now also inspected while opening a device? If so, this makes the name of the parameter a bit of a misnomer, of course.. Is there a way to get the currently programmed and active value of the DC offset through the API, after opening a device without a reset/reconfigure? As a last remark: I made a pretty eleborate Python binding to libdwf, which I
  12. Hi Attila, That's great! Will this feature be available in upcoming stable releases as well? For my application I need a 64-bit Linux version. Best regards, Sidney
  13. Hi, I have a question about the Analog Discover 2. I am programming it using Python. When you close a device, it's possible to keep the device running by setting the "OnClose" parameter on the device. This is useful, e.g., when the AD2 is part of a larger measurement setup. I use it in this way to set a DC voltage on the AnalogOut device. However,. when you later re-open the device, it resets the AnalogOut device, setting the output level to 0V. Is there a way to prevent this resetting behavior at open time (analogous to preventing resetting of the device at close ti