А мне нравится. Аргументы "против" понятны, и в случае коммерческого лицензирования имеют смысл: очень часто необходимость в осциллографе внезапно возникает на этапе "код написали, а как это дебажить то теперь?". Т.е. на этапе архитектуры о таком часто забывают. И вот тут действительно в рамках задачи отладки быстренько изобретается свой велосипед, который как правило кривоват, т.к. времени на него никто не выделял, но в принципе работает.
Сам пару месяцев назад таким страдал: нужно было сделать шаговый привод в рамках девайса, у которого двигать шестеренкой вообще не основная задача. Но потом поняли что "влючить таймер на генерацию ШИМ для сигнала step" таки работает криво и понеслось: подчиненный таймер для счета выданных импульсов, разгон/торможение, контура скорости и позиции, регуляторы этих контуров, "о блин, а как это тюнить?" и за пару часов родился осциллограф. Благо нужны были только медленные процессы, поэтому исключительно реалтайм-roll mode.
Это я к чему: в описанной ситуации пойти и купить что-то специализированное просто некогда было. Поэтому продавать это как по мне сложно (ну я правда тоже технарь и может просто не понимаю как). А вот в open source - я считаю круто.
У меня вот есть pet-проектик векторного привода, который буксует на месте из-за нехватки времени, но как раз пару дней назад озаботился поиском подходящего плоттера чтобы не изобретать свой, и этот проект выглядит круто. При том что я как раз начал склоняться в сторону чего-то вроде рисовалки из simplefoc studio.
Ну т.е. потрудиться и сделать "рекламу с примесью пользы" без желтушных заголовков и низкосортных картинок где грабитель долбит ногой в дверь, накладной замок которой на его стороне в коридоре, а у дедушки за спиной дверь-купе как в поезде, лень? Ну окей :)
"По камерам мы часто видим" и нейрослоп в качестве иллюстраций... Не знаю что вы накопили за 30 лет но ни показать ни рассказать нечего, только реклама ваших услуг. А главное знали, что будут минусовать и сделали оговорку про "нестандартные обороты". Дескать смотрите, мы же говорили. Так? Нет, за мусор бесполезный вас будут минусовать, и только.
Обычно там течет все и ото всюду. В особо "хронических" местах у нас слесаря сваривали поддоны со штуцером куда одевался шланг и масло самотеком уходило обратно в бак гидростанции... Вот такая вот модернизация.
Ну сварочный аппарат это скорее "мелкая переносная техника", даже если она на колесах...
А ЧПУшки да, светло-серый/темно-серый, но сейчас синий еще часто, видимо хорошо сочетается. У DMG из всех более стильно как по мне, TRUMPF ничего так по дизайну. Но вообще по цветам самое странное что видел - лазеры Bystronic выпуска начала 00х: огромные по площади машины полностью ярко-оранжевого цвета. Причем у нас их не перекрашивали и цех прямо явно выделялся )))
Когда работал на заводе у нас мягко-зеленым красили все. Когда ты 8 часов в день видишь этот цвет то с годами начинает асоциироваться с унынием... Но на деле смысл в этом есть конечно: если на фоне что-то выделено цветом, то это заметно сразу...
Помню держал в руках снятую с головы 4кВт машины (раскроечный станок Bystronic на CO2 лазере) ZnSe линзу с отверстием с одной стороны и красивым вулканом с кратером с другой. При работе на нее что-то попало. Действительно удивительно было впервые наблюдать... Такая мощность на маленькой площади это действительно много... Неудивительно что всякие импульсные с модулятором добротности буквально взрывают металл )
Просто "нить накала" слишком явно содержит назначение в своем названии, мне как инженеру прям больно читать про нее в предохранителе. Лучше уж "проволочка", "проводник", "волосок". Если совсем душнить - плавкая вставка. Но оно точно не накаливается.
Я конечно не дипломиповпнных химик, но в данном случае не зарядом единым. Заряд можно пропустить и получить плохой результат: важен и электролит и температура и время. Потому так и ваходит. Может лично вам удобнее, но сомневаюсь, что вся отрасль просто не догадалась...
Поискал информацию, в очередной раз убедился, что C это поле граблей, и некоторые мы подсознательно обходим...
Задумался что компилер уж при прямом то присваивании должен или предупредить или не паковать, но он как обычно никому ничего не должен. У меня просто выработалась привычка набивать структуры как в тетрисе - чтобы паддинг если и оставался - то в хвосте и в 90% случаев тогда и packed не нужен, само собой уляжется. Спасибо за интересный кейс.
Посыл понятен, но кажется таки на любом, ибо pack это "очень хочется сложить поплотнее", но если архитектура не позволяет кривой доступ, то компилер один фиг выравняет. Или я ошибаюсь?
А вот передать такую структуру "как есть" на другую архитектуру и на том конце привести ее в этому же типу без искажения уже не выйдет...
Никак. Это указание компилятору "не оптимизировать". С аппаратурой это никак не связано, утверждение выше про кеши не верно.
Т.е. обычно у вас i+=1 выглядит как чтение в регистр, модификация, запись.
Если вы напишите
while (i != 0) {
...
}
и при этом в цикле переменная не модифицируется, то с включенной оптимизацией компилятор имеет полное право один раз прочитать из памяти в регистр значение и дальше решить: если не 0, то бесконечный цикл. Потому что если в теле цикла переменная не меняется - то и измениться значение не может. Программа по умолчанию штука линейная. И вот volatile нужен как раз для того, чтобы сказать явно "не оптимизировать". Т.е. при каждой проверке условия компилер будет честно каждый раз читать память.
Поэтому тезис "переменная, которая может измениться в другом потоке должна быть помечена как volatile" очень упрощает, иногда портит производительность. Я встречал человека, который все переменные так объявлял. На мое удивление, ответил "чтобы наверняка".
Вообще многопоточное программирование и поведение компилятора - это не только про volatile, но еще и про кэши, барьеры памяти и т.п...
Бегите оттуда. Почему? Потому что это узкоспециализированная система. На реддите как-то была тема, и все кто изнутри в один голос говорили - что если смотреть на отрасль, то сидя на AUTOSAR вы стагнируете, ибо за его пределами все что вы за это время изучили - бесполезно...
Два варианта:
Встроенные средства STM32CubeIDE различных версий и пару раз подключение к его серверу внешним CLI
Open OCD + GDB + VSCode (Cortex Debug).
Нет, все стабильно работает.
До того стабильно, что я наоборот - использую Nucleo в качестве STLink для отладки своих плат, не парясь с покупкой отдельного
В общем-то заметка как заметка, "Как подключить JLink к STM32, а вот эти надуманные проблемы - лишнее.
А мне нравится. Аргументы "против" понятны, и в случае коммерческого лицензирования имеют смысл: очень часто необходимость в осциллографе внезапно возникает на этапе "код написали, а как это дебажить то теперь?". Т.е. на этапе архитектуры о таком часто забывают. И вот тут действительно в рамках задачи отладки быстренько изобретается свой велосипед, который как правило кривоват, т.к. времени на него никто не выделял, но в принципе работает.
Сам пару месяцев назад таким страдал: нужно было сделать шаговый привод в рамках девайса, у которого двигать шестеренкой вообще не основная задача. Но потом поняли что "влючить таймер на генерацию ШИМ для сигнала step" таки работает криво и понеслось: подчиненный таймер для счета выданных импульсов, разгон/торможение, контура скорости и позиции, регуляторы этих контуров, "о блин, а как это тюнить?" и за пару часов родился осциллограф. Благо нужны были только медленные процессы, поэтому исключительно реалтайм-roll mode.
Это я к чему: в описанной ситуации пойти и купить что-то специализированное просто некогда было. Поэтому продавать это как по мне сложно (ну я правда тоже технарь и может просто не понимаю как). А вот в open source - я считаю круто.
У меня вот есть pet-проектик векторного привода, который буксует на месте из-за нехватки времени, но как раз пару дней назад озаботился поиском подходящего плоттера чтобы не изобретать свой, и этот проект выглядит круто. При том что я как раз начал склоняться в сторону чего-то вроде рисовалки из simplefoc studio.
Ну т.е. потрудиться и сделать "рекламу с примесью пользы" без желтушных заголовков и низкосортных картинок где грабитель долбит ногой в дверь, накладной замок которой на его стороне в коридоре, а у дедушки за спиной дверь-купе как в поезде, лень? Ну окей :)
"По камерам мы часто видим" и нейрослоп в качестве иллюстраций... Не знаю что вы накопили за 30 лет но ни показать ни рассказать нечего, только реклама ваших услуг. А главное знали, что будут минусовать и сделали оговорку про "нестандартные обороты". Дескать смотрите, мы же говорили. Так? Нет, за мусор бесполезный вас будут минусовать, и только.
А где там много делений на три? Там сплошной корень из двух и прочая тригонометрия...
Обычно там течет все и ото всюду. В особо "хронических" местах у нас слесаря сваривали поддоны со штуцером куда одевался шланг и масло самотеком уходило обратно в бак гидростанции... Вот такая вот модернизация.
Ну сварочный аппарат это скорее "мелкая переносная техника", даже если она на колесах...
А ЧПУшки да, светло-серый/темно-серый, но сейчас синий еще часто, видимо хорошо сочетается. У DMG из всех более стильно как по мне, TRUMPF ничего так по дизайну. Но вообще по цветам самое странное что видел - лазеры Bystronic выпуска начала 00х: огромные по площади машины полностью ярко-оранжевого цвета. Причем у нас их не перекрашивали и цех прямо явно выделялся )))
Когда работал на заводе у нас мягко-зеленым красили все. Когда ты 8 часов в день видишь этот цвет то с годами начинает асоциироваться с унынием... Но на деле смысл в этом есть конечно: если на фоне что-то выделено цветом, то это заметно сразу...
Помню держал в руках снятую с головы 4кВт машины (раскроечный станок Bystronic на CO2 лазере) ZnSe линзу с отверстием с одной стороны и красивым вулканом с кратером с другой. При работе на нее что-то попало. Действительно удивительно было впервые наблюдать... Такая мощность на маленькой площади это действительно много... Неудивительно что всякие импульсные с модулятором добротности буквально взрывают металл )
Ну вот, теперь через несколько лет иметь второй комплект колес будет еще сложнее :)
Просто "нить накала" слишком явно содержит назначение в своем названии, мне как инженеру прям больно читать про нее в предохранителе. Лучше уж "проволочка", "проводник", "волосок". Если совсем душнить - плавкая вставка. Но оно точно не накаливается.
Блин, ну вот все вполне ничего, кроме нити накала в предохранителе, это ж надо так...
Я конечно не дипломиповпнных химик, но в данном случае не зарядом единым. Заряд можно пропустить и получить плохой результат: важен и электролит и температура и время. Потому так и ваходит. Может лично вам удобнее, но сомневаюсь, что вся отрасль просто не догадалась...
Это откуда такая информация?
Поискал информацию, в очередной раз убедился, что C это поле граблей, и некоторые мы подсознательно обходим...
Задумался что компилер уж при прямом то присваивании должен или предупредить или не паковать, но он как обычно никому ничего не должен. У меня просто выработалась привычка набивать структуры как в тетрисе - чтобы паддинг если и оставался - то в хвосте и в 90% случаев тогда и packed не нужен, само собой уляжется. Спасибо за интересный кейс.
Посыл понятен, но кажется таки на любом, ибо pack это "очень хочется сложить поплотнее", но если архитектура не позволяет кривой доступ, то компилер один фиг выравняет. Или я ошибаюсь?
А вот передать такую структуру "как есть" на другую архитектуру и на том конце привести ее в этому же типу без искажения уже не выйдет...
Никак. Это указание компилятору "не оптимизировать". С аппаратурой это никак не связано, утверждение выше про кеши не верно.
Т.е. обычно у вас i+=1 выглядит как чтение в регистр, модификация, запись.
Если вы напишите
while (i != 0) {
...
}
и при этом в цикле переменная не модифицируется, то с включенной оптимизацией компилятор имеет полное право один раз прочитать из памяти в регистр значение и дальше решить: если не 0, то бесконечный цикл. Потому что если в теле цикла переменная не меняется - то и измениться значение не может. Программа по умолчанию штука линейная. И вот volatile нужен как раз для того, чтобы сказать явно "не оптимизировать". Т.е. при каждой проверке условия компилер будет честно каждый раз читать память.
Поэтому тезис "переменная, которая может измениться в другом потоке должна быть помечена как volatile" очень упрощает, иногда портит производительность. Я встречал человека, который все переменные так объявлял. На мое удивление, ответил "чтобы наверняка".
Вообще многопоточное программирование и поведение компилятора - это не только про volatile, но еще и про кэши, барьеры памяти и т.п...
Бегите оттуда. Почему? Потому что это узкоспециализированная система. На реддите как-то была тема, и все кто изнутри в один голос говорили - что если смотреть на отрасль, то сидя на AUTOSAR вы стагнируете, ибо за его пределами все что вы за это время изучили - бесполезно...
Сколько нужно программистов чтобы вкрутить лампочку?