Ответы пользователя по тегу Микроконтроллеры
  • Что лучше для embeded WizNet или встроенный MAC в STM32?

    @Mirn
    Для простых задачь однозначно лучше WizNet
    его сильные стороны:
    1. Есть паралельная 8 битная шина - её хватает для достижения скорости в 700 тыс мелких пакетов по 3-5 байт. т.е. 3-5 мегабайт в секунду можно достичь
    2. Внутри уже есть TCP стек и он настроен на скорость - алгоритм деления пакетов на двое и всё прочее.
    3. Есть примеры кода и они реально полезны
    4. Есть хорошая документация и коммунити

    слабые стороны:
    1. TCP стек урезанный и в экзотических пакетах особено бродкастинге может косячить.
    2. мало одновременно открытых каналов (около 4 чтоли).
    3. корпус плохопаябельный мелкий и привередлевый - лучше брать готовую миниплатку.
    4. требования к ген тактов или кварцу особые, можно забить и забыть - но можно вспомнить после пары месяцев безпомощной отладки идиотских и нелепых багов. - хотя это и к стм32 относится тоже, сам езернет не прощает кривого тактирования.

    реализация в МК (именно на стм32 не щупал, только nxp и техасы)
    минусы:
    1. Надо самому подымать TCP стек и по хорошему тут нужна нормальная ОС и весьма не маленький скил программинга чего обычно нет у схематехников и инженеров.
    2. Надо настравивать стек правильно иначе получишь пару килобайт в сек.
    3. качество либ для стека не отличается дружелюбностью, а микроайпи вообще адовый треш
    4. внутренние ДМА буфера часто мелкие и нередко пропускают данные из за обильного бродкастинга уровня DDOS, но хотябы не глючат роняя всю сеть совсем.
    5. требуют для нормальной скорости ОЧЕНЬ МНОГО ПАМЯТИ.
    6. жрут нереально много проц. времени на высокой скорости, хотя тот же целерон 500мгц на самбе тоже работал не быстро из за нехватки проца лет 15 назад.

    плюсы:
    1. можно сделать более сложные штуки - не только TCP протокол а старые и экзотику
    2. все исходники доступны, можно баги в либах править - визнет железо закрытое
    3. все ошибки можно прочесть и обработать (потратив вагон личного времени)
    Ответ написан
    Комментировать
  • Какой выбрать самый быстрый микроконтроллер для создания игровой клавиатуры (PS/2)?

    @Mirn
    Я делал реализацию PS/2 клавиатуры на ванильном intel8051 что 24мгц 12 тактов на инструкцию. Ещё в 90ые этому МК хватало скорости чтоб по прерываниям прямыми ножкодрыганиями формировать коды клавиш, задержек нет, прерывание и опрос и начало передачи гораздо меньше времени занимают чем посылка кода клавишы который по сути UART с мелкими правками (физ уровень как i2c) - он сам по себе медленный и поэтому быстрее 3000-4000 раз в секунду невозможно что либо быстрее передавать - станет каша из бит если мы текущую передачу прервём и начнём нову.
    Поэтому ответ прост - подойдёт любой МК который работает свыше 2 миллионов команд в секунду (вообще любой из современных) и имеет хотябы один вход прерывания - на него повесить через диодное И выход со всех кнопочек что на землю.
    Ответ написан
    Комментировать
  • Как можно отловить случайную багу в embadded проекте?

    @Mirn
    1. Возможно это блокировки шины памяти.
    Они бывают если что-то занимает озу или флешь надолго или уарт очень быстрый, 500кБод и выше.
    Классика жанра - прошивка параметров в флеш или самого флеша. Или работа другого канала ДМА на макс скорости.
    2. Возможно ошибки приёма уарта, советую глянуть осцилографом стабильность уровней напряжения и временную стабильность фронтов.
    3. Баг в коде и порча ОЗУ - советую поменять раскладку памяти, если использовать LD файлы то это прощее, в других более закоренелых системах типа кейла непонятно как. Но метод такой - если перенести буфер уарта на другое место в ОЗУ и всё исправилось то это оно и есть. Можно размер стека изменить, поиграться с размером прочих буферов, массивов и тд.
    4. Попытаться покускам поотключать бизнес код.
    5. Не использовать RTOS - да фантастика, но очень часто причина в нём. Он не идеален, да даже если он был бы идеален, можно накосячить с его использованием.
    6. Неправильно настроенная прочая аппаратура - поотключать левое.
    7. Подумать когда возникла ошибка и об обстоятельстве её возникновения, нередко бывает например когда ошибка в ячейке c смещением 0х13 и тут вспоминаешь что была добавлена стркутура и третий байт массива в этой структуре как раз с смещением 0х13 после вызова уарта меняется ... опа!
    Ответ написан
    6 комментариев
  • Как передать данные через аудиоразъем?

    @Mirn
    однозначно второй вариант "микроконтроллеру добавить сд карту памяти" лучше и предпочтительнее раз возникают проблемы просто с получением звука, и поэтому в реализацию звукового ФСК модема лучше даже не суваться.

    Примеров с СД карточкой море. Но раз не указано на чём делаешь, ардуино/стм32 и тд то ничем помочь не могу. Советую гуглить согласно своей платформе. СД карточки разжованы донельзя, "припаял 10 проводков, скопировал готовый пример и сразу всё заработало" такие примеры из разряда находятся сразу и надо незнай кем быть чтоб их не найти.
    Ответ написан
  • Фриланс, системное программирование и контроллеры?

    @Mirn
    в этом деле чертовски важен опыт инженера, а не ИТшника.
    т.е. знать что и как и что в реале работает и какие случаи бывают.
    поверь, ардуино это stickman, даже не каркас а один иероглиф будущей многотомника.

    очень частот требуется спец например в двигателях, и без наличия на месте и опыта никто не пустит по объективным причинам: ты его сожжёшь, а стоить может и лям и выше.
    часто надо посмотреть сигналы, самому поударять по плате, пальцем провести и тд
    поэтому физ наличие очень рекомендовано

    Мой совет - иди в гос-шарагу, типа радиозавода местного. Но только туда где реально есть полноценное конструкторское КБ и разработки свои. Получишь там опыт и пару грошей на пиво не более. (студентов там за мусор считают).
    Параллельно можно пилить что нибудь своё. умный дом например, или для авто приблуду.
    Пытаться это пиарить, писать статьи в начале в радиокота, потом на изи, потом на хабр - будут критиковать и получишь практ опыт чужих людей. Ну и свой если дело дойдёт до прототипа и запуска его.
    Вполне реально научиться вести самому разработку, совершенствовать и продавать ни от кого не завися. примеров на хабре много DiHalt например.
    Ответ написан
    Комментировать
  • Программирование МК, ASM действительно на 30-40% эффективнее Си?

    @Mirn
    это не правда,
    делая отлично всякую мелочь ручками на асме упустишь всё остальное, т.к. оптимизируешь что-то одно, а в целом выйдет коряво.
    Современные же компиляторы и в целом и в частностях срабатывают получше людей, они делают хорошо сразу всё, пусть не идеально но сразу всё хорошо. Т.е. может один вызов или цикл сделают на 1-2 такта побольше и на пару байт побольше человека, но в общей картине выходит порой В РАЗЫ меньше и быстрее чем человек.

    Высказывание автора про 30-40% хуже можно объяснить только тем что в начале 2000ых для МК компиляторы были не развиты. Теперь же на арм gcc выдаёт отличный код который уделывает даже мастера асма который старался написать минимальную прогу на асме и доказывал что только на нём это можно сделать.
    НО я взял просто gcc и просто и тривиально в лоб написал прогу и она сразу вышла меньше чем результат его статьи
    https://habrahabr.ru/post/274901/#comment_8738493

    вывод: упор на асм и такие заявления в современном мире равноценны признанию в своей некомпетентности.
    А асм сам выучится по практике. главно на СИ уметь писать хорошо и знать язык и компилятор отлично.
    Одним Си обойтись можно. И даже нужно! Хотя-бы потому что надо в начале изучить что-то одно а не научившись ходить записывать в мировую олимпиаду. Многие люди кодят на си не зная асма и проблем не имеют ни с быстродействием нисчем другим.
    Ответ написан
    1 комментарий
  • Изучение С для программирования микроконтроллеров?

    @Mirn
    Внимание: Всё что пишу, пишу про голое железо или простые RTOS (стм32 и тд)

    Это программирование делится на три части:
    1. Это железо! С железом проблем нет, читаем мануал, используем рекомендуемую производителем железа библиотеку по работе с железом получаем гарантированный результат. Трудно будет только по началу. Но это опыт наживной и относительно лёгкий.

    2. Реалтайм и инженерное мастерство и инженерный опыт: Часто проги под МК работать будут в реальном времени налету, ждать никто не будет. Дважды измеренная величина всегда будет отличаться, произойти может что угодно и в какой угодно последовательности. Клоки и тактовая плавает. Количество переданных и принятых данных всегда будет разное даже по одному и тому же уарту. Всё это должна учитывать ТВОЯ программа и не падать при любом раскладе. Как видишь программа будет иметь дело с гораздо большим количеством случайностей чем при программировании в вебе/ПК и повторяемости событий почти не будет. И надо быть чуточку инженером и знать что у всего с чем работаешь есть отклонения и шум в результатах, особенно аналоговых и АЦП.

    3. Это программирование на Си как обычном языке. Тут всё просто и понятно, мануалов море - выбирай по вкусу и цвету.

    4. ОБЩЕЕ АЛГОРИТМИЧЕСКОЕ ПРОГРАММИРОВАНИЕ. Неважно что это железо но алгоритм оптимально но не слишком перфекционистки. Ты должен реализовать и язык тебе тут не поможет, он не связан с алгоритмом и наборов удобных библиотек гораздо меньше чем под ПК и веб.

    5. НЕ УЧИ АССЕМБЛЕР. не углубляйся в схемотехнику, достаточно будет уровня уверенного ардуинщика. Ассемблер сейчас нужен не для написания программ а вылизывания отлично сделанной проги которая уже продаётся но нужно выжать ещё 5-10% быстродействия, ТОЛЬКО ТОГДА. Всё остальное делается либо конфигами либо LD файлом линкера. Дебри схемотехники тоже не нужны, главное понимание как и почему это работает, без всяких четырёх полюсников и глубоких анализов фазовых задержек.
    Ответ написан
    4 комментария
  • Arduino Как из получаемой веб страницы выделить основную часть?

    @Mirn
    искать две пустых строки друг за другом
    и после них уже полезная нагрузка
    dvwviWq.png
    Ответ написан
    Комментировать
  • Stm32 SPL или Регистры?

    @Mirn
    SPL
    плюсы:
    1. Приемлемый уровень абстракции между разными камнями и семействами, есть мануалы как переводить софт с одного на другое семейство стм32 и в них описан ТОЛЬКО SPL
    2. Он понятнее чем запись в регистры, особенно если нужно наработки использовать потом через пару лет или другим человеком.
    3. Сама фирма производитель тестировала чипы именно на SPL и значит порядок работы с периферией что заложен в SPL даст существенно меньше глюков чем любой другой.
    4. В SPL интуитивно понятный и можно писать "на деревню дедушке", т.е. DAC_deinit() например зная что ADC_DeInit() существует значит и другое есть
    5. В SPL всё таки много наработок - в множестве функций есть очень тонкие моменты и ньюансы которые уже сделаны и при работе с регистрами на них точно напорешся и потратишь не одну неделю.

    МИНУСЫ:
    1. SPL медленный, особенно ножкодрыганье - но он для этого не предназначен вообще то и ждать от него скоростей в пару тактов глупо. Да и для 99% задач SPL достаточно быстр. Как решение проблемы использовать побитовый доступ для ножкодрыгания, или один раз через SPL настроил что надо, сохранил все значения регистров в временные переменные и одним memmove просто скопировал в блок регистров сразу всё - максимально быстро особенно для ДМА которой надо дофига всего сделать.
    2. SPL толстый - жрёт много флеша, решается сия проблемма превращением части функций в инлайн вариант, тогда отпадают все проверки для всех блоков переферии и код уменьшается в 3-5 раз но только если он использован разово. Можно напороться на особенности инлайн функций и прочие недостатки. Но для 99% задач размера флеша хватает и садить SPL на диету не нужно или просто глупо.
    3. код SPL громоздкий ... ну вы батенька WinAPI не видели и другие высокоуровневые языки.
    4. SPL написан с учотом что кодить на нём будет профессионал Си и такие ляпы как забыть очистить структуру от мусора стека подразумевается что профессионал не сделает, но если новичок допускает их то сам дурак и можно долго на форумах вонять что SPL гавно - руки от этого не выпрямятся.
    Ответ написан
  • ПЛИС, в каком сейчас состоянии?

    @Mirn
    Знать МК и ПЛИС на порядок лучше чем просто МК. При помощи ПЛИС подключенной к МК можно существенно быстрее и лучше делать сложные проекты в которых нужно управлять чем то сложным или быстрым или где нужно множество выводов (более 100шт например) и тд. Таким образом такой разработчик может сделать почти всё что связано с железом ... (за исключением того что связанно с сетями езернет и инетом - для этого нужны одноплатные ARM Cortex Ax с полноценным Люниксом и полноценными сетевыми протоколами).
    Даже простую периферию чаще проще и быстрее сделать на плис чем разбираться с таймерами, ДМА и тд
    Но это дороже и плата болше, зато разделение хорошее - плис дёргает ножками и делает реалтайм, а МК считает и управляет и дёргает низкоскоростным или не реалтаймовым железом как дисплей, кнопки и тд
    Более того такой разработчик по факту становится незаменимым ... а это в какой то степени и минус - уйти в отпуск почти невозможно, а з/п редко когда могут поднять - часто денег нет и з/п уже максимальная на предприятии.
    Ответ написан
  • Где найти специалиста по микроконтроллерам?

    @Mirn
    Можно попросить / нанять тут:
    electronix.ru/forum/index.php?showforum=24

    Ну а в общем вот:
    electronix.ru/forum/index.php
    Ответ написан
    Комментировать