Страница 1 из 2
Вопрос про ATtiny13A
Добавлено: Вс ноя 13, 2016 16:58:01
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.
Получается микроконтроллер сгорел? Если да, то почему?

Re: Вопрос про ATtiny13A
Добавлено: Вс ноя 13, 2016 17:07:35
Z_h_e
Программатор не видит возможно потому, что неправильно установили фьюзы.
Что касаемо кода, а почему он должен мигать? Что должен делать МК после выполнения кода оператора PORTB |= (1 << 4); ?
Re: Вопрос про ATtiny13A
Добавлено: Вс ноя 13, 2016 17:54:33
divisоr
Z_h_e, про порты:
поставить тогда PNP и от него проверить, раз промахнулся с HIGH и LOW?
Фьюз стартового времени (0 ms) это SUT0 это критично?
Re: Вопрос про ATtiny13A
Добавлено: Вс ноя 13, 2016 18:05:17
Z_h_e
Ваша программа "мигать" не может.
Программатор почему перестал видеть МК я не знаю. Сгорел, отпал провод, неправильные фьюзы ...
Re: Вопрос про ATtiny13A
Добавлено: Вс ноя 13, 2016 18:14:43
divisоr
Z_h_e, я правильно понимаю, что вы говорите про отсутствие паузы между HIGH и LOW?
Тогда на B4 будет только LOW, если его подать на базу PNP, светодиод должен светится.
Правильно я рассуждаю?
Re: Вопрос про ATtiny13A
Добавлено: Вс ноя 13, 2016 18:19:42
Z_h_e
Абсолютно неправильно.
Ваша программа линейна, после выполнения PORTB |= (1 << 4);, какое действие должна выполнить программа следующми?
Хочу обратить внимание, что Вы не определили тактовую частоту, о чем должно было быть предупреждение, ну это другое., но тоже существенно.
Re: Вопрос про ATtiny13A
Добавлено: Вс ноя 13, 2016 18:27:37
divisоr
Z_h_e, пояснение понял (нет цикла), однако, это значит что на B4 будет тогда Vcc, или тоже нет? Других вариантов даже представить не могу...
Тактовую частоту пишу в main.h: #define F_CPU 9600000UL.
Еще не правильно, что проверял без RESET'а, но вроде тоже не должно поломать микроконтроллер. Хотя, за много ошибок уже надо себе сделать строгий выговор...
Re: Вопрос про ATtiny13A
Добавлено: Пн ноя 14, 2016 07:46:34
Engineer_Keen
Когда прошивали код, записывали фьюз-биты? А перед тем как записать - считывали? Знаете какую точно конфигурацию бит записали? Приведите тут. Могли отключить RESET, внутрисхемное программирование, переключить источник тактирования на внешний. Все это может быть причиной невозможности дальнейшего программирования.
Новый т13 по умолчанию работает на частоте 9.6 / 8МГц, а то, что вы в программе прописали F_CPU, без выставления фьюз только рассчитывает задержки для функции delay, подразумевая, что тактирование действительно идет на такой частоте.
Ну про отсутствие цикла в программе вы в курсе...
И еще. При использовании внутрисхемного программирования на контроллер нужно подавать питание ШТАТНЫМ способом. Контакт VCC в интерфейсе внутрисхемного программирования служит для согласования уровней МК и программатора, а не для питания МК. Ну и ресет конечно надо подтянуть к +питания, если этого не сделано ранее.
Re: Вопрос про ATtiny13A
Добавлено: Пн ноя 14, 2016 08:22:39
akl
Замечу, что согласно DS ATtiny13 fuse-bit SPIEN при последовательном программировании не получится отключить.
The SPIEN fuse is not accessible in SPI Programming mode
SPIEN доступен только при HV SERIAL программировании.
Re: Вопрос про ATtiny13A
Добавлено: Пн ноя 14, 2016 09:08:01
Z_h_e
Engineer_Keen писал(а):При использовании внутрисхемного программирования на контроллер нужно подавать питание ШТАТНЫМ способом. Контакт VCC в интерфейсе внутрисхемного программирования служит для согласования уровней МК и программатора, а не для питания МК.
Не считаю верным подавать одновременно два питания и нормально у меня всегда программировалось с питанием всей схемы от программатора.
Re: Вопрос про ATtiny13A
Добавлено: Пн ноя 14, 2016 09:45:17
akl
По мне, лучше наоборот питать программатор от программируемого устройства. Например, мой программатор потребляет 50 мА и работает в диапазоне от3 до 5V, а плата в которой стоит контроллер 200 мА.
Re: Вопрос про ATtiny13A
Добавлено: Пн ноя 14, 2016 10:14:30
Z_h_e
Понятно, что если схема потребляет много, то лучше от своего питания, но не одновременно же два питания.
Re: Вопрос про ATtiny13A
Добавлено: Пн ноя 14, 2016 10:31:13
Engineer_Keen
Если у программатора есть переключатель "внешнее/внутреннее питание", то никто 2 питания одновременно подавать и не будет. У меня в программаторе например, пока питание целевой платы не включишь программатор ругаться будет, что питания контроллера нет (AVRISP II). В некоторых схемах USBASP насколько я знаю, стоит джампер на питание рядом с разъемом программирования.
Re: Вопрос про ATtiny13A
Добавлено: Пн ноя 14, 2016 10:32:32
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.
В итоге, не знаю, толи руки нужно "выпрямлять", толи микроконтроллеры попались такие.
Re: Вопрос про ATtiny13A
Добавлено: Пн ноя 14, 2016 10:38:50
Z_h_e
Engineer_Keen писал(а): Контакт VCC в интерфейсе внутрисхемного программирования служит для согласования уровней МК и программатора, а не для питания МК.
Поясните тогда что Вы имели ввиду этой фразой.
Добавлено after 1 minute 27 seconds:
divisоr писал(а):Компилируется, а вот прошить этим hex не получается.
Наверное программатор на что-то ругается?
Re: Вопрос про ATtiny13A
Добавлено: Пн ноя 14, 2016 10:42:02
Engineer_Keen
Как это прошить конкретный hex не получается? От самого HEX файла это зависеть не может (ну разве что размер не влез, если он разный получается, но для такого кода это врядли). Сигнатура либо читается всегда, либо не читается никак (как и возможность прошить любой hex-файл). Если сигнатура не читается, или читается с ошибками, возможно дело в скорости программатора. Нужно попробовать поставить минимальную, вообще она должна быть не выше 1/4 тактовой, т.е. для новой тиньки не более 300кГц. Когда будет 100% читаться сигнатура, тогда можно уже и с кодом разбираться.
Z_h_e, Atmel вроде как так задумали, но потом появилась куча других программаторов, где питание берется от самого программатора.
Re: Вопрос про ATtiny13A
Добавлено: Пн ноя 14, 2016 10:42:49
akl
divisоr писал(а):Вчера решил проверить на другой ATtiny13A. Фьюзы вообще не переписывал, только прочитал...
Вот и выложили бы картинку прочтенных. Код здесь не при делах.
Re: Вопрос про ATtiny13A
Добавлено: Пн ноя 14, 2016 10:55:23
divisоr
akl, буду ждать вторую партию микроконтроллеров, надо же к истине прийти-то

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

Re: Вопрос про ATtiny13A
Добавлено: Пн ноя 14, 2016 13:38:23
divisоr
... прошей какую-нибудь чужую тестовую прошивку, заведомо проверенную.
BOB51, увы, таких нет.
Про программатор, я мегу 8-ую им по несколько раз прошивал - все нормально.
Тут именно с tiny13A нужно видимо проверять, в чем проблема.
Обидно, два микроконтроллера на тот свет отправил

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