[subexp-daq] SIS3316 implementation in NURDLIB fixed

[Weber, Guenter Dr.]

Dear friends,


who are the other users of the 3316 module? As I understand, most other groups are using the faster 250 MHz, 14-bit version, while we are (the only) ones who are using the 125 MHz, 16-bit version.


If there is an interest to use the software version that was bugfixed as a common standard for the future, we should not be the only ones testing it. 😊

(But if we are the only user of the software for now, we could have a look if we want to adjust the output of the module better to our needs. For example, at the moment the temperature of the module is written to the data of every individual channel. Even though it is a global variable, whose more suitable place would be in the header(s) information.)



Best greetings

Günter


________________________________
Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo at chalmers.se>
Gesendet: Samstag, 27. April 2024 15:58:13
An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
Betreff: Re: [subexp-daq] SIS3316 implementation in NURDLIB fixed


I think this was the most recent mail regarding the SIS3316.

To not let this drop, I rebased 'rebasing_sis3316_dma_align' on top of
current master (no conflicts).  In the hope that this gets tested and
then merged.

Cheers,
Håkan



On Sat, 23 Mar 2024, Håkan T Johansson wrote:

>
> Dear Günter,
>
> I just pushed a new branch 'rebasing_sis3316_dma_align' to gitlab which
> changes to use that method instead.  It also moved the calculation of
> bytes_to_read up, as otherwise warnings for possibly uninitialised variable
> use were generated.
>
> I am not sure if the check for buffer overflow is taking into account other
> data already added to the output.  This I think Hans is better to figure out.
>
> Perhaps too many variables at once, but this new branch has been rebased on
> top of current nurdlib master.
>
> Cheers,
> Håkan
>
>
>
>
> On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote:
>
>>
>> Yes, I think you are right.
>>
>>
>> ____________________________________________________________________________
>> Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan
>> T Johansson <f96hajo at chalmers.se>
>> Gesendet: Freitag, 22. März 2024 17:37:42
>> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
>> Betreff: Re: [subexp-daq] SIS3316 implementation in NURDLIB fixed
>>
>> Dear Günter,
>>
>> just had a quick look:
>>
>> This old code with +1 is surely not good:
>>
>>                 bytes_to_read =
>>                     ((a_words_to_read * sizeof(uint32_t)) + 1) & ~0x7;
>>
>> Since sizeof(uint32_t) is 4, the addition of 1 would not have any effect.
>>
>> However, I'm a bit wondering about addint 8 (and 16 in the case of ~0xf).
>>
>> How about the following:
>>
>>                 bytes_to_read =
>>                     ((a_words_to_read * sizeof(uint32_t)) + 0x7) & ~0x7;
>>
>> (and '+ 0xf' with '& ~0xf') ?
>>
>> That ought to bring it up to the next boundary if the read count was
>> unaligned.  And the if-statements would not be needed.
>>
>> Cheers,
>> Håkan
>>
>>
>>
>>
>> On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote:
>>
>> >
>> > Dear friends,
>> >
>> >
>> > we just pushed a fixed version of the SIS3316 implementation. Compared to
>> > the original version of REBASING_SIS3316 a lot of glitches in the code
>> were
>> > fixed in a first run a few days ago and now we finally also fixed a
>> > long-standing problem with the readout of the averaged traces.
>> >
>> >
>> >
>> >
>> >
>> > Best greetings and have a nice weekend everybody
>> >
>> > Günter
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240428/1bae2b4c/attachment.html>