Rpm wrong value about iiot-eddp HOT 4 CLOSED

Hi Phil.
Can you please try to modify axis_encoder_v1_0.vhd line 235, from
if(div_value < divider)then -- End of division
to
if(div_value <= divider)then -- End of division

BR
Alex

from iiot-eddp.

Hi Alex
No effect rpm_data[15:0] and m_rpm_data[15:0] still are equal to 0.
My signals for A,B,C are managed with internal counter (base on time_pulse for pulse duration) :
time_pulse = (6000000 / rpm_t);
A_1 = 0; // means A signal set to high
A_0 = (time_pulse / 2); // for 180°e
B_1 = (time_pulse / 4); // for 90°e
B_0 = (time_pulse / 4 + time_pulse / 2);
I_1 = (time_pulse / 2 + time_pulse / 8); // only manage once on 1st pulse
I_0 = (time_pulse / 2 + time_pulse / 4 + time_pulse / 8); //only manage once on 1st pulse
// I duration 90°e on a complete revolution (pulse on 1000 overall pulse in my config).
My signal are simulated compliant to 23Y106D-LW8-1000SI spec. from EDDP System Kit.
Does it seems correct to you ?
I will investigate on my side IP vhdl code in the coming weeks if necessary.

BR
Philippe

from iiot-eddp.

I found the problem, which is not really in issue for real execution but only in simulation.
rpm_data is computed by dividing the period_value (period between 2 rising edge of A signal by div_value as CLK_FREQ * 60 / CPR. The dividing operation is operated by successive substraction controlled by a state machine, to lock computation ressource for the dividing operation (sm_state).
After a reset or power-up, period_value is latched to 1. So the first computation of rpm_data is 363904 (for my configuration FREQ = 100MHz et CP = 1000) / 1 = 363904 * 10 ns = 3,6 ms.
For HDL simulation a long simulation, but for real execution.

from iiot-eddp.

I propose to close the issue.
A fix could be to allow only dividing after a valid period_value (2 edge of A signal for a correct measurement of the period).

from iiot-eddp.