I don’t think it makes sense to start using the sync1_shift_time parameter, as
that would introduce incompatibility with other code (that perhaps hasn’t
upgraded to that build yet, or hasn’t noticed or doesn’t care about the change
in start time), and introduce some additional ambiguity.
In
Hi Gavin,
Thanks for the detailed explanation, this explain why the code is like it is.
This works for slaves that are doing oversampling but not for mine that just
want to shift the SYNC1 a bit.
Now if we want a solution working for all kind of possibles slave
configurations we will need
Hi Graeme,
Thanks for your analysis that I fully agree with.
Regarding your proposition to set two last parameters to zero:
ecrt_slave_config_dc(sc, 0x0700, 50, 25, 0, 0);
This would fix the start time calculation but I can not put sync1->cycle_time
to zero because this value (1000
The SYNC1 Cycle register (0x09A4) is a little weird; it acts as both a cycle
and shift in one register, depending on the value of the SYNC0 Cycle (0x09A0).
* Where SYNC0 Cycle is X and SYNC1 Cycle is 0, SYNC0 and SYNC1 occur at the
same time – thus same cycle, no shift.
* Where SYNC0
Hi,
This piece of code is getting a start time that is in sync with the initial app
time from a multiple of the sync0/sync1 cycle times, adjusted by the sync0
shift time.
Hi,
I have changed how to calculate the slave start time by taking only the
sync0->cycle_time as cycle time.
The results is good and I can see in the log that the 'remainder' is almost the
same for all slaves.
@Florian: Why did you did this change on 2016-09-16 ?
Best regards
Philippe
>
