Комментарии 25
всякие там циклопические и дорогущие IDE для пошаговой отладки не особо-то и нужны как бы
Но если ide уже имеется - странно им не пользоваться.
Можно вообще отлаживать без кода, просто получив по почте один лишь *.elf файл.
Можно, но с исходниками как то проще. Странно, когда пишет код один, а отлаживает другой.
абсолютно бесплатно
Можно совершенно бесплатно вместо паяльника использовать зажигалку и канцелярскую скрепку. Но паяльник удобнее, хоть и дороже;)
Но если ide уже имеется - странно им не пользоваться.
По моим и не только наблюдениям, люди, которые привыкли что-то ковырять внутри IDE имеют тенденцию становится очень слабыми программистами. Даже микроконтроллер прошить без IDE не могут.
Эти IDE-наркоманы даже не догадываются о существовании файлов отличных от *.h и *.сpp. Коммитят в репозиторий всё даже *.i, *.obj(ты), *.a, *.hex, *.bin, *.elf.
А когда IDE не открывается из-за несовместимости версий, то у таких случается приступ панической атаки.
люди, которые привыкли что-то ковырять внутри IDE имеют тенденцию становится очень слабыми программистами.
Если у меня есть выбор - ковырять чего-то в IDE или в vim - я выберу IDE. Жизнь слишком коротка чтобы тратить ее на закат солнца вручную:)
Даже микроконтроллер прошить без IDE не могут.
Если в результате микроконтроллер прошит - какая разница, на что потрачено время - на нажатие кнопки или на подбор заклинания для программатора?
А когда IDE не открывается из-за несовместимости версий
Wtf? ;)
Автору спасибо, полезная информация. Поддержу предыдущего комментатора. Меня тоже раздражает раздуваемая сложность на ровном месте. Для чего накручиваются всевозможные костыли. Вот 13 лет назад я сел за среду SiLabs. Нажал кнопку загрузить и работаю, не нужны ни какие конфигураторы, серверы, инициализаторы, ...-ры и т.д. Напоминает старый анекдот: "... Вот унитаз, вот моя жопа, продайте, наконец то, мне туалетную бумагу. ". Скоро что бы запрограммировать микроконтроллер специальные курсы посещать придётся.
Так сейчас практически все производители MCU дают бесплатную IDE, обычно на базе эклипса, на кой эти консольные страдания?
А "дорогие" IDE нужны не для стразиков, тот же IAR жмет код получше чем GNU Arm, для кого то это может оказаться критично. Плюс там misra и статический анализатор. Из популярных есть еще Keil, но за него как то нечего сказать.
На мой взгляд, все это может быть полезно только при удаленной отладки через gdb server.
Эпично, но не думаю что быстро и удобно.
Как пища для мозгов и в целях понимания процессов, думаю куда полезнее чем в практических целях.
До чего дошло разделение труда в программировании микроконтроллеров (сарказм). Один пишет код, отправляет второму elf по почте, и второй его в консоли отлаживает :)
Отличная шутка. Я давно так не смеялся.
На самом деле я просто хотел подчеркнуть, что при отладке через консоль при помощи GDB зависимости c самими сорцами и репозиторием уже нет.
Это для тех кто всё еще верует, что без IDE невозможна пошаговая отладка.
*.elf самодостаточный файл с тонной полезной инфы.
Можно отлаживаться в консоли, а на код поглядывать лежащий где-н в Web(e), например на github.com
Можно отлаживаться в консоли, а на код поглядывать лежащий где-н в Web(e), например на github.com
Зачем поглядывать на код, который, возможно, никак не связан с отлаживаемым бинарником? Почему нельзя загрузить этот код в IDE, скомпилировать и ни в чём себя не ограничивать ?
Это для тех кто всё еще верует, что без IDE невозможна пошаговая отладка
Человечество придумало много разных штук, чтобы упростить работу. Конечно же, от них можно отказаться, но зачем?
Зачем поглядывать на код, который, возможно, никак не связан с отлаживаемым бинарником? Почему нельзя загрузить этот код в IDE, скомпилировать и ни в чём себя не ограничивать ?
Ответ прост.
Дело в том что в крупных компаниях работает защита на копирование исходных кодов.
Как это работает?
Все исходники собираются на удаленных серверах. Редактирование код тоже только через консоль ssh на том же удаленном сервере при помощи консольного текстового редактора vim или nano.
Вам как разработчику можно только получить по почте артефакты, чтобы загрузить hex в устройство или для пошаговой отладки.
Вот так.
Редактирование код тоже только через консоль ssh на том же удаленном сервере при помощи консольного текстового редактора vim или nano.
У каждого тамады свои конкурсы ;) Ладно бы rdp с отключенным буфером обмена. Если мне доступен ssh - что мне мешает скачать исходники на локальную машину и редактировать как мне удобно?
Ну штош, если работодатель непременно желает, чтобы в гамаке, стоя и в противогазе, и оплачивает этот перфоманс - почему бы и нет ;)
Ладно бы rdp с отключенным буфером обмена
Там пробовали через rdp, однако сеть не справлялась с трафиком. Сервер был в 7,359тыс км от офиса.
При нажатии кнопки в текстовом редакторе символ отрисовывался на экране ровно через 6 секунд.
В результате приходилось всем редактировать исходники через ssh + vim. Только так Latency был не особо заметен.
при отладке через консоль при помощи GDB зависимости c самими сорцами и репозиторием уже нет.
Если вы дебажите .elf с дебажными символами - ещё как есть. Если номера строчек в сборке не соответствуют исходникам - happy debugging :) Но раз у вас есть elf с дебагом - исходники у вас тоже есть ;)
Сокращение для target remote это tar rem :2331
Всегда писал с пробелом. Но если речь о том, чтобы максимально сократить команду, то лишний, да.
Разве gdb не умеет сам перезапускать прошивку командой run, если стартовать с target extended-remote?
Поэтому всякие там циклопические и дорогущие IDE для пошаговой отладки не особо-то и нужны как бы.Результаты голосования это опровергают: на втором вопросе в 6 раз, на третьем вопросе в… 35 (тридцать пять) раз.
Пошаговая GDB отладка ARM процессора из консоли в Win10