Вопрос про ATtiny13A

divisоr

Подключил микроконтроллер к USBAsp, загрузил в него:

#include <avr/io.h>
#include <util/delay.h>

int main (void) {
//Set PORTB to all outputs
DDRB = 0xFF;
//turns B4 LOW
PORTB &= ~(1 << 4);
//PAUSE 5 seconds
_delay_ms(5000);
//turns B4 HIGH
PORTB |= (1 << 4);
}

Далее, отсоединяю микроконтроллер от программатора, подключаю питание, поставив параллельно электролитический (47 uF) и керамический (104) конденсаторы, далее, подключаю к PB4 резистор 220 Ом, и последовательно к резистору, анод светодиода, катод подключаю к минусу питания. В итоге, светодиод не мигает

Подключаю его к программатору, и он уже определяет сигнатуру микроконтроллера как 0x000000.

Получается микроконтроллер сгорел? Если да, то почему?

Реклама

Z_h_e

Программатор не видит возможно потому, что неправильно установили фьюзы.

Что касаемо кода, а почему он должен мигать? Что должен делать МК после выполнения кода оператора PORTB |= (1 << 4); ?

Реклама

divisоr

Z_h_e, про порты:

поставить тогда PNP и от него проверить, раз промахнулся с HIGH и LOW?

Фьюз стартового времени (0 ms) это SUT0 это критично?

Z_h_e

Ваша программа "мигать" не может.

Программатор почему перестал видеть МК я не знаю. Сгорел, отпал провод, неправильные фьюзы ...

Реклама

divisоr

Z_h_e, я правильно понимаю, что вы говорите про отсутствие паузы между HIGH и LOW?

Тогда на B4 будет только LOW, если его подать на базу PNP, светодиод должен светится.

Правильно я рассуждаю?

Реклама

Z_h_e

Абсолютно неправильно.
Ваша программа линейна, после выполнения PORTB |= (1 << 4);, какое действие должна выполнить программа следующми?

Хочу обратить внимание, что Вы не определили тактовую частоту, о чем должно было быть предупреждение, ну это другое., но тоже существенно.

Реклама

divisоr

Z_h_e, пояснение понял (нет цикла), однако, это значит что на B4 будет тогда Vcc, или тоже нет? Других вариантов даже представить не могу...

Тактовую частоту пишу в main.h: #define F_CPU 9600000UL.

Еще не правильно, что проверял без RESET'а, но вроде тоже не должно поломать микроконтроллер. Хотя, за много ошибок уже надо себе сделать строгий выговор...

Engineer_Keen

Когда прошивали код, записывали фьюз-биты? А перед тем как записать - считывали? Знаете какую точно конфигурацию бит записали? Приведите тут. Могли отключить RESET, внутрисхемное программирование, переключить источник тактирования на внешний. Все это может быть причиной невозможности дальнейшего программирования.
Новый т13 по умолчанию работает на частоте 9.6 / 8МГц, а то, что вы в программе прописали F_CPU, без выставления фьюз только рассчитывает задержки для функции delay, подразумевая, что тактирование действительно идет на такой частоте.
Ну про отсутствие цикла в программе вы в курсе...

И еще. При использовании внутрисхемного программирования на контроллер нужно подавать питание ШТАТНЫМ способом. Контакт VCC в интерфейсе внутрисхемного программирования служит для согласования уровней МК и программатора, а не для питания МК. Ну и ресет конечно надо подтянуть к +питания, если этого не сделано ранее.

akl · Сообщение **akl** » Пн ноя 14, 2016 08:22:39

Замечу, что согласно DS ATtiny13 fuse-bit SPIEN при последовательном программировании не получится отключить.

The SPIEN fuse is not accessible in SPI Programming mode

SPIEN доступен только при HV SERIAL программировании.

Z_h_e

Engineer_Keen писал(а):При использовании внутрисхемного программирования на контроллер нужно подавать питание ШТАТНЫМ способом. Контакт VCC в интерфейсе внутрисхемного программирования служит для согласования уровней МК и программатора, а не для питания МК.

Не считаю верным подавать одновременно два питания и нормально у меня всегда программировалось с питанием всей схемы от программатора.

akl · Сообщение **akl** » Пн ноя 14, 2016 09:45:17

По мне, лучше наоборот питать программатор от программируемого устройства. Например, мой программатор потребляет 50 мА и работает в диапазоне от3 до 5V, а плата в которой стоит контроллер 200 мА.

Z_h_e

Понятно, что если схема потребляет много, то лучше от своего питания, но не одновременно же два питания.

Engineer_Keen

Если у программатора есть переключатель "внешнее/внутреннее питание", то никто 2 питания одновременно подавать и не будет. У меня в программаторе например, пока питание целевой платы не включишь программатор ругаться будет, что питания контроллера нет (AVRISP II). В некоторых схемах USBASP насколько я знаю, стоит джампер на питание рядом с разъемом программирования.

divisоr

Вчера решил проверить на другой ATtiny13A. Фьюзы вообще не переписывал, только прочитал... Далее, сделал такой код:

Код: Выделить всё

//these are the include files. They are outside the project folder
#include <avr/io.h>
#define F_CPU 9600000UL
#include <util/delay.h>

int main (void) {
//Set PORTB to all outputs
DDRB = 0xFF;
while(1) {
 // turns B4 HIGH
 PORTB |= (1 << 4);
 // PAUSE 5 seconds
 _delay_ms(5000);
 // turns B4 LOW
 PORTB &= ~(1 << 4);
 // PAUSE 5 seconds
 _delay_ms(5000);
}
}

Компилируется, а вот прошить этим hex не получается. Нашел такой код:

Код: Выделить всё

#include <avr/io.h>
#define F_CPU 9600000UL
#include <avr/delay.h>

int main(void)
{
DDRB = (1 << PB0);
PORTB = (1 << PB1);
while(1)
if (!(PINB & (1 << PB1))) //если нажата кнопка
{
_delay_ms(50); //задержка, для пропуска дребезка контактов кнопки
if (!(PINB & (1 << PB1))) //если кнопка всё ещё нажата
PORTB ^= (1 << PB0); //изменить значение на PB0 противоположным
while(!(PINB & (1 << PB1))); //ждать, пока не будет отжата кнопка
}
return 0;
}

Он скомпилировался и прошился. Не знаю, чем он, по сравнению с колом выше, так отличается пробовал использовать avr библиотеку delay и добавить return 0, но ко все равно записываться не хотел.

В итоге, снова сделал hex и второго кода, и он опять записался. Сделал запрос сигнатуры, дабы убедиться что микроконтроллер "жив", и проверять его работу на втором коде, получил 0x000000.

В итоге, не знаю, толи руки нужно "выпрямлять", толи микроконтроллеры попались такие.

Z_h_e

Engineer_Keen писал(а): Контакт VCC в интерфейсе внутрисхемного программирования служит для согласования уровней МК и программатора, а не для питания МК.

Поясните тогда что Вы имели ввиду этой фразой.

Добавлено after 1 minute 27 seconds:

divisоr писал(а):Компилируется, а вот прошить этим hex не получается.

Наверное программатор на что-то ругается?

Engineer_Keen

Как это прошить конкретный hex не получается? От самого HEX файла это зависеть не может (ну разве что размер не влез, если он разный получается, но для такого кода это врядли). Сигнатура либо читается всегда, либо не читается никак (как и возможность прошить любой hex-файл). Если сигнатура не читается, или читается с ошибками, возможно дело в скорости программатора. Нужно попробовать поставить минимальную, вообще она должна быть не выше 1/4 тактовой, т.е. для новой тиньки не более 300кГц. Когда будет 100% читаться сигнатура, тогда можно уже и с кодом разбираться.

Z_h_e, Atmel вроде как так задумали, но потом появилась куча других программаторов, где питание берется от самого программатора.

akl · Сообщение **akl** » Пн ноя 14, 2016 10:42:49

divisоr писал(а):Вчера решил проверить на другой ATtiny13A. Фьюзы вообще не переписывал, только прочитал...

Вот и выложили бы картинку прочтенных. Код здесь не при делах.

divisоr

akl, буду ждать вторую партию микроконтроллеров, надо же к истине прийти-то

BOB51

Может попроще сделать - прошей какую-нибудь чужую тестовую прошивку, заведомо проверенную.
Тем самым отделим неисправность кристалла/программатроа от ошибок в прожке.
Да на заведомо проверенных железе и прожке-оболочке самого программатора.
СОМ - порт на компе имеется (интегрированный у материнку)?
и какая "форточек" установлена (ХР, семерка 32 или 64 разрядная)?

divisоr

... прошей какую-нибудь чужую тестовую прошивку, заведомо проверенную.

BOB51, увы, таких нет.

Про программатор, я мегу 8-ую им по несколько раз прошивал - все нормально.

Тут именно с tiny13A нужно видимо проверять, в чем проблема.

Обидно, два микроконтроллера на тот свет отправил

И даже не понял как так получилось...