Для этого например существует целевое обучение в вузах - но как по мне из именно целевиков кадры в большинстве случаев посредственные, не претендую на истину, чисто из личных наблюдений. Куда лучше иметь знакомых профессоров в вузах - заинтересованных и способных ребят они в состоянии заметить довольно быстро. И с такими людьми уже можно работать. Все в выигрыше:
студенты получают актуальные знания и реальный практический опыт, а не устаревающую с бешеной скоростью программу вуза;
вы получаете сотрудника, который знает ваш стек, продукт и легче вкатывается в процессы в виду отсутствия привычек (иногда не очень полезных).
А вы можете дать гарантию, что найденный с такими трудозатратами сеньор не помашет вам ручкой через день/месяц/год даже не окупив их?
А польза будет для всего рынка. Без джунов не будет ни мидлов, ни остальных. Учитесь создавать условия, чтобы человек был менее заинтересован в уходе. И да люди будут приходить и уходить, по тысяче причин - с этим фактом нужно научится жить. Крепостное право все же давно отменили.
В ТК для этого отдельная вещь придумана - испытательный срок. Только вместо того, чтобы сократить расходы на найм, все ставят заборы повыше да подороже, а потом все равно остаются с непризрачным шансом, что человек пробившийся через этот самый забор - не потянет, а стоимость его найма уже составила оверхед.
Все и так уже воют, что банально до тех. интервью через расставленные hr-ами фильтры не пробиться, а вы предлагаете поставить забор повыше - не находите в этом проблему? И не забывайте, что пока вы сидите и ждёте своего единственного и прекрасного единорога - вы теряете деньги и время, а иногда и других людей, ишачащих за себя и за Сашку. Так может хоть будете тогда терять его с пользой, обучая джуна)
Мое мнение, что в текущей ситуации надо не искать сеньоров-помидоров-фуллстек-рокзвезд (вы все равно их не потянете по деньгам в большинстве случаев), а вкладываться в джунов и рекрутинг начинать с вузов. Да это не спец тут и сейчас, да это дорого (но все ещё дешевле), но вы со временем (и относительно небольшим при грамотном подходе) получите тех самых кадров, которые нужны вам для решения ваших же бизнес задач. И не нужно будет гадать на этапе найма, берете вы очередного: вкатуна/волка/промпт-"инженера".
Так остальные вполне справедливы, а статья для кого-то да будет полезна. Хотя бы в части GDB сервера.
У Миландра на платах вообще зачастую торчит JTAG (на некоторых платах аж 2 сразу), и отдельно программатора в составе платы нет, не считая загрузку по UART.
В плане надёжности тоже такое, а вот не держать кучу старых кабелей действительно было бы приятно. У ST-шников просто есть n-разновидностей идентичных борд на разных камнях, вот видимо и не заморачиваются с заменой пока что.
Ну до MiniUSB в отладочной плате, цена которой чем ближе к нулю, тем лучше для всех, докопаться это конечно такое) Есть желание переплачивать за USB-C? На H7 платах вообще до сих пор micro ставят)
И что одно, что второе выглядит как бесполезная трата человеческого, временного и технического ресурса, ибо кто ищет, тот найдет способ как до этого самого "контента" добраться.
Взять тот же Ютуб: если вы там не ищете контент на какую-либо тему, то вероятность того, что вам это полетит в ленту стремится к нулю, а даже если таки рандомно залетело - волшебная кнопка "не рекомендовать видео с данного канала" вам в помощь, для особо чувствительных даже кнопка репорта есть (проверено, работает - один канал с мягко скажем "неудовлетворительным обращением с животными" отъехал в течении пары суток). Но всегда найдутся мыши кушающие кактус.
Фиксированная длинна пакета не то чтобы прямо плохо и ужасно, если нет желания в бинарном протоколе сопровождать данные заголовками и надо гонять сообщения быстро, то вполне приемлемо (за исключением поддержки и ломающегося обмена при апдейтах). Там именно больше вопросов к тому, что какой смысл был пытаться в ASCII строку, если по факту с ней работать один черт невозможно, приходится выгребать все 0x30, обратно клеить "полубайты" в байты и работать по факту с бинарным протоколом. Ещё из "приколов" той же железки, при реверсе протокола выяснилось, что хендшейк идёт через запрос версии (ПО/железа? а вот черт его знает) и на один и тот же запрос приходят разные ответы. Всего ответов оказалось два для более новой железки и один для более старой. В итоге если по какой-либо причине терялся один из запросов для новой железки она наглухо отрубала обмен без какого-либо ответа. Игнорировалась даже команда для софт ребута. Пришлось городить логику с контролем ответа на первое сообщение и дальше уже либо слать второй запрос, либо уже работать по остальной части протокола. Не удивлюсь, если в новом железе тоже поменялся хендшейк.
Ну и вместо обычной unix-time метки был какой-то свой костыль который по сути отличался только начальной датой ¯\_(ツ)_/¯
Спустя несколько лет ковыряния как своих, так и чужих протоколов пришел к выводу, что лучше потратить время, но сделать поддержку как бинарного, так и текстового протокола (не обязательно json). Первый даст скорость и компактность кому это реально нужно, а второй в самом плохом варианте даст достучаться до железки на коленке, без мучительных попыток вспомнить "да где ж тот самый бит в этом месиве".
После протокола одних "коллег по цеху" глаз до сих пор дёргается, вот вроде и пакуют в стандартную строку ASCII символов, но нет же, байты бьют на "полубайты" (если что, это цитата из документации), докидывают 0x30 и начинаешь ловить по итогу и спецсимволы и текст там, где ждёшь числа. Зачем и чего ради непонятно, ибо получается и хуже битового и сложнее для парсинга, чем текстовые. И все это при фиксированной длине пакета.
Разработка на одноплатник тоже не бесплатная же, по части плат (если не берём ST-шные, а любой Китай) будет не дороже. В целом как прототип - ок, но добиться лучшей разрешающей способности по дальности, а как я понял, то больше интересует именно детекция дистанции до грозы, то тут уже повозиться придется, если оно конечно нужно вообще, условно что-то обесточить и ошибки в 300 метров вполне можно простить
Так основная проблема в текущем виде - цена, даже если не заморачиваться со своей платой, то можно уложиться в сильно меньшую стоимость, чем брать любой одноплатник, заведомо отъедая одно ядро на мало эффективную работу. И как тут люди заметили, при грамотном подходе с DMA вы получите и лучшие показатели по скорости АЦП и ядро будет в простое почти все время, можно его спокойно нагрузить ещё чем-нибудь.
Ну вы же не гигабайтами данные храните + выгрузка на сервер. Обновляться можно так же по сети/UART/microsd. Одноплатник все же дорого для такого детектора. Причем одно ядро которого фуллтайм занято, я бы понял если бы детекции была мало ощутимой фоновой нагрузкой. Для массовости стоит упростить и удешевить решение.
Да имелась ввиду документация, NVIC упомянут естественно в контексте ARM, в других контроллерах контроллер прерываний может иначе именоваться.
В RTOS это разруливается отдельным api работы с примитивами синхронизации и очередями из ISR. Это конечно накладывает определенные затраты на время реакции системы и в каждом случае надо смотреть под конкретную задачу. Грубо говоря сам callback может быть в целом отвязан логикой от RTOS, но в нем все равно придется вернуть например семафор/очередь через api, чтобы дать контекст планировщику. Допустим есть несколько таймеров, callback они могут дергать один и тот же, внутри уже определяем кто конкретно его вызвал и для каждого отдельно дергаем семафоры RTOS. Только держим в уме, что помимо приоритетов самих прерываний нужно учитывать и приоритеты задач. Таким образом можно условно "параллельно" обработать несколько таймеров например, просто на каждом тике прыгая между отдельными задачами туда-обратно, естественно по итогу потратим и на один и на другой больше времени, но один при этом не будет ждать полного выполнения таски другого.
Не путайте callback и сам вызов обработчика прерывания, у STM callback'и это буквально функции вызывающиеся HAL кодом из ISR и они сами читают и сбрасывают флаги в большинстве своем, да по умолчанию они имеют weak атрибут и 0 нагрузки внутри, но логика проверки флагов присутствует всегда, а это те самые ветвления кушающие драгоценные такты. Поэтому при большом объеме прерываний их и невозможно нормально использовать, так как главное правило "обработчик должен быть компактным и достаточным" нарушается. Плюс расходы на перенос контекста в стек и обратно. Такое считается всегда для худшего варианта развития событий когда асинхронных вызовов может прилететь сразу пачкой и у каждого есть жёсткие требования по тайм-ауту. Изначальная ценность callback'ов и самого HAL - простота миграции кода между разными МК.
Все callback вызовы всегда прозрачны, независимо от того работаете вы с голым железом или через ОСРВ. Если требуется ковырять макросы ST, то это явный указатель того, что в данной части кода лучше вообще отказаться от callback'ов и написать обработчик прерывания самостоятельно, благо это не рокетсайнс. И номенклатура прерываний там не такая страшная, открываем описание NVIC и все на ладони.
"будет туча callback, реализовать которые надо самому программисту"
Это далеко не слезы) Как минимум, коллбеки сами обрабатывают флаги большинства периферии (за исключением коллбеков ошибок, там да, надо ручками почитать стейты и обработать их). А, если прямо жмет, то лучше вообще обойтись без них и ручками написать свои, исходя из заложенного функционала, чтобы не тратить время на проверку флагов, которые никогда в данной конфигурации не появятся вовсе.
Количество тактов по-честному все равно нужно считать после трансляции в асм. Либо закладывать везде счетчики тиков и понимать, на чем реально они съедаются (пока опустим даже работу стека в режиме вложенных прерываний). Плюс не забываем про конвейер в АРМ, который с теми же nop ассемблерными вставками может вести себя по разному. А вот барьеры памяти, кеширование - действительно первое время вызывают боль, но это уже касается высокопроизводительных ядер, у того же Cortex-M4 кеш работает предсказуемее и иначе в отличии от М7 и надо понимать как организовать доступ к данным тому же DMA.
Так что жить стало определенно проще. Я начинал с 8051 и его ассемблера, и возвращаться к нему после АРМ и Си вообще не хочется)
Если есть возможность - использовать внешний источник опорного напряжения. В некоторых приложениях и вовсе внешний АЦП с соответствующей обвязкой.
Для этого например существует целевое обучение в вузах - но как по мне из именно целевиков кадры в большинстве случаев посредственные, не претендую на истину, чисто из личных наблюдений. Куда лучше иметь знакомых профессоров в вузах - заинтересованных и способных ребят они в состоянии заметить довольно быстро. И с такими людьми уже можно работать. Все в выигрыше:
студенты получают актуальные знания и реальный практический опыт, а не устаревающую с бешеной скоростью программу вуза;
вы получаете сотрудника, который знает ваш стек, продукт и легче вкатывается в процессы в виду отсутствия привычек (иногда не очень полезных).
"Можно, а зачем?" - более актуальными трендами
А вы можете дать гарантию, что найденный с такими трудозатратами сеньор не помашет вам ручкой через день/месяц/год даже не окупив их?
А польза будет для всего рынка. Без джунов не будет ни мидлов, ни остальных. Учитесь создавать условия, чтобы человек был менее заинтересован в уходе. И да люди будут приходить и уходить, по тысяче причин - с этим фактом нужно научится жить. Крепостное право все же давно отменили.
В ТК для этого отдельная вещь придумана - испытательный срок. Только вместо того, чтобы сократить расходы на найм, все ставят заборы повыше да подороже, а потом все равно остаются с непризрачным шансом, что человек пробившийся через этот самый забор - не потянет, а стоимость его найма уже составила оверхед.
Все и так уже воют, что банально до тех. интервью через расставленные hr-ами фильтры не пробиться, а вы предлагаете поставить забор повыше - не находите в этом проблему? И не забывайте, что пока вы сидите и ждёте своего единственного и прекрасного единорога - вы теряете деньги и время, а иногда и других людей, ишачащих за себя и за Сашку. Так может хоть будете тогда терять его с пользой, обучая джуна)
Ну тогда можно продолжать сидеть и ждать сказочных единорогов, желательно задешево)
Мое мнение, что в текущей ситуации надо не искать сеньоров-помидоров-фуллстек-рокзвезд (вы все равно их не потянете по деньгам в большинстве случаев), а вкладываться в джунов и рекрутинг начинать с вузов. Да это не спец тут и сейчас, да это дорого (но все ещё дешевле), но вы со временем (и относительно небольшим при грамотном подходе) получите тех самых кадров, которые нужны вам для решения ваших же бизнес задач. И не нужно будет гадать на этапе найма, берете вы очередного: вкатуна/волка/промпт-"инженера".
Так в этом утверждение меняем раст на <language name> и оно продолжает так же работать.
Так остальные вполне справедливы, а статья для кого-то да будет полезна. Хотя бы в части GDB сервера.
У Миландра на платах вообще зачастую торчит JTAG (на некоторых платах аж 2 сразу), и отдельно программатора в составе платы нет, не считая загрузку по UART.
В плане надёжности тоже такое, а вот не держать кучу старых кабелей действительно было бы приятно. У ST-шников просто есть n-разновидностей идентичных борд на разных камнях, вот видимо и не заморачиваются с заменой пока что.
Ну до MiniUSB в отладочной плате, цена которой чем ближе к нулю, тем лучше для всех, докопаться это конечно такое) Есть желание переплачивать за USB-C? На H7 платах вообще до сих пор micro ставят)
И что одно, что второе выглядит как бесполезная трата человеческого, временного и технического ресурса, ибо кто ищет, тот найдет способ как до этого самого "контента" добраться.
Взять тот же Ютуб: если вы там не ищете контент на какую-либо тему, то вероятность того, что вам это полетит в ленту стремится к нулю, а даже если таки рандомно залетело - волшебная кнопка "не рекомендовать видео с данного канала" вам в помощь, для особо чувствительных даже кнопка репорта есть (проверено, работает - один канал с мягко скажем "неудовлетворительным обращением с животными" отъехал в течении пары суток). Но всегда найдутся мыши кушающие кактус.
Фиксированная длинна пакета не то чтобы прямо плохо и ужасно, если нет желания в бинарном протоколе сопровождать данные заголовками и надо гонять сообщения быстро, то вполне приемлемо (за исключением поддержки и ломающегося обмена при апдейтах). Там именно больше вопросов к тому, что какой смысл был пытаться в ASCII строку, если по факту с ней работать один черт невозможно, приходится выгребать все 0x30, обратно клеить "полубайты" в байты и работать по факту с бинарным протоколом. Ещё из "приколов" той же железки, при реверсе протокола выяснилось, что хендшейк идёт через запрос версии (ПО/железа? а вот черт его знает) и на один и тот же запрос приходят разные ответы. Всего ответов оказалось два для более новой железки и один для более старой. В итоге если по какой-либо причине терялся один из запросов для новой железки она наглухо отрубала обмен без какого-либо ответа. Игнорировалась даже команда для софт ребута. Пришлось городить логику с контролем ответа на первое сообщение и дальше уже либо слать второй запрос, либо уже работать по остальной части протокола. Не удивлюсь, если в новом железе тоже поменялся хендшейк.
Ну и вместо обычной unix-time метки был какой-то свой костыль который по сути отличался только начальной датой ¯\_(ツ)_/¯
Спустя несколько лет ковыряния как своих, так и чужих протоколов пришел к выводу, что лучше потратить время, но сделать поддержку как бинарного, так и текстового протокола (не обязательно json). Первый даст скорость и компактность кому это реально нужно, а второй в самом плохом варианте даст достучаться до железки на коленке, без мучительных попыток вспомнить "да где ж тот самый бит в этом месиве".
После протокола одних "коллег по цеху" глаз до сих пор дёргается, вот вроде и пакуют в стандартную строку ASCII символов, но нет же, байты бьют на "полубайты" (если что, это цитата из документации), докидывают 0x30 и начинаешь ловить по итогу и спецсимволы и текст там, где ждёшь числа. Зачем и чего ради непонятно, ибо получается и хуже битового и сложнее для парсинга, чем текстовые. И все это при фиксированной длине пакета.
Разработка на одноплатник тоже не бесплатная же, по части плат (если не берём ST-шные, а любой Китай) будет не дороже. В целом как прототип - ок, но добиться лучшей разрешающей способности по дальности, а как я понял, то больше интересует именно детекция дистанции до грозы, то тут уже повозиться придется, если оно конечно нужно вообще, условно что-то обесточить и ошибки в 300 метров вполне можно простить
Так основная проблема в текущем виде - цена, даже если не заморачиваться со своей платой, то можно уложиться в сильно меньшую стоимость, чем брать любой одноплатник, заведомо отъедая одно ядро на мало эффективную работу. И как тут люди заметили, при грамотном подходе с DMA вы получите и лучшие показатели по скорости АЦП и ядро будет в простое почти все время, можно его спокойно нагрузить ещё чем-нибудь.
Ну вы же не гигабайтами данные храните + выгрузка на сервер. Обновляться можно так же по сети/UART/microsd. Одноплатник все же дорого для такого детектора. Причем одно ядро которого фуллтайм занято, я бы понял если бы детекции была мало ощутимой фоновой нагрузкой. Для массовости стоит упростить и удешевить решение.
Да имелась ввиду документация, NVIC упомянут естественно в контексте ARM, в других контроллерах контроллер прерываний может иначе именоваться.
В RTOS это разруливается отдельным api работы с примитивами синхронизации и очередями из ISR. Это конечно накладывает определенные затраты на время реакции системы и в каждом случае надо смотреть под конкретную задачу. Грубо говоря сам callback может быть в целом отвязан логикой от RTOS, но в нем все равно придется вернуть например семафор/очередь через api, чтобы дать контекст планировщику. Допустим есть несколько таймеров, callback они могут дергать один и тот же, внутри уже определяем кто конкретно его вызвал и для каждого отдельно дергаем семафоры RTOS. Только держим в уме, что помимо приоритетов самих прерываний нужно учитывать и приоритеты задач. Таким образом можно условно "параллельно" обработать несколько таймеров например, просто на каждом тике прыгая между отдельными задачами туда-обратно, естественно по итогу потратим и на один и на другой больше времени, но один при этом не будет ждать полного выполнения таски другого.
Не путайте callback и сам вызов обработчика прерывания, у STM callback'и это буквально функции вызывающиеся HAL кодом из ISR и они сами читают и сбрасывают флаги в большинстве своем, да по умолчанию они имеют weak атрибут и 0 нагрузки внутри, но логика проверки флагов присутствует всегда, а это те самые ветвления кушающие драгоценные такты. Поэтому при большом объеме прерываний их и невозможно нормально использовать, так как главное правило "обработчик должен быть компактным и достаточным" нарушается. Плюс расходы на перенос контекста в стек и обратно. Такое считается всегда для худшего варианта развития событий когда асинхронных вызовов может прилететь сразу пачкой и у каждого есть жёсткие требования по тайм-ауту. Изначальная ценность callback'ов и самого HAL - простота миграции кода между разными МК.
Все callback вызовы всегда прозрачны, независимо от того работаете вы с голым железом или через ОСРВ. Если требуется ковырять макросы ST, то это явный указатель того, что в данной части кода лучше вообще отказаться от callback'ов и написать обработчик прерывания самостоятельно, благо это не рокетсайнс. И номенклатура прерываний там не такая страшная, открываем описание NVIC и все на ладони.
"будет туча callback, реализовать которые надо самому программисту"
Это далеко не слезы) Как минимум, коллбеки сами обрабатывают флаги большинства периферии (за исключением коллбеков ошибок, там да, надо ручками почитать стейты и обработать их). А, если прямо жмет, то лучше вообще обойтись без них и ручками написать свои, исходя из заложенного функционала, чтобы не тратить время на проверку флагов, которые никогда в данной конфигурации не появятся вовсе.
Количество тактов по-честному все равно нужно считать после трансляции в асм. Либо закладывать везде счетчики тиков и понимать, на чем реально они съедаются (пока опустим даже работу стека в режиме вложенных прерываний). Плюс не забываем про конвейер в АРМ, который с теми же nop ассемблерными вставками может вести себя по разному. А вот барьеры памяти, кеширование - действительно первое время вызывают боль, но это уже касается высокопроизводительных ядер, у того же Cortex-M4 кеш работает предсказуемее и иначе в отличии от М7 и надо понимать как организовать доступ к данным тому же DMA.
Так что жить стало определенно проще. Я начинал с 8051 и его ассемблера, и возвращаться к нему после АРМ и Си вообще не хочется)