<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:14pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<meta content="text/html; charset=UTF-8">
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size: 14pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, "EmojiFont", "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<p>Dear H<span>ċ</span>kan,</p>
<p><br>
</p>
<p>thank you very much for the explanations and the modifications.<br>
</p>
<p><br>
</p>
<p>I see that you updated the automatic determination of the VULOM4_FW variable in the NURDLIB Makefile. Just for clarification: it will always come up with the VULOM4B version, even though there might be a VULOM4 module in the setup, as the firmware for both
modules is identical for the purpose of this compilation, right?</p>
<p><br>
</p>
<p>Moreover, to make things more comfortable for the user, I added the following code to the Makefile:</p>
<p><br>
</p>
<p></p>
<div><span style="font-size: 10pt;">ifeq (,$(TRLOII_PATH))</span><br>
<span style="font-size: 10pt;">TRLOII_PATH_TEST:=$(shell pwd)/../trloii</span><br>
<span style="font-size: 10pt;">ifeq ("$(wildcard $(TRLOII_PATH_TEST))", "")</span><br>
<span style="font-size: 10pt;">TRLOII_ERROR:=WARNING: Makefile guessed $(TRLOII_PATH_TEST), but folder does not exist!</span><br>
<span style="font-size: 10pt;">$(call infovar,TRLOII_ERROR)</span><br>
<span style="font-size: 10pt;">else</span><br>
<span style="font-size: 10pt;">TRLOII_PATH:=$(TRLOII_PATH_TEST)</span><br>
<span style="font-size: 10pt;">endif</span><br>
<span style="font-size: 10pt;">endif</span></div>
<br>
<p></p>
<p>This assumes that it is unlikey that you want to compile NURDLIB without TRLOII being present. But maybe, if it is desired to decide if NURDLIB should compile with or without TRLOII it is better to have this as an explict option for "make" instead of doing
it implicitly by having the TRLOII_PATH variable being set by hand or not.</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Best greetings</p>
<p>Günter<br>
</p>
<p><br>
</p>
<br>
</div>
<hr style="display:inline-block; width:98%" tabindex="-1">
<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> Samstag, 13. April 2024 03:50:36<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>
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/ 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>
></div>
</span></font></div>
</body>
</html>