首先，祝贺我成功地点亮了LED灯！

电路：
第1脚接正常的AVR RESET电路，和ATMega16一样，电容10μF。
第3脚通过一个200欧姆的电阻接发光二极管的正极。
然后按照ATMega16的电路图接上ISP下载口。

如图，插好USBASP。图中的两个HC595和一个8x8LED不用管，我以前就焊好了。

然后编写一个C文件，文件名tiny.c：
#include <avr/io.h>
#include <avr/eeprom.h>

int main()
{
    DDRB |= _BV(4); //把PB4设置为输出
    PORTB |= _BV(4); //把PB4设置为高电平
   
    eeprom_busy_wait();
    eeprom_write_byte(0x00, 0xa5);
    eeprom_busy_wait();
    eeprom_write_byte(0x01, 0xb6);
    eeprom_busy_wait();
    eeprom_write_byte(0x02, 0xc7);
    eeprom_busy_wait();
    eeprom_write_byte(0x03, PORTB);
    eeprom_busy_wait();
    eeprom_write_byte(0x04, DDRB);
    eeprom_busy_wait();
    eeprom_write_byte(0x05, PINB);
    eeprom_busy_wait();
   
    while (1);
}
为了方便起见，笔者是在Linux下用的avrdude+gccavr进行编译的程序。在Windows平台上和WinAVR等价。用ICC AVR的话就得把头文件改了，还要把_BV改成BIT。

Makefile：
# make
tiny.hex: tiny.c
    avr-gcc -mmcu=attiny13 -Wall -Os tiny.c -o tiny.o
    avr-objcopy -j .text -j .data -O ihex tiny.o tiny.hex

# make run   
run: tiny.hex
    sudo avrdude -p t13 -c usbasp -e -U flash:w:tiny.hex

在终端中执行make run（也可以先make后make run），把程序下载到芯片中。程序的运行结果是：LED亮了！

同时，程序运行后获得的EEPROM内容如下：

这说明，
PORTB = 0x10 （00010000）
DDRB = 0X10 (00010000)
PINB = 0x18 (00011000)

PORTB = 0x10 （00010000）
左边第一位是PB7（当然ATtiny13根本没这个端口）
左边第4位就是PB4，PORTB中只有这一位为1
右边最后一位是PB0

现在删掉EEPROM部分的代码。
#include <avr/io.h>

int main()
{
    DDRB |= _BV(4); //把PB4设置为输出
    PORTB |= _BV(4); //把PB4设置为高电平
    
    while (1);
}
程序运行结果：LED亮


#include <avr/io.h>

int main()
{
    DDRB |= _BV(4); //把PB4设置为输出
    PORTB &= ~_BV(4); //把PB4设置为低电平
   
    while (1);
}
程序运行结果：LED灭

令我奇怪的是，之前不能运行的以下程序：
#include <avr/io.h>

int main()
{
    DDRB = 0xff;
    PORTB = 0xff;
   
    while (1) {
        PORTB = 0xff;
    }
}
现在居然又能正常运行了。。。我靠！所以这个原因暂时还没找到。。。

闪烁灯程序，本人已证明该程序可以在ATtiny13A上正常运行。
#include <avr/io.h>
#define F_CPU 1000000U // 这个我是暂时乱写的晶振大小，我也不知道现在晶振大小是多少！！！！
#include <util/delay.h>

int main()
{
    DDRB = 0xff;
    PORTB = 0xff;
    
    while (1) {
        PORTB = 0xff;
        _delay_ms(1000);
        PORTB = 0x00;
        _delay_ms(1000);
    }
}

我的熔丝位被设置成了2A FF。因为CKSEL = 10，所以芯片是使用的内部的9.6 MHz晶振，又因为CKDIV8 = 0，所以晶振进行了8分频，因为9.6÷8=1.2，所以F_CPU应该被设置为1200000U:
#define F_CPU 1200000U

插上一个74HC595后，用Linux下的avrdude烧写的以下程序：
#include <avr/io.h>
#define F_CPU 1200000U
#include <util/delay.h>

int main()
{
    DDRB = 0xff;
    PORTB = 0xff;
   
    while (1) {
        PORTB = 0xff;
        _delay_ms(500);
        PORTB = 0x00;
        _delay_ms(500);
    }
}
可以正常运行。运行结果：LED亮0.5s灭0.5s。
但是，用AVR_frighter保存flash内容，擦除芯片，重新烧写保存的flash内容后，程序完全不能运行，LED完全不亮。
不过，用AVR_frighter读写熔丝位还是可以的。

这充分表明了：
我的推测1“因为ATtiny13的PB口不足8个I/O口，执行DDRB = PORTB = 0xff把全部8个I/O口都设置为1会引起程序故障而导致所有I/O口都不能输出任何电平。必须要执行DDRB |= _BV(4)单独设置一个I/O口为输出，程序才能正常运行” 是 错误的！
我的推测2“74HC595芯片影响了AVR_frighter对ISP程序下载的操作导致程序不能正常下载，而该芯片不影响avrdude下载程序” 可能是正确的。

现在通过实验证明推测2的正确性。
在ICC AVR中编写以下程序，并用AVR_frighter烧写：
#include <iot13Av.h> // ATtiny13A

void main(void)
{
    DDRB = 0xff;
    PORTB = 0xff;
   
    while (1) {
        PORTB = 0xff;
    }
}
程序运行结果：LED灯不亮。
把PORTB = 0xff;改成PORTB = 0x00;
再编译，烧写，LED灯仍然不亮！！！
这TMD还真是AVR_frighter的问题！

现在，马上用Linux下的avrdude重新烧写程序：
[octopus@pc3 ATTiny13]$ make run
avr-gcc -mmcu=attiny13 -Wall -Os tiny.c -o tiny.o
tiny.c:5:6: warning: return type of 'main' is not 'int' [-Wmain]
 void main()
      ^
avr-objcopy -j .text -j .data -O ihex tiny.o tiny.hex
sudo avrdude -p t13 -c usbasp -e -U flash:w:tiny.hex
[sudo] password for octopus:

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9007
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "tiny.hex"
avrdude: input file tiny.hex auto detected as Intel Hex
avrdude: writing flash (86 bytes):

Writing | ################################################## | 100% 0.76s

avrdude: 86 bytes of flash written
avrdude: verifying flash memory against tiny.hex:
avrdude: load data flash data from input file tiny.hex:
avrdude: input file tiny.hex auto detected as Intel Hex
avrdude: input file tiny.hex contains 86 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.58s

avrdude: verifying ...
avrdude: 86 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:FF, L:2A)

avrdude done.  Thank you.

[octopus@pc3 ATTiny13]$

程序正常运行！
（那个int main()写错了暂时不管了。。。）

笔者又把ICC AVR生成的hex文件复制到Linux下用avrdude烧写，LED亮了！程序正常运行。

所以，ATtiny13A芯片本身没有什么问题。我的电路也没有问题。问题主要出在AVR_frighter上，都怪它！以后不要再用AVR_frighter烧写ATtiny13的程序了！
AVR_frighter烧写gccavr和ICC AVR的程序都无法正常运行。
而Linux下的avrdude烧写gccavr和ICC AVR的程序都可以正常运行。
至于Windows平台下的WinAVR，因为用的编译器和linux下是相同的，所以我估计烧写后也可以正常运行。不过我还没有测试额。。。。

笔者又把74HC595取下来了。然后再用AVR_frighter烧写ICCAVR程序，LED不亮。再用avrdude烧写同一个hex文件（ICCAVR生成），LED亮。这证明：
不是74HC595芯片影响了AVR_frighter烧写程序。是AVR_frighter压根就没法正确地烧写ATtiny13芯片！

另外，4~13楼的程序中所有的int main()都改为void main(void)，笔者疏忽了，不过也不影响程序的编写。

时间过了一年半，问题终于解决了。。。。

现在事情已经彻底水落石出了。是AVR_frighter本身的问题导致的，它根本无法烧写程序到ATtiny13。至于开头第二次用avrdude烧写程序到芯片后LED灯还不亮的问题，是因为Makefile导致的。是# make run    下面那一行写错了，导致程序文件修改后执行make run时却没有重新编译就直接烧写到了芯片而出错。avrdude是可以正常烧写ATtiny13的。

avrdude烧写程序后也可以在控制台看到熔丝位的值：
avrdude: safemode: Fuses OK (E:FF, H:FF, L:2A)

avrdude done.  Thank you.

[octopus@pc3 ATTiny13]$