[subexp-daq] SIS3316 implementation in NURDLIB fixed

[Håkan T Johansson]

Dear Günter,

I am just looking for a positive report about some/any actual use if the 
code such that there is enough confidence in the branch to get it merged.

That would also give a much better reference point for anyone wanting to 
do further improvements.

(I am pushing since having unmerged branches stalls other development 
since one is more reluctant to do global improvements that potentially 
would break in a branch...)

Best regards,
Håkan



On Sun, 28 Apr 2024, Weber, Guenter Dr. wrote:

> 
> 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
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >
> 
>