Smart card and pic programming

Hi all, I'm planning to do some experimentation on pic programming and smart cards. This link refers to what product I'm talking about.

formatting link
am just looking for some tips, links to tutorials, suggestions, guidelines etc that other people may have who may also have experience in this topic. As far as I understand, you are meant to write a program that goes into the

16F84 in the smart card and this program acts as a 'firmware'. You then use this 16F84 and firmware to access data in the 24LC16B eeprom. Is what I just stated correct? or is it done differently? My other question is, say if I made a device that reads and writes to the smart card eeprom, does my device need to provide a seperate clock (from a crystal for example) for the clock of the smart card? or should I generate a clock with the microcontroller in my device. Anyway, any useful comments, suggestions, answers to questions etc would be most helpful. Thanks

-Warren

Reply to
Warren Thai
Loading thread data ...

If you are unfamiliar with PICs, you may want to start with a PIC development system, which will include tutorials building up from scratch to a thorough understanding. I can recommend:

formatting link
Once you have that understanding, you will need to develop or buy a smartcard programmer. If you develop your own, it has to provide all the interface signals, with the correct timing (including power on timing) specified by the standard:

formatting link
Here is a suitable programmer:

formatting link

Basically, you follow much the same routine for program development for the smartcard as you do for the tutorial kit. The programmer will take care of all the clocks and interface signals needed.

The result will be a programmed smart card - which will start processing whenever it is placed in a smart card reader.

Going from zero to a programmed smart card produced in your own designed programmer is a leap too far for most.

-- Sue

Reply to
Palindrome

Thanks for the input. I already have experience with pic programming so I feel confident that I can do this. All I want to do is experiment with smart cards as a challenge and a hobby. My aim is to program a microcontroller (just call it A) that will connect to the smartcard (call the smart card microcontroller B) and read and write to its EEPROM memory. I'm thinking I will have to write a program to micro B that will use asynchronous serial transfer with one of its portb pins to input and output data. Micro B will operate as a 'middleman' between micro A and the EEPROM in the smartcard. So a 'firmware' needs to be written for micro B. Do others usually design their own firmware and communication protocol or do they usually use a set standard? This is where I am confused about. The smart card programmers out in the shops don't actually read or write to the EEPROM do they? I'm guessing they write the firmware and a different device is required to communicate with the smart cards firmware to read and write to the EEPROM. I'm also confused about the clock. Say I make a device with micro A. In this device I can connect a smart card. Then micro A can communicate to micro B and read/write the EEPROM. When the smart card is connected to the device, I want to know what clock source do I use for the smart card? Do I use a separate crytal oscillator? Thanks again for the input.

-Warren

Reply to
Warren Thai

OK. What a smartcard programmer does is first to load a special program into the PIC, called a bootloader. It does that in much the same way as any pic is programmed.

Once the bootloader is in place, it is run, allowing the programmer access to read and write to the EEPROM (via the PIC, of course).

The final step it that the PIC code is overwritten by the operational PIC code. At which point the EEPROM cannot be accessed by the programmer

- unless the operational code allows it. eg the operational code may contain debug routines which are essentially the routines contained in the bootloader.

Most people just buy a smartcard programmer - which comes with a bootloader for each of the cards supported.

You can, of course, write your own bootloader. It would typically take and parse text strings from the programmer. eg

REB 032F - which equates to READ_EEPROM_BYTE address 032F

If you write your own you can do things that the standard bootloader will not - eg read and write ASCII character mapping blocks.

You are correct that the smartcard EEPROM cannot be read or written directly by the programmer - it uses the PIC running the bootloader. However, that is only of academic interest as the programmer will normally do all of this transparently - so it appears that the EEPROM is being directly addressed.

The clock is external. It is provided by the programmer, when being programmed, and by the smartcard reader, when in normal use.

The ISO reference that I provided gives full details of what is acceptable as a clock signal - plus what is required for all the other signals.

Reply to
Palindrome

Reply to
Warren Thai

The question isn't confusing but it is hard to make the answer simple. The complete answer is given in the ISO reference. A very much simplified answer is that the clock needs to have an even mark-space ratio with a frequency between 1-5 MHz.

However the clock frequency is also constrained by a parameter called the etu, and has to be 372/etu.

The etu is basically the width of a transmission bit.

So, you start with the Baud rate that you intend to use when communicating with the card. That determines the etu. That determines the clock frequency.

So, let's say that you were using 9600 Baud. That gives a transmission bit width of 104 uSec. Which gives an etu of 104 uSec. Which gives a clock frequency of 372/104 = 3.577MHz.

I hope that is the answer that you were looking for.

-- Sue

-- Sue

Reply to
Palindrome

Reply to
Warren Thai

You appear to have answered your own question... The smartcard is not involved in generating the clock. Your external device(whether it be a programmer or cardreader) has to generate it.

Reply to
Palindrome

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.