RFID on EICO-40

[IVL]

Hi,

I tested the RFID on EB006 and it works fine.
However, it doesn't work on EICO-40.

Does anyone know the correct jumper settings to use RFID on EICO-40 ?

I'm using :
Port B : LCD
Port C : RFID
Port D : Led

On EB006 with 16F877 it works fine.

RFID 16F877.fcf

(7.5 KiB) Downloaded 307 times

On EICO-40 with EB061 ECIO application board it doesn't.

RFID_EICO.fcf

(12.5 KiB) Downloaded 315 times

The status returned by the initialise macro returns 128 on the EB006, but 255 on the EICO.

The RFID reader recognises the card (green led) on both test setups.

Regards,
Ivan

[JohnCrow]

Hi

Ive not tried these setting, but I've found a note I'd got on a post it about the ECIO

Set RFID Jumpers to "C" & "1"

In Flowcode ser CTS on Port C to Pin 0

Hope it works

[IVL]

Thanks for the feedback John.

I've tried those settings and it does make a difference, but it still doesn't work.

Using the settings RFID jumpers to "C" and "2" with CTS to port C bit 4 i get the following results
- Init macro reply : 255
- Get RFid status macro : 255

Using the settings RFID jumpers to "C" and "1" with CTS to port C bit 0 i get the following results
- Init macro reply : 255
- Get RFid status macro : 128

The E-Block datasheet unfortunately doesn't metion the significance of b7...
It does mention "More commands can be found in the RFID module datasheet." However, i didn't find any refernce to the module used nor the suplier...

Using the settings RFID jumpers to "C" and "2" with CTS to port C bit 4 on my EB006 (16F877) instead of the EICO gives the following results
- Init macro reply : 128
- Get RFid status macro : 134

If anyone has a reference to the module and it's manufacturer it might help to take a look at the datasheets.

Regards,
Ivan

[IVL]

Hi,

Meanwhile i made some progress.
Looking at the RS232 diagram in the E-Block datasheet I noticed a remark "Host must transmit CMD/DATA within 10ms of BUSY going low". That made me think this might be a timing issue with the component macro's.

I did some trial and errors with different delays in the code but that didn't help.
Next I tried to call the macro's twice and that did the trick...
So, now I'm able to get the init and get status macro's to work by issuing them twice.
I believe this confirms my gutfeeling this is a timing issue.

Naturally it doesn't make sence to start writng code sending each macro twice, so I hope someone of MM will take a look at this in the coming days and finds a solution.
For info, i'll attach the flowcode that does work on the EICO :

RFID_EICO.fcf

(10 KiB) Downloaded 308 times

Regards,
Ivan

[Benj]

Hello Ivan,

Please can you confirm that you are using Flowcode v4.

A return value of 255 means that no data was received via the incoming UART.

I will try and have a look into this for you and see if I can find out where the issue is.

As a after thought. Pin C4 on the ECIO is not available as it is being used by the USB. What happens if you use the patch system to connect the signal through to say C1 or C2?

[IVL]

Yes, I'm using Flowcode V4.

I did try to use jumper setting 1 which connects CTS to C0.
This is the setting that works fine, if i send each macro call twice as you can see in the attached flowcode program.

I can try C1 or C2 as well, but not right now.

[Benj]

Hello,

Right I think I see what the issue is.

Basically for the RFID component the UART is send a command and then sampled a number of times for a response. On the standard devices this is working fine but because the ECIO runs faster the samples are faster which means that the response is not received until you send the second command which effectively doubles the timeout.

In Flowcode select the RFID component and then select custom code.

Edit the RFID_ReceiveRS232Char function.

Find this section of code.

Code: Select all

	while (rxStatus == 0)
	{
		if (ts_bit(pir1, RCIF) != 0)
		{
			//received a Char
			rxStatus = 2;
		}
		else
		{
			if (bWaitForever == 0)
			{
				//don't wait forever, so do timeout thing...
				if (nTimeout == 0)
				{
					rxStatus = 1;
				}
				else
				{
					//decrement timeout
					delay1--;
					if (delay1 == 0)
					{
						nTimeout--;
	}	}	}	}	}

And change to this.

Code: Select all

	while (rxStatus == 0)
	{
		if (ts_bit(pir1, RCIF) != 0)
		{
			//received a Char
			rxStatus = 2;
		}
		else
		{
			if (bWaitForever == 0)
			{
				//don't wait forever, so do timeout thing...
				if (nTimeout == 0)
				{
					rxStatus = 1;
				}
				else
				{
					//decrement timeout
					delay1--;
					delay_us(10);
					if (delay1 == 0)
					{
						nTimeout--;
	}	}	}	}	}

Upon compilation the RFID component should work correctly with the ECIO without having to call functions twice.

[IVL]

Hi,

Indeed, adding a delay as sugested solves the problem.
I did some tests changing the delay value and found even 1 µs is sufficient to make it work.

Question,
What is the usual pratice for this kind of problems ? Would the component be changed to include an additional delay in the next release ? Would a patch be released for V4 to solve the problem ? Or is it up to each user to find out what's going on when bumping into the problem ? Naturally using the forum the problem will get solved, as proven by this tread. I'm just curious to get to know the common practices as I'm new to the user group.


PS
It might be usefull to mention the jumper settings to use for the EICO-20 and 40 in the EB006 datasheet.


Thanks for your help,
Ivan

[Benj]

Hello,

Great glad you have it working, thanks for letting us know.

For v5 we have already fixed this issue by using delays in the UART abstraction code file rather then simply relying on a number of iterations. This then takes the device clock speed out of the equation.

For a problem like this where it is on a older version of the product we would probably not fix it using a patch but we would provide support to help the user fix it.

The ECIO devices and the EB006 are not compatible and should not be used together. The E-blocks base board for the ECIO range of devices is the EB061.