SD card protocol. Secure Digital (SD) card pinout

As can be seen from the figure, after the command frame is transmitted, it is necessary to continue reading bytes (Ncr) from the microSD until a response (R1) is received, while the CS level must be active "0".

Depending on the command index, the answer may be not only R1(see set basic commands) on CMD58 response R3(R1 and the terminating 32-bit OCR value), and some commands need more NCR time and they will respond R1b. This is an R1 response followed by a busy flag (the signal on the "DO" line is held low by the card while the internal process continues). The host controller must wait until the end of the process until "DO" goes high (i.e. wait for 0xFF). As well as R2 when requesting the state of the STATUS register.

R1 response contains 1 byte, its structure can be seen in the table below. The R2 response consists of two bytes, the first byte R1 and the second R2 (see R2 structure table). And the answer R3, respectively, of 5 bytes.


R1 response at 0x00 means successful completion of the command, otherwise the corresponding flag will be set.

The structure of the answer R1.


The structure of the answer R2.


Initialization in SPI mode.

After resetting and powering on, the card is set by default to the MMC (Serial Peripheral Interface) protocol mode, to switch to SPI mode, do the following:

  1. After reaching the 2.2 V supply, wait at least a millisecond, set the DI and CS lines high and give about 80 pulses to the CLK pin. After this procedure, the card will be ready to accept the native team.
  2. Send command CMD0 (soft reset). The card should respond (R1) with the pending bit (0x01) set.
  3. Send command CMD1 (to start card initialization). Wait for a 0x00 response to confirm the completion of the process initialization.

Let me remind you that the CMD0 command must contain the correct CRC field. It makes no sense to calculate, since there are no arguments in this command, therefore it is constant and has a value of 0x95. When the card enters SPI mode, the CRC function will be disabled and will not be checked. The CRC option can be re-enabled with the CMD59 command.

As a result, the CMD0 command will look like this: 0x40.0x00.0x00.0x00.0x00.0x95.

  • command index - 0x40.
  • argument is 0x00.0x00.0x00.0x00.
  • CRC-0x95.

As for 80 pulses, they can be generated by transmitting the value 0xFF via SPI10 times in a rowat set high levels on the lines DI and CS.

After being idle for more than 5 ms, the memory card enters a power-saving mode, and is only able to receive commands CMD0, CMD1 and CMD58. Therefore, the initialization process (CMD1) must be repeated almost every time when reading / writing a data block or checking the card status.

For SDC cards in case of command rejectionCMD1 is recommended to use the ACMD41 command.

The initialization process itself can take a relatively long time (depending on the size of the card) and can reach hundreds of milliseconds.

Reading and writing a block of data.

By default, in SPI mode, the exchange between the microcontroller and the card is carried out in blocks of 512 bytes, so to write even one byte, you will first have to read the entire block and change the byte to overwrite it back. The block size can be changed in the CSD register of the memory card.

In order to avoid an addressing error when executing read / write commands, it is necessary that the address be clearly indicated at the beginning of the sector. To do this, you can reset bit "0" 3 bytes of the sector address, i.e. make it even, and the low value should always be 0x00.

Reading a block of data.

The data block reading algorithm is as follows:

  • After confirming the initialization, we send the CMD17 command (response R1), with the address of the required sector.
  • We send 0xFF before receiving the start byte 0xFE .
  • We accept a data block (by default 512 bytes) and 2 bytes CRC.

The CRC value is not required, but the acceptance procedure (transmission of 0xFF from the MCU) is required.

Block reading.


Write a block of data.

The algorithm for writing a data block is as follows:

  • If the idle time of the card was more than 5 ms, send the CMD1 command (response R1).
  • After confirming the initialization, we send the CMD24 command (response R1), with the address of the required sector.
  • We send the start byte 0xFE .
  • We send a data block (by default 512 bytes) and 2 bytes CRC.
  • We get a write confirmation byte.
  • We are waiting for the end of the recording (changes in byte 0x00).

The data block can be smaller than 512 bytes when changing the block length with the CMD16 command.

The CRC value is not required, but the procedure for passing any values ​​is necessary.

You can programmatically not evaluate idle time, but immediately give an initialization command. During software implementation, I encountered an incorrect write, for some reason all bytes were written to the sector with a shift to the left. The problem was solved only by passing the start bit (0xFE) twice.

Block record.


Acknowledgment byte when writing a data block.


Write / read several blocks in a row.

With the help of commands cmd18, cmd25 you can read / write several blocks in a row or the so-called multi-block read / write. If the number of blocks has not been set, then the read / write process can be stopped by CMD12 commands when reading, as well as by passing the token " Stop Tran" when recording, respectively.

Practical use.

The practical use of memory cards is quite wide. In his latest design, he used microSD to record readings from various sensors (temperature, alarms) every hour during the day. The data is saved as follows:

  • The year is taken as the last two digits - this corresponds to the first (main) byte of the memory card sector address.
  • Month, two digits - this corresponds to the second, most significant byte of the memory card sector address.
  • Day, two digits are multiplied by 2 (to avoid collision outside the sector boundary) - this is the third, middle byte of the memory card sector address.
  • The lower, fourth byte, respectively, is always "0".

As a result, the search for data by date is simplified, it is enough just to translate the request to the address of the sector and read from the card. With this method, data can be stored for several years. True, there are drawbacks, there is quite a lot of unused space. Although, if desired, you can use for other tasks.

Who needs to throw off a code fragment in assembler for 18 peaks.

Questions can be asked at..

We displayed the picture on the display from the sd card, but some points were missed in it, the first - connecting the card itself, the second - only part of the library functions was considered Petit FatFs Let's take a closer look at these points.

Communication with the card is possible via one of two interfaces, SPI or SD.



I must say that the SD interface can work in one-bit and four-bit modes.

The scheme for connecting the card via SPI is standard and looks like this, unused card pins must be connected to the power supply using a 10K resistor.


But in amateur designs, pull-up resistors are often neglected, simplifying the connection diagram.

It should be noted that when connected via SPI, the card is very demanding on the supply voltage and a small drop in the supply voltage leads to the inoperability of the card, this has been verified from personal experience, there is nothing to say about the SD interface, I have not tried it yet. All this was written to for power supply, it is necessary to install capacitors. As for the inductor, it must be rated for current up to 100mA, but it is not necessary to install it.

The diagrams shown above show that the card needs 3.3 volts to work, respectively, in the data transmission lines, the voltage should not go beyond the range of 0 - 3.3 volts, and here the question arises, what if the MC is powered by 5 volts?
The answer is simple, you need to match the data lines, and this can be done using a conventional resistive divider.


The diagram shows that the MISO line does not need to be matched as data is transmitted over this line from card to MK.
In fact, few people connect the card directly to the MK, it is much more convenient to connect a card connector to the MK or buy a shield with a connector and all the necessary harness.

We figured out the connection, now let's look at how to use the library Petit FatFs, which is designed for 8-bit microcontrollers with a small memory size.

The library consists of 5 files:
integer.h- a header file that describes the main data types.

diskio.h- a header file that declares the prototypes of low-level functions for working with the disk and the status codes they return.

diskio.c- low-level functions should be implemented in this file, initially there are "stubs".

pffconf.h- configuration file.

pff.h- header file in which the prototypes of functions for interacting with the disk file system are declared.

pff.c- the file contains implementations of functions for interacting with the disk file system.

It can be seen that in order for the library to work, it is necessary to implement low-level functions. But if we are talking about AVR or PIC, for them on the site you can download an example of working with the library, which has a file mmc, low-level functions are already implemented in it. It is also necessary to set the library configuration in the pff.h file and write the functions necessary for SPI to work.

Functions of Petit FatFs.

FRESULT pf_mount (FATFS*)- the function mounts/dismounts the disk. This function must be called before starting work with the disk, if you call the function with a null pointer, the disk is unmounted. The function can be called at any time.

Options
FATFS* fs- a pointer to an object of type FATFS, a description of this structure can be found in the pff.h file. We just need to declare a variable of this type.

Return values:
FR_OK (0)
FR_NOT_READY- the device could not be initialized
FR_DISK_ERR- an error occurred while reading from disk
FR_NO_FILESYSTEM- the drive does not have a valid FAT partition

FATFS fs;//Declare an object of type FATFS //Mount the disk if (pf_mount(&fs) == FR_OK) ( //The disk is mounted, working with it //Dismount the disk pf_mount(NULL); ) else ( //Failed to mount the disk )

FRESULT pf_open (const char* path)- the function opens an existing file. After the file is opened, you can work with it, that is, read from it and write to it. You can work with an open file until another file is opened. The function can be called at any time.

Options
const char* path- a pointer to a string indicating the path to the file. The path must be specified completely relative to the root directory, separating the directories with a slash.

Return values:
FR_OK (0)- returned in case of successful execution of the function
FR_NO_FILE- File not found
FR_DISK_ERR- disk error
FR_NOT_ENABLED- disk has not been mounted

FATFS fs;//declaring an object of FATFS type //mounting the disk if (pf_mount(&fs) == FR_OK) ( //opening the file located in the root directory if(pf_open("hello.txt") == FR_OK) ( //doing something ) //open the file located in the folder new if(pf_open("new/hello.txt") == FR_OK) ( //do something ) //dismount the disk pf_mount(NULL); ) else ( // failed to mount disk)

FRESULT pf_read(void* buff, WORD btr, WORD* br)- the function reads the specified number of bytes from the file and saves them to the buffer. If the number of bytes read is less than specified, then the end of the file has been reached.
#define _USE_READ 1

Options:
void*buff- pointer to the buffer in which the read data is stored
WORD btr- number of bytes to be read
WORD*br- a pointer to a variable that stores the number of bytes read.

Return values:
FR_OK (0)- returned in case of successful execution of the function
FR_DISK_ERR- disk error
FR_NOT_OPENED- the file was not opened
FR_NOT_ENABLED- disk has not been mounted

FATFS fs;//declare an object of type FATFS BYTE buff;//buffer for reading a file WORD br; // counter of bytes read // mount the disk if (pf_mount(&fs) == FR_OK) ( // open the file located in the root directory if(pf_open("hello.txt") == FR_OK) ( // read 10 bytes from it pf_read(buff, 10, &br); if(br != 10) ( //if br is not equal to 10 //it means we have reached the end of the file ) ) )

FRESULT pf_write(const void* buff, WORD btw, WORD* bw)- the function allows you to write data to an open file. In order for the function to work in the pffconf.h file, you need to write
#define _USE_WRITE 1

Options:
void*buff- pointer to the buffer we want to write, zero value finalizes the write
WORD btw- the number of bytes we want to write
WORD*bw- a pointer to a variable that stores the number of bytes that could be written. By analyzing this variable, you can find out whether the end of the file has been reached.

Return values:
FR_OK (0)- returned in case of successful execution of the function
FR_DISK_ERR- disk error
FR_NOT_OPENED- the file was not opened
FR_NOT_ENABLED- disk has not been mounted

Due to the fact that the library is designed for microcontrollers with a small amount of memory, this function has a number of limitations:

  • you cannot create new files, and you can only write to existing ones
  • file size cannot be increased
  • can't update timestamp
  • a write operation can only be started/stopped at a sector boundary
  • read-only file attribute cannot prevent writing

In order to understand the penultimate point, you need to know that the memory of the card is divided into blocks (sectors) of 512 bytes and recording can only be started from the beginning of the sector. Thus, if we want to write 1000 bytes, then the first sector will be written completely, and only 488 bytes will be written to the second, and the remaining 24 bytes will be filled with zeros.

To write to an open file, do the following:

  • set the pointer to the sector boundary, if set not to the boundary, the pointer will be rounded to the lower sector boundary
  • call the write function the desired number of times
  • finalize the entry by calling the function with a null pointer

In order to give an example of the work of the recording function, it is necessary to consider one more function.

FRESULT pf_lseek(DWORD offset)- sets the read/write pointer in the open file. You can set the pointer with an absolute or relative offset; for an absolute offset, you must pass a number to the function
pf_lseek(5000);
for relative, pass the value of the pointer to the current position fs.fptr and the amount of displacement
pf_lseek(fs.fptr + 3000);
In order for the function to work in the pffconf.h file, you need to write
#define _USE_LSEEK 1

Options:
DWORD offset is the number of bytes to shift the pointer to.

Return values:
FR_OK (0)- returned in case of successful execution of the function
FR_DISK_ERR- disk error
FR_NOT_OPENED- the file was not opened

You can write data to a file in the following way.
FATFS fs;//declare an object of type FATFS BYTE buff;//buffer for reading a file WORD br; // counter of bytes read // mount the disk if (pf_mount(&fs) == FR_OK) ( // open the file located in the root directory if(pf_open("hello.txt") == FR_OK) ( // set the pointer to the first sector pf_lseek(0); //write pf_write(buff, 10, &br); //finalize the write pf_write(0, 0, &br); ) )

I also leave here a piece of really working code that uses all the functions described above.
#define F_CPU 8000000UL #define buff_size 10 #include #include #include "diskio.h" #include "pff.h" #include "spi.h" FATFS fs;//declaring an object of type FATFS BYTE read_buff;//buffer for reading the file BYTE write_buff = "hello word";/// /buffer to write to file UINT br; // counter of bytes read int main(void) ( // mount the disk if (pf_mount(&fs) == FR_OK) ( // open the file in the folder new if(pf_open("new/hello.txt") == FR_OK) ( //set write pointer pf_lseek(0); //write pf_write(write_buff, buff_size, &br); //finalize write pf_write(0, 0, &br); //set read pointer pf_lseek(0); //read that that we wrote pf_read(read_buff, buff_size, &br); if(br != buff_size) ( //if br is not equal to buff_size //it means we have reached the end of the file ) ) //mount the disk pf_mount(NULL); ) while(1) ( ) )

FRESULT pf_opendir(DIR* dp, const char * path)- the function opens an existing directory and creates a pointer to an object of type DIR, which will be used to get a list of files in the open directory.
In order for the function to work in the pffconf.h file, you need to write
#define _USE_DIR 1

Options:
DIR *dp- pointer to a variable of type DIR.

const char * path- pointer to a string that contains the path to the directory, directories are separated by a slash

Return values:
FR_OK (0)- returned in case of successful execution of the function
FR_NO_PATH- could not find path
FR_NOT_READY- Failed to initialize disk
FR_DISK_ERR- disk error
FR_NOT_ENABLED- disk has not been mounted

//declaring variables FATFS fs; DIR dir; //mount disk pf_mount(&fs); //open directory pf_opendir(&dir, "MY_FOLDER");

FRESULT pf_readdir(DIR* dp, FILINFO* fno)- function allows you to read the contents of the directory. To do this, open a directory with the pf_opendir() function and call pf_readdir(). Each time the function is called, it will return the name of the object (folder/file) located in the specified directory. When it has gone through all the objects, it will return the null string in the fno.fname array element.
In order for the function to work in the pffconf.h file, you need to write
#define _USE_DIR 1

Options:
DIR *dp- pointer to a variable of type DIR, which must be previously declared

FILINFO *fno- a pointer to a variable of type FILINFO, which must be previously declared.

Return values:
FR_OK- successful completion of the function
FR_DISK_ERR- disk error
FR_NOT_OPENED- directory not open

FATFS fs; FRESULT res; FILINFO fno; DIR dir; //mount disk pf_mount(&fs); //open directory res = pf_opendir(&dir, MY_FOLDER); //read the contents of the directory for(;;)( res = pf_readdir(&dir, &fno); //check if there were any errors while reading // and if there are still files in the specified directory if ((res != FR_OK) || ( fno.fname == 0))( break; ) //display in a convenient way fno.fname usart_sendStr(fno.name); usart_sendStr(/r); )

And finally, I'll leave the working project here

SD cards are based on the older Multi Media Card (MMC) format, but most are physically slightly thicker than MMC cards. They also boast higher data transfer rates. DRM features are available but are little-used. SD cards generally measure 32 mm × 24 mm × 2.1 mm, but can be as thin as 1.4 mm, just like MMC cards.

There are different speed grades available. They are referred to with the same nx notation as CD-ROMs; a multiple of 150 kB/s. Devices with SD slots can use the thinner MMC cards, but the standard SD cards will not fit into the thinner MMC slots. MiniSD and MicroSD cards can be used directly in SD slots with an adapter. There are readers which allow SD cards to be accessed via many connectivity ports such as USB, FireWire.

Pin SD Mode SPI Mode
Name type Description Name type Description
1 CD/DAT3 I/O/PP Card detection / Connector data line 3 CS I Chip selection in low status
2 cmd PP command/response line DI I data input
3 Vss1 S GND VSS S GND
4 vdd S power supply VDD S power supply
5 CLK I Clock SCLK I Clock
6 Vss2 S GND VSS2 S GND
7 DAT0 I/O/PP connector data line 0 DO O/PP data output
8 DAT1 I/O/PP connector data line 1 RSV
9 DAT2 I/O/PP connector data line 2 RSV

SD cards interface is compatible with standard MMC card operations. All SD memory and SDIO cards are required to support the older SPI/MMC mode which supports the slightly slower four-wire serial interface (clock, serial in, serial out, chip select) that is compatible with SPI ports on many microcontrollers. Many digital cameras, digital audio players, and other portable devices probably use MMC mode exclusively. MMC mode does not provide access to the proprietary encryption features of SD cards, and the free SD documentation does not describe these features. As the SD encryption exists primarily for media producers, it is not of much use to consumers who typically use SD cards to hold unprotected data.

There are three transfer modes supported by SD: SPI mode (separate serial in and serial out), one-bit SD mode (separate command and data channels and a proprietary transfer format), and four-bit SD mode (uses extra pins plus some reassigned pins) to support four bit wide parallel transfers. Low speed cards support 0 to 400 kbit/s data rate and SPI and one-bit SD transfer modes. High speed cards support 0 to 100 Mbit/s data rate in four-bit mode and 0?25 Mbit/s in SPI and one-bit SD modes.

SD cards security features includes:

  • Copyright protection mechanism with the SDMI standard (Secure Digital Music Initiative)
  • Integrated CPRM file protection and encryption system (CPRM is a Content Protection for Recordable Media)

A few years ago in May 2011, the creator of the cult game Elite, David Breben, presented the first concept of a Raspberry Pi single-board computer. This moment became a turning point in my life. The idea of ​​making a computer the size of a flash drive was on the surface, but it only gained momentum with the help of the Raspberry Pi Foundation.

Already on July 25, 2011, the alpha version of the computer is being put into production. Unfortunately, the concept of the project has changed, and now it is positioned as a computer the size of a credit card. Despite this circumstance, millions of people followed him. I also obeyed the effect of the crowd, checking the official page of the project daily. A long and painful wait began for the "miracle" that happened on February 29, 2012 - the start of sales.

The Raspberry Pi could be purchased through the Farnell network or from RS Components. As it turned out, on February 29, only pre-orders could be made. None of the offices had these boards in stock. The first batch of devices was only 10,000 copies, so, given the excitement around the project, it was very difficult to place an order. However, after overcoming all difficulties, at 2:06 pm the same day, the computer was purchased for £46.73 from Farnell.

None of my foreign orders have been fulfilled for such a long time. I was extremely upset that Farnell, taking £20 for delivery, sent the package on May 29, 2012 (2 months later) by regular mail without a tracking number. Surprisingly, the symbiosis of the Royal and Russian mail delivered the package safe and sound already on June 22. It was the most desired package in the last few months, so, unable to withstand the stress, I had to take time off from work and run to the post office.

It makes no sense to talk about how to set up the Raspberry Pi for the first run. With an article on this topic, I was a couple of years late, many lines about this have already been written on other resources, and on Youtube enough videos have been posted. But I want to talk about a significant flaw in the design for me - the inconvenient location of the SD card slot. When the card is inserted, it strongly protrudes beyond the board, which spoils the appearance of a homemade case.

There are two options for solving this problem: solder the SD-> microSD adapter in parallel with the connector installed on the Raspberry Pi (you can read how to do this in an article on Habré), or use the Low-profile MicroSD-> SD adapter. The first option is simply unacceptable for me - well, the hand does not rise to solder the board, because. I'm afraid to spoil the presentation of my Malinka. I think that the best choice is to use a Low-profile adapter.

Initially, it was decided to purchase such an adapter in one of the foreign online stores. There is a choice, but the cost of such trinkets is simply prohibitive. The cheapest ones cost $10, and some of them look frankly homemade. The final decision to make the adapter myself was made after visiting the DIYGadget website, pay attention to how easy it is to repeat their creation.

Ready? Let's move from words to deeds. To make the adapter correctly, let's study the specification for SD and microSD cards. Everything that is necessary for manufacturing, I tried to systematize in table 1, 2.

Table 2: Pinout of SD memory cards

By connecting the corresponding contacts on the memory cards, and by combining Vss1, Vss2, we get the electrical circuit diagram of the adapter.

To make an adapter we need:
1) Holder for microSD (CF TFC-WPCE-08 MICROSD CARD) - 52.22 rubles.
2) A piece of double-sided foil fiberglass with an area of ​​\u200b\u200babout 4 cm 2 (2% of the position STEKLOTEKSTOLIT FOIL GIR.1.5MM 2 SIDES) - 3 rubles.
3) Materials for installation (ferric chloride, tin, flux) - 10 rubles.

Then the cost of the project will be 65 rubles 22 kopecks and a certain amount of free time. In order to reduce the cost of construction, you can replace the microSD card holder with a CF TFC-WPCER-08 MICROSD CARD. Unfortunately, this item was not available at the warehouse of CJSC Promelectronica, so I purchased a more expensive option. I draw your attention to the fact that if you change the type of holder, then you may not be able to use my template for LUT (laser-ironing technology).

For PCB design, I used Autocad, because my favorite SprintLayout could not please with the presence of the desired template. For those who like to modify the printed circuit board, you can download the source in DWG format, and if there is no such need, then a blank in PDF format (I recommend checking the dimensions before applying the template from PDF).

After the template is transferred to the board, I recommend drilling holes with a diameter of 0.5 mm to go from one layer to another.

I make the transition from layer to layer using a thin wire, having previously tinned the tracks of the future adapter. In those places where the holes are under the microSD holder, it is necessary to grind off drops of tin with a needle file so that it is installed without distortion. Lastly, we mount the holder. If various fluxes were used during the manufacturing process of the board, be sure to flush the board before pushing it into your Raspberry Pi.

Make the adapter yourself or buy - you choose. To make the choice more informed, especially for you, I have selected several links for purchase:
1) Raspberry Pi Premium Low-profile MicroSD (TF) to SD Card Adapter. Protect board.
2) Raspberry Pi Low-profile MicroSD to SD Card Adapter, SD card won't get damaged!!
3) MicroSD to "short" SD / RS-MMC adapter. For Everdrive carts, Raspberry Pi, etc.
4) Low-profile MicroSD to SD Card Adapter for Raspberry Pi.
5) SD card adapter for Raspberry pi REV2 + free shipping.

In conclusion, I would like to say that all material is intended for informational purposes only. The use of developments for commercial purposes is strictly prohibited. Reprinting of materials is possible only with my permission and subject to references to the source. Those who wish to support not only in word, but also in deed, as well as thank you - please contact me by mail.

To assemble the device yourself, you need to download the following files:
1. Source board for LUT in DWG format
2. Fee for LUT in PDF format

Good luck in your endeavors!!!

For as long as I can remember, I have always loved to read, but in the yard of the 21st century, and sometimes the necessary literature can only be found on the Internet. Yes, and you can read e-books on an electronic device such as a tablet, computer or reader. The result is a small device that can read text files from an SD or microSD card and display their contents on the screen.

The brain of the device is an Atmega32 microcontroller operating at a frequency of 8 MHz. The MK is clocked from an external quartz at 8 MHz; as a device screen, I used a small LCD indicator WH1604A on the HD44780 controller with a resolution of 4 lines of 16 characters each. The buttons used the usual clock, as for the SD card to connect it to the microcontroller, I used resistor dividers to match the logic levels.

Schematic diagram of the device:

In the diagram, the pinout is correct only for the SD card or SD adapter, use their pinout to connect other cards!

The device supports SD, miniSD and microSD memory cards up to 4GB formatted in FAT, FAT16 file system. It should be remembered that the device does not support directories, so all files must be written only to the root of the flash drive. Text files must be in the usual txt format and without formatting, file names must be no longer than 8 characters (not counting the extension).

When the device is turned on, the splash screen will appear on the display:

If the SD card is not installed in the device, is not connected correctly, or something else, the following message will appear:

If everything is in order, the main menu will appear:

Using the buttons, you can enter the "Browse files" item, where you can select the file you need to read.

In the "Settings" item, you can choose with which file extension to display in the "Browse Files".

And in the last paragraph "About the system ..." you can read information about the device, its author, etc.

I wrote the firmware for the device in the BASCOM-AVR environment using the AVRDOS library, the firmware occupies only 30% of the microcontroller program memory, so there is room for creativity. Inside, the device is assembled on two printed circuit boards: on one there is an MK with a body kit, on the other there is a connector for an SD card and matching chains of logical levels.

Here is a photo of the device inside:

For power, I used a 4.8V, 600mAh Ni-Cd battery. After flashing the microcontroller, you must install the following fuse bits:

List of radio elements

Designation Type of Denomination Quantity NoteScoreMy notepad
U1 MK AVR 8-bit

ATmega32

1 To notepad
D1, D2 rectifier diode

1N4001

2 To notepad
C1, C2 Capacitor22 pF2 To notepad
C3 electrolytic capacitor100uF1 To notepad
C4 Capacitor100 nF1 To notepad
R1 Resistor

10 kOhm

1 To notepad
R2-R4 Resistor

4.7 kOhm

3 To notepad
R5-R7 Resistor

1 kOhm

3 To notepad
LCD1 LCD displayLM014L1 To notepad
X1 Quartz8 MHz1 To notepad
Button 4 To notepad
Switch 1

Related publications