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

А прошивать её тогда через USB как? Всётаки тоже МК, а тут вся фишка в гибкости схемы. Без этого то можно обойтись, но всёравно экономим только мультиплексор...
 
BootLoader использовать. Ну съест он пару сотен байт...
 
А тинька разве умеет писать код в свою память (из своей же программы)? Бут-лоадер то штука хорошая, но он ведь не каждым МК поддерживается...
 
Главное, чтобы была инструкция для записи во FLASH. О ее наличии надо сверится с даташитом.
 
Я какраз о ней и пишу. Я её высматривал. У тинек вообще её не наблюдал...
 
В таком случае, можно поступить так: в процессе работы передавать данные по I2C, а на время программирования работать по SPI, благо на меге есть свободные пины.
 
Периферия во время программирования будет мешать. Можно заюзать либо то, либо то. Вариант с дугими AVR, без USB интерфейса, отпадает. А среди оставшихся выбор очень скудный и нет I2C интерфейса. Другое дело микрочип. Да и МК стоит три бакса, куда дешевле 10-ти еврового АЦП, и 5-ти и 2-х баксовых МК. За габариты уже молчу. Это дело не только для себя делается. В серию пойдёт. Поэтому и гоняюсь за характеристиками. Вариант с AVR я с самого начала рассматривал, и не нашел ничего подходящего. Начал даже посматривать в сторону ARM, но у микрочипа всётаки нашелся заманчивый вариант. Осталось только общий язык с ним найти...
 
Если пойдет в серию, значит, будет продаваться?
Тогда встает вопрос об аудитории.
Неискушенным людям гораздо понятнее экран, чем показометр на трех светодиодах.
Далее, зачем в устройство добавлено USB? Как его конфигурировать, если под рукой нет ПК, а индикация на устройстве убога?
Кто будет писать программу для ПК, обслуживающую устройство?

Для написания основной прошивки, я рекомендую использовать C.
Потери в производительности минимальны (настройкой компилятора от них можно избавится). За то, много полюсов:
-Нет необходимости разбираться и оптимизировать арифметику.
-Всегда есть возможность быстро исправить программу.
-Есть возможность отладки модулей программы на ПК.
-Имеются готовые библиотеки для работы с периферией. В том числе, программные UART, I2C, SPI и так далее.
 
Последнее редактирование:
В устройсте, в котором это дело будет использоватся, дисплей смотрится как третья нога у человека. Речь идёт о мощном лазерном целеуказателе или фонарике на 5...10W. И габариты у него относительно скромные. Индикация может и убогая, но информативная. Там ведь не просто мигание RGB светодиодами, а ШИМ на каждый канал. В любом случае индикатор это отдельный узел, связаный с основным через UART, и его всегда можно заменить на более крутой, даже с тачскрином и играми :). Делать я его буду на ATtiny2313, с которой я уже опыт работы имею...
Конфигурировать необходимости нет. Для управления есть всего одна кнопка, с кучей функций на ней (реализация удобная). Если же надо будет что-то изменить, через USB можно перепрошить, или переконфигурировать. Софт на комп есть кому писать...
USB интерфейс используется главным образом как источник питания для заряда аккумулятора (причём контроллер может определять от чего питается и выставлять лимиты в 100mA, 500mA, 800mA и >1A), и уже потом для мониторинга, конфигурации и т.п. Сейчас к компу доступ получить может каждый, а заряжать можно и через готовый адаптер...

Для такой задачи собирать сложное, громоздкое и дорогое устройство нецелесообразно. Поэтому AVR и пошел лесом...
Си я не понимаю, и врятли осилю. Ассемблер гораздо проще и является чистым машинным кодом. Тут программа не занимает десятки килобайт, чтоб задумыватся о языке высокого уровня. Думаю она и килобайта не займёт. Да и видил я примеры написания программы разными языками. Ассемблер в разы меньше, опрятнее, и неизвестно на сколько быстрее за Си. А паскаль это вообще тихий ужас. У 13-й тиньки не хватает памяти, чтоб сделать простую линейную шкалу на 5 светодиодов...
Примеров программ и для ассемблера хватает (программная реализация интерфейсов, умножение, деление и т.п.).
 
Последнее редактирование:
Всегда можно посмотреть код, который создал компилятор, причем вместе со строчками программы на языке высокого уровня. Он мало отличается от того, что пишется на ассемблере.

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

Зачем таскать аппаратный USB, если он используется только для конфигурирования?

Будет маленькое устройство и книжка: нажмите 23 раза на кнопку. Убедитесь, что второй слева светодиод стал светло-розовым.

Можно сделать красивый док для указки с экраном и сетевым зарядным устройством.
 
На Си писать не стану. Не уговоришь. Не та ситуация. Тут проще написать на ассемблере, чем учить язык высокого уровня. А этот код ещё и работает лучше.
У кнопки только 4...6 режимов. И за индикаторами следить ненадо. На выбор любого режиме уходит 0...1с, а число нажатий не превышает 2-х (правда игратся с временными интервалами надо, но это дело привычки). Куда там дисплей то лепить, если места под панель сантиметр на два?..
 
Дисплей от какой-нибудь Нокии войдет.

Вот. Мне во всех таких устройствах не нравится именно игра в морзянку с кнопочкой. Обратная связь с пользователем в таком случае нужна обязательно .
 
В фонарике дисплей с клавиатурой. Разве это лучше простого индикатора состояния батареи с кнопкой включения? Чем там можно управлять целой клавиатурой с дисплеем? Яркостью? Если в 1х2см и впишется какой-нибудь ЖКИ, то разве что от наручных часов. А ведь ещё и для кнопки место требуется...

Игра в морзянку - двой клик по левой кнопке мыши по-моему всем нравится больше, чем альтернативные варианты без этой морзянки. Это я к тому, что если в меру, то вполне удобно. Удобнее использования нескольких кнопок вместо одной...

Добавлено:
И тема заглохла...
 
Последнее редактирование:
Мне, например, не нравится, что многие вещи собраны отдельных микросхемах - преобразователь, контроль заряда... Их можно попытаться реализовать программно.
Кстати, Tiny25 умеет писать в свою FLASH. Инструкция SPM в даташите присутствует.
 
Пройденный этап, за экономию на деталях. Программно никакой МК не справится с задачей так хорошо, как управляемый им контроллер. Вот мне нужно и понижать и повышать. Ток до 2A в обоих режимах. С этим справится один корпус, а так мне придется лепить 4 полевика, драйверы к каждому, т.к. их затворами на частоте 3МГц МК никогда в жизни не сможет рулить. Ещё они будут боятся КЗ и перегрева, от чего есть защита в контроллере. Контроллер аналоговый и реакция у него куда лучше, за этот медленный МКшный АЦП...
В итоге получается громоздкая, тугодумная и ненадёжная система...
 
С этим придется согласится. И на каком сейчас этапе разработка?
 
Схема готова, прошивку нужно написать. Может придётся что-то в схеме изменить. Затем печатка, прототип и заказ на заводе...
 
А в чем заключается математическая обработка результатов АЦП?
Есть ли проблемы с написанием прошивки?
 
С алгоритмами я разберусь. Просто мне надо найти общий язык с этим МК. Литературы русскоязычной по ним много, но с разбирающимся человеком будет проще...

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

Есть ещё ОС по току. Механизм такой же, только в ЦАП данные записываются заведомо меньше необходимых, и аккуратно растут до тех пор, пока АЦП не выплюнет правильный ответ. В системе всё равно юзается плавный пуск и выключение. Это равносильно как для ОС по току, так и для ОС по напряжению...

Ещё остаётся два канала АЦП. Один мониторит ток аккумулятора, а другой его напряжение...
 
АЦП ведь работает через мультиплексор. Возможно, что результаты измерения сразу после переключения каналов будут неверными.

Какие действия выполняются, если в результате вычисления произошел уход в минус?
 
Войдите или зарегистрируйтесь для ответа.
Назад
Сверху