| ID |
Date |
Author |
Subject |
|
434
|
Fri Jun 19 12:32:10 2015 |
Gregor Kramberger | drs 5.03 and windows 8.1 |
| Gregor Kramberger wrote: |
|
I have problems with driver installation on windows 8.1 (software version 5.03). I have sen that that has been an issue before (driver signing) and I would like to know if this has been solved. We run several DRS4 evaluation boards on different PCs all running Win7 without any problems. Therefore we are almost confident that it is related to Win 8.1. Thanks.
|
Solved. Need to restart Windows 8.1 (64 bit) in recovery mode and dissable driver signing as mandatory. Then it works fine. |
|
581
|
Fri Jan 13 12:58:22 2017 |
Gregor Kramberger | DRS software doesn't work under Windows XP SP3 |
Hi all
I have a problem with running the DRSOSC under windows XP SP3. We have some hardware which is not supported under newer versions of windows and we would like to use DRS boards along it, therefore we would higly appreciated any help in that direction. We have installed the software (V 5.03) to two different XP machines and got the same problem. The driver installs without any problem, but when the drsosc is run the system says " drsosc.exe is not a valid Win32 application". We have developed our own API for our software which also doesn't recognize the board. It says on the www page that it has been tested for windows XP, but I would appreciate if you can verify it? With best regards and thanks... |
|
593
|
Mon Apr 10 08:50:11 2017 |
Giovanni Bruni | drs4 registers behaviour |
Hej everyone!
I have some questions regarding what happens to some DRS registers in some scenarios:
1. How are the registers affected by a RESET? According to the data sheet all the CONFIG REGISTER bits are initilialized to 1. But what about the WRITE SHIFT and the READ SHIFT registers? Are they affected somehow after a RESET has been applied?
2. Suppose the DRS is happily running and I have done some readouts in ROI mode, so that the only "1"-value bit in the READ SHIFT register is in a random position. If now I want to execute a FULL READOUT, should I use the procedure explained in the data sheet (figure 11) for the FULL READOUT mode? or is this procedure useless since my "1"-value bit is already set somewhere in the READ SHIFT register and therefore a ROI readout of 1024 cells would be the solution (and getting the initial position from the SROUT pin)?
Thanks a lot!
Have a nice day!
Giovanni |
|
596
|
Mon Apr 10 13:41:41 2017 |
Giovanni Bruni | drs4 registers behaviour |
Hej Stefan! Thank you for your answer!
Just to be sure to have understood properly:
1. Using the RESET line should be avoided. And in any case, the CONFIG register and the WRITE SHIFT register need to be initialized "by hand" using the A0-A3, SRCLK and SRIN pins. Is it correct?
2. Doing the procedure shown in Figure 11 will always inject a "1" in cell #0 of the READ SHIFT register, regardless if (before starting the procedure) there was a "1" in any other cell, right?
Thank you!
Giovanni
| Stefan Ritt wrote: |
|
Using the RESET line to reset registers is not a good idea since it can have some bad side-effects. The READ SHIFT register is NOT affected by RESET, so you have to inititialize these registers differently. To set a "1"-value at a defined position, you have to follow figure 11 in the data sheet. Once you executed that, your "1" is always at the same posiiton (namely cell #0), so after 1024 clock cycles you arrive at the same state, and do not have to re-do fig. 11 again.
Stefan
| Giovanni Bruni wrote: |
|
Hej everyone!
I have some questions regarding what happens to some DRS registers in some scenarios:
1. How are the registers affected by a RESET? According to the data sheet all the CONFIG REGISTER bits are initilialized to 1. But what about the WRITE SHIFT and the READ SHIFT registers? Are they affected somehow after a RESET has been applied?
2. Suppose the DRS is happily running and I have done some readouts in ROI mode, so that the only "1"-value bit in the READ SHIFT register is in a random position. If now I want to execute a FULL READOUT, should I use the procedure explained in the data sheet (figure 11) for the FULL READOUT mode? or is this procedure useless since my "1"-value bit is already set somewhere in the READ SHIFT register and therefore a ROI readout of 1024 cells would be the solution (and getting the initial position from the SROUT pin)?
Thanks a lot!
Have a nice day!
Giovanni
|
|
|
|
598
|
Tue Apr 11 09:07:33 2017 |
Giovanni Bruni | drs4 registers behaviour |
Thank you Stefan for replying!
I have still the RESET issue in mind: how would you suggest to reset properly the DRS? Is there a particular procedure to follow instead of just sending a negative pulse to the RESET pin? Is it preferable to turn the DRS off and then restart?
Thanks!
Giovanni
| Stefan Ritt wrote: |
|
1. WRITE SHIFT register and CONFIG registers are initialized to "1" on power up, but if you want to change that, use A0-A3 etc. as you indicated.
2. If you address the READ SHIFT register by applyin "1011" to A0-A3, the input of the register is connected to SRIN. So in fig. 11, you apply 1023x"0" plus 1x"1", which effectively clears the register and keeps one "1" at the last position, so on the next rising clock this gets shifted into position #0. If you do the readout, and NOT addresing the READ SHIFT register, then the input of that register is connected to it's output internally. Therefore the single "1" keep rotating on every 1024 clock cycles.
| Giovanni Bruni wrote: |
|
Hej Stefan! Thank you for your answer!
Just to be sure to have understood properly:
1. Using the RESET line should be avoided. And in any case, the CONFIG register and the WRITE SHIFT register need to be initialized "by hand" using the A0-A3, SRCLK and SRIN pins. Is it correct?
2. Doing the procedure shown in Figure 11 will always inject a "1" in cell #0 of the READ SHIFT register, regardless if (before starting the procedure) there was a "1" in any other cell, right?
Thank you!
Giovanni
| Stefan Ritt wrote: |
|
Using the RESET line to reset registers is not a good idea since it can have some bad side-effects. The READ SHIFT register is NOT affected by RESET, so you have to inititialize these registers differently. To set a "1"-value at a defined position, you have to follow figure 11 in the data sheet. Once you executed that, your "1" is always at the same posiiton (namely cell #0), so after 1024 clock cycles you arrive at the same state, and do not have to re-do fig. 11 again.
Stefan
| Giovanni Bruni wrote: |
|
Hej everyone!
I have some questions regarding what happens to some DRS registers in some scenarios:
1. How are the registers affected by a RESET? According to the data sheet all the CONFIG REGISTER bits are initilialized to 1. But what about the WRITE SHIFT and the READ SHIFT registers? Are they affected somehow after a RESET has been applied?
2. Suppose the DRS is happily running and I have done some readouts in ROI mode, so that the only "1"-value bit in the READ SHIFT register is in a random position. If now I want to execute a FULL READOUT, should I use the procedure explained in the data sheet (figure 11) for the FULL READOUT mode? or is this procedure useless since my "1"-value bit is already set somewhere in the READ SHIFT register and therefore a ROI readout of 1024 cells would be the solution (and getting the initial position from the SROUT pin)?
Thanks a lot!
Have a nice day!
Giovanni
|
|
|
|
|
|
564
|
Fri Nov 18 16:38:42 2016 |
Gerard Montarou | LabView |
Hello,
Did you start to write some VI to interface DRS4board with labview ?
i also have in mind to do that.I am surprised that nobody alraedy did it since there is no answer toyour question
gerard
| Christian D wrote: |
|
Hi,
I would like to use the DRS4 board with LabView for fast readout.
Do you know anyone who has written a VI for that?
Thanks,
Christian
|
|
|
717
|
Sun Sep 23 02:22:46 2018 |
Gerard Arino-Estrada | Trigger OUT pulse width variable from 100 us up to 100 ms |
Hello Stefan,
I am using the DRS4 board connected to a Raspberry PI and through the drsosc application. I am interested on using the "Trigger OUT" signal to do some extra data processing with NIM modules. According to the manual, for each hardware trigger a TTL pulse of 150 ns width should be send through the "trigger OUT". In my case I do see pulses with widths ranging from 100 microseconds up to hundreds of miliseconds. I am connecting the signal directly to an oscilloscope with 50 Ohm termination. I have tried two DRS4 boards in identical conditions and both show the same behavior. Having such wide and variable pulses makes it complicated for me to do the extra post-processing. Have you any idea of what might be going wrong? Thank you very much.
Best regards,
Gerard |
|
Draft
|
Wed Sep 26 18:25:07 2018 |
Gerard Arino-Estrada | Trigger OUT pulse width variable from 100 us up to 100 ms |
Thank you very much for the answer, I really appreciate your help.
Thanks!
Gerard
| Stefan Ritt wrote: |
|
The "Trigger OUT" has changed recently. It goes high on a new trigger, but then STAYS high until the board has been read out by the PC and re-started. This allows better synchronization with some external trigger, which can be re-armed with the falling edge of the trigger out signal. The signal can be quite long, since readout of an event via USB typically takes 2 ms, but can be more if the PC is busy. If you need back your 150 ns pulse, send the trigger out to an external pulse shaper with fixed shaping width.
Stefan
| Gerard Arino-Estrada wrote: |
|
Hello Stefan,
I am using the DRS4 board connected to a Raspberry PI and through the drsosc application. I am interested on using the "Trigger OUT" signal to do some extra data processing with NIM modules. According to the manual, for each hardware trigger a TTL pulse of 150 ns width should be send through the "trigger OUT". In my case I do see pulses with widths ranging from 100 microseconds up to hundreds of miliseconds. I am connecting the signal directly to an oscilloscope with 50 Ohm termination. I have tried two DRS4 boards in identical conditions and both show the same behavior. Having such wide and variable pulses makes it complicated for me to do the extra post-processing. Have you any idea of what might be going wrong? Thank you very much.
Best regards,
Gerard
|
|
|
|
720
|
Wed Sep 26 18:28:20 2018 |
Gerard Arino-Estrada | Trigger OUT pulse width variable from 100 us up to 100 ms |
Thank you very much for the answer, I really appreciate your help.
Thanks!
Gerard
| Stefan Ritt wrote: |
|
The "Trigger OUT" has changed recently. It goes high on a new trigger, but then STAYS high until the board has been read out by the PC and re-started. This allows better synchronization with some external trigger, which can be re-armed with the falling edge of the trigger out signal. The signal can be quite long, since readout of an event via USB typically takes 2 ms, but can be more if the PC is busy. If you need back your 150 ns pulse, send the trigger out to an external pulse shaper with fixed shaping width.
Stefan
| Gerard Arino-Estrada wrote: |
|
Hello Stefan,
I am using the DRS4 board connected to a Raspberry PI and through the drsosc application. I am interested on using the "Trigger OUT" signal to do some extra data processing with NIM modules. According to the manual, for each hardware trigger a TTL pulse of 150 ns width should be send through the "trigger OUT". In my case I do see pulses with widths ranging from 100 microseconds up to hundreds of miliseconds. I am connecting the signal directly to an oscilloscope with 50 Ohm termination. I have tried two DRS4 boards in identical conditions and both show the same behavior. Having such wide and variable pulses makes it complicated for me to do the extra post-processing. Have you any idea of what might be going wrong? Thank you very much.
Best regards,
Gerard
|
|
|
|
222
|
Wed Feb 27 13:47:32 2013 |
Georg Winner | Chip Test - Cell Error |
When starting Chip Test in DRS Command Line Interface, I receive the following message:
Cell error on channel 1, cell 5: -154.4 mV instead 0 mV
Chip Error!
What does this mean? The maximal peak-to-peak Amplitude given to channel was for a short time 10V.
The graphical interface shows no artefacts when using channel 1.
|
|
228
|
Mon Mar 25 11:12:53 2013 |
Georg Winner | Differences in Source Code |
I have noticed some differences in the source code between Windows (4.0.0) and Linux (4.0.1) Version.
drs_exam.cpp: In the windows version when setting the trigger there is no part "if (b->GetBoardType() == 8) {...} else {...}" like in Linux version. So under Windows drs_exam does not start readout of DRS 4 Evalutation Board V4, because it does not get the trigger, under linux the board can be read out succesfull. I have found out, that adding the missing part solves the problem for the windows version.
drs.cpp (Windows Version), line 2101, function "int DRSBoard::SetTriggerDelayNs(int delay)":
There is no operation which calculates the variable "fTriggerDelayNs" out of variable "ticks" like in function "int DRSBoard::SetTriggerDelayPercent(int delay)" (Line 2073). So "fTriggerDelayNs" can get diverse values when using one of the Trigger Setting Functions. Was this intended?
|
|
402
|
Thu Apr 9 11:46:33 2015 |
Felix Bachmair | DRSBoard::SetTriggerSource |
Hi
I have a question about the function SetTriggerSource in the class DRSBoard (DRS.h/DRS.cpp)
In the implementation there is the following comment:
// Set trigger configuration
// OR 0=CH1, 1=CH2, 2=CH3, 3=CH4, 4=EXT
// AND 8=CH1, 9=CH2, 10=CH3, 11=CH4, 12=EXT
What does this exactly mean? I am assuming that this are the bits which are set?
e.g
source = 1 ==> CH1
source = 4352 = 0x1100 ==> CH1 and ext
How is the AND/Or logic implemented?
When i have:
source = 0x1803 (bit 12,11,1,0)
what is the right way to set the brackets to expalin the logic?
(EXT and CH4 ) or CH2 or CH1 ?
Cheers Felix Bachmair
ETH Zurich |
|
423
|
Sat May 23 11:03:20 2015 |
Felix Bachmair | Issue with Trigger rates below ~100Hz |
Hi
We are working with the DRS 4 V5 version and we investigated an issue with the trigger at rates below ~120 Hz.
As long as we have a trigger rate of more than 125 Hz. everything seems to work fine and we are recording more or less all events.
As soon as we go lower in input trigger rate to 100Hz, we see a drop in trigger rates to approx 15 - 20 Hz.
When we use the new firmware we can see that the busy signal is 0 for much longer times than usual up to .5 seconds.
We made a plot of input trigger rate vs trigger rate of drs: https://plot.ly/~simon.corrodi/316
In the oscilloscope plots one can see the the trigger in in yellow and the trig out from drs board in blue.
Do you have any idea what could be the reason?
We also |
| Attachment 1: drs_v5_newStefan_10Hz.png
|
|
| Attachment 2: drs_v5_newStefan_4Hz.png
|
|
| Attachment 3: drs_v5_500_160Hz.png
|
|
| Attachment 4: drs_5-0-0_4hz.png
|
|
|
425
|
Tue May 26 11:27:27 2015 |
Felix Bachmair | DRS4 firmware UCF constraints |
> > Hello, I'm using two DRS4 rev.5 boards for 8ch readout and triggering.
> >
> > I needed to modify the trigger logic and implement some tweaks in the firmware, and noticed that
> > the firmware source in drs-5.0.2 (and 5.0.3, SVN:5339) while still compiling fine with Xilinx ISE 10, stops
> > doing so in the ISE 14.7 (also already in 13.2)
> >
> > While the Synthesis is running through (in the new ISE it complains about using more than 100% of resources.)
> > The Mapping fails due to constraints (firmware/ucf/drs4_eval5.ucf) complaining about an illegal IOSTANDARD
> > for P_IO_PMC_USR<55> (LVDS_25).
> >
> > In the newer version the wild-cards (lines 67..69 ) are not properly dealt with, it seems, and if I move the
> > property by hand to all the wild-carded NETs it start to recognise the LVDS_25.
> > But after that Place&Route fails with messages about locked Banks due to incompatible VCCO.
> >
> > I'm trying to adapt the ucf file and am reading about the changes in the ISE software and constraints files, but
> > want to ask if some of you guys have seen the same issue and resolved it out "officially".
>
> The current firmware compiles nicely under 14.7. I attached it. It also has one modification which you probably need:
>
> When the board triggers, the TRG OUT goes high and stays high until the board has been read out and restarted. So it can be used as a "busy" signal for an external trigger logic.
>
> Best regards,
> Stefan
Hi Stefan,
Thanks a lot for the new firmware. We are testing it at the moment in a beam test at PSI (PiM1) and we realized that this doesn't seem to work 100%.
We need to extend the death time after a trigger by approx. 200 mus in order to not loose triggers.
It seems that under certain circumstances a trigger within that window is ignored.
We do a handshake after each trigger so we are able to recognize such ignored events. This can happen quite often (within the first few hundered events) when we do not increase the deadtime.
Do you have any idea what could be the reason for that issue?
Best regardds
Felix |
|
428
|
Fri Jun 5 13:15:35 2015 |
Felix Bachmair | DRS4 firmware UCF constraints |
Hi Stefan,
No we only use one evaluation board. We use the evaluation board as a part of our beam test setup. It includes a telescope based on the current PSI46V2.1 CMS Pixel chip and a trigger logic board for triggering the telescope and the evaluation board. This includes a
handshake between every device and the tlu
e.g. the tlu expects an answer for each trigger.
If the trigger comes within this first 200 mus it seems that not every trigger is accepted.
In this moment our readout would 'die' since the tlu is waiting for the handshake.
Cheers
Felix
> I presume you have several evaluation boards and want to run them in sync, right?
>
> This can be either made in daisy-chain mode (see manual page 25). In this case only the master board can trigger the slave boards. If you need to trigger on SEVERAL boards (like a coincidence between two boards), you have to do this with an external trigger and
busy logic. This is rather
> complicated and needs detailed explanations. So come to my office and I will teach you.
>
> Best,
> Stefan |
|
435
|
Thu Jul 2 08:53:17 2015 |
Felix Bachmair | Issue with Trigger rates below ~100Hz |
Hi,
We did a further investigation of this problem:
We figured out that this issue seems to be related to the kernel.
We tested it now on two machines with Ubuntu 14.04.2 LTS (kernel 3.16.0-41), one with RHEL 6.6 (kernel 2.6.32) , one with Fedora 20 (kernel 3.18.7) and one with Mac OSX. We see this issue with the Ubuntu and the fedroa machines.Both have a kernel above 3.0 while RHEL has a kernel of 2.6
We can repoduce the problem on all input channels as a trigger.
I will try to find out what could be the cause of it.
Cheers
Felix
| Felix Bachmair wrote: |
|
Hi
We are working with the DRS 4 V5 version and we investigated an issue with the trigger at rates below ~120 Hz.
As long as we have a trigger rate of more than 125 Hz. everything seems to work fine and we are recording more or less all events.
As soon as we go lower in input trigger rate to 100Hz, we see a drop in trigger rates to approx 15 - 20 Hz.
When we use the new firmware we can see that the busy signal is 0 for much longer times than usual up to .5 seconds.
We made a plot of input trigger rate vs trigger rate of drs: https://plot.ly/~simon.corrodi/316
In the oscilloscope plots one can see the the trigger in in yellow and the trig out from drs board in blue.
Do you have any idea what could be the reason?
We also
|
|
|
436
|
Thu Jul 2 13:20:51 2015 |
Felix Bachmair | Creation of Object files |
HI,
We are using the DRS4 Board in the EUDAQ framework [1]. We wrote a a Producer based on the software of the evaluation board, which is using the DRS class/header/src files.
In order to make it work we needed to compile it with a shared object file. [2]
Would it be possbile to include a shared object in the 'official' release?
Cheers
Felix
[1]https://telescopes.desy.de/EUDAQ
[2]https://github.com/veloxid/DRS4-v5-shared |
|
438
|
Mon Jul 6 11:30:56 2015 |
Felix Bachmair | Creation of Object files |
Hi Stefan,
That's fine for me. I thought it might be interesting for others as well..
Cheers
Felix
| Stefan Ritt wrote: |
|
Hi Felix,
the distribution does not contain any binaries, since there are too many Linux distributions around, so everybody compiles from the sources under Linux. Do you want me to just add libDRS.so to the official Makefile? Actually you are the first one asking for this. Would it be beneficial to have this in the distribution, or can you just maintain your own Makefile in the github repository?
Stefan
| Felix Bachmair wrote: |
|
HI,
We are using the DRS4 Board in the EUDAQ framework [1]. We wrote a a Producer based on the software of the evaluation board, which is using the DRS class/header/src files.
In order to make it work we needed to compile it with a shared object file. [2]
Would it be possbile to include a shared object in the 'official' release?
Cheers
Felix
[1]https://telescopes.desy.de/EUDAQ
[2]https://github.com/veloxid/DRS4-v5-shared
|
|
|
|
440
|
Tue Jul 7 09:29:21 2015 |
Felix Bachmair | Creation of Object files |
Yes of course no problem.
You can download via github https://github.com/veloxid/DRS4-v5-shared and I also put it in the attachment.
It's tested with Ubuntu, Fedora and RHEL.
For mac OSX one needs to create a dylib out of the so file.
Cheers
Felix
| Stefan Ritt wrote: |
|
Anyhow it would be nice if you just post your Makefile here, which runs with the standard distribution, so people can use it if needed.
Stefan
| Felix Bachmair wrote: |
|
Hi Stefan,
That's fine for me. I thought it might be interesting for others as well..
Cheers
Felix
| Stefan Ritt wrote: |
|
Hi Felix,
the distribution does not contain any binaries, since there are too many Linux distributions around, so everybody compiles from the sources under Linux. Do you want me to just add libDRS.so to the official Makefile? Actually you are the first one asking for this. Would it be beneficial to have this in the distribution, or can you just maintain your own Makefile in the github repository?
Stefan
| Felix Bachmair wrote: |
|
HI,
We are using the DRS4 Board in the EUDAQ framework [1]. We wrote a a Producer based on the software of the evaluation board, which is using the DRS class/header/src files.
In order to make it work we needed to compile it with a shared object file. [2]
Would it be possbile to include a shared object in the 'official' release?
Cheers
Felix
[1]https://telescopes.desy.de/EUDAQ
[2]https://github.com/veloxid/DRS4-v5-shared
|
|
|
|
|
| Attachment 1: Makefile
|
########################################################
#
# Makefile for drsosc, drscl and drs_exam
# executables under linux
#
# Requires wxWidgets 2.8.9 or newer
#
########################################################
# check if wxWidgets is installed
HAVE_WX = $(shell which wx-config)
ifeq ($(HAVE_WX),)
$(error Error: wxWidgets required to compile "drsosc")
endif
# check for OS
OS = $(shell uname)
ifeq ($(OS),Darwin)
DOS = OS_DARWIN
else
DOS = OS_LINUX
endif
CFLAGS = -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -D$(DOS) -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX
LIBS = -lpthread -lutil -lusb-1.0
ifeq ($(OS),Darwin)
CFLAGS += -stdlib=libstdc++
endif
# wxWidgets libs and flags
WXLIBS = $(shell wx-config --libs)
WXFLAGS = $(shell wx-config --cxxflags)
CPP_OBJ = DRS.o averager.o ConfigDialog.o DOFrame.o DOScreen.o DRSOsc.o MeasureDialog.o Measurement.o Osci.o InfoDialog.o DisplayDialog.o AboutDialog.o EPThread.o TriggerDialog.o rb.o
OBJECTS = musbstd.o mxml.o strlcpy.o
SHARED_OBJECTS= libDRS.so
ifeq ($(OS),Darwin)
all: drsosc drscl drs_exam drs_exam_multi DRSOsc.app
else
all: drsosc drscl drs_exam drs_exam_multi
endif
DRSOsc.app: drsosc
-mkdir DRSOsc.app
-mkdir DRSOsc.app/Contents
-mkdir DRSOsc.app/Contents/MacOS
-mkdir DRSOsc.app/Contents/Resources
-mkdir DRSOsc.app/Contents/Resources/English.lproj
echo 'APPL????' > DRSOsc.app/Contents/PkgInfo
cp Info.plist DRSOsc.app/Contents/Info.plist
cp DRSOsc.icns DRSOsc.app/Contents/Resources
cp drsosc DRSOsc.app/Contents/MacOS/DRSOsc
drsosc: $(OBJECTS) $(CPP_OBJ) main.o
$(CXX) $(CFLAGS) $(OBJECTS) $(CPP_OBJ) main.o -o drsosc $(LIBS) $(WXLIBS)
drscl: $(OBJECTS) DRS.o averager.o drscl.o
$(CXX) $(CFLAGS) $(OBJECTS) DRS.o averager.o drscl.o -o drscl $(LIBS) $(WXLIBS)
drs_exam: $(OBJECTS) drs_exam.o $(SHARED_OBJECTS)
# $(CXX) $(CFLAGS) -L . $(OBJECTS) -lDRS drs_exam.o -o drs_exam $(LIBS) $(WXLIBS)
$(CXX) $(CFLAGS) $(OBJECTS) -L. drs_exam.o -lDRS -o drs_exam $(LIBS) $(WXLIBS)
drs_exam_multi: $(OBJECTS) DRS.o averager.o drs_exam_multi.o
#old $(CXX) $(CFLAGS) $(OBJECTS) DRS.o averager.o drs_exam_multi.o -o drs_exam_multi $(LIBS) $(WXLIBS)
$(CXX) $(CFLAGS) $(OBJECTS) -L. DRS.o averager.o drs_exam_multi.o -o drs_exam_multi -lDRS $(LIBS) $(WXLIBS)
main.o: src/main.cpp include/mxml.h include/DRS.h
$(CXX) $(CFLAGS) $(WXFLAGS) -c $<
drscl.o: src/drscl.cpp include/mxml.h include/DRS.h
$(CXX) $(CFLAGS) -c $<
drs_exam.o: src/drs_exam.cpp include/mxml.h include/DRS.h
$(CXX) $(CFLAGS) -c $<
drs_exam_multi.o: src/drs_exam_multi.cpp include/mxml.h include/DRS.h
$(CXX) $(CFLAGS) -c $<
$(CPP_OBJ): %.o: src/%.cpp include/%.h include/mxml.h include/DRS.h
$(CXX) $(CFLAGS) $(WXFLAGS) -c $<
$(OBJECTS): %.o: src/%.c include/mxml.h include/DRS.h
$(CC) $(CFLAGS) -c $<
$(SHARED_OBJECTS): %.so: DRS.o mxml.o averager.o musbstd.o
# Make Shared objectss
# g++ -Wall -shared -fPIC -o libDRS.so src/DRS.cpp src/averager.cpp src/mxml.c -I include/
# < $<
# @ $@
# %.so
#g++ -Wall -shared -fPIC -o libDRS.so src/DRS.cpp src/averager.cpp src/mxml.c -I include/")
$(CXX) $(CFLAGS) $(WXFLAGS) -Wall -shared -fPIC -o $@ -I include/ src/DRS.cpp src/averager.cpp src/mxml.c src/musbstd.c $(LIBS) $(WXLIBS)
clean:
rm -f *.o *.so drscl drsosc
|
|
444
|
Fri Aug 7 20:32:15 2015 |
Felix Bachmair | DRS4 |
Hi
Did you copy the udev rule 41-drs.rules into /etc/udev/rules.d/ ?
Which operating system are you using?
Cheers
Felix
| dante wrote: |
|
Hi
I have just installed DRS4, but when I try to view it from the USB it don't work. Why?
[ .../home $] lsusb -d 04b4:1175 -v
Bus 002 Device 008: ID 04b4:1175 Cypress Semiconductor Corp.
Couldn't open device, some information will be missing
Device Descriptor:
|
|