Можно бесконечно спорить, франкенштейн это или нет, F5 или не F5, недостаток аргументов прикрывая бессмысленными картинками. Но суть моего комментария в другом, повторюсь: Каждый инструмент предназначен для своих задач. Нельзя одним инструментом покрыть все потребности любого проекта. Если инструмент не подходит - пожалуйста, используйте другой. Но категорично говорить, что "Достоинства сборки из-под Eclipse c ARM плагинами - Отсутствуют.." я считаю неправильно. Для других разработчиков там найдётся масса достоинств, - далеко не все в промышленности используют Jenkins/CI/CD. Если бы Вы сказали, "Почему Сборка с Помощью Есlipse ARM GCC Плагинов это Тупиковый Путь Для Меня" и что "Eclipse c ARM плагинами не подходит под мои задачи потому что ..." - пожалуйста, это Ваше мнение, мы бы поняли.
Абсолютно не согласен. Вот все эти минусы как-то притянуты за уши. Ну не отсортирован cproject, и чем это мешает? Он не предназначен для диффа и ручного редактирования. Ленивые юзеры получают франкенштейнов. Но это их проблемы, а если они начнут писать make вручную, их проекты вообще перестанут собираться. Папки и отдельные файлы вполне можно исключить из билда (да, через контекстное меню). И нажать F5 (refresh) ну ни разу не проблема. А передавать пути к проекту в IDE через bat-скрипт - так это очень странное решение. Каждый инструмент предназначен для своих задач. И Eclipse + embedcdt многие задачи по сборке проекта хорошо решает. Если этого инструмента недостаточно - пожалуйста, пользуйтесь make-файлом. На make/cmake действительно можно организовать любую монструозную сборку, см. например ESP32. Да, и докажите ещё любителям ХалоКуба, почему мышиная возня это плохо. Мы то понимаем, почему. Но миллионы людей тыкают мышкой, и вполне довольны, задачи решаются, программы работают.
Ох уж эти картинки... На 100 с небольшим килобайт текста - картинок на 18 мегабайт. Формат png хорошо жмёт однотонные картинки, не если есть градиент - беда. Если перевести картинки из статьи в обычный jpeg, страница похудеет в два раза (на 10 Мб) без заметной потери качества. Или - формат webp - вообще показывает чудеса, размер файла ещё раза в 2-3 меньше. Уважаемые авторы! Не у всех есть быстрый интернет. Пожалуйста, берегите наш трафик, время и нервы. А за интересные статьи - всем спасибо.
Нет такого понятия "чувствительность антенны". Говорят про чувствительность приёмника, а по сути - это способность демодулировать сигнал с заданным выходным BER при заданном входном S/N. Плохая антенна (т.е. с низким Ку) будет одинаково плохо и принимать, и передавать сигнал. "Односторонняя" связь в первую очередь обусловлена схемотехникой приёмопередатчика базовой станции. Там обычно нет проблем с электричеством, поэтому можно использовать мощный передатчик и высококачественный (высокодинамичный высокоизбирательный) приёмник. Например, GSM: у мобильного аппарата излучаемая мощность 1-2 Вт, а базовая станция передаёт десятки ватт. Вот и получаем "однонаправленность". Если взять две антенны, одна хорошая, другая плохая, то при прочих равных условиях бюджет линии что в одну, что в другую сторону будет одинаков. "Хорошая дорогая" [направленная] антенна действительно может улучшить приём, но только за счёт подавления помех с побочных направлений.
Было дело, писал загрузчик. Собственный протокол, интерфейс USB, память под загрузчик 16 кб. С оптимизацией Os + LTO в указанную память загрузчик не влезал, не хватало буквально сотни байт. Изучая ассемблерный листинг обнаружил функции 64-битной арифметики. Сюрприз был спрятан в хал-библиотеке stm32f4xx_hal_rcc.c:
Небольшая доработка кода, и вуаля - полкилобайта памяти свободно. В моём случае функция вызывается однократно, просадки производительности нет, но память - ценный ресурс. Поэтому читать и понимать map/asm/lst файлы действительно бывает очень полезно.
Этот прикол связан с оптимизацией производства и маркетингом, уже неоднократно обсуждалось. В соседних моделях микроконтроллера STM32 часто используются одинаковые кристаллы. У младших чипов тестируется только часть FLASH-памяти. Что существенно экономит время производства, и поэтому чипы получаются дешевле. Например, в STM32F103C8T6, что массово устанавливаются в голубую таблетку, вполне можно записать 128 кБ. Без гарантий, естественно. И наоборот, в китайских клонах, например в CKS32F103C8T6, честные 64 кБ.
Можно бесконечно спорить, франкенштейн это или нет, F5 или не F5, недостаток аргументов прикрывая бессмысленными картинками. Но суть моего комментария в другом, повторюсь:
Каждый инструмент предназначен для своих задач. Нельзя одним инструментом покрыть все потребности любого проекта. Если инструмент не подходит - пожалуйста, используйте другой. Но категорично говорить, что "Достоинства сборки из-под Eclipse c ARM плагинами - Отсутствуют.." я считаю неправильно. Для других разработчиков там найдётся масса достоинств, - далеко не все в промышленности используют Jenkins/CI/CD. Если бы Вы сказали, "Почему Сборка с Помощью Есlipse ARM GCC Плагинов это Тупиковый Путь Для Меня" и что "Eclipse c ARM плагинами не подходит под мои задачи потому что ..." - пожалуйста, это Ваше мнение, мы бы поняли.
Абсолютно не согласен. Вот все эти минусы как-то притянуты за уши. Ну не отсортирован cproject, и чем это мешает? Он не предназначен для диффа и ручного редактирования. Ленивые юзеры получают франкенштейнов. Но это их проблемы, а если они начнут писать make вручную, их проекты вообще перестанут собираться. Папки и отдельные файлы вполне можно исключить из билда (да, через контекстное меню). И нажать F5 (refresh) ну ни разу не проблема. А передавать пути к проекту в IDE через bat-скрипт - так это очень странное решение.
Каждый инструмент предназначен для своих задач. И Eclipse + embedcdt многие задачи по сборке проекта хорошо решает. Если этого инструмента недостаточно - пожалуйста, пользуйтесь make-файлом. На make/cmake действительно можно организовать любую монструозную сборку, см. например ESP32.
Да, и докажите ещё любителям ХалоКуба, почему мышиная возня это плохо. Мы то понимаем, почему. Но миллионы людей тыкают мышкой, и вполне довольны, задачи решаются, программы работают.
Ох уж эти картинки... На 100 с небольшим килобайт текста - картинок на 18 мегабайт. Формат png хорошо жмёт однотонные картинки, не если есть градиент - беда. Если перевести картинки из статьи в обычный jpeg, страница похудеет в два раза (на 10 Мб) без заметной потери качества. Или - формат webp - вообще показывает чудеса, размер файла ещё раза в 2-3 меньше. Уважаемые авторы! Не у всех есть быстрый интернет. Пожалуйста, берегите наш трафик, время и нервы. А за интересные статьи - всем спасибо.
Нет такого понятия "чувствительность антенны". Говорят про чувствительность приёмника, а по сути - это способность демодулировать сигнал с заданным выходным BER при заданном входном S/N. Плохая антенна (т.е. с низким Ку) будет одинаково плохо и принимать, и передавать сигнал. "Односторонняя" связь в первую очередь обусловлена схемотехникой приёмопередатчика базовой станции. Там обычно нет проблем с электричеством, поэтому можно использовать мощный передатчик и высококачественный (высокодинамичный высокоизбирательный) приёмник. Например, GSM: у мобильного аппарата излучаемая мощность 1-2 Вт, а базовая станция передаёт десятки ватт. Вот и получаем "однонаправленность". Если взять две антенны, одна хорошая, другая плохая, то при прочих равных условиях бюджет линии что в одну, что в другую сторону будет одинаков.
"Хорошая дорогая" [направленная] антенна действительно может улучшить приём, но только за счёт подавления помех с побочных направлений.
Было дело, писал загрузчик. Собственный протокол, интерфейс USB, память под загрузчик 16 кб. С оптимизацией Os + LTO в указанную память загрузчик не влезал, не хватало буквально сотни байт. Изучая ассемблерный листинг обнаружил функции 64-битной арифметики. Сюрприз был спрятан в хал-библиотеке stm32f4xx_hal_rcc.c:
Небольшая доработка кода, и вуаля - полкилобайта памяти свободно. В моём случае функция вызывается однократно, просадки производительности нет, но память - ценный ресурс. Поэтому читать и понимать map/asm/lst файлы действительно бывает очень полезно.
Этот прикол связан с оптимизацией производства и маркетингом, уже неоднократно обсуждалось. В соседних моделях микроконтроллера STM32 часто используются одинаковые кристаллы. У младших чипов тестируется только часть FLASH-памяти. Что существенно экономит время производства, и поэтому чипы получаются дешевле. Например, в STM32F103C8T6, что массово устанавливаются в голубую таблетку, вполне можно записать 128 кБ. Без гарантий, естественно. И наоборот, в китайских клонах, например в CKS32F103C8T6, честные 64 кБ.