Jump to content

    

Arlleex

Свой
  • Content Count

    968
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Arlleex

  • Rank
    Господин Никто

Контакты

  • Сайт
    http://
  • ICQ
    0

Recent Profile Visitors

2775 profile views
  1. STM нормально никогда не делали особо. Они сделали в старших сериях чуть получше, ИМХО, но не идеально. Собственно, только поллить. Я делал и на прерываниях, и на прерываниях + DMA. Года четыре назад, когда первый раз писал драйвер I2C под STM32F4, нахлебался косяков в работе этого поделия, в том числе таких, при которых модуль повисал намертво до полной перезагрузки его через RCC-регистры. И никакие серии стоп- или -старт-бит не помогали, только сброс через RCC и полный реконфиг. А не так давно снова пришлось поддерживать I2C под этот камень, но тут я сделал немного по-другому: транзакции и управление состоянием автомата I2C по-прежнему в прерываниях, транзакции данными по DMA, но вся посылка (или некоторые ее части) обрамляется таймерным сторожем. На картинке пример. Так начинается транзакция. В момент (1) происходит запрос на формирование START-условия. Дальше, если тупо поллить, в программе будет бесконечный цикл ожидания установки флага, сигнализирующего о том, что условие сформировано на шине (но я не поллю). А если по прерываниям делать, то поллить не надо и мы влетаем (2) через какое-то время в обработчик, и делаем следующий шаг (3) в алгоритме I2C-автомата - отправляем аппаратный адрес микросхемы. Ну дык вот. Таймер у меня в момент (1) заряжается на интервал, который чутка больше по времени между событиями (1) и (2). Формирую START и запускаю таймер. В ISR I2C, как только обнаружил START-ack (бит SB регистровой модели I2C STM32F4), таймер останавливаю. Теперь надо отправить адрес микросхемы, но до этого рассчитываю интервал таймера на чуть больше времени передачи одного байта; отправляю адрес и запускаю таймер. И так по всему циклу автомата. Если хоть где-то выстрелит прерывание по таймеру, это будет значить, что произошла какая-то лажа на шине - в этом случае я сбрасываю транзакцию, уведомляю необходимые потоки RTOS об этом и перезапускаю периферию. А там что?
  2. В свое время тоже пытался сделать обмен чисто на прерываниях, только окончание прошлой транзакции я оценивал по биту BUSY. Сейчас глянул в исходник - все на прерываниях, кроме злосчастного поллинга BUSY перед началом передачи. Западло, однако... P.S. Интересно снять осциллограмму в случае, когда выставляется STOP и сразу же осуществляется попытка передать START - возможно, контроллер I2C корректно обработает эту портянку и надобность в поллинге отпадет.
  3. Использовал ADuM240/ADuM242 в своих проектах, полет нормальный. Правда, при монтаже, лучше их запаять и больше не лазить туда руками - а то у меня так парочка вышла из строя.
  4. PIC16F1827 как отключить режим PWM?

    Что ж сразу не сказали, что симулятор использовали. Так до бесконечности можно гадать. Соберите в железе, ИМХО, будет все работать.
  5. PIC16F1827 как отключить режим PWM?

    Ну чисто беглым взглядом в Datasheet (стр. 208): Не оно?
  6. Настоятельно рекомендую потренироваться на доноре. Как правило, все идет как по маслу лишь когда рука набита, иначе - С нижним подогревом и паяльником с тонкопроволочной оплеткой очень даже неплохо получается, как тут уже писали.
  7. раскуриваю stm32h7xx_hal_flash.c

    Ну вот ассемблером я иногда, все же, пользуюсь. Редко, конечно, относительно основного кодирования, но, бывает. ИМХО, каждый работает с тем, с чем ему удобнее. Главное хорошо разбираться в своем же творческом беспорядке
  8. раскуриваю stm32h7xx_hal_flash.c

    Помнить, чем там отличается C++11 от C++14, и в свою очередь, чем от них отличается C++17... А через год, глядишь, и опять разбираться придется; либо, впопыхах впихивая новые фишечки, старое компилиться перестанет А тот же C99 уже как бэ не девочка и для разработки под МК его более чем хватает. Впрочем, дело вкуса.
  9. Попутно вопрос тем, кто поддерживал HTTP на МК: протокол программировали сами или пользовались готовым стеком от, например, LwIP?
  10. Я обычно заостряю внимание на сам факт необходимости в "человеке-оркестре". С ЗП вопрос, конечно, интересный. Ну а разве человек с четкой специализацией не должен разбираться в той массе технологий, с которыми, возможно, он не знаком еще даже? С теми технологиями, с которыми ему предстоит еще познакомиться, чтобы иметь принципиальную возможность откликаться на подобные объявления о работе? Как мне кажется, работодатель зачастую предполагает, что программист МК, это человек, который пишет что-то в регистры и иногда читает что-то из внешних микросхем. Ну, может лет 20 назад так и было. Логично, что ему кажется, что работа не шибко сложная и зарплату ему стоит платить на уровне дворника. Сейчас же программист МК уже по своей сути является человеком-оркестром - он, не сильно парясь, изучает различные технологии смежных областей информатики, систем телекоммуникаций - потому что надо. Потому что кого сейчас удивишь мигающим светодиодом, когда Китай штампует чайники с Wi-Fi-ем? А обывателю (да тому же работодателю) такие технологии уже изначально кажутся примитивными. Поэтому он требует бОльшего. А работодатель еще и доплачивать не станет, ибо "какой ты специалист, если за пять минут мне веб-морду не набросал; вон, гляди, китаец делает и не особо возится".
  11. К сожалению, лично я вижу кардинальное снижение востребованности хороших узконаправленных специалистов. И в большинстве случаев нужны люди, которые "и швец, и жнец, и на дуде игрец". Далеко за примерами ходить не надо - почти каждое сообщение в разделе "Предлагаю работу" прекрасно отражает данный факт. Сам я отлично понимаю, что стать во всех специализациях профессионалом не хватит и жизни. Но изучать что-то новое, расширяя свой кругозор, сейчас куда важнее. А, ИМХО, программируя только микроконтроллеры и не понимая, как работает взаимосвязь с внешним современным миром (в том числе миром веб-технологий), особо не разгуляешься - современному программисту МК платят хорошие деньги вовсе не за "светодиодом помигать". Поэтому программист МК, кроме профессионализма в низкоуровневом слое, должен знать и понимать, как ему эту железку совместить с теми технологиями, которые есть в смежных сферах (в данном случае это веб-технологии). Не спроста же ведь специалисту, которому знакомы слова TCP/HTTP и т.д. не понаслышке, в карман прилетает больше, чем тому, кто об этом даже не хочет слышать. Поэтому приходится разбираться и с платами, и с программированием под МК, и с программированием под ПК (чтобы тестовые утилиты писать, прежде чем отдавать железку разработчикам прикладного ПО на ПК (если вообще этим самым программистом, опять же, не являешься ты сам)), и с веб-программированием хотя бы на начальном уровне, для того, чтобы "въехать" и чтобы, будучи потом (возможно) руководителем, не дать ездить по ушам ушлым "специалистам", высасывающим все деньги за десяток строчек кода в квартал Хороший специалист, ИМХО, и это тот, кто понемногу разбирается во всем (при этом не сильно углубляясь в подробности), но отлично разбирающийся в каком-то одном направлении. Для которого не составит большого труда досконально разобраться в чем-то новом для себя - вот это действительно важно.
  12. Как раз сам начал изучать связку HTML/CSS/JS/Ajax для более комфортного ощущения себя в веб-дизайне (в том числе и для приложений на МК). Стоит один раз прошить МК из смартфона через браузер, как назад пути уже нет...
  13. Случай действительно забавный, но реальный
  14. Свое прерывание

    Ну вот определитесь, что Вам нужно. А то до setjmp/longjmp так дойдем.
  15. Свое прерывание

    Еще раз: если аппаратура МК имеет физическую реализацию вектора прерывания, то Вы вправе делать с этим вектором что угодно и описывать его как заблагорассудится. Если вектора нет - Вы должны описать его как пустое пространство (например, с помощью директивы DCD 0) и не иметь попыток доступа к этому вектору любым способом, потому что это вызовет, скорее всего, какой-нибудь fault, эскалирующий до HF при возможности. Резюме: Вы можете сформировать программный запрос на любое прерывание, физически выведенное на NVIC.