<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:14pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Dear H<span>å</span>kan,</p>
<p><br>
</p>
<p>does this also mean that I can just do the following</p>
<p><br>
</p>
<p><span style="font-size:10pt">make fw_1409285e_trlo_build # choose the vulom4b trlo</span></p>
<p><br>
</p>
<p>even if I have a VULOM4 instead of VULOM4B in my setup?</p>
<p><br>
</p>
<p>My understanding was that I should use</p>
<p><br>
</p>
<p><span><span style="font-size:10pt">make fw_</span><span style="font-size:10pt">6e4ba1a9</span><span style="font-size:10pt">_trlo_build
</span><span style="font-size:10pt"># choose the vulom4 trlo</span><br>
</span><br>
</p>
<p>instead.</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Thank you very much!</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Best greetings</p>
<p>Günter<br>
</p>
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo@chalmers.se><br>
<b>Gesendet:</b> Montag, 15. April 2024 12:59:46<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
<b>Betreff:</b> Re: [subexp-daq] Possible problem in Makefile of NURDLIB</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
On Mon, 15 Apr 2024, Weber, Guenter Dr. wrote:<br>
<br>
> <br>
> Dear Håkan,<br>
> <br>
> <br>
> thank you very much for the explanations and the modifications.<br>
> <br>
> <br>
> I see that you updated the automatic determination of the VULOM4_FW variable<br>
> in the NURDLIB Makefile. Just for clarification: it will always come up with<br>
> the VULOM4B version, even though there might be a VULOM4 module in the<br>
> setup, as the firmware for both modules is identical for the purpose of this<br>
> compilation, right?<br>
<br>
Yes, that is the idea.<br>
<br>
If the trloii/trloctrl/ contain several incompatible versions, it will <br>
just pick the first, which might not work. But in that case, at least the <br>
setup routines will complain about alias not in list, and then one has <br>
to clean up. I think we can live with that.<br>
<br>
The rest below is for Hans :-)<br>
<br>
Cheers,<br>
Håkan<br>
<br>
> Moreover, to make things more comfortable for the user, I added the<br>
> following code to the Makefile:<br>
> <br>
> <br>
> ifeq (,$(TRLOII_PATH))<br>
> TRLOII_PATH_TEST:=$(shell pwd)/../trloii<br>
> ifeq ("$(wildcard $(TRLOII_PATH_TEST))", "")<br>
> TRLOII_ERROR:=WARNING: Makefile guessed $(TRLOII_PATH_TEST), but folder does<br>
> not exist!<br>
> $(call infovar,TRLOII_ERROR)<br>
> else<br>
> TRLOII_PATH:=$(TRLOII_PATH_TEST)<br>
> endif<br>
> endif<br>
> <br>
> This assumes that it is unlikey that you want to compile NURDLIB without<br>
> TRLOII being present. But maybe, if it is desired to decide if NURDLIB<br>
> should compile with or without TRLOII it is better to have this as an<br>
> explict option for "make" instead of doing it implicitly by having the<br>
> TRLOII_PATH variable being set by hand or not.<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> <br>
> <br>
> ____________________________________________________________________________<br>
> Von: subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Håkan<br>
> T Johansson <f96hajo@chalmers.se><br>
> Gesendet: Samstag, 13. April 2024 03:50:36<br>
> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
> Betreff: Re: [subexp-daq] Possible problem in Makefile of NURDLIB <br>
> <br>
> Dear Günter,<br>
> <br>
> we think that we have managed to solve the issues at hand (there were<br>
> multiple):<br>
> <br>
> - The missing TRIDI compile: r3bfuser compiles (unconditionally) with both<br>
> tridi and vulom support if it compiles with one of them. (tridi is a<br>
> module with similar hardware as the vulom). Now the compile<br>
> instructions also include to get the tridi things compiles.<br>
> <br>
> - The VULOM4_FW now only picks one version, which should be enough.<br>
> Those named _trlo actually have the same register layout, and<br>
> find_firmwares.pl point them to the same, so any should do.<br>
> <br>
> (Please see the updated instructions in the other mail. Only the<br>
> compilation sequence had additions, not the download parts. But nurdlib<br>
> and r3bfuser repositores need to be updated.<br>
> <br>
> For this:<br>
> <br>
> > Reporting compilation errors when they happen and why they happen would<br>
> > be really very much appreciated<br>
> <br>
> I am not sure what can be done when the issues are within the<br>
> feature-finding builds. I.e., when those fail, it just means that<br>
> certains options are not available. Problem is when later programs rely<br>
> on them.<br>
> <br>
> if anything, the later programs should then produce more specific errors<br>
> telling what they are missing. That might be doable with some #error<br>
> macros, if they do not have complex makefiles to find features.<br>
> <br>
> The other thing might be that 'make showconfig' is too cluttered. There<br>
> are essentially two kinds of features. The uninteresting ones where the<br>
> systems need to find one working option out of many. If no option works,<br>
> things will stop, as it cannot continue.<br>
> <br>
> The more interesting selections are the ones where it can get away with no<br>
> support, i. this case e.g. not compiling tridi support.<br>
> <br>
> Perhaps one should have a 'make showconfig_all' which works as the one<br>
> now, and 'make showconfig' only giving the important ones.<br>
> <br>
> Cheers,<br>
> Håkan<br>
> <br>
> <br>
> <br>
> On Fri, 12 Apr 2024, Weber, Guenter Dr. wrote:<br>
> <br>
> ><br>
> > Dear friends,<br>
> ><br>
> ><br>
> > on line 108 to 110 of the Makefile there is an automatic setting of the<br>
> > VULOM4_FW parameter:<br>
> ><br>
> ><br>
> > ifeq (,$(VULOM4_FW))<br>
> > VULOM4_FW:=$(shell ls $(TRLOII_PATH)/trloctrl | grep _trlo | $(SED)<br>
> > 's,fw_,,;s,_trlo.*,,')<br>
> > endif<br>
> ><br>
> > However, if I let this run (i.e. VULOM4_FW is not set by hand) the outcome<br>
> > is as follows:<br>
> ><br>
> ><br>
> > VULOM4_FW = "1409285e 68f8955e 6e4ba1a9 a73c5093 af33ed35"<br>
> ><br>
> ><br>
> > My understandig is that there should only be a single number selected<br>
> > (1409285e for VULOM4B and 6e4ba1a9 for VULOM4). I checked what the "ls"<br>
> > command produces on two systems:<br>
> ><br>
> ><br>
> > RIO4L-2 mbsdaq > ls $TRLOII_PATH/trloctrl<br>
> > Makefile examples/ find_firmwares.pl* firmwaredirs fw_0866c243_rfx1/ <br>
> > fw_1409285e_trlo@ fw_5e8f5ef4_tridi/ fw_68f8955e_trlo_all_in/ <br>
> > fw_6e4ba1a9_trlo/ fw_a1729cda_rfx0/ fw_a73c5093_trlo@ <br>
> > fw_af33ed35_trlo_big/ trloctrl.sh* trlolib/<br>
> ><br>
> > RIO4-MCAL-1 mbsdaq > ls $TRLOII_PATH/trloctrl<br>
> > Makefile examples/ find_firmwares.pl* firmwaredirs fw_0866c243_rfx1/ <br>
> > fw_1409285e_trlo@ fw_5e8f5ef4_tridi/ fw_68f8955e_trlo_all_in/ <br>
> > fw_6e4ba1a9_trlo/ fw_a1729cda_rfx0/ fw_a73c5093_trlo@ <br>
> > fw_af33ed35_trlo_big/ tridi_log.txt trloctrl.sh* trlolib/ <br>
> vulom_log.txt<br>
> ><br>
> ><br>
> > RIO4L-2 is the one I am working on right now with the VULOM4, whereas<br>
> > RIO4-MCAL-1 is the system already running with VULOM4B.<br>
> ><br>
> ><br>
> > To me it looks like the code in the Makefile is not working as intended,<br>
> > right?<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > Best greetings<br>
> ><br>
> > Günter<br>
> ><br>
> ><br>
> ><br>
> ><br>
> <br>
></div>
</span></font>
</body>
</html>