twix 0 26 апреля, 2018 Опубликовано 26 апреля, 2018 · Жалоба RAD Studio, Android Studio, Sysmac Studio, IntelliJ IDEA.... Это только те с которыми я работаю прямо сейчас. Справедливости надо таки да сказать что Android Studio и Intellij IDEA это одна и та же среда :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 26 апреля, 2018 Опубликовано 26 апреля, 2018 · Жалоба Справедливости надо таки да сказать что Android Studio и Intellij IDEA это одна и та же среда :) Если еще справедливей, то Android Studio идет со своими addon-ами для рефакторинга, а Intellij IDEA со своими. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 26 апреля, 2018 Опубликовано 26 апреля, 2018 · Жалоба >> Назовите такой продвинутый редактор, в котором можно посмотреть состояние проекта неделю назад? RAD Studio, Android Studio, Sysmac Studio, IntelliJ IDEA.... . . . RAD Studio . . . редактор, а особенно броузер .... "не-дай-бог". Тупило и глюкало. Структура и состав контекстного меню - тоже "оригинально" сделана. Явно не для отладки и чтения чужого кода. IMHO. Контроль версий - Git+Tortoise (вполне комфортно работать и без Tortoise - из командной строки). Недостаток - нет сплошной номерации ревизий, как в SVN. На мой взгляд - единственный. (не столько недостаток, сколько "шаг назад", чтобы сделать несколько вперед). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 26 апреля, 2018 Опубликовано 26 апреля, 2018 · Жалоба >> Назовите такой продвинутый редактор, в котором можно посмотреть состояние проекта неделю назад? RAD Studio . . . редактор, а особенно броузер .... "не-дай-бог". Тупило и глюкало. Структура и состав контекстного меню - тоже "оригинально" сделана. Явно не для отладки и чтения чужого кода. Так ставьте расширения GExprets, AQtime, CodeSite... и будет счастье. Все равно под десктоп ничего лучшего нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 26 апреля, 2018 Опубликовано 26 апреля, 2018 · Жалоба . . . . а-а-а-а. В ЭТОМ смысле. . . . . Дельные ответы изо всей "воды" здесь вылитой я всё-же получил: 12345. . . . 5. ...... Далее прошу продолжить участникам данной темы, если не лень конечно... 5. Для поиска очень редких сбоев, полуаппаратный метод. В том числе в среде RTOS. Используете лог. анализатор (онлайновый, с возможностью просмотра движущейся "ленты". У меня - встроенный в осц-ф, 16 каналов). В критические участки кода (вектора прерываний, планировщик RTOS, флаги ошибок) ставите "ногодрыг". Если необходимо поймать комбинацию флагов, можно линии "ногодрыга" подключить на внешние схемы "И". Развертка ставится самая медленная. Если в осц-фе есть память - это также можно использовать (но это "не про меня"). Далее писать алгоритм "отлова" нет смысла, все очень индивидуально. Эта метода поможет "засечь" состояние первого сбоя, который в любом случае придется ловить вручную или наполовину вручную. При появлении сбоя - жмем на осциллографе "Stop/Freeze" и не спеша рассматриваем предисторию вылета. Так ставьте расширения GExprets, AQtime, CodeSite... и будет счастье. Все равно под десктоп ничего лучшего нет.Спасибо за инф. Посмотрим что за звери. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 10 28 апреля, 2018 Опубликовано 28 апреля, 2018 · Жалоба Суть в том, что глюки начинают вылазить при оживленном траффике по сети, если запросов-ответов мало может неделями работать без проблем. нувыблиндаёте!!! Вы же нашли, можно сказать, багу и продолжаете гадать на кофейной гуще. Прибор на стол и эмулируем не то что оживленный трафик, перегруженный трафик. Во первых бага быстро появиться, во вторых вы обязаны были разработчик обязан был на столе проверить, что будет, если трафик будет перегружен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 29 апреля, 2018 Опубликовано 29 апреля, 2018 · Жалоба Прибор на стол и эмулируем не то что оживленный трафик, перегруженный трафик. Я так подозреваю, что в этом случае "прибор" вообще перестанет работать. :rolleyes: Вообще конечно: стресс-тест - это обязательный этап тестирования для таких устройств. Всегда делаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 29 апреля, 2018 Опубликовано 29 апреля, 2018 · Жалоба Прибор на стол и эмулируем не то что оживленный трафик, перегруженный трафик. Во первых бага быстро появиться, во вторых вы обязаны были разработчик обязан был на столе проверить, что будет, если трафик будет перегружен. Хотя звучит умно, но по факту это немного глупо. На кой нагружать трафиком если известно, что дивайс или система наверняка заглохнет при превышении определенного уровня? Что вам даст если вы зафиксируйте несколько раз этот уровень? Ошибка конечно проявится, но это будет не та ошибка! А чтобы была та, нужно именно тот трафик смоделировать. А если вы знаете именно тот трафик, то знаете и ошибку. Так что "стресс-тест" это просто семантический плеоназм в данном случае. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 29 апреля, 2018 Опубликовано 29 апреля, 2018 · Жалоба Хотя звучит умно, но по факту это немного глупо. На кой нагружать трафиком если известно, что дивайс или система наверняка заглохнет при превышении определенного уровня? Т.е. - Вы считаете, что зависание или перезагрузка или улёт по неизвестному адресу выполнения при штатном обмене по интерфейсу - это вполне допустимое поведение прибора? И даже и выяснять ничего не надо? Странный у Вас подход к разработке устройств..... :smile3046: И что значит "не та ошибка"? Считаете, что нужно устранять только те ошибки, что сейчас кто-то заметил, а на остальные забить? А как поймёте, что "та" или "не та", какой критерий? Так что "стресс-тест" это просто семантический плеоназм в данном случае. Стресс-тест - это один из методов нагрузочного тестирования в ходе разработки и отладки безглючных устройств, которые работают всегда, при любых условиях, а не только при каких-то тепличных, настольных. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
novikovfb 17 29 апреля, 2018 Опубликовано 29 апреля, 2018 · Жалоба На кой нагружать трафиком если известно, что дивайс или система наверняка заглохнет при превышении определенного уровня? Дивайс должен уйти во вполне определенное состояние при превышении определенного уровня и выйти из него в рабочее после нормализации обстановки. Например, пропускать только те пакеты, на которые хватает производительности канала, а в слове состояния выставить признак проблем с подключением. Или при превышении частоты ошибок прекратить общение до паузы в сигнале или появлении корректного сообщения. Почитайте описание протокола CAN, например. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 29 апреля, 2018 Опубликовано 29 апреля, 2018 · Жалоба Дивайс должен уйти во вполне определенное состояние при превышении определенного уровня и выйти из него в рабочее после нормализации обстановки. Вот именно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 10 29 апреля, 2018 Опубликовано 29 апреля, 2018 · Жалоба На кой нагружать трафиком если известно, что дивайс или система наверняка заглохнет при превышении определенного уровня?Чтобы попадать в баг не раз в месяц, а раз в 1 минуту (или хотя бы раз в час, как можно чаще). Чем чаще бага проявляется, тем легче её найти. Ошибка конечно проявится, но это будет не та ошибка! А чтобы была та, нужно именно тот трафик смоделировать. Согласен. Но как стоит условие задачи - "глюки начинают вылазить при оживленном траффике". Нужно на столе смоделировать оживленный трафик, а также стресс-тест. Если бы было в условии "глюки начинают вылазить при ОПРЕДЕЛЁННОМ оживленном траффике, а при другом оживленном трафике нет баги", то тут сложнее, тут да, лови и моделируй нужный трафик. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 29 апреля, 2018 Опубликовано 29 апреля, 2018 · Жалоба Дивайс должен уйти во вполне определенное состояние при превышении определенного уровня и выйти из него в рабочее после нормализации обстановки. В CAN-е это аппаратно сделано, поэтому я только CAN везде и применяю. И да логируется у меня достаточно счетчиков относящихся к работе CAN. Но если я сделаю некий "стресс-тест" с хаотичными командами, то система подвиснет, лог будет переполнен, даже могут возникнуть конструктивные повреждения, сработает WDT И че я выясню в результате? Попробуйте "стресс-тест" провести где нить в сети промышленных логических контроллеров. Тоже получите катастрофу. Опять же применив некую симуляцию запредельного трафика можно просто ввести устройство в ступор и при этом вообще ничего реально тестироваться не будет. Т.е. сделать грамотное нагрузочное тестирование очень сложно во первых, а во вторых оно не для выявления ошибок, а скорее для тестирования риалтайма систем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 35 29 апреля, 2018 Опубликовано 29 апреля, 2018 · Жалоба Это может означать, что плохо или спроектировано или реализовано, а может и то и другое. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 30 апреля, 2018 Опубликовано 30 апреля, 2018 · Жалоба Опять же применив некую симуляцию запредельного трафика можно просто ввести устройство в ступор и при этом вообще ничего реально тестироваться не будет. Это только говорит о том, что данное устройство неправильно спроектировано. Никакая комбинация входных данных (валидных или просто мусора) с любой частотой повторения на внешних интерфейсах не должна вводить устройство в состояние ступора либо любое другое нерабочее состояние. Если это не так - это кривое устройство и надо переделывать. Как то так. Всегда следую данному правилу. Да и по внутренним интерфейсам устройства - например если у меня есть SPI-FLASH в устройстве, но обращение к ней идёт не часто, то для теста (обнаружения редко проявляющихся непериодических сбоев как у ТС), я нагружаю данный интерфейс транзакциями чтения/записи по самое нехочу. Например - создаю несколько задач ОС, которые параллельно обращаются к этому интерфейсу со случайными запросами чтения/записи случайной длины и адресом, так чтобы загрузка CPU при такой работе была близка к максимальной. Гоняю этот тест несколько часов с общим объёмом траффика во много ГБ. И одновременно с этим устройство должно продолжать выполнять свои штатные функции. Вот если за время такого теста сбоев не было - значит всё ок. Иначе - разбираюсь, пока не устраню причину. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
