Справедливости надо таки да сказать что Android Studio и Intellij IDEA это одна и та же среда

Если еще справедливей, то Android Studio идет со своими addon-ами для рефакторинга, а Intellij IDEA со своими.

>> Назовите такой продвинутый редактор, в котором можно посмотреть состояние проекта неделю назад?

RAD Studio . . . редактор, а особенно броузер .... "не-дай-бог". Тупило и глюкало. Структура и состав контекстного меню - тоже
"оригинально" сделана. Явно не для отладки и чтения чужого кода.
IMHO.
Контроль версий - Git+Tortoise (вполне комфортно работать и без Tortoise - из командной строки).
Недостаток - нет сплошной номерации ревизий, как в SVN. На мой взгляд - единственный.
(не столько недостаток, сколько "шаг назад", чтобы сделать несколько вперед).

Так ставьте расширения GExprets, AQtime, CodeSite... и будет счастье. Все равно под десктоп ничего лучшего нет.

. . . . а-а-а-а. В ЭТОМ смысле.
5. Для поиска очень редких сбоев, полуаппаратный метод. В том числе в среде RTOS.
Используете лог. анализатор (онлайновый, с возможностью просмотра движущейся "ленты". У меня - встроенный в осц-ф, 16 каналов).
В критические участки кода (вектора прерываний, планировщик RTOS, флаги ошибок) ставите "ногодрыг". Если необходимо поймать комбинацию флагов, можно линии "ногодрыга" подключить на внешние схемы "И".
Развертка ставится самая медленная. Если в осц-фе есть память - это также можно использовать (но это "не про меня").
Далее писать алгоритм "отлова" нет смысла, все очень индивидуально.
Эта метода поможет "засечь" состояние первого сбоя, который в любом случае придется ловить вручную или наполовину вручную.
При появлении сбоя - жмем на осциллографе "Stop/Freeze" и не спеша рассматриваем предисторию вылета.
Спасибо за инф. Посмотрим что за звери.

нувыблиндаёте!!! Вы же нашли, можно сказать, багу и продолжаете гадать на кофейной гуще.

Прибор на стол и эмулируем не то что оживленный трафик, перегруженный трафик. Во первых бага быстро появиться, во вторых вы обязаны были разработчик обязан был на столе проверить, что будет, если трафик будет перегружен.

Я так подозреваю, что в этом случае "прибор" вообще перестанет работать.
Вообще конечно: стресс-тест - это обязательный этап тестирования для таких устройств. Всегда делаю.

Хотя звучит умно, но по факту это немного глупо.
На кой нагружать трафиком если известно, что дивайс или система наверняка заглохнет при превышении определенного уровня?
Что вам даст если вы зафиксируйте несколько раз этот уровень?
Ошибка конечно проявится, но это будет не та ошибка!
А чтобы была та, нужно именно тот трафик смоделировать. А если вы знаете именно тот трафик, то знаете и ошибку.
Так что "стресс-тест" это просто семантический плеоназм в данном случае.

Т.е. - Вы считаете, что зависание или перезагрузка или улёт по неизвестному адресу выполнения при штатном обмене по интерфейсу - это вполне допустимое поведение прибора? И даже и выяснять ничего не надо?
Странный у Вас подход к разработке устройств.....
И что значит "не та ошибка"? Считаете, что нужно устранять только те ошибки, что сейчас кто-то заметил, а на остальные забить? А как поймёте, что "та" или "не та", какой критерий?


Стресс-тест - это один из методов нагрузочного тестирования в ходе разработки и отладки безглючных устройств, которые работают всегда, при любых условиях, а не только при каких-то тепличных, настольных.

Дивайс должен уйти во вполне определенное состояние при превышении определенного уровня и выйти из него в рабочее после нормализации обстановки.
Например, пропускать только те пакеты, на которые хватает производительности канала, а в слове состояния выставить признак проблем с подключением.
Или при превышении частоты ошибок прекратить общение до паузы в сигнале или появлении корректного сообщения.
Почитайте описание протокола CAN, например.

Вот именно.

Чтобы попадать в баг не раз в месяц, а раз в 1 минуту (или хотя бы раз в час, как можно чаще). Чем чаще бага проявляется, тем легче её найти.
Согласен. Но как стоит условие задачи - "глюки начинают вылазить при оживленном траффике". Нужно на столе смоделировать оживленный трафик, а также стресс-тест. Если бы было в условии "глюки начинают вылазить при ОПРЕДЕЛЁННОМ оживленном траффике, а при другом оживленном трафике нет баги", то тут сложнее, тут да, лови и моделируй нужный трафик.

В CAN-е это аппаратно сделано, поэтому я только CAN везде и применяю.
И да логируется у меня достаточно счетчиков относящихся к работе CAN.
Но если я сделаю некий "стресс-тест" с хаотичными командами, то система подвиснет, лог будет переполнен, даже могут возникнуть конструктивные повреждения, сработает WDT
И че я выясню в результате?
Попробуйте "стресс-тест" провести где нить в сети промышленных логических контроллеров. Тоже получите катастрофу.

Опять же применив некую симуляцию запредельного трафика можно просто ввести устройство в ступор и при этом вообще ничего реально тестироваться не будет.
Т.е. сделать грамотное нагрузочное тестирование очень сложно во первых, а во вторых оно не для выявления ошибок, а скорее для тестирования риалтайма систем.

Это может означать, что плохо или спроектировано или реализовано, а может и то и другое.

Это только говорит о том, что данное устройство неправильно спроектировано.
Никакая комбинация входных данных (валидных или просто мусора) с любой частотой повторения на внешних интерфейсах не должна вводить устройство в состояние ступора либо любое другое нерабочее состояние. Если это не так - это кривое устройство и надо переделывать.
Как то так. Всегда следую данному правилу.
Да и по внутренним интерфейсам устройства - например если у меня есть SPI-FLASH в устройстве, но обращение к ней идёт не часто, то для теста (обнаружения редко проявляющихся непериодических сбоев как у ТС), я нагружаю данный интерфейс транзакциями чтения/записи по самое нехочу. Например - создаю несколько задач ОС, которые параллельно обращаются к этому интерфейсу со случайными запросами чтения/записи случайной длины и адресом, так чтобы загрузка CPU при такой работе была близка к максимальной. Гоняю этот тест несколько часов с общим объёмом траффика во много ГБ. И одновременно с этим устройство должно продолжать выполнять свои штатные функции.
Вот если за время такого теста сбоев не было - значит всё ок. Иначе - разбираюсь, пока не устраню причину.