помощ лузерам в прогромировании МК PIC

[Aaantonnn15]

А если подумать?
И до конца предложения цитировать надо.

О чем, Вы мне предлагаете подумать??? Повторюсь еще раз. Изучайте даташит. В нем всё есть.

Взята из даташита на PIC12F675. Судя по рисунку можно понять, что и при нулевом значении константы генератор будет работать, но на минимальной частоте.

[m.ix]

[OKF]

О чем, Вы мне предлагаете подумать???

)) Внимательно прочтите моё предложение.
Подумайте о том, каким образом производится калибровка.
И что будет если калибровочная константа будет отсутствовать.

[Aaantonnn15]

)) Внимательно прочтите моё предложение.

Вот дословно Ваше сообщение. Пусть модераторы простят меня за флуд -
Пик будет перезапускаться, если он использует OSСCAL, а вместо OSСCAL, будет вовсе не OSСCAL)).

OSCCAL - это вообще регистр! В который можно поместить значение от 00 до FF. При чем здесь перезапуск мк. Взгляните на предыдущий мой пост. На рисунке именно этот регистр сверху над каждым битом есть R/W-n. n - принимает значение 0 или 1. Те значения, которые указанны в даташите - это значения при сбросе мк по условию POR. Получившееся значение(10000000) соответствует среднему значению!

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

Подумайте о том, каким образом производится калибровка.

Чего тут думать??? Даже если стереть калибровочную константу, то-есть превратить её в 00 или в FF, то в регистр запишется это значение. И частота генератора скорректируется на неё.

[Aaantonnn15]

В одном из постов предлагал попробовать отключить сторожевой таймер WDT. Скорее всего вся проблема в нем.

Если прочесть про регистр OSCCAL, то в даташите написано, что от содержит биты для увеличения или уменьшения частоты в ПРЕДЕЛАХ 4 МГЦ. И не более.

[КРАМ]

Чего тут думать??? Даже если стереть калибровочную константу, то-есть превратить её в 00 или в FF, то в регистр запишется это значение. И частота генератора скорректируется на неё.

Да ладна...
Калибровочная константа записана в виде КОМАНДЫ retlw XX, где ХХ и есть та самая константа.
То есть записанный в последней ячейке флеша код будет 0x34XX, а если его стереть, то будет ox3FFF, что означает NOP.
И вызов этого адреса флеша приведет не к возврату константы в аккумулятор и адреса возврата из стека в программный счетчик, а переход к СЛЕДУЮЩЕМУ АДРЕСУ ФЛЕША. И этот адрес будет НУЛЕВЫМ. Сиречь контроллер перезапустится.
Чтобы этого не произошло, нужно либо записать ту же retlw с любой константой, либо не вызывать этот адрес флеша в программе.

OSCCAL - это вообще регистр! В который можно поместить значение от 00 до FF. При чем здесь перезапуск мк.

Да, это регистр. Причем СПЕЦИАЛЬНЫЙ регистр. То есть ЧАСТЬ ОПЕРАТИВНОЙ ПАМЯТИ контроллера, которая используется для управления самим МК. Спецрегистры при старте инициализируются определенными в даташите значениями, если не указано иное.
Так вот OSCCAL инициализируется по даташиту ВСЕГДА одной и той же величиной 0х80, то есть ЦЕНТРАЛЬНОЙ ЧАСТОТОЙ.
А вопрос калибровки отнесен к ПРОГРАММЕ, где с помощью команды вызова подпрограммы call адресуется переход на ПОСЛЕДНЮЮ ячейку флеша, где ПРОИЗВОДИТЕЛЬ записал команду ВОЗВРАТА ИЗ ПОДПРОГРАММЫ С ОДНОВРЕМЕННОЙ записью константы в аккумулятор. Это и есть команда retlw <константа>. И лишь ПОТОМ эта константа из аккумулятора попадает в регистр OSCCAL.

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

bsf  STATUS, RP0  ;Bank 1
call  3FFh     ;вызов программного адреса 3FF
movwf OSCCAL    ; W->OSCCAL
bcf  STATUS, RP0  ;Bank 0
...............
...............
...............

ORG  0x3FFF
retlw <constant>   ; возврат по адресу следующему за вызовом с WREG=constant

[Aaantonnn15]

КРАМ точно написал. Мой пост немного ошибочный. Там ведь точно стоит retlw xx.

[OKF]

Чтобы этого не произошло, нужно либо записать ту же retlw с любой константой, либо не вызывать этот адрес флеша в программе.

А ежели STARTUP компилятора автоматом использует OSCCAL, то ещё нужно приложить некоторые телодвижения что бы его НЕ использовать.))
А из за невнимательности, да и по забывчивости (ввиду редкого использования ПИКов), приносит весьма интересный эффект.))

[КРАМ]

А ежели STARTUP компилятора автоматом использует OSCCAL

Полагаю использование Си для таких архитектур изощренным мазохизмом.

[OKF]

Глубоко ошибаетесь. Как раз ассемблер для таких архитектур мазохизм. Спасают только макро.))
Программирование на Си даже для PIC10 не вызывает никаких проблем. Ну а плюсы очевидны.

[Smen]

Как раз ассемблер для таких архитектур мазохизм

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

[OKF]

Посмейтесь над "устрицами", когда попробуете.
И даже если не мазохизм, то нет АБСОЛЮТНО НИКАКОГО смысла его использовать там где возможно использование СИ.

[BOB51]

Любой язык имеет и сторонников и противников. А удобство... зависит от навыков и уровня изученности конкретным пользователем.

[КРАМ]

Глубоко ошибаетесь. Как раз ассемблер для таких архитектур мазохизм. Спасают только макро.))
Программирование на Си даже для PIC10 не вызывает никаких проблем. Ну а плюсы очевидны.

Любезные, можете конечно ржать, но я пишу и на Си и на АСМе. даже в дурном сне я не буду писать на ПИК10...ПИК16 на Си. Тогда уж лучше от этой архитектуры вообще отказаться. А то, что писать можно - я в курсе.
Единственное исключение - стеки протоколов. Писать USB или TCP/IP стек на АСМе я конечно не буду.

[OKF]

Да, касательно написания программ согласен. Были проекты и до 40 тыс. строк на ассемблере. Но как насчёт переносимости, на другое семейство, например? Можно не отвечать.))

[OKF]

Любезные, можете конечно ржать, но я пишу и на Си и на АСМе. даже в дурном сне я не буду писать на ПИК10...ПИК16 на Си. Тогда уж лучше от этой архитектуры вообще отказаться. А то, что писать можно - я в курсе.

А в чём проблема?. Объясните лузерам. А то, "может в консерватории что то надо подправить?"))

[КРАМ]

Поправлять? А зачем?

Для меня не представляет трудностей написание кода ни на Си, ни на АСМе.
Более того, в 70% МОИХ проектов (на работе), работа в АСМе приносит ОЩУТИМЫЕ преимущества при выборе элементной базы (читайте контроллеров).
Там где у конкурентов для той же задачи стоит TMS320 за 15 долларов, я ставлю dsPIC33 за 5 таких же долларов. Только решаю задачу не на Си, а на АСМ. И ресурсов хватает чуть ли не с двойным запасом. Аналогично и с младшими ПИКами.
А вот мост HID USB - UART на ПИК18 написан на Си...

[OKF]

Ради коммерции можно пойти на любые жертвы. Тут спору нет.
А если вы любите каждый раз всё писать с нуля... Или, если любите дурную работу...
Только не говорите что все проекты у вас абсолютно разные.

[scorpi_0n]

Да КРАМ вас тихо троллит а вы ведётесь. Никогда ещё работа в АСМе не приносила ОЩУТИМЫХ преимуществ при выборе элементной базы. Это нонсенс. А сказки про TMS и dsPIC это от лукавого для непосвящённых. Он просто скромно умолчал что писать для dsPIC на асме можно так же легко как на Си. Но это быстрее исключение из правил это просто удачность архитектуры . Для других архитектур это уже не прокатывает. Та же любовь к Асму на СТМ ему уже никак не поможет. А всё написанное ранее можно будет просто запихнуть на полку в дальний уголок.

[BOB51]

МММ... Насчет "переносимости" под ассемблером - так впоолне нормально работается - MCS51-PIC16-AVR и проверено и весьма много интересного добавляет (взаимоприятные влияния удобных приемов).
Под STM8 пока "в работе", также как и еще не перепроверенное практикой с PIC18.
Кому интерес будет - милости просим в "винную тему" ( viewtopic.php?f=62&t=94201 ).

Кстати... Тема создана любителем (а не профессиональным разработчиком ПО) и в основном для любителей.