Комментарии 16
«дорого» каждой кнопки по пину
Надоели такие оптимизаторы. Ну давайте на один АЦП все кнопки поцепим!? Если МК позволяет, то почему бы и не по кнопке на пин?
Не кипятитесь :)
Просто комментатор не совсем умело намекает, что в случае, если установка потребует расширения в плане возможностей ввода/вывода, то первый способ это сделать — добавить шифратор/дешифратор в блок принятия команд пользователя
Просто комментатор не совсем умело намекает, что в случае, если установка потребует расширения в плане возможностей ввода/вывода, то первый способ это сделать — добавить шифратор/дешифратор в блок принятия команд пользователя
и все равно первый комментарий глупый. Потребует расширения — дешифратор добавится. А в данном случае зачем плодить сущности и добавлять новые корпуса, тратить время на мультиплексирование, городить матричную клавиатуру и прочее. Цели и задачи топика совершенно другие. Контроллер выбран, а методы вытекают из данного железа. Честно, надоели такие комментарии, где «оптимизаторы» навязывают какие-то ненужные телодвижения, порою парадоксальные и ненадежные.
ps. А можно еще и семисегментник по одному проводу подключить через сдвиговый регистр. А то сейчас «дорого» выходит
ps. А можно еще и семисегментник по одному проводу подключить через сдвиговый регистр. А то сейчас «дорого» выходит
И правда, вдруг придется увеличить число кнопок. Или даже так!
NOJNITSI мой мозг!
НЛО прилетело и опубликовало эту надпись здесь
Увидев заголовок, почему-то подумал, что речь идет о новом проекте Нотча 0x10c, где нужно программить какой-то допотопный DCPU-16.
Теплый ламповый PIC… В эпоху повальных АРМов и Андроидов так приятно почитать о чем-то древнем и дремучем.
История одного байта, хоть и не упоминает модели, но всем и так понятно, что PIC.
Когда-то начинал работать с микроконтроллерами с PIC16f628A. Никогда не думал, что смогу настолько яростно ненавидеть паршивый кусок кремния, сделанный анацефалами. Даже у x86 набор инструкций логичнее, понятнее и проще.
Когда-то начинал работать с микроконтроллерами с PIC16f628A. Никогда не думал, что смогу настолько яростно ненавидеть паршивый кусок кремния, сделанный анацефалами. Даже у x86 набор инструкций логичнее, понятнее и проще.
Я конечно не могу сказать, что их ненавидел. Но четко помню уровень свое восторга, когда стали доступны компиляторы С для PIC и я понял, что ассемблер можно начинать забывать :-)
sdcc? Во-первых, если я не ошибаюсь, то его разработка прекращена, а во-вторых он генерирует настолько неоптимальный код, что годится только для поделок. PIC-и (по крайней мере PIC8; знакомый утверждал, что в PIC24 все обстоит не менее плохо) очень хреново дружат с C.
Да нет, не SDCC точно. Я закончил работать с PIC в 2005 году и перешел на ARM, тогда популярным компилятором был продукт от HI-TECH.
Да я смотрю, что сейчас их компилятор предлагается прямо на сайте Microchip, видимо они его купили. Вот ссылка.
Качество генерируемого кода было вполне достаточным, в узких местах, где производительность была критичной делались вставке на ассемблере.
Я много лет уже даже не открывал сайт Microchip, но был уверен, что сейчас уже у всех производителей процессоров есть компиляторы с С и это и является основным способом разработки а серьезных проектах. А по вашим словам получается, что для PIC до сих пор в основном на ассемблере пишут. Это действительно так?
Да я смотрю, что сейчас их компилятор предлагается прямо на сайте Microchip, видимо они его купили. Вот ссылка.
Качество генерируемого кода было вполне достаточным, в узких местах, где производительность была критичной делались вставке на ассемблере.
Я много лет уже даже не открывал сайт Microchip, но был уверен, что сейчас уже у всех производителей процессоров есть компиляторы с С и это и является основным способом разработки а серьезных проектах. А по вашим словам получается, что для PIC до сих пор в основном на ассемблере пишут. Это действительно так?
Не стану что-то утверждать про состояние разработки на PIC в настоящий момент; про hi-tech C я знаю и код у него, действительно, намного лучше sdcc-шного (sdcc — та еще опенсорсная поделка, но htcc не работает под всякими *nix-ами, что для меня было проблемно).
Могу только сказать, что набор инструкций у него абсолютно не совпадает по парадигме с тем, подо что заточен Си: одни банки памяти чего стоят (в результате получаем большие проблемы с планированием load/store в компиляторе), да и неидемпотентные регистры (сброс по чтению, принципиальные отличия в поведении при чтении/записи) тоже далеко не самая удобная особенность. Насколько я понимаю, порта gcc (который генерирует весьма убогий код, но все же лучше, чем sdcc) именно поэтому и нет. Те же AVR-ы существенно прямее, не говоря уж об ARM-ах.
Могу только сказать, что набор инструкций у него абсолютно не совпадает по парадигме с тем, подо что заточен Си: одни банки памяти чего стоят (в результате получаем большие проблемы с планированием load/store в компиляторе), да и неидемпотентные регистры (сброс по чтению, принципиальные отличия в поведении при чтении/записи) тоже далеко не самая удобная особенность. Насколько я понимаю, порта gcc (который генерирует весьма убогий код, но все же лучше, чем sdcc) именно поэтому и нет. Те же AVR-ы существенно прямее, не говоря уж об ARM-ах.
вы просто не любите ассемблер, как его люблю я!
Именно так. Я вообще не вижу смысла писать на ассемблере (критические куски кода в расчет не берем, это не «писать на ассемблере», это «оптимизировать»).
Во-первых, сам Си — это такой архитектурно-независимый макроассемблер (цитируя одного фрика, ассемблер для PDP-11, которому снится, что он компилятор, и в этом есть доля правды).
Во-вторых, что в нем вообще любить? Да, код для микроконтроллеров зачастую приходится писать на ассемблере. Это не меняет того факта, что такой код не переносим даже между вариантами одной архитектуры (взять хотя бы зоопарк ARM-ов с кучей нюансов), долго пишется, сложно отлаживается и так далее.
Вам никогда не удастся меня убедить, что, скажем, алгоритм PID-контроллера, который выполняет свою задачу (работает достаточно быстро и помещается в выбранный контроллер), лучше писать на ассемблере, чем на т.н. «ЯВУ» (почему в кавычках? см. выше про Си). Учитывая, что даже в самых дешевых ARM-ках (я замечу, что PIC-и не только крайне извращенные, но и весьма дорогие), ресурсов просто навалом, проблемы с крохотными контроллерами отпадают сами собой.
Во-первых, сам Си — это такой архитектурно-независимый макроассемблер (цитируя одного фрика, ассемблер для PDP-11, которому снится, что он компилятор, и в этом есть доля правды).
Во-вторых, что в нем вообще любить? Да, код для микроконтроллеров зачастую приходится писать на ассемблере. Это не меняет того факта, что такой код не переносим даже между вариантами одной архитектуры (взять хотя бы зоопарк ARM-ов с кучей нюансов), долго пишется, сложно отлаживается и так далее.
Вам никогда не удастся меня убедить, что, скажем, алгоритм PID-контроллера, который выполняет свою задачу (работает достаточно быстро и помещается в выбранный контроллер), лучше писать на ассемблере, чем на т.н. «ЯВУ» (почему в кавычках? см. выше про Си). Учитывая, что даже в самых дешевых ARM-ках (я замечу, что PIC-и не только крайне извращенные, но и весьма дорогие), ресурсов просто навалом, проблемы с крохотными контроллерами отпадают сами собой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программирование PIC16f886. Игра «Камень, ножницы, бумага»