April 2004, Issue 165

BasicCard 101 (Part 2):
Use in a Liquid Nitrogen Monitor

INTERFACE TO THE AVR MCU

Before I ordered the BasicCard development kit, I wanted to be sure I could use the cards with my MCU of choice, the AVR series from Atmel. The BasicCard development kit contains software to program the cards themselves, as well as a few different programs to develop PC applications. However, the kit doesn’t provide any support for interfacing them to MCUs, apart from providing a technical reference document describing the ISO/IEC 7816-3 standard that the cards use for communication. From what I could see, it would have been quite time-consuming to personally write a suitable driver to allow AVR MCUs to talk to BasicCards. As luck would have it, the developer of the BASCOM AVR compiler (the language I use exclusively for all of my AVR-based projects) had a beta version of a driver library available. This was one of those good news/bad news situations. I was able to get the library free from the developer, but I was, at that time, the first and only beta tester! I ended up figuring out on my own some of the patches needed to make it work.

To interface a BasicCard to an AVR MCU using the Bascom compiler, you must run Bascom version 1.11.6.8 or newer. You must also load the BasicCard library (available from MCS) into BASCOM’s LIB folder.

Next, within your BASCOM program, you must do the following four things. First, use the CONFIG BCCARD command to tell the driver which port pins you have connected your BasicCard socket to. This is simple because you only have to tell it which port you are using and to which pins the *RESET and I/O lines are connected. This is clearly described in the documentation that comes with the library.

Second, you must declare each of your BasicCard commands to the BASCOM program using the BCDEF command. Because you have already written the Basic code that runs in the BasicCard, you will have already defined the commands that the BasicCard recognizes. These command names, followed by their parameter lists, are used with the BCDEF command.

Next, instruct the compiler to use the proper data rate. Use the $BAUD = 9600 and the $Crystal = 3579000 directives. Finally, issue a BCRESET command to initialize the BasicCard as soon as you see that a card has been inserted into the card socket.

After this preparation/initialization, all you have to do to access a particular command in the BasicCard is use the BCCALL procedure. This is similar to any Basic procedure, except that it includes some BasicCard-specific parameters. The following is the syntax for this command: 

BCCALL name( nad , cla, ins, p1, p2 [param1 , paramn]) 

where name is the name of the procedure in the BasicCard to call. It must be defined first with BCDEF. The name used with BCDEF and BCCALL does not need to be the same as the procedure in the BasicCard, because the CLA and INS bytes actually tell the BasicCard which command to execute. However, it makes sense to use the same names for consistency.

nad is the node address byte. Basic-Cards respond to all node address values; zero is used here as a default. cla is the class byte. It is the first of a 2-byte CLA-INS command. It must match the value you used for the command in the BasicCard program itself.

ins is the instruction byte. It is the second of the 2-byte CLA-INS command. The same consideration applies as for the CLA byte. p1 is parameter 1 of the CLA–INS header. (Use a zero for your purposes.) p2 is parameter 2 of CLA-INS header. (Again, use a zero for your purposes.) param1 through paramn are the parameters you want to pass to the BasicCard (as required by the command).

The BasicCard operating system employs a comprehensive error-reporting scheme. This is necessary in any device used for commerce, particularly in a device that you can pull out of its socket in the middle of program execution! Describing the error handling is beyond the scope of this article, but I will mention that the BCCARD library supports it to some extent. In essence, if the BasicCard returns an error, the library will set the Basic variable ERR and two status bytes—SW1 and SW2—will contain error codes. Many of these codes are predefined in the BasicCard protocol, but you can also set the value of these variables yourself within your BasicCard program should your code encounter an error condition.

In most designs, the card-in-socket switch will notify the program if the card is removed during use; but, if an actual data transaction is in progress when this happens, the BasicCard driver within Bascom may hang the program until a time-out interval passes. Depending on a number of variables, this might take up to a minute, so beware of this during debugging.

Before trying your own Basic-Card program, I recommend that you load the sample Bccard.bas program into your AVR MCU, program a BasicCard with the Calc demo program provided with the development kit, and try that combination. If everything is satisfactory, you will see the results of the communication between the two devices. You can then enter some numbers into your AVR MCU, and let the BasicCard act as a calculator.