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.
http://www.jaycar.com.au/products_uploaded/ZZ-8800.pdf I 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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Warren Thai wrote:

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:
http://www.quasarelectronics.com/3081.htm
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:
http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816.aspx
Here is a suitable programmer:
http://www.maxking.com/programmers.htm
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Warren Thai wrote:

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.
--
Sue




Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Sorry to ask this again, perhaps my question wasn't clear. If a designed a device containing a microcontroller. Noting just a general device and not refering to a programmer. This device has one job to read and write to a smart card's eeprom via the smartcards 16F84. What clock should be connected to the smart card when it is connected to my device? I hope my question isnt confusing.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Warren Thai wrote:

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
That was a helpful post. However I'm sorry to say that my question was actually talking about the physical clock. That is (refering back to this 'device' i would supposedly design) would I use the device micro to generate the clock signal for the smart cart micro? Or should I have the smart card micro clock input connected to RC oscillator? Because the smart card micro will need a clock source otherwise the micro won't do anything. I ask because with the smart card I have in mind, the internal connections between the micro and the smart card terminals gives access to only OSC1 of the micro so then you cannot use say a crytal oscillator which requires OSC1 and OSC2 pins. So my real question is when I design a device to interface the card (not a programmer so not connected to computer) how do you provide the clock signal to run the smart card micro?

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Warren Thai wrote:

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.
--
Sue

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.