|
Сообщение от Luzkov
|
У железной реализации есть преймущество. Пока железо работает ты можеш программу направить на решение других задач. Это ценее золата при сложных проэктах.
На заре ПК тоже все прогрммно решалось. А сейчас? Видио - видиокарта, прередача данных - сетевуха, звук - зуковуха ... А основная прога только АИПИ функции шлет.
При том важно помнить что в железной реализации ошибок при программировании меньше наделаеш.
А скорость написания кода? Послал байт в регистр, выставил флаг, а дальше пусть железо с протоколом парится, у тебя головка не болит.
Я за реализацию в железе (конечно в рамках разумного).
|
Ещё один не очень убедительный пример! Реализация звука, модем, и нек. другие в большенстве современных компов - програмные. Просто скрыты от пользователя за счёт BIOSа. То есть парится с протоколом не железо, а прога написанная другими программистами и являющаяся составной частью железа. А именно материнской платы.
Я не говорю, что софтовая реализация хуже. Обычно безусловно применяется "железная" реализация. И она явно предпочтительна. Но если нет возможности её применить, и достаточно ресурсов у МП, то совтовая реализация предпочтительней применения внешних компонентов. Это совершенно очевидно.
Объясняю почему.
МК отличается от компьютера (это для предыдущего автора). И освобождать ему вычислительную мощность совершенно бесмысленно. Если написанная Вами прога использует 12% вычислительной мощности МК, то он всю оставшуюся жизнь будет работать с такой загрузкой. Таким образом чем эффективней загрузка МК, тем правильнее написана программа. И если имеется возможность убрать какие-то внешние компоненты, то это совершенно необходимо. Прога пишется один раз, а изделие потом серийно выпускается.
У меня было изделие, которое на 89c51 занимало 22 копуса на частоте 12MHz. При переходе на 24 осталось 18. При переходе на at90s8515-8MHz - 13. Использовалось три питания.
Теперь оно выпускается на atmega8+144467 +33063(для формирования необходимых питаний прямо на плате). 16MHz. Выброшена вся аналоговая часть. Сигнал поступает в цифре, внутри преобразуется в математический аналоговый образ, обрабатывается 10 цифровыми фильтрами, перепаковывается в другую цифру и передаётся на кофидек 144467. Внутри контроллера реализовано нескоолько внешних микросхем. Загрузка МК составляет 97%. Выпускается год.
Приведу ещё один пример.
Приборная панель для автобуса МАЗ. ATMEGA8+6 датчиков + шесть шаговых двигателей (стрелки).
Можно применить на каждый двигатель свою микруху с SPI входом. В этом случае мы "разгрузим" МК и упростим программу. Но зачем?
У меня двигателя подключены прямо на ноги МК. используется цифровая фильтрация входных данных, дробление шага на шесть, разгон, торморжение. Независимое выполнение блоков программы (миниOS). И со всем этим мега вполне справляется на 8МГц (внутр. RC). И задействованы все ноги. Так зачем её разгружать???
Зато стоимость - ниже, плата - меньше, наладка - проще, надёжность - выше, гибкость - выше (я сейчас отрабатываю плавность хода стрелок за счёт програмного ШИМа - 12 каналов.)
Посмотрите подход - виртуальная переферия - на сайте UBICOM. Очень интересная идея.
Для avr123-nm-ru. Вы при отладке в VMLAB (помоему) рекомендуете применять МК для эмуляции того или иного устройства. Так я Вам скажу в жизни это тоже не так редко делается. При стоимости МК ~ 1.5$ и при высокой надёжности я иногда применяю такие вещи. Так например в одном случае у меня используется расширитель портов (на 8515). Вход SPI - выход 3 порта х8, 1 порт на 4, и один порт на 8 аналоговый выход (используется ШИМ для формирования выходного изменяемого напряжения).
