• Добро пожаловать на компьютерный форум Tehnari.ru. Здесь разбираемся с проблемами ПК и ноутбуков: Windows, драйверы, «железо», сборка и апгрейд, софт и безопасность. Форум работает много лет, сейчас он переехал на новый движок, но старые темы и аккаунты мы постарались сохранить максимально аккуратно.

    Форум не связан с магазинами и сервисами – мы ничего не продаём и не даём «рекламу под видом совета». Отвечают обычные участники и модераторы, которые следят за порядком и качеством подсказок.

    Если вы у нас впервые, загляните на страницу о форуме и правила – там коротко описано, как задать вопрос так, чтобы быстро получить ответ. Чтобы создавать темы и писать сообщения, сначала зарегистрируйтесь, а затем войдите под своим логином.

    Не знаете, с чего начать? Создайте тему с описанием проблемы – подскажем и при необходимости перенесём её в подходящий раздел.
    Задать вопрос Новые сообщения Как правильно спросить
    Если пришли по старой ссылке со старого Tehnari.ru – вы на нужном месте, просто продолжайте обсуждение.

Микроконтроллеры PIC

INFERION

Новые
Регистрация
23 Ноя 2008
Сообщения
1,084
Реакции
21
Баллы
0
Микроконтроллеры PIC

Всем привет :). Вопрос у меня следующий. Есть ли среди нас кто-нибудь, кто умеет их программировать (на ассемблере)? Я знаком с AVR и уже не одну прошивку написал, но несмотря на обилие русскоязычной технической документации, на микрочиповские МК, мне понять их сложнее. Незнаю с какого боку подлезть. Документация очень увесистая, с чего начинать - хз. Кое как понял организацию прерываний, с памятью, регистрами и этими банками ещё не разобрался. Если у AVR все конфигурационные регистры расположены на одной странице даташита, в понятной мне таблице, то тут они разбросаны по всему даташиту, весом в 586 страниц! И их тут гораздо больше (наворотов то дофига). Всё дело осложняется ещё и тем, что на нужный мне МК (PIC18F26J53) нет даташита на русском языке...
А необходимость в заюзывании именно PIC большая. AVR пока ещё не дотягивается до периферии и разнообразия микрочиповских МК. Заюзав PIC18F26J53 вместо AT90USB82 я упрощу схему и габариты раза в два, за себистоимость уже молчу...
 
Последнее редактирование:
Я могу помочь. Но мне уж очень не нравятся PIC как раз из-за того, как они устроены.
Изложите описание прошивки.
 
Многим они ненравятся, а для меня это находка. Перед AVR у них и преимуществ куча. Например скорость работы портов ввода/вывода, из-за гораздо бОльшей тактовой частоты МК. Довольно точный встроеный генератор тактовой, позволяющий заюзать USB интерфейс без кварцевого резонатора. Встроеный детектор напряжения, можно заюзать компаратор как супервизор, и вовремя начинать писать в EEPROM. 12 бит АЦП, который мне какраз очень нужен. Довольно быстрый ШИМ без всяких там PLL, без которых AVR не обойдётся из-за низкой тактовой частоты (8МГц против 48МГц, на 2,7V питания), корпус в самый раз (у Атмель всё USB-шное в огромных корпусах, с кучей ненужных мне лап), команды работы с константами там все есть. Ненужно сначала записывать константу в регистр, чтоб провести с её участием какую-нибудь логическую или арефмитическую операцию, ну и т.д.

В общем я собираю умный компактный преобразователь. Готовый конвертер рулится через ЦАП по I2C шине. По этой же шине рулится и ещё куча периферии. Контроллер заряда Li-ion, термодатчики и т.п. Выходное и входное напряжения и токи снимаются встроеным в МК АЦП (4 канала заюзано). Есть ещё ШИМ модуляция выходного напряжения. Тактовая 48МГц, глубина 8 бит. Связь с компом через USB, и с панелью управления (и индикации) через UART. При снижении напряжения питания ниже допустимого (если кто аккумулятор отключит) МК должен быстро бросать все свои дела, отрубать всё жрущее энергию, и записывать в EEPROM данные с ОЗУ, пока остатков энергии достаточно. Благо для этого внутри у него всё необходимое есть (в отличии от AVR, требующего внешнего супервизора).

Более детальное описание прошивки займёт тут всю страницу. Я её всё равно сам буду писать. Мне просто нужен человек, которого я смогу по мере необходимости подоставать в аське своими тупыми вопросами типа "а как мне настроить этот модуль?"
 
Последнее редактирование:
"Вы просто не умеете их готовить".
AVR может работать и на 20 МГц (с кварцем, естественно).
При этом, большинство инструкций выполняются за один такт, в отличии от PIC, требующего 4 такта на инструкцию.
48/4=12.
Встроенный супервизор питания есть, в даташите есть целая глава о работе с ним и правильной работе с EEPROM, как в программном, так и в схемотехническом аспектах.

Встроенный источник напряжения для АЦП тоже есть, как ни странно.

Вопрос с USB можно решить установкой FT232R. Сразу решается вопрос с перепрограммированием контроллера, никакой BootLoader не нужен, освобождается место во FLASH.

Для индикации можно использовать ЖКИ на 4 строчки.

Как ни странно, у меня в планах почти такой же преобразователь на Atmega8.

В целом, идея устройства понятна. Но для написания прошивки этой информации недостаточно.
 
Встроеный супервизор питания разве умеет не только сбрасывать, но и запускать процесс записи в EEPROM?

FT232R серьёзно поднимает себистоимость и занимает место. С таким же успехом я могу заюзать AT90USB82 и внешний АЦП, с 25-й тинькой (шустрый ШИМ то всёрано нужен).

А при чём тут встроеный ИОН для АЦП? он везде есть, но я буду юзать ИОН с ЦАП, так стабильнее.

ЖКИ некуда лепить. Устройство компактное и там планируется использовать 3 RGB светодиода и простую кнопку. Да и ненужна там такая информативность, начнут прикалыватся что тачскрина и игр нехватает...

По поводу быстродействия - сомневаюсь что AVR даст 20МГц на 2,7V питания. А PIC 48 уже на 2,35V. У меня 3,3V по плану. Даже если не обращать внимание на более высокое быстродействие PIC, в данной ситуации, я ещё избавлюссь от ATtiny25 и получу возможность шустро дёргать лапами и возится с константами. И кварц лепить я не хочу...

Я же не прошу писать прошивку. Я прошу научить меня её писать. Базовые представления есть, писал уже, только для других МК :)...
 
Последнее редактирование:
Супервизор питания должен только сбрасывать контроллер. Работа контроллера при "плохом" питании запрещена - в таких условиях, контроллер может сам себя прошить неизвестно чем, а также испортить данные в EEPROM.

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

Кроме этого, как гарантировать, что запаса энергии хватит на запись данных в EEPROM? Это одна из самых энергоемких операций.
 
И часть данных тогда потеряется, если питание вдруг вырубится, т.к. последние записаные данные на тот момент будут устаревшими. А ещё это здорово изнашивает EEPROM, т.к. писать прийдётся постоянно, а не только в моменты отключения аккумулятора, которые происходить будут крайне редко. У меня предполагается вести лог времени наработки, израсходованой энергии и т.п. И часы реального времени там есть для этого.
Народ ведь с EEPROM так и поступает. Пишет туда только когда питание начинает падать после отключения. Прерывание генерит внешний супервизор.
Да и я считал требуемую мощность. У меня единицы микрофарад получались. Этого достаточно чтоб питать чип миллисекунды. Влепить тантал на 100 микрофарад не проблема...
А встроный супервизор способен только удерживать МК в сброшеном состоянии, чтоб он дел не натворил при экстримально низком напряжении питания. Но ведь есть некоторый запас. Например у меня 3,3V питания, а проседать может до 2,35V. На 3,2V можно запускать запись в EEPROM и ещё остаётся 0,85V!
 
Последнее редактирование:
Идея понятна.

Давайте разбираться с периферией и задачами контроллера.
 
Секунду, плиз. Валерий проснулся :). Я чуть позже схему выложу. Там всё сразу станет ясно. Но она недорисована. Не придумал ещё какой туда преобразователь влепить, для питания самой периферии. Нужно держать 3,3V во всём диапазоне напряжений аккумулятора (4,2...2,9V). Но самое противное - в спящем режиме периферия тоже должна питатся, и преобразователь нельзя глушить, а он жрёт дофига на холостом ходу. Даже простые ULDO стабилизаторы миллиампер едят...
 
Как насчет идеи реализовать USB программно?
 
Жрет МНОГО ресурсов. Там арифметики будет много. МК будет с максимальной скоростью АЦП (50 килосэмплов) снимать данные, проводить расчёты и задавать новый режим. Паралельно ещё отчитываясь индикации о текущем стостоянии, температуре и т.п., и ещё должно оставатся время на реагирования на внешние прерывания, или какой-нибудь сигнал. Вся программа построена на прерываниях, никаких циклов между ними (разве что команда sleep).
 
Вот:
Драйвер1.webp
Но она ещё не раз будет перерисовыватся. Я ведь с МК почти незнаком...
 
Вижу схему электрическую: что-то куда-то соединено, но без скачивания даташитов на микросхемы мне ничего не ясно.

Опишите принцип работы и назначение узлов устройства в двух словах.
 
PIC18F26J53 - сам МК.
TPS63020 - преобразователь.
BQ24155 - контроллер заряда Li-ion.
LTC2631LM12 - ЦАП.
INA138 - датчик тока
TSV631 - ОУ.

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

Кстати о прерываниях. Какой-нибудь временной расчет сделан? Накладок не будет?

Почему выбрана такая частота дискретизации, почему нельзя взять меньше?
 
К частоте семплирования серьёзной привязки нет. Можно и меньше, но нежелательно. Стабилизатор ведь, и реагировать должен как можно шустрее.
Никаких временных расчётов не потребуется. Не будет успевать - просто медленнее будет работать, что не катастрофично. Но я постараюсь сделать так, чтоб ресурсов хватало с запасом. Это всё симулятор покажет...

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

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

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

Работа программы должна быть математически обоснована, а не проверена на частном примере в симуляторе.

Для AVR есть график зависимости максимальной частоты от напряжения питания. На полной скорости при заниженном питании они не работают.

По поводу частоты семплирования: будет ли успевать микросхема - стабилизатор реагировать на команды от ЦАП?
Возможна ведь и ситуация возникновения очень неприятных колебаний выходного напряжения - как это учтено?
 
Ну, я не такой уж и ламер в этих вопросах :). До трёх прерываний одновремено дело не дойдёт. А если дойдёт - я это увижу. Да и очередь там всётаки есть. Может прерывания и будут накладыватся, но во время обработки предведущее снова не выскочит. Можно неважные вообще игнорировать. Есть же в PICах низкоприоритетные прерывания... В любом случае это уже мои проблемы. По-моему производительности тут выше крыши, благодаря тому, что все тупые ресурсоёмкие операции полностью обрабатываются на железном уровне. МК только руководит. Задал параметр один раз, и дальше этот параметр поддерживается уже самостоятельно...

Стабилизатор самостоятельный, у него своя ОС, и МК можеет напряжение задавать вообще без АЦП, полагаясь на линейность ЦАП и стабилизатора. Если будет какая-нибудь неприятная ситуация - она спокойно устранится программным методом. Но сейчас этого не предвидится. Да и 12,5кГц (у АЦП то 4 канала, и только каждый 4-й семпл несёт информацию о состоянии стабилизатора) любой стабилизатор осилит без проблем, иначе это будет вообще непригодный эстонец...

ШИМ мне симулировать и ненадо. Там нечего и проверять. Просто записать значение в регистр сравнения и всё. А железо уже само всё сделает, а если и неправильно сделает - к катастрофе это не приведёт. Схему вообще невозможно убить кривой программой. Она может только неправильно функционировать, но на это есть дебаггинг. Так что все возможные неприятности пока что можно отбросить, и потом уже по мере необходимости их устранять программно. Переписать код - это не детали перепаивать...

Для AVR есть график зависимости максимальной частоты от напряжения питания. На полной скорости при заниженном питании они не работают.
Так я за это с самого начала и пишу. Реально я с AVR только 8МГц и выжму, но мне этого может и хватить. Вот только периферия тогда серьёзно толстеет. I2C на программном уровне, SPI занят 25-й тинькой, внешний АЦП. Если избавится от программного I2C, который жрать будет практически все ресурсы (обмен данными то постоянный), то прийдётся ещё и мультиплексор на SPI цеплять. И кварц чуть ли не треть платы занимает...
 
Последнее редактирование:
А если повесить Tiny25 на I2C?
 
Назад
Сверху