Начинающим с нуля (PIC)

[Alexeyslav]

Ага, и в дополнение - чтобы получить на выходе 00, нужно еще помимо сброса ТРИСА, сбросить еще и ПОРТА.

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[Bugrim]

Дело в том, что при сбрасывании TRISA MPLAB показыает в результате что TRISA=h'20', то есть у меня должным образом TRISA не сбрасывается. И как следствие RA5 остается настроеным на вход, а мне нужен выход!!! Почему? А PORTA я сбрасываю.

То есть эти директивы подобны оператарам языка программирования (Паскаль Вейсик) и работают аналогично? Тогда этот код имеет право на жизнь? И если да, то как он работает? Его пошагово можно выполнить?

variable cikl
variable rezult

cikl=0
rezult=0
while cikl==1
rezult=cikl+5
rezult++
cikl++
endw
movf rezult
end

Изменено 20 марта, 2009 пользователем Bugrim

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[my504]

Внимательно читайте даташит.

пин RA5 не может быть выходом, это ТОЛЬКО ВХОД ИЛИ СБРОС. Соответственно этот разряд триса читается только как 1. Это прямо указано в даташите на рис. 5-5 и в таблице 3-2.

Второе. У Вас полная каша из понятий. В АСМе нет исполняемых команд вида IF и подобных. Там только команды из инструкций данного камня (смотрим в даташит), а ДИРЕКТИВЫ о которых я говорил позволяют УСЛОВНО транслировать код. Так можно создавать переносимый на разные камни текст программы. Тогда перед трансляцией указывается тип камня или какие иные параметры и макроассемблер АВТОМАТИЧЕСКИ содает версию кода, который нужен для такого варианта. Но сами эти директивы никуда в код не включаются и при работе камня не исполняются. В языках типа Си это не директивы, а сам текст программы и он транслируется в исполняемый код.

Изменено 20 марта, 2009 пользователем my504

[Реклама]

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[Bugrim]

:rolleyes: !!!!!!!БОЛЬШОЕ СПАСИБО!!!!!!! :rolleyes:

Вот становиться кое что на места (по IF). Примеров мало дают и пощупать это не где, по крайней мере в моих источниках, так что если подскажете где это посмотреть, так чтоб можно было разобраться, буду очень рад.

А по RA5 прошу прощения не доглядел, ОТМЕЧУ БОЛЬШИМИ КРАСНЫМИ БУКВАМИ, чтоб потом на грабли не наступить.

Изменено 20 марта, 2009 пользователем Bugrim

[Реклама]

Сравнительное тестирование аккумуляторов EVE Energy и Samsung типоразмера 18650

Инженеры КОМПЭЛ провели сравнительное тестирование аккумуляторов EVE и Samsung популярного для бытовых и индустриальных применений типоразмера 18650. 

Для теста были выбраны аккумуляторы литий-никельмарганцевой системы: по два образца одного наименования каждого производителя – и протестированы на двух значениях тока разряда: 0,5 А и 2,5 А. Испытания проводились в нормальных условиях на электронной нагрузке EBD-USB от ZKEtech, а зарядка осуществлялась от лабораторного источника питания в режиме CC+CV в соответствии с рекомендациями в даташите на определенную модель. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[my504]

Так есть на русском языке описание MPASM, только не помню где... попробуйте на сайте Гаммы или Тритона...

А на английском у Микрочипа есть вообще все...

А что касается Си, то это зависит от версии компилятора и нужно читать у создателей конкретной версии транслятора (Хайтек, Микроэлектроника и т.д.) Всякие Васики лучше не вспоминайте даже - это убогость для совсем тупых...

[Реклама]

Литиевые аккумуляторы EVE Energy и решения для управления перезаряжаемыми источниками тока (материалы вебинара)

Опубликованы материалы вебинара Компэл, посвященного литиевым аккумуляторам EVE Energy и решениям для управления перезаряжаемыми источниками тока.

На вебинаре мы представили информацию не только по линейкам аккумуляторной продукции EVE, но и по решениям для управления ею, что поможет рассмотреть эти ХИТ в качестве дополнительной альтернативы для уже выпускающихся изделий. Также рассмотрели нюансы работы с производителем и сервисы, предоставляемые Компэл по данной продукции. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[ikarab]

Так есть на русском языке описание MPASM, только не помню где...

Там все по русски и АСМ инструкции PIC расписаны с примерами

А на английском у Микрочипа есть вообще все...

И вся дока Микрочип по устройству PIC по ссылке есть на русский переведена.

Изменено 20 марта, 2009 пользователем ikarab

[Реклама]

Литиевые батарейки и аккумуляторы от мирового лидера  EVE в Компэл

Компания Компэл, официальный дистрибьютор EVE Energy, бренда №1 по производству химических источников тока (ХИТ) в мире, предлагает продукцию EVE как со склада, так и под заказ. Компания EVE широко известна в странах Европы, Америки и Юго-Восточной Азии уже более 20 лет. Недавно EVE была объявлена поставщиком новых аккумуляторных элементов круглого формата для электрических моделей «нового класса» компании BMW.

Продукция EVE предназначена для самого широкого спектра применений – от бытового до промышленного. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[my504]

Я бы поосторожней рекомендовал с выражениями... ВСЯ ДОКА нигде не переведена... Нет такой "переводилки" на всю... Основные моменты архитектуры и применения среднего семейства действительно есть и причем первоисточники переводов именно у Гаммы.

[ikarab]

ВСЯ ДОКА нигде не переведена...

Имелось в виду то та которая там ВСЯ переведена.

[Bugrim]

Спасибо будем дерзать.

[Bugrim]

Доброго времени суток всем.

Я опять за помощью. Дело в том, что необходимо сделать вычисляемый переход.На сколько я понимаю ничего сложного здесь нет, однако в даташите сказано , что необходимо обратить внимание на то, чтобы значение PLC не пересекало границу блока памяти. Подскадите подалуста, можно ли в MPLAB определить где именно в памяти (начало, конец блока) находится мой вычисляемый переход, для корректного вычисления перехода.

Заранее благодарен.

P.S. А примеров по использованию директив я нашел мало, если вести реч о ORG, EQU, то я ими и так пользуюся а их тк еще много осталоь.

[antzol]

Ну EQU немного не из той оперы... Это просто определение константы ассемблера, т.е. сопоставление текстовой метке к какому-нибудь числу.

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

Это всё об абсолютном коде.

Если же пишешь перемещаемый, то смотри директивы BANKSEL и PAGESEL и страницу 42 в руководстве по ассемблеру.

[Bugrim]

ORG + листинг=думаю получется, и на сколько я понял начало юлока памяти это каждый 256 байт?

А директивы BANKSEL и PAGESEL - для объектных файлов, я до них не дорос, не могу найти где бы объектные файлы были разжованы для "Чайников".

Изменено 22 марта, 2009 пользователем Bugrim

[Alexeyslav]

Тут лишь имеется в виду что изменить можно только младший байт счетчика команд, а старший необходимо устанавливать отдельной командой, если происходит переполнение младшего. Но все же, проще быть убежденным в том что вычислимый переход происходит без изменения старшего байта счетчика команд. как отследить? все зависит от ситуации, и лучше не отслеживать а быть точно уверенным что код будет работать без отслеживания - например располагать вызывающую процедуру и вызываемые в ОДНОМ блоке. если это невозможно, значит передавать управление в два этапа - сначала передать управление в маленькую подпрограмму-диспетчер в нужном блоке, которая перенаправит в нужную точку. Насколько я знаю, такая фигня происходит только в контроллерах PIC, в других таких проблем нет.

[Bugrim]

Всем свпасибо - буду пробывать.

[my504]

Нет совершенно никаких проблем с вычисляемым переходом. Необходимо ПОСЛЕ написания кода отследить по содержимому программной памяти (отображаем в форме дизассемблирования) нахождение таблиц и сдвинуть их в необходимом направлении.

Если необходимо разместить таблицу с пересечением границы страниц, то код будет выглядеть таким образом:

;исходное состояние - относительное смещение в таблице находится в аккумуляторе (W), начало таблицы на первой странице

clrf PCLATH

incf PCLATH,f ; установка страницы начала таблицы

addlw 0xNN ; NN - младший байт начального адреса таблицы

btfsc STATUS,C

incf PCLATH,f

movwf PCL

.....................

ORG 0x1NN

retlw ......

retlw ......

retlw ......

Таким образом можно вообще размещать таблицы ORGами где угодно и ПРЕДВАРИТЕЛЬНО, а в программе лишь обращаться по известным начальным адресам.

Что касается этой особенности ПИКов, то это историческии сложившаяся особенность БАЗОВОГО И СРЕДНЕГО семейства и она при умелом пользовании не оказывает никакого влияния на написание кода...

Изменено 23 марта, 2009 пользователем my504

[Bugrim]

Господа! Опять прошу меня вразумить.

Использую три таймера (PIC16F628A). При чем, один таймер должен иметь высший приоритет по прерыванию, то есть, должен обслуживаться даже в обработке другого прерывания. На сколько я понимаю при обслуживании прерывания обработка других прерываний запрещена, пока не даш команду retfie. Кто нибудь сталкивался с такой проблеммой?

[my504]

Это не проблема. Это не верно прописанный алгоритм. Рекурсии в прерываниях в ПИКах среднего семейства - это ужасно...

Учтите, что при таких фокусах переполнить стек - раз плюнуть. Опять же отсутствие команд PUSH и POP приводит к необходимости сохранения контекста прямой пересылкой в ОЗУ. Таким образом по контексту ВООБЩЕ НЕТ ГЛУБИНЫ ВЛОЖЕНИЙ.

Что касается приоритетов, то максимум, что можно получить - это порядок следования определений источника прерывания в семафоре обработчика. Так как в текущем обработчике флаг отложенного прерывания сброшен не будет, то по необработанному источнику интеррапта вызов последует немедленно после возврата из текущего. И если Вы корректно и очень коротко напишете обработчик - проблем не будет.

Однако при критически малой требуемой латентности прерывания с высшим приоритетом необходимо применять аппаратные способы (в том числе и встроенные) решения проблемы. Например режим Capture.

Изменено 7 апреля, 2009 пользователем my504

[Alexeyslav]

Если это действительно необходимо - при вызове не приоритетного прерывания необходимо запретить все остальные (в регистрах источников) и разрешить глобальный бит прерывания - вызов прерывания его сбрасывает, а retfie его восстанавливает.

[Bugrim]

Добрый день.

Подскажите, из вашего опыта, кто нибыдь замечал глюки на pic16f628a при работе TMR1(работает от внешнего кварца) и CCP (настроен на сравнение). При обработке прерывания от CCP переодически необходимо менять значение CCPR1H И CCPR1L и тут то прооисходит что то, которое не поддается моему пониманию. Proteus этого не замечает, по MPLAB тоже ничего не вижу, а вот в живую - бред. Может в камне глюк?

[Alexeyslav]

А что именно происходит? Я как-то мучился со считыванием значения регистра таймера, ну нивкакую не читалось - всегда 00 а прерывания происходят, оказалось надо было правильно биты конфигурации выставить.

[zverdvd]

проект приложите. ifolder.ru

[Bugrim]

Происходит весма странная чтука.

Порядок работы программы такой: прерывание таймера 1 - отсчет секунды и пересчет регистров в озу. Раймер 0 - динамическая индикация регистров, которые пересчитываются прерываним таймером 1, клавиатура и т.д. Пусть на индикаторе - цифра 5. При изменении CCPR1 (или регистра таймера 1, необходимо скоректировать время) динамическая индикации не измененяет цифры (цифра выдается PORTA0-PORTA3), то есть цифра 5 так и остается, хотя по логике должна была пересчитаться и отображать 6. После пошествия времени примерно в два раза большей чем обычно - динамическая индикация показывает цифру 7. Часа 4 пытался в ПРОТЕУСе и МПЛАБе это споймать - не споймал. А в жизни вот такая штука.

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

Ничего больше сказать не могу, все что имею осталось на работе, а на ней я появлюсь только в понедельник. Хотел узнать может это глюк и при использовании этой комбинации TMR1 и CCP гдето какаято оговорка есть. Если оговорок нет, то буду с понедельника дальше мучать, если сдамся - то сюда за помощью.

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

А какие биты конфигурации вы изменяли?

[Alexeyslav]

Скорей всего, я установил биты конфигурации в МПлабе так как это нужно было для проекта, а не те что были по умолчанию.

Насчет глюков, смотри внимательней распределение регистров, не изменяешь ли в прерывании регистрыы которые используются в другом прерывании или основной программе, особенно это касается аккумулятора и регистра статуса.

[my504]

А теперь скажите, ув. Бугрим, ЗАЧЕМ нужно в Вашем раскладе разрешать вложеные прерывания? Какой из процессов требует фиксации событий с минимальным джиттером? Разве учет секунды требует четкой привязки к моменту ее появления? Нет...

Достаточно МЕЖДУ приходами успеть обработать ее в прерывании, а сделаете ли Вы это немедленно или через 100 машинных циклов, какая разница? Флаг от Сompare будет стоять пока Вы не обработаете это событие по вектору 4.

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

Общее резюме.

Короткий как выстрел обработчик и Вы имеете минимальный джиттер (подергивание) процесса относительно события прерывания. НО ПЕРИОД ПРЕРЫВАНИЙ ВСЕГДА ОСТАНЕТСЯ БЕЗ ИЗМЕНЕНИЙ - он определяется их источником.

А коротким обработчик будет, если в нем нет никаких длинных вычислений. Быстрые инкременты/декременты, выставление/гашение флагов для процессов, которые производятся в суперлупе (основном цикле). Т.е. взвели флаг в прерывании - вышли из обработчика прерывания - основная программа увидела взведенный флаг, исполнила требуемое и сразу этот флаг загасила. В таком раскладе все делает основная программа, а события прерываний отображаются у нее как взведенные флаги и инкрементированные/декрементированные счетчики.

Но даже если Вы настаиваете на приоритетной обработке, то надлежит сделать вначале обработчика не стандартное сохранение аккумулятора и статуса, а как минимум двухуровневое - т.е. организовать специальный флажок/бит, который при первом вхождении имеет, положим, значение 0, а при втором 1, и после стандартного сохранения контекста (иначе нельзя - потеряете статус), Вы перебрасываете первичный буфер контекста(аккумулятора и статуса, иногда и PCLATH с FSR) по упомянутому флажку далее. Восстановление в обратном порядке. Можно проще, через FSR, но тогда FSR нельзя использовать в основном теле программы.

Объясняю почему симулятор не фиксирует этот баг. В симуляторе ВСЕ ПРОЦЕССЫ СИНХРОННЫ. Даже если Вы их задаете как независимые. Поэтому возможна ситуация (и скорее всего это так), когда при разрешенных вложенных прерываниях оно никогда не произойдет из за кратных и строго синхронных процессов.

Изменено 10 апреля, 2009 пользователем my504

[Bugrim]

В первоначальном варианте использовал прерывание таймера 1, которое при запоздплом прерывании (обработке другого прерывания) могло привести к потере времени, пока перейдем на обработку считаем текущую информацию с регистров таймера, сложим с нужным числом и запишем обратно. Это давало погрешность. От вложеных прерываний отказался - другой подход - таймер 1 оставить как считает, а модуль ССР настроить на сравнение с обнулением таймера 1. В моделировании работает как надо, с небольшой погрешностью. Однако в реале - то ли кварц, от которого работает тиймер 1 имеет погрешность, которая довольно быстро набигает, толи что то есче принудили сделать коррекцию, которая уменьшает/увеличивает значение регистра ССР. Для этого изменения, времени предостаточно и нет необходимости точно выполнять прерывание, ведь средний период этих прерываний будет нужным. Так вот при обработке прерывания от ССР, каждую 32 секунду, так захотел, происходит коррекция егистр ССР уменьшается на 1 - на индакатое - цифра 32, пауза примерна в 2 секуны, потом цифра 34. Интересная штука, на моделировании не видно, или не вижу, прийдеться помучатся исходник на работе, с понедельника посмотрю, может что то прояснится.