Emulate ibutton with rfid tag ?

[Joarez Fonseca]

Hello, I would like help in a test I'm doing on the bench ...

I would like to emulate an ibutton using a simple rfid type tag.

The Reader I am using is an RDM6300 that provides the data via serial 232. I would like to use a pic 12F675 or another to be able to collect the data of the card through the serial and transmit the data as if it were an ibutton via serial.

Can someone help me?

[temtronic]

Break the project down into small sections.
1) cut code to have the PIC read the RFID rcvr data,save in a 'buffer' and either display onto a local LCD module or send to a PC.

2) now cut code to take that 'buffer' data and send to an Ibutton rcvr. You'll have to lookup the Ibutton specs for signalling,so check with Dallas.

You should select a PIC that has a hardware UART. It makes the 1st section EASY. While cutting code for a software UART can be made to work it involves a LOT of time and effort to get the timing just right. Life is too short so buy a more 'powerful' PIC. Be sure to read the RFID reader's datasheet. How much data will it send? You need a PIC with at least 2x the RFID data! So if the reader sends say 30 bytes of data, the PIC NEEDS at least 64 bytes of RAM space. Always buy a 'bigger' PIC. If you think an 8 pin device might work use an 18 pinner ! Select one with LOTS of EEPROM, RAM and peripherals. Some 'power packed' PICs as actually cheaper then a lesser unit!!

Once you've got your PIC, the 1st program to cut is the '1Hz LED' program. It simple flashes an LED at a 1Hz rate. Remember to have a 470r in series with the LED to limit pin current. This program may be simple BUT it will confirm your PCB is wired right, the PIC is good, the compiler functions as well as the programmer.

You talk about RS-232. Is the reader really outputting RS-232? If so you'll need a 'max232' style device between the reader and your PIC.

Start small, build upon what you learn. Once it works, copy the source to say 'myproject_v2.c' ,make changes and then compile/test. Everytime you want to make changes/add code... copt old source, edit, compile ,test. yes you can end up with 30-40-100 versions BUT you can always go back to any previous one where 'it worked before.....' When the project is completed then delete all but the last 3 versions. The problem with always editting the same file is that you can make 2-3 changes, it compiles and doesn't work and you spend 3 DAYS looking for why and never see the silly typing error.

Jay

[Ttelmah]

Seriously, this is going to need a much larger chip than the 12F675.

An iButton, has 576 bytes of RAM, and 8KB of storage available for use. So you have to fit all the code, and still have this much left over.
To emulate all the functions of an iButton, is several _weeks_ of work for an experienced programmer.....

You need to start much smaller and larger. Bigger PIC, and then only work on the parts you actually need....

Thinking further, I don't think any but a very fast PIC is actually going to be able to handle the one wire interface at the speed the iButton can manage. 140Kbps+.

[temtronic]

I think the original poster needs to restate the question again, in better detail.
What I read in the original post is...
RFID tag -> RFID reader -> PIC -> PC with iButton interface

So the PIC reads the RFID reader that has read the RFID tag data. This is only 14 bytes according to the RFID reader datasheet.Once the data has been read, into a 'buffer', the PIC then transmits that data in 'iButton' format to an iButton device, presumably attached to a PC.

This is what I'm thinking he wants but we really need it to be confirmed. I understand English is not everyone's 1st language. Heck I have troubles with it for 60+ years!

If this IS the project, then any reasonably fast PIC, should be able to do the job, though I've neverlooked at the iButton specs.

Of course now, while typing this I've thought that maybe he want to use the RFID tag as an iButton 'clone'. Really a small scale version, where only a few bytes of data are transfered to say a PC, though a PIC interface.

Jay

[Ttelmah]

Problem is the iButton handles a 1 wire interface at nearly 150KHz. Now it you think how many machine cycles are needed for the operations on this interface, you would need a very fast PIC or hardware to do this. 1 wire at only a few kHz is easy, but at this sort of rate, I can see it being really hard to code. Now coding a 1 wire master is relatively easy. You control the timing. But the iButton is a slave device, and to 'emulate' the iButton, would require you to match the performance of the real device, including support for the speed.

Now given that the device is going to have to handle the 1 wire and the serial possibly at the same time, it is actually going to need quite a fast PIC.
I'd be visualising something like a 32MHz PIC18 with hardware UART, as making the task 'reasonably possible', though even with this the latency that would exist on the 1 wire responses could be a problem....

Remember that there is no way you have the time to go and handle an interrupt driven serial RX for example, while data is arriving on the 1 wire interface, without upsetting the timings. So the serial would have to be checked by polling the interrupt flag at points in the 1 wire handling. Or possibly by using a GLOBAL interrupt and timer to do the reading of the 1 wire timings. It's a very timing critical problem. The one wire slave implementations around for the PIC, need 10MHz plus to just handle the interface, without doing a second asynchronous task at the same time....

[Ttelmah]

Thinking about it, the way to do it is with a modern PIC with two UART's.
Use the first UART to talk to the RFID.
On the second, feed the one wire interface line into the UART receive input, via a buffer. You need a buffer to provide the input protection, and to give the lower signal input levels than the PIC's UART input supports.
Connect the UART output back to the same pin with an inverter and FET to give pull-down only drive.
Then you set this UART up with a suitably fast baud rate so that the small pulse on 1-wire is approximately one bit time.
You can then simply poll this chip when it receives data, with it seeing either just a start bit and the rest of the byte high for the smaller pulses and several bits low for the long pulses.
Same comment then applies that you will need to poll the first UART between 'characters' (bits) on the second UART, but all the timing is done for you, with really simple detection on the bit lengths. Then for the reply back to the master you can use the same trick to send the bits.

[temtronic]

I got curious about this and googled some.
Seems there's a LOT of chatter about hacking iButtons and some use the Atmel micros to read/write the iButtons. Haven't dug too deep into this but it seems that getting a micro to 'talk'( look) like an iButton isn't that hard, in the grand scheme of things.
Someone, somewhere has probably got a PIC to do it, I did see a Dallas Appnote about doing it in machine code...

[Ttelmah]

Agreed it is not actually hard to make a micro look like the iButton. What you have to remember is that as the slave device, you have to detect all the edge changes and be able to do this on quite short pulses. It is doable on a PIC, but gets hugely harder if you are having to deal with another asynchronous event.

So a PIC that (for instance), sent the reading from an ADC, from some input pins, or out of memory, is relatively easy. But doing it with a serial port being run at the same time, and not missing edges, is much harder.

It would be really easy on a PIC24, which has a multi-byte buffer for the edge capture peripheral.

You could also do it with two capture peripherals, and feed the signal to both CCP inputs. Then program one for the falling edge, and the other for the rising, and then when you see the rising edge, the time between the two counts would give the pulse width easily.