Помогите выбрать - PIC или AVR или ARM

[my504]

Вы обсуждаете вопросы соотношения труда схемотехника и программиста в профессиональных применениях. Причем тут форум вообще? Прежде чем делиться мнением прочтите последних 10...15 постов. А то как то не в кассу....

[Реклама]

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

[COKPOWEHEU]

Прочитал. Ничего не изменилось. Можете назвать основные применения МК где нужна серьезная аналоговая часть? Я сейчас могу вспомнить только аудиопреобразователи (да и то, преобразование-то ведется в цифровом виде и входные характеристики АЦПа изменить довольно трудно). Вот применения МК как цифрового устройства гораздо проще найти, достаточно оглянуться вокруг (я имею в виду не столько "радиолюбительские" МК, сколько МК вообще, включая встроенные в бытовую технику)

Причем тут форум вообще?

Ну надо же по чему-то судить. Сюда же приходят не только студенты с лабами.

А вот Вам бы не помешало почитать первый пост с описанием самой проблемы.

Давно с завистью смотрю на тех кто умеет делать всякие штучки на микроконтроллерах, вроде дозрел до того чтобы и самому что-то попытаться сделать, попытаться научится программировать. <...> С чего бы вы почоветовали начать ?

[Реклама]

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

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

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

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

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

[my504]

Прочитал. Ничего не изменилось.

Странно... последние десяток постов обсуждался вопрос соотношения трудозатрат программиста и схемотехника. Авторский вопрос давно себя исчерпал.

В качестве примеров применения МК в аналоговой технике могу привести:

-управление электродвигателями

-управление измерительными приборами, включая обработку результатов

-автоматика защиты в электросетях

-детекторы физических величин (давление, температура, влажность, концентрация газов, тензоизмерители......)

-локационная техника (сонары, радары, детекторы тегов, дальномеры....)

-автоматика механических устройств (двигатели внутреннего сгорания, роботы, станки....)

-обработка звука и изображения

-автоматика бытовых приборов (телевизоры, приемники, СВЧ-печи, кофеварки, утюги, стиральные машины, посудомойки....)

- игрушки

далее продолжать?

Во всех этих приборах основная функция сугубо аналоговая. МК поддерживает схемотехнику на верхних уровнях обработки-управления. Т.е. протоколы и вычислительные функции в таких приложениях занимают хоть и важную, но второстепенную нишу.

Это всё продукты разработки радиоинженера-схемотехника прежде всего....

[Реклама]

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

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

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

[COKPOWEHEU]

Во всех этих приборах основная функция сугубо аналоговая.

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

"-управление измерительными приборами, включая обработку результатов" см. выше

"-автоматика защиты в электросетях" - сравнение текущего значения напряжения (тока) с предельным. Логическая операция.

"-детекторы физических величин (давление, температура, влажность, концентрация газов, тензоизмерители......)" - от программиста требуется только преобразование кода величины к выводу на индикатор и составление корректирующих таблиц.

"-локационная техника (сонары, радары, детекторы тегов, дальномеры....)" - в основном это измерение интервалов времени. Формирование "логического" сигнала из входного - задача схемотехника.

"-автоматика механических устройств (двигатели внутреннего сгорания, роботы, станки....)" - как раз логическая. Алгоритм движения инструмента.

"-обработка звука и изображения" - согласен

"-автоматика бытовых приборов (телевизоры, приемники, СВЧ-печи, кофеварки, утюги, стиральные машины, посудомойки....)" - Телевизоры и приемники - возможно, остальное - нет, в СВЧ-печке, кофеварке, стиральной машине МК в основном обрабатывает алгоритм работы переферии (скорость барабана там или мощность магнетрона). Утюг - аналогично термометру, только добавляется сравнение логических величин.

"- игрушки" - чистая цифра. Даже "музыкальные" автоматы: аналоговая часть начинается после ЦАПа или ШИМа, ее фильтрование также не относится к программе. А уж мигалки и декодеры команд радиоуправления вообще с аналогом не контактируют.

"-моторы" - не уверен, но аналоговое управление требуется только в асинхронных, да и то его стараются применять пореже. Цифровое реализовать проще.

[my504]

Это все чистый бред.

Сначала сделайте своими руками реальный датчик с выходом на АЦП с потребной для устройства точностью, либо силовой драйвер, который не устроит пожар через 2 мин. работы, либо схему обработки сигнала, которая поддерживается МК вменяемой стоимости и т.п.

Сразу видно, что ничего серьезного в этой области вы не только не делали, но даже и не анализировали с целью обучения.

Считать, что ключевым сечением является АЦП - радиолюбительщина в худшем проявлении.

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

Изменено 25 июня, 2010 пользователем my504

[lc433]

Вы спорите кто важнее, программист или схемотехник? Непростой вопрос... Схемотехник может обойти программиста, намотав трансформатор для сварки. А программист не сможет написать ВЧ-сварку без применения схемотехнических решений. Поэтому в джунглях, вероятно, выживет именно схемотехник.

[тимвал]

В джунглях выживет ТИГР! А эти оба пойдут ему на корм.

[Alexeyslav]

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

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

[rtfcnf]

Извиняюсь за оффтоп:

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

ИМХО:

Каждый выполняет свою работу дополняя друг друга, поэтому спор не корректен.

[Alexeyslav]

Ну почему же некорректен, из примера видно что программный подход постепенно вытесняет схемотехнику... Уже появились полностью цифровые ФМ-приемники, ни единого контура - полосовые фильтры на кристалле + усилитель а все остальное делается программно - демодулятор, ФАПЧ, и т.д.

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

[rtfcnf]

Конкретный пример: У меня один коллега без знания схемотехники, программист одним словом, собрал плату на базе микросхемы AD9910 дня два удивлялся почему по SPI она не хочет управляться, а знал бы схемотехнику обратил бы внимания на требования к фронтам предъявляемые данным чипом для SPI интерфейса, и не пришлось бы переделывать плату.

Изменено 29 января, 2011 пользователем rtfcnf

[lc433]

Если копнуть глубже, они оба - ничто. И схемотехник и программист без микросхем и компиляторов ничего не смогут сделать. Кроме, разве что, совместного ведения натурального хозяйства. Возможности обоих определены (иногда даже ограничены) производителями чипов и разработчиками средств программирования.

Создание же продукта берет свое начало не в цехе или кабинете, а в конструкторском бюро, в иследовательском институте, в умах научных работников. Поэтому я не стал бы боготворить ни схемотехника, ни программиста. Если кто-то и может почувствовать себя Богом во всей этой цепочке, то это несомненно Учёный.

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

[nikakoy]

Помогите с выбором контролера. Основная проблема не в фирме(архитектуре) а вычислительной мощности. Учил всего почучуть (AVR, PIC, ARM) Как посчитать образно нужную вычислительную мощность.? устройство будет принимать масив данных 160х120 , по параллельному 8бит интерфейсу, искать строку и столбец с максимальной суммой элементов от 0 до 255 и выдавать номера по spi. что посоветуете? считать надо хотя бы 15 кадров за сек. реально ли такое " в домашних условиях"? я подозреваю, что нужен арм с немаленькой частотой

Изменено 10 февраля, 2011 пользователем nikakoy

[Alexeyslav]

Я думаю практически любой контроллер справится, только что значит "максимальная сумма элементов от 0 до 255", и собственно какой массив, каждый элемент его может быть размером в 1 бит или 1кБайт...

Если принять что там передается байт, то контроллеру надо будет принять 160x120x15 = 288000 элементов и просуммировать в 160+120 = 280 ячеек памяти. Это не так уж и много. Просчитать это все дело не так уж и сложно, прием данных скорей всего будет происходить по прерыванию(не организовывать же цикл ожидания следующей порции данных в основной программе) - а значит, суммирование и сохранение результата в ячейку памяти должно произойти по крайней мере раньше чем поступит следующая порция. по окончанию передачи массива пройти по ячейкам и найти максимум - это займет немного времени (всего 280 ячеек).

[nikakoy]

Я думаю практически любой контроллер справится, только что значит "максимальная сумма элементов от 0 до 255", и собственно какой массив, каждый элемент его может быть размером в 1 бит или 1кБайт...

имеется ввиду масив размером 160 столбцов и 120 строк, каждый элемент может принимать значения от 0 до 255 (тоесть 8 бит). ну вобщем это изображение. тоесть если я все правильно себе представляю элементов у нас 160*120=19200. в каждом элементе 8 бит - 19200*8=153600 бит ну и если 15 кадров то 153600*15=2304000 бит за сек - 2 Мбит/с. Многовато для любого элементарного. темболее что хотелось бы 30 кадров за секунду ну и запас для вычислений, управлений. И запас тоже хотелось бы побольше чтоб можно было усложнять алгоритмы обработки и подключать перефирию. Я так понимаю мне надо искать "полюбившийся народом", недорогой, быстрый, в QFP а лучше SOIC корпусе

[Alexeyslav]

так ты же собрался не последовательно загружать данные, а параллельно - а это значит, 288000 загрузок в секунду.

Вобщем, надо прикинуть сколько тактов может занять обработка и рассчитать необходимую тактовую частоту.

Чтобы подсчитывать сумму для строки - достаточно одной команды сложения, а для суммы каждого столбца - вычисление адреса ячейки(обычный инкремент) где хранится сумма, собственно операция суммирования и сохранение в той же ячейке. 10Мгц тактовой частоты(по 34 такта на выполнение всей работы) поидее должно хватить с головой, с учетом того что будет использован конвеер команд и каждая команда будет выполнятся за 1 такт.

[nikakoy]

так ты же собрался не последовательно загружать данные, а параллельно - а это значит, 288000 загрузок в секунду.

Вобщем, надо прикинуть сколько тактов может занять обработка и рассчитать необходимую тактовую частоту.

Чтобы подсчитывать сумму для строки - достаточно одной команды сложения, а для суммы каждого столбца - вычисление адреса ячейки(обычный инкремент) где хранится сумма, собственно операция суммирования и сохранение в той же ячейке. 10Мгц тактовой частоты(по 34 такта на выполнение всей работы) поидее должно хватить с головой, с учетом того что будет использован конвеер команд и каждая команда будет выполнятся за 1 такт.

а как прикинуть? я то ведь буду писать явно не на ассемблере где всегда знаеш за сколько тактов выполняется команда. или я чегото не понимаю о си? тоесть по вашим расчетам мне хватит меги16? (она самая привычная и родная )

[rtfcnf]

>>а как прикинуть?

Практически каждый СИ компилятор умеет создавать ассемблерный листинг того что Вы написали. Вот в нем и посмотреть и посчитать сколько и каких команд выполняется.

[Alexeyslav]

Такие вещи надо делать только на ассемблере, если начнешь делать на Си - результат трудно будет предсказать, может и 40Мгц не хватить. Чтобы выжать максимум производительности, нужен полный контроль над выполнением который может дать только ассемблер. По крайней мере, саму процедуру накопления статистики - а передачу результата можно делать и на Си - эта часть алгоритма вполне может выполнятся в перерывах между обработкой прерывания.

[nikakoy]

Такие вещи надо делать только на ассемблере, если начнешь делать на Си - результат трудно будет предсказать, может и 40Мгц не хватить. Чтобы выжать максимум производительности, нужен полный контроль над выполнением который может дать только ассемблер. По крайней мере, саму процедуру накопления статистики - а передачу результата можно делать и на Си - эта часть алгоритма вполне может выполнятся в перерывах между обработкой прерывания.

так я и не хотел усложнять себе задачу я вот и думал попробовать с мощными арм, ради полезного опыта. Спасибо за совет. Ну может тогда посоветуете конкретную микросхемку (очень надеюсь на SOIC корпус или подобные) по мощней AVR (желательно не дорогой) ну и програмный пакет. Ато я до сих пор занимался только теорией, касательно микроконтролеров, ну и порстенькие програмки в VMlab ну и IAR писал. Буду очень благодарен с выбором. Ато именно такие практические вопросы отнимают больше всего времени у начинающих...

Чуть почитал я так понимаю надо смотреть в сторону ATmega128...

Изменено 10 февраля, 2011 пользователем nikakoy

[rtfcnf]

А откуда Вы будете загружать данные по параллельному интерфейсу? Другими словами, что за источник потока данных?

[nikakoy]

А откуда Вы будете загружать данные по параллельному интерфейсу? Другими словами, что за источник потока данных?

не хотелось рассказывать подробности проекта. но уже не вижу выхода, так как проект все больше кажется не выполнимым для меня. входные данные по 8 разрядной шине должны поступать от видео камеры.

но теперь проблема в том что ОЗУ в ATmega128 всего 4кБ а один кадр содержит в моем случае 19,2 кБ(поправте если не прав). Обойти надобность хранения кадров для моих расчетов я не придумал как. подключать внешнее озу + мучаться с написанием программы на асемблере, кажется слишком трудоемким. Все больше склоняюсь к мощному АРМ из преимуществ: мощности должно хватить для Си, ну и куча полезных интерфейсов типа ЮСБ хотя по АРМ и знаний минимум...

Изменено 11 февраля, 2011 пользователем nikakoy

[rtfcnf]

Если не хранить данные кадра, то думаю можно попробовать и на AVR.

Тогда следующий вопрос:

Как планируете пересылать данные на шину? Будет внешний строб? Если да, могу попробовать прикинуть сколько времени займет обработка. Напишу на СИ и сформирую ассемблерный листинг. И еще раз, что Вам надо сделать с кадром. Подсчитать сумму каждой строки и ....

[nikakoy]

Если не хранить данные кадра, то думаю можно попробовать и на AVR.

Тогда следующий вопрос:

Как планируете пересылать данные на шину? Будет внешний строб? Если да, могу попробовать прикинуть сколько времени займет обработка. Напишу на СИ и сформирую ассемблерный листинг. И еще раз, что Вам надо сделать с кадром. Подсчитать сумму каждой строки и ....

именно да. там же есть кадровая и строчная синхронизация. камера с каждым своим тактом(ее можно настроить на те же 16МГц что и ATmega, ну и синхронизировать по идее) выдает информацию об одном пикселе. по сути надо находить номер строки с максимальной сумой и столбца тоже с максимальной сумой. данная штука написанная в матлабе хорошо работает, только не очень быстро, но это как я понимаю особенности матлаба. хочу перенести в контроллер. не выйдет, тогда на делфи.

хранить кадр нужно, темболее в перспективе надо еще и другой алгоритм прикрутить для других целей

[Alexeyslav]

Потому что матлаб производит вычисления в числах с плавающей запятой.

Для чего надо хранить весь кадр? Ведь всеравно его не успеешь обработать за время кадровой синхронизации(хотя кто знает...) ведь камера не будет ждать.

И все-таки такие участки лучше делать сразу на ассемблере, а не надеятся на оптимизатор компилятора.

Хранить можно и во внешней ОЗУ в режиме прямого доступа к памяти. Хочешь-не-хочешь, а всеравно прийдется познакомится с этой технологией.