проблема с ATmega16, помогите новичку Опции

[junoSynthesizer]

люди, я щас буду головой об стенку биться всю ночь мучаюсь а ничего не работает, как в принципе уже и мозг под утро

ситуация следующая

есть кристалл АТмега16-16PI, распаяный на монтажке с питанием 5В.
есть программатор СТК200, собраный один в один со схемой с сайта ПОНИпрога
собственно понипрог версии 2,06f который даёт Тест ОК при проверке программатора

теперь даже не знаю как описать собственно проблему...

я хотел спаять управлялку стеклоочистителем для своей старенькой машины... пару кнопок, таймер... ничего сложного. думал, для начального освоения АВР пойдёт. ну, написал прогу на асме, залил, смотрю - не работает. исправил кой чаво - всё равно не работает. потом думаю, дай ка я начну с простого... и написал следующее:

код в АВРстудии версии 4.12 билд 460:
.include "m16def.inc"

.def tmp = r16

.cseg
.org 0

jmp reset


reset:

ldi tmp, 0b11111111
out DDRC, tmp

main:

ldi tmp, 0b00000001

nop_cicle:
rol tmp
out PORTC, tmp
nop
jmp nop_cicle

;----------------------------

вот такой вот код. просто как сиськи первого размера.


ну думаю, щаз увижу имульс какой-то частоты. беру осциллограф, встаю на 0 пин порта С и о чудо! импульс! 1 пин - импульс.... а дальше - 2 пин - единица, 3 - единица, 4 и 5 - нули, 6 и 7 - показывают правильный импульс.
получается, что в порту работают только два старших и два младших бита, а средние - показывают детскую неожиданность.
думаю, может что с осциллографом? иду и смотрю на цифровом (кажись Тектроник за 7 косарей) - всё идентично с показаниями старого советского осциллографа.

затем пишу другую программу:

.include "m16def.inc"

.def tmp = r16
.def tmp1 = r17

.cseg
.org 0

jmp reset

reset:

main:

ldi tmp, 0b11111111
out DDRB, tmp ; так же ставил ДДРЦ, ДДРА, ДДРД

ldi tmp, 0b00000000
ldi tmp1, 0b00000001


nop_cicle:
add tmp, tmp1
nop
out PORTB, tmp
nop
jmp nop_cicle
;------------------------------------------------

ну и по идее что я должен увидеть? делитель частоты. осциллограф.... порт C - те же пины работают, те же не работают. другие порты - ВООБЩЕ нули.

беру другую атмегу16..... ****, то же самое!

сто раз проверяю схемотехнику монтажки - всё правильно (да и негде там ошибиться! )

может я где-то чего-то не дочитал о назначении портов?

что может быть? кто-то знает?

[junoSynthesizer]

но факт остаётся фактом - после установки фьюза ДЖТАГА - чтение флеша даёт нумерацию ячеек памяти, после ирейза - чистый флеш.

вы лучше скажите, когда жмёшь read фьюзов в свежекупленной атмеге какие должны быть отмечены галочкой в понипроге?

[WHALE]

галочкой(0) должны быть:
JTAGEN,SPIEN,BOOTSZ1,BOOTSZ0,SUT0,CKSEL1,CKSEL2,CKSEL3.
А че,даташита нету?

[junoSynthesizer]

даташита есть!
спросил потому, что у меня ни один фьюз не помечен (может чего не знаю как должно быть) ! => понипрог не читает фьюзы, но не читает только на эту атмегу! завтра ещё 2313 попробую прочесть...

[bodja74]

Вообще мега16 пользуюсь более 2 лет,и проблема была только из за JTAG.Про остальные порты подобное первый раз слышу.
Вот настройки меги16 - отключение JTAG и частота 8Мгц.

Эскизы прикрепленных изображений

 

[bodja74]

Еще,похоже у Вас кристалл дейсвительно сидит в защите.
Подайте команду "стереть кристалл" - она должна снятся.
Как только вы прочитаете эфки,вы сможете прочитать и фузы , и перебить если нужно.
При прошивке лучше подавать команду "записать кристал полностью" ,чем
"прошить флеш",в противном случае прошивка будет накладыватся поверх предыдущей,что приводит
к ошибке верификации.

[defunct]

Ничего пони прог не путает для меги16. Программирую им мегу три месяца(в том числе и фьэы). Все нормально.

Хотя я и не пользуюсь ponyprog'ом вообще. Но ситуация описанная автором поста напрямую свидетельствует о том, что были прошиты LOCK's в режиме LB MODE3.

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

Неправильно знаете.. LOCKS снимаются командой стирания (ChipErase).

Ваш ответ из разряда, "слышал звон да непонял откуда он" ;>
Здесь речь не идет о запрете ISP соответвующим fuse'ом SPIEN, т.к. запретить этот fuse по ISP вообще-то не представляется возможным. LOCK's по ISP программировать можно, и нужно если речь идет о коммерческом изделии. Но очевидно у ponyprog'a, который можно отнести только к разряду любительских программаторов, имеются проблемы с программированием или отображение FUSES/LOCKs. Это факт.

Я бы, конечно, посоветовал автору вместо того чтобы лочить JTAG интерфейс - наоборот приобрести JTAGICE и ощутить все прелести внутрисхемной отладки. Из программаторов посоветовал бы приобрести AVRISP по критериям - скорость программирования и качество поддержи. Однако если он не собирается вплотную работать с AVR, тогда вероятно бесплатный AVReal через STK200/byteblaster будет самым лучшим выбором, т.к. достаточно надежен и судя по постам автора AVReal - на порядок более быстр по сравнению с другими LPT программаторами.

Сообщение отредактировал defunct - Aug 6 2006, 20:28

[SergSit]

За ошибку извените, признаю. Но проблем с программированием (по крайней мере с ATmega16)у пони нет. Это тоже факт. И если вы им не занимались ,помойму , не надо говорить о проблемах. Еще раз повторяю програмирую мегу16 пони_прогом месяца 3 , проблем нет. В том числе и фьюзами. Надо только помнить, что "1" фьза(незапрограмирован) есть пустая клетка. И "0" фьюза (запрограмирован) стоит галочка.

The ATmega16 provides six Lock bits which can be left unprogrammed (“1”) or can be
programmed (“0”)

Сообщение отредактировал SergSit - Aug 7 2006, 21:12

[junoSynthesizer]

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

пришёл я на работу, отобрал у людей рабочий прогграмматор, которым они кодили разные "классики". принёс домой, попробовал - аналогичная ситуация. (нумерация во флеше и нет фьюзов). принёс оба программатора на работу, подключил свой - тестится пони прогом, но не видит !никаких! кристаллов. включил рабчий программатор - теститься, видит кристалл, и атмегу 16 и её фьюзы! чудо! программлю JTAGEN, прекрасно! думаю, ну, дело в моём программаторе.
приношу всё домой, подключаю свой программатор к своему компу.. и тихо афигеваю. видится атмега 16, её флеш, её фьюзы, всё пишется и читается, в т.ч. и если повторно зашить и отшить JTAGEN.

потом правда долго догонял, почему у меня не работает порт А... но догнал =)

что могло послужить причиной аномальной работы на моём компе двух программаторов, а после того как я их повозил по городу - к работе обоих? (кста у меня комп не перезагружался между подключениями!) но что больше меня волнует, почему мой программатор работает у меня дома, но не работает на рабочем компе?

[bodja74]

У меня была подобная загадка природы из за блока питания.
Еще была проблема ,прикупил два программатора под ПОНИ и КОМ- один простенький JDM,
другой навороченый от КиевСат (карточки под спутник,карточки SIM,мобилы,Pfoenix,PIC,AVR ,ну и разнокалиберная память само собой),так вот на стационарном компе оба работали, на буке только КиевСат.Проблема оказалась в напряжении уровней КОМ порта,в буке было +\- 5в заместь +\-12в.

[junoSynthesizer]

снова обращаюсь за помощью к знающим форума сего =)))


не очень уверен куда мне писать - в подраздел ИАР или в общий форум по АВР... поэтому напишу в эту тему =)


итак, суть задачи, которую реализовываю:

необходимо сделать генератор импульсов с разной (регулируемой независимо) длительностью единицы и нуля + по переключению испольнять пару строк кода.

что используется: вся та же атмега16, в качестве среды программирования - ИАР, среда отладки - АВР студия.

идея реализации: после неудавщихся экспериментов с режимом СТС таймера_1 решил делать через прерывание по переполнению того же таймера_1, поскольку длительность удержания 1 и 0 довольно большая и измеряется в десятках секунд.

итак, в режиме СТС идея не работала. думал, что что-то неправильно работает именно из-за режима. стал экспериментировать с прерыванием по переполнению (куда уж проще?). код обработчика кнопки вкл/выкл:

if (on = ~on)
{
PORTC = 0xff;

setbit(TIMSK, TOIE1);
setbit(TCCR1B, CS11);
setbit(TCCR1B, CS10);

TCNT1L = imp_L;
TCNT1H = imp_H;
}
else
{
clrbit(TIMSK, TOIE1);

TCCR1A = 0;
TCCR1B = 0;
TCNT1 = 0;
OCR1A = 0;
OCR1B = 0;
ICR1 = 0;

PORTC = 0x00;
}


примечание: clrbit и ей подобные функции работают корректно - это 200%.


код обработчика прерывания переполнения таймера:
#pragma vector = TIMER1_OVF_vect
__interrupt void impulse_change(void)
{
if (PORTC == 0x00)
{
TCNT1L = imp_L;
TCNT1H = imp_H;
}
else
{
TCNT1L = pause_L;
TCNT1H = pause_H;
}

PORTC = ~PINC;
}


комментарии по поводу кода и как он по идее должен работать (и работает в симуляторе!!!):
простейший кусок кода, который при включении устройства должен выдать 1 на выходе (порт С в данном случае), далее по вхождению в прерывание этот сигнал постоянно инвертировать. прикол в том, что он должен предустанавливать (определёнными заранее и, возможно, динамически меняющимися значениями), как в инициализации таймера (длительность первой единицы), так и в прерывании, регистр TCNT1 для получения необходимых длительностей сигналов.

теперь, как это всё работает в реальной жизни:
а работает почти правильно, за исключением одного смертельного дя меня глюка:
после инициализации таймера и его запуске, первый цикл счёта от 0000 до ФФФФ он деалет абсолютно не обращая внимания на предустановки TCNT1. соответственно, первый импульс длится слишком дохрена, а после вхождения первый раз в прерывание - всё устаканивается и предустановки берутся в расчёт, схема начинает работать правильно.

что уже предпринималось (и не привело к изменениям):
не ресетя контроллер, выключаю генерирование, включаю его снова - та же картина.
менял порт вывода
менял места первой инициализации регистра TCNT1
делаю тотальное обнуление регистров таймера при запуске процессора
менял структуру проги
менял делители частоты

делал финт ушами: ставил сначала прямую подачу частоты на счётчик, а по первому вхождению в прерывание - добавлял ещё один CS, деля тем самым частоту счёта. всё равно один раз он после этого просчитывает до ФФФФ.

и самое странное, что меня настораживает и заставляет задуматься: сразу после инициализации таймера и установки значений выставляю вручную флаг прерывания по переполнению - !и всё равно! проц ведёт себя абсолютно точно так же - первый импульс ооооочень длинный! он не входит в прерывание пока не досчитает до FFFF от 0000!


неделю бъюсь головой о стенку и понимаю что ошибся где-то в мелочи, помогите увидеть, где!

[singlskv]

setbit(TCCR1B, CS11);
setbit(TCCR1B, CS10);

Вот так нельзя
CSx нужно устанавливать одной командой.

if (on = ~on)
{
PORTC = 0xff;

setbit(TIMSK, TOIE1);
setbit(TCCR1B, CS11);
setbit(TCCR1B, CS10);

TCNT1L = imp_L;
TCNT1H = imp_H;
}
else
{
clrbit(TIMSK, TOIE1);

TCCR1A = 0;
TCCR1B = 0;
TCNT1 = 0;
OCR1A = 0;
OCR1B = 0;
ICR1 = 0;

PORTC = 0x00;
}

У Вас сильно попутана последовательность программирования регистров таймера.
Сначала программируем TCNT1,OCR1A,OCR1B,TCCR1A и т.д.,
затем запускаем таймер TCCR1B=(1<<CS11)|(1<<CS10).

[junoSynthesizer]

позволю доложить, что эти советы к положительным результатам не привели

по поводу выставления CSx одной командой, позволю высказать 2 возражения. если уж одной командой - то
TCCR1B |= (1 << CS11) | (1 << CS10);
а не
TCCR1B = (1 << CS11) | (1 << CS10);
чтобы оставить целыми все остальные разряды. поправьте меня если я ошибаюсь.

имхо, эти биты можно выставлять и последовательно. ведь по сути, счётчик запускается, и успевая (или не успевая) сделать пару тиков переходит к более длительному интервалу инкремента, что при моей точности "+/- километр" не принципиально.

что же качсается обнуления таймера, то имхо нет особой важности в последовательности. а вот при инициализации - есть, и я инитил регистры так, как было описано в предыдущем посте... результат прежний.


ещё версии? кто-то сталкивался с таким?

Сообщение отредактировал junoSynthesizer - Sep 8 2006, 14:32

[singlskv]

код обработчика прерывания переполнения таймера:
#pragma vector = TIMER1_OVF_vect
__interrupt void impulse_change(void)
{
if (PORTC == 0x00) <-------- наверное все-таки дожно быть PINC ?
{
TCNT1L = imp_L;
TCNT1H = imp_H;
}
else
{
TCNT1L = pause_L;
TCNT1H = pause_H;
}

PORTC = ~PINC;
}

[_Bill]

if (on = ~on)
{
PORTC = 0xff;

setbit(TIMSK, TOIE1);
setbit(TCCR1B, CS11);
setbit(TCCR1B, CS10);

TCNT1L = imp_L;
TCNT1H = imp_H;
}
else
{
clrbit(TIMSK, TOIE1);

TCCR1A = 0;
TCCR1B = 0;
TCNT1 = 0;
OCR1A = 0;
OCR1B = 0;
ICR1 = 0;

PORTC = 0x00;
}


примечание: clrbit и ей подобные функции работают корректно - это 200%.


код обработчика прерывания переполнения таймера:
#pragma vector = TIMER1_OVF_vect
__interrupt void impulse_change(void)
{
if (PORTC == 0x00)
{
TCNT1L = imp_L;
TCNT1H = imp_H;
}
else
{
TCNT1L = pause_L;
TCNT1H = pause_H;
}

PORTC = ~PINC;
}


комментарии по поводу кода и как он по идее должен работать (и работает в симуляторе!!!):
простейший кусок кода, который при включении устройства должен выдать 1 на выходе (порт С в данном случае), далее по вхождению в прерывание этот сигнал постоянно инвертировать. прикол в том, что он должен предустанавливать (определёнными заранее и, возможно, динамически меняющимися значениями), как в инициализации таймера (длительность первой единицы), так и в прерывании, регистр TCNT1 для получения необходимых длительностей сигналов.

теперь, как это всё работает в реальной жизни:
а работает почти правильно, за исключением одного смертельного дя меня глюка:
после инициализации таймера и его запуске, первый цикл счёта от 0000 до ФФФФ он деалет абсолютно не обращая внимания на предустановки TCNT1. соответственно, первый импульс длится слишком дохрена, а после вхождения первый раз в прерывание - всё устаканивается и предустановки берутся в расчёт, схема начинает работать правильно.

что уже предпринималось (и не привело к изменениям):
не ресетя контроллер, выключаю генерирование, включаю его снова - та же картина.
менял порт вывода
менял места первой инициализации регистра TCNT1
делаю тотальное обнуление регистров таймера при запуске процессора
менял структуру проги
менял делители частоты

делал финт ушами: ставил сначала прямую подачу частоты на счётчик, а по первому вхождению в прерывание - добавлял ещё один CS, деля тем самым частоту счёта. всё равно один раз он после этого просчитывает до ФФФФ.

и самое странное, что меня настораживает и заставляет задуматься: сразу после инициализации таймера и установки значений выставляю вручную флаг прерывания по переполнению - !и всё равно! проц ведёт себя абсолютно точно так же - первый импульс ооооочень длинный! он не входит в прерывание пока не досчитает до FFFF от 0000!


неделю бъюсь головой о стенку и понимаю что ошибся где-то в мелочи, помогите увидеть, где!

Что означает Выражение

Код

  if  (on = ~on)
     ........

Вы переменную on каким значением инициализируете, если инициализируете вообще? И потом, такая конструкция не очень надежна. Если хотя бы один бит будет ненулевым, то данное условие будет выполняться всегда. Для подобных целей лучше использовать один бит. Это повысит надежность Вашей программы.

[junoSynthesizer]

2 _Bill

не там копаете. это тупо переменная она или 0xFF или 0x00 (инитится нулём), соответственно её инвертируем и получаем переключение состояний. это работает стопудов, не здесь глюк






2 singlskv

тоже не то. порт С - выходной. соответсвенно...
пин С я в конце функции использую чисто для читабельности и компактности кода.