Сделано чисто для отлова ситуации, когда старший таймер обработает переполнение младшего, иначе получите метку времени "из прошлого": младший уже сбросится, а данные считанные со старшего уже не актуальны. Можно сделать проще и проверять, что новое значение младшего таймера больше предыдущего, но на длинных интервалах времени это не исключает ошибку полностью, поэтому действительно корректнее после записи повторно сверяться со старшим таймером и при необходимости повторить операцию заново.
Просто именно на M3/M4 я с этим проблем обычно не имел (в Keil и CubeIDE с GCC), а вот при порте на M7 уже пришлось ручками барьеры вешать, но там все работой кеша объясняется. Надо посмотреть по дизассемблеру, мне казалось для всех исключений (т.е. не только прерываний) на выходе автоматом встаёт барьер.
Никогда не ждите событий в бесконечных циклах - в них и поляжете. В baremetal прошивке по-хорошему должен быть только 1 бесконечный мастер цикл, иные должны иметь тайм-аут с возможностью его обработать (хотя бы светодиодом поморгать, чтобы дать понять, что словили ошибку при ожидании события), либо берете решение на RTOS. Если на этапе отладки падать - это нормально и даже полезно, то в проде лучше так не делать.
Для этого например существует целевое обучение в вузах - но как по мне из именно целевиков кадры в большинстве случаев посредственные, не претендую на истину, чисто из личных наблюдений. Куда лучше иметь знакомых профессоров в вузах - заинтересованных и способных ребят они в состоянии заметить довольно быстро. И с такими людьми уже можно работать. Все в выигрыше:
студенты получают актуальные знания и реальный практический опыт, а не устаревающую с бешеной скоростью программу вуза;
вы получаете сотрудника, который знает ваш стек, продукт и легче вкатывается в процессы в виду отсутствия привычек (иногда не очень полезных).
А вы можете дать гарантию, что найденный с такими трудозатратами сеньор не помашет вам ручкой через день/месяц/год даже не окупив их?
А польза будет для всего рынка. Без джунов не будет ни мидлов, ни остальных. Учитесь создавать условия, чтобы человек был менее заинтересован в уходе. И да люди будут приходить и уходить, по тысяче причин - с этим фактом нужно научится жить. Крепостное право все же давно отменили.
В ТК для этого отдельная вещь придумана - испытательный срок. Только вместо того, чтобы сократить расходы на найм, все ставят заборы повыше да подороже, а потом все равно остаются с непризрачным шансом, что человек пробившийся через этот самый забор - не потянет, а стоимость его найма уже составила оверхед.
Все и так уже воют, что банально до тех. интервью через расставленные hr-ами фильтры не пробиться, а вы предлагаете поставить забор повыше - не находите в этом проблему? И не забывайте, что пока вы сидите и ждёте своего единственного и прекрасного единорога - вы теряете деньги и время, а иногда и других людей, ишачащих за себя и за Сашку. Так может хоть будете тогда терять его с пользой, обучая джуна)
Мое мнение, что в текущей ситуации надо не искать сеньоров-помидоров-фуллстек-рокзвезд (вы все равно их не потянете по деньгам в большинстве случаев), а вкладываться в джунов и рекрутинг начинать с вузов. Да это не спец тут и сейчас, да это дорого (но все ещё дешевле), но вы со временем (и относительно небольшим при грамотном подходе) получите тех самых кадров, которые нужны вам для решения ваших же бизнес задач. И не нужно будет гадать на этапе найма, берете вы очередного: вкатуна/волка/промпт-"инженера".
Так остальные вполне справедливы, а статья для кого-то да будет полезна. Хотя бы в части GDB сервера.
У Миландра на платах вообще зачастую торчит JTAG (на некоторых платах аж 2 сразу), и отдельно программатора в составе платы нет, не считая загрузку по UART.
В плане надёжности тоже такое, а вот не держать кучу старых кабелей действительно было бы приятно. У ST-шников просто есть n-разновидностей идентичных борд на разных камнях, вот видимо и не заморачиваются с заменой пока что.
Ну до MiniUSB в отладочной плате, цена которой чем ближе к нулю, тем лучше для всех, докопаться это конечно такое) Есть желание переплачивать за USB-C? На H7 платах вообще до сих пор micro ставят)
И что одно, что второе выглядит как бесполезная трата человеческого, временного и технического ресурса, ибо кто ищет, тот найдет способ как до этого самого "контента" добраться.
Взять тот же Ютуб: если вы там не ищете контент на какую-либо тему, то вероятность того, что вам это полетит в ленту стремится к нулю, а даже если таки рандомно залетело - волшебная кнопка "не рекомендовать видео с данного канала" вам в помощь, для особо чувствительных даже кнопка репорта есть (проверено, работает - один канал с мягко скажем "неудовлетворительным обращением с животными" отъехал в течении пары суток). Но всегда найдутся мыши кушающие кактус.
Фиксированная длинна пакета не то чтобы прямо плохо и ужасно, если нет желания в бинарном протоколе сопровождать данные заголовками и надо гонять сообщения быстро, то вполне приемлемо (за исключением поддержки и ломающегося обмена при апдейтах). Там именно больше вопросов к тому, что какой смысл был пытаться в ASCII строку, если по факту с ней работать один черт невозможно, приходится выгребать все 0x30, обратно клеить "полубайты" в байты и работать по факту с бинарным протоколом. Ещё из "приколов" той же железки, при реверсе протокола выяснилось, что хендшейк идёт через запрос версии (ПО/железа? а вот черт его знает) и на один и тот же запрос приходят разные ответы. Всего ответов оказалось два для более новой железки и один для более старой. В итоге если по какой-либо причине терялся один из запросов для новой железки она наглухо отрубала обмен без какого-либо ответа. Игнорировалась даже команда для софт ребута. Пришлось городить логику с контролем ответа на первое сообщение и дальше уже либо слать второй запрос, либо уже работать по остальной части протокола. Не удивлюсь, если в новом железе тоже поменялся хендшейк.
Ну и вместо обычной unix-time метки был какой-то свой костыль который по сути отличался только начальной датой ¯\_(ツ)_/¯
Спустя несколько лет ковыряния как своих, так и чужих протоколов пришел к выводу, что лучше потратить время, но сделать поддержку как бинарного, так и текстового протокола (не обязательно json). Первый даст скорость и компактность кому это реально нужно, а второй в самом плохом варианте даст достучаться до железки на коленке, без мучительных попыток вспомнить "да где ж тот самый бит в этом месиве".
После протокола одних "коллег по цеху" глаз до сих пор дёргается, вот вроде и пакуют в стандартную строку ASCII символов, но нет же, байты бьют на "полубайты" (если что, это цитата из документации), докидывают 0x30 и начинаешь ловить по итогу и спецсимволы и текст там, где ждёшь числа. Зачем и чего ради непонятно, ибо получается и хуже битового и сложнее для парсинга, чем текстовые. И все это при фиксированной длине пакета.
Разработка на одноплатник тоже не бесплатная же, по части плат (если не берём ST-шные, а любой Китай) будет не дороже. В целом как прототип - ок, но добиться лучшей разрешающей способности по дальности, а как я понял, то больше интересует именно детекция дистанции до грозы, то тут уже повозиться придется, если оно конечно нужно вообще, условно что-то обесточить и ошибки в 300 метров вполне можно простить
Сделано чисто для отлова ситуации, когда старший таймер обработает переполнение младшего, иначе получите метку времени "из прошлого": младший уже сбросится, а данные считанные со старшего уже не актуальны. Можно сделать проще и проверять, что новое значение младшего таймера больше предыдущего, но на длинных интервалах времени это не исключает ошибку полностью, поэтому действительно корректнее после записи повторно сверяться со старшим таймером и при необходимости повторить операцию заново.
Просто именно на M3/M4 я с этим проблем обычно не имел (в Keil и CubeIDE с GCC), а вот при порте на M7 уже пришлось ручками барьеры вешать, но там все работой кеша объясняется. Надо посмотреть по дизассемблеру, мне казалось для всех исключений (т.е. не только прерываний) на выходе автоматом встаёт барьер.
Разве при выходе из прерывания в Cortex-M не выполняется обязательный неявный __DSB()?
Код-гольф все про более высокоуровневые языки. Тут скорее речь про оптимизации на уровне алгоритмов и тонкостей архитектуры.
Никогда не ждите событий в бесконечных циклах - в них и поляжете. В baremetal прошивке по-хорошему должен быть только 1 бесконечный мастер цикл, иные должны иметь тайм-аут с возможностью его обработать (хотя бы светодиодом поморгать, чтобы дать понять, что словили ошибку при ожидании события), либо берете решение на RTOS. Если на этапе отладки падать - это нормально и даже полезно, то в проде лучше так не делать.
Если есть возможность - использовать внешний источник опорного напряжения. В некоторых приложениях и вовсе внешний АЦП с соответствующей обвязкой.
Для этого например существует целевое обучение в вузах - но как по мне из именно целевиков кадры в большинстве случаев посредственные, не претендую на истину, чисто из личных наблюдений. Куда лучше иметь знакомых профессоров в вузах - заинтересованных и способных ребят они в состоянии заметить довольно быстро. И с такими людьми уже можно работать. Все в выигрыше:
студенты получают актуальные знания и реальный практический опыт, а не устаревающую с бешеной скоростью программу вуза;
вы получаете сотрудника, который знает ваш стек, продукт и легче вкатывается в процессы в виду отсутствия привычек (иногда не очень полезных).
"Можно, а зачем?" - более актуальными трендами
А вы можете дать гарантию, что найденный с такими трудозатратами сеньор не помашет вам ручкой через день/месяц/год даже не окупив их?
А польза будет для всего рынка. Без джунов не будет ни мидлов, ни остальных. Учитесь создавать условия, чтобы человек был менее заинтересован в уходе. И да люди будут приходить и уходить, по тысяче причин - с этим фактом нужно научится жить. Крепостное право все же давно отменили.
В ТК для этого отдельная вещь придумана - испытательный срок. Только вместо того, чтобы сократить расходы на найм, все ставят заборы повыше да подороже, а потом все равно остаются с непризрачным шансом, что человек пробившийся через этот самый забор - не потянет, а стоимость его найма уже составила оверхед.
Все и так уже воют, что банально до тех. интервью через расставленные hr-ами фильтры не пробиться, а вы предлагаете поставить забор повыше - не находите в этом проблему? И не забывайте, что пока вы сидите и ждёте своего единственного и прекрасного единорога - вы теряете деньги и время, а иногда и других людей, ишачащих за себя и за Сашку. Так может хоть будете тогда терять его с пользой, обучая джуна)
Ну тогда можно продолжать сидеть и ждать сказочных единорогов, желательно задешево)
Мое мнение, что в текущей ситуации надо не искать сеньоров-помидоров-фуллстек-рокзвезд (вы все равно их не потянете по деньгам в большинстве случаев), а вкладываться в джунов и рекрутинг начинать с вузов. Да это не спец тут и сейчас, да это дорого (но все ещё дешевле), но вы со временем (и относительно небольшим при грамотном подходе) получите тех самых кадров, которые нужны вам для решения ваших же бизнес задач. И не нужно будет гадать на этапе найма, берете вы очередного: вкатуна/волка/промпт-"инженера".
Так в этом утверждение меняем раст на <language name> и оно продолжает так же работать.
Так остальные вполне справедливы, а статья для кого-то да будет полезна. Хотя бы в части GDB сервера.
У Миландра на платах вообще зачастую торчит JTAG (на некоторых платах аж 2 сразу), и отдельно программатора в составе платы нет, не считая загрузку по UART.
В плане надёжности тоже такое, а вот не держать кучу старых кабелей действительно было бы приятно. У ST-шников просто есть n-разновидностей идентичных борд на разных камнях, вот видимо и не заморачиваются с заменой пока что.
Ну до MiniUSB в отладочной плате, цена которой чем ближе к нулю, тем лучше для всех, докопаться это конечно такое) Есть желание переплачивать за USB-C? На H7 платах вообще до сих пор micro ставят)
И что одно, что второе выглядит как бесполезная трата человеческого, временного и технического ресурса, ибо кто ищет, тот найдет способ как до этого самого "контента" добраться.
Взять тот же Ютуб: если вы там не ищете контент на какую-либо тему, то вероятность того, что вам это полетит в ленту стремится к нулю, а даже если таки рандомно залетело - волшебная кнопка "не рекомендовать видео с данного канала" вам в помощь, для особо чувствительных даже кнопка репорта есть (проверено, работает - один канал с мягко скажем "неудовлетворительным обращением с животными" отъехал в течении пары суток). Но всегда найдутся мыши кушающие кактус.
Фиксированная длинна пакета не то чтобы прямо плохо и ужасно, если нет желания в бинарном протоколе сопровождать данные заголовками и надо гонять сообщения быстро, то вполне приемлемо (за исключением поддержки и ломающегося обмена при апдейтах). Там именно больше вопросов к тому, что какой смысл был пытаться в ASCII строку, если по факту с ней работать один черт невозможно, приходится выгребать все 0x30, обратно клеить "полубайты" в байты и работать по факту с бинарным протоколом. Ещё из "приколов" той же железки, при реверсе протокола выяснилось, что хендшейк идёт через запрос версии (ПО/железа? а вот черт его знает) и на один и тот же запрос приходят разные ответы. Всего ответов оказалось два для более новой железки и один для более старой. В итоге если по какой-либо причине терялся один из запросов для новой железки она наглухо отрубала обмен без какого-либо ответа. Игнорировалась даже команда для софт ребута. Пришлось городить логику с контролем ответа на первое сообщение и дальше уже либо слать второй запрос, либо уже работать по остальной части протокола. Не удивлюсь, если в новом железе тоже поменялся хендшейк.
Ну и вместо обычной unix-time метки был какой-то свой костыль который по сути отличался только начальной датой ¯\_(ツ)_/¯
Спустя несколько лет ковыряния как своих, так и чужих протоколов пришел к выводу, что лучше потратить время, но сделать поддержку как бинарного, так и текстового протокола (не обязательно json). Первый даст скорость и компактность кому это реально нужно, а второй в самом плохом варианте даст достучаться до железки на коленке, без мучительных попыток вспомнить "да где ж тот самый бит в этом месиве".
После протокола одних "коллег по цеху" глаз до сих пор дёргается, вот вроде и пакуют в стандартную строку ASCII символов, но нет же, байты бьют на "полубайты" (если что, это цитата из документации), докидывают 0x30 и начинаешь ловить по итогу и спецсимволы и текст там, где ждёшь числа. Зачем и чего ради непонятно, ибо получается и хуже битового и сложнее для парсинга, чем текстовые. И все это при фиксированной длине пакета.
Разработка на одноплатник тоже не бесплатная же, по части плат (если не берём ST-шные, а любой Китай) будет не дороже. В целом как прототип - ок, но добиться лучшей разрешающей способности по дальности, а как я понял, то больше интересует именно детекция дистанции до грозы, то тут уже повозиться придется, если оно конечно нужно вообще, условно что-то обесточить и ошибки в 300 метров вполне можно простить