PmodENC Example code repetition

[3STTW]

I'm adapting the Pmod encoder example to use with one of my projects. In the example source code, Encoder.v, there is a state repetition during the FSM - state "R3" occurs twice.

I just want to confirm that this is a mistake - or maybe it's repeated for some reason I have yet to consider?

 

					  // R2
					  "R2" : begin
							 LED <= 2'b01;

							 if (A == 1'b1) begin
								 nextState <= "R1";
							 end
							 else if (B == 1'b1) begin
								 nextState <= "R3";
							 end
							 else begin
								 nextState <= "R2";
							 end
					  end
					  // R3
					  "R3" : begin
							 LED <= 2'b01;

							 if (B == 1'b0) begin
								 nextState <= "R2";
							 end
							 else if (A == 1'b1) begin
								 nextState <= "add";
							 end
							 else begin
								 nextState <= "R3";
							 end
					  end
					  // R3
					  "R3" : begin
							 LED <= 2'b01;

							 if (B == 1'b0) begin
								 nextState <= "R2";
							 end
							 else if (A == 1'b1) begin
								 nextState <= "add";
							 end
							 else begin
								 nextState <= "R3";
							 end
					  end
					  // Add
					  "add" : begin
							 LED <= 2'b01;
							 nextState <= "idle";
					  end

 

[artvvb]

Hi @3STTW,

Yep, it's a mistake, the second R3 state should be unreachable.

Thanks,

Arthur

[3STTW]

Thanks @artvvb

Another aspect that I've noticed about the example code, it assumes that the decoder will always land at a detent position where A=1 and B=1 ("idle" state).

If you have an encoder which doesn't have detents or the encoder has, say, 30 detents and 15 positions, the logic may not function properly. In either case, it's unlikely (50% at best) that the encoder will rest in the "idle" state.

I appreciate that the code was written specifically for the Pmod part, but maybe it could have been more universal to use the circular logic (below) as opposed to the L-R strategy in the example?

Just a thought!