[Forger 20]

Блажен, кто верует, тепло ему на свете!

А другой долбил молотком по стамеске до конца дней своих ...

[SapegoAL 0]

По статистике, среди программистов самый популярный способ продемонстрировать крутизну проекта - указать число строк и файлов )))

И совершенно до лампочки тот факт, что из них львиная доля - сторонние чужие библиотеки ...

Из сторонних библиотек только LwIP и FreeRTOS. Больше ничего нет. Я HAL не пользуюсь. Из HAL использовал только инициализацию CPU и шин переписанную и Ethernet подправленный.

Строки, естественно считал по своим файлам. Нафига чужое считать.

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

 

Насчёт плюсов я так скажу. Это надо бы взять какой-нибудь камень ясный... Ну типа того же AVR. Ну чтобы ассемблер был такой, чтобы читался как роман... ))

После чего наваять несколько простых проектов. Компильнуть и посмотреть чё получилось. Поиграться. Ну чтобы ясная картина появилась, во что превращается та хрень, что ты написал.

Вот где на это время взять?

[scifi 1]

Насчёт плюсов я так скажу. Это надо бы взять какой-нибудь камень ясный... Ну типа того же AVR. Ну чтобы ассемблер был такой, чтобы читался как роман... ))

После чего наваять несколько простых проектов. Компильнуть и посмотреть чё получилось. Поиграться. Ну чтобы ясная картина появилась, во что превращается та хрень, что ты написал.

Это ассемблер головного мозга. Его надо лечить электрошоком.

В машинный код нужно смотреть тогда, когда реально не хватает памяти и/или скорости, то есть раз в год

А иначе не останется времени на отдых. Ну и программы будут писАться по два года :smile3009:

[Forger 20]

Ну чтобы ассемблер был такой, чтобы читался как роман... ))

 

Искренне сочувствую и .. желаю удачи!

[let's see 0]

А другой долбил молотком по стамеске до конца дней своих ...

Продолжайте набор...

Увы, не все на этом свете излечимо...

Изменено 19 января, 2017 пользователем pitt

[Forger 20]

Классика жанра: вопрос -> холивар -> срач -> закрытие темы.

 

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

[k000858 0]

не соглашусь

 

темы подобного рода создаю в части случаев не для того, что бы получить готовый ответ "нажми А + Б и все заработает", а для того, что бы почитать размышления и опыт других программеров по теме.

можно кое что подчерпнуть.

 

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

 

дам немного конкретики: устройство помимо ethernet интерфейса имеет на борту радио-интерфейс, который обслуживает 6lowPAN протокол (само устройство - координатор, общается с конечными устройствами через ре-трансляторы). По радио-интерфейсу конечные устройства скидывают данные, а так же обновляются прошивки. Прошивка конечных устройств закачивается в координатор через вэб-интерфейс. Один из этапов обновления ПО конечных устройств - передача частей ПО по радио-интерфейсу, для этого каждая часть по очереди копируется с FLASH и упаковывается в DataPacket. эффект наступает именно на этом этапе. Спровоцировать эффект можно повысив нагрузку на ethernet-интерфейс. под штормом трафика подразумивал банальный UDP спам

[Forger 20]

не соглашусь

 

темы подобного рода создаю в части случаев не для того, что бы получить готовый ответ "нажми А + Б и все заработает", а для того, что бы почитать размышления и опыт других программеров по теме.

можно кое что подчерпнуть.

Все идет хорошо, пока не дошло до срача ...

 

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

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

В данном случае предлагаю поэтапно отключать куски проекта.

Если построение модульное, то это сделать очень просто, если нет, придется "разрезать" и изолировать блоки друг от друга.

 

Но есть другой - более радикальный способ (однажды именно так я и сделал, о чем не жалею).

Заново перепроектировать проект, постепенно набивая ее функционалом из существующего.

Конечно, это потребует несколько дней кропотливой работы, но потом только спасибо себе скажите )))

Для этого не обязательно сразу перескакивать на С++, для начала нужно просто спроектировать проект.

Я очень часто пользую такую прогу - XMind и не только для этого.

Главное - не спешить набивать проект кодом, это мелочи, главное - разумно и однозначно спроектировать связи между модулями.

Для уже существующего проекта это делать намного проще. "Глаза боятся, а руки делают" )))

 

Забыл добавит - нельзя забывать о тестовом коде, который должен "проверять на прочность" каждый модуль.

 

[SapegoAL 0]

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

...

Спровоцировать эффект можно повысив нагрузку на ethernet-интерфейс. под штормом трафика подразумивал банальный UDP спам

Очень очень давно разрабатывал модем. Появлялись сбои непонятные. Очень редкие... Примерно 1 сбой на 2 Мб передаваемых данных. Отладчика тогда не было как класса. По вероятности вычислил что ошибка возникает если приходит прерывание в каком-то месте головы. Осей тогда тоже не было. Сделал синхронный вывод инфы. Ну и обнаружил переменную. Дальнейшее было делом техники.

На вашем месте я попробовал бы

1. добиться повторяемости ошибки

2. Выводил бы отладочную инфу по прерываниям и задачам (для локализации)

3. дальше - глубже залазил.

 

 

[k000858 0]

Очень очень давно разрабатывал модем. Появлялись сбои непонятные. Очень редкие... Примерно 1 сбой на 2 Мб передаваемых данных. Отладчика тогда не было как класса. По вероятности вычислил что ошибка возникает если приходит прерывание в каком-то месте головы. Осей тогда тоже не было. Сделал синхронный вывод инфы. Ну и обнаружил переменную. Дальнейшее было делом техники.

На вашем месте я попробовал бы

1. добиться повторяемости ошибки

2. Выводил бы отладочную инфу по прерываниям и задачам (для локализации)

3. дальше - глубже залазил.

В принципе именно такую методику и применяю

Выяснил что именно и при каких условиях портится: вот есть буфер со скопированной часть ПО, вот он же но уже битый. За время порчи молотил езернет (именно им провоцирую баг). Не удается пока выяснить почему происходит эта порча в буфере (а может происходит порча указателей на буферы ака указатели типа хедер?).

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

[Forger 20]

В принципе именно такую методику и применяю ... ...но пока безрезультатно.

.

[SapegoAL 0]

Ну в принципе, здесь возможны 4 ошибки.

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

2. неверная работа с указателем.

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

4. стек задачи выходит за пределы.

Исходя из того, что порча происходит кратковременно, и потом ситуация восстанавливается, две последних маловероятны.

А портится один и тот же участок?

[Forger 20]

Если проектировать код похожим образом (на C++ без глобальных объектов), т.е. как я указывать в самом начале этой темы, то:

 

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

Этого никогда не произойдет, т. к. нет ни одного глобального объекта.

 

2. неверная работа с указателем.

Указатели не используется, лишь ссылки на объекты, и то очень многие с квалификатором const. Нужно изрядно постараться, чтобы навредить ))

Т.к. нет указателей, то приведение типов НИГДЕ не используется, а это - тоже очень частая причина неконтроллируемых сбоев.

 

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

Самодельных буферов нет, есть давно отлаженные и вылизанные классы, которые реализуют работу буферов.

 

Нет никакого смыслы изобретать колесо в каждом проекте и потом его каждый раз отлаживать -

за нас уже придуманы и написаны шаблоны списков, очередей, контейнеров и т. п.

 

4. стек задачи выходит за пределы.

Контроль стека средствами RTOS с соотв. отладочной информацией. Это уже встроено во всех нормальных RTOS.

 

Эти все сущности однажды написаны и отлажены, поэтому нет никакой нужды в каждом проекте лечить подобный "анальный зуд"!

Впрочем, у каждого свои предпочтения :biggrin:

 

 

зы. Речь идет лишь о коде приложения, а не о коде сторонних библиотек, где наверняка используются указатели, самодельные буферы и т. п. наследия голого С

[SapegoAL 0]

Уважаемый Forger. Мы вас уже поняли. Надо проект обязательно переписать на C++. Обязательно использовать синглтоны. И, конечно, тогда никаких ошибок не будет. Потому что у программистов пишущих на С++ не бывает ошибок. Особенно у программистов пишущих на С++ и включающих в проект FreeRTOS и LwIP на Си. Понятно, что надо использовать статическое выделение памяти, так как динамическое это смерть.

Хотелось бы спросить, а как быть с LwIP? Вы там тоже статическое выделение используете?

Понятно что надо использовать стороннюю библиотеку.. Лучше брать PeriphLib или переключиться на HAL...

Мы услышали. Спасибо.

Не понятно, с кем вы здесь спорите? Со мной? Так у меня нет таких ошибок. По крайней мере на данном этапе. Надеюсь это понятно?

А у топикстартера есть. И я пытаюсь ему помочь.

Я не знаю в каком коллективе вы работаете, но иногда проект переписать нельзя. И этому может быть сто причин, как правило, все они лежат вне программирования... Например сроки, финансирование, малая вероятность того, что в новом проекте не будет других ошибок, или как минимум, отсутствие веры в это руководства. И так далее...

Я просто не хочу вступать в полемику с вами. Я не всегда писал проекты по 2 года. Например был проект с экспортным автобусом маз. Дисплей 480x272 + светодиодные столбики + стрелки + 2 CAN и два проца в жёсткой связке LPC2478 + stm32f103 был написан за 2 месяца. Потому что законченное решение. А крупный проект - там проблема в том, что сотни параметров исходных, и в зависимости от этого работа прибора полностью меняется. Там объективно много работы. А писал я его в одиночку, попутно занимаясь другой работой.

Может не стоит хаить человека, не зная реальной ситуации?

Асмом я не пользуюсь. На плюсах пишу, но пока незначительный объём.

Но мы сейчас не обо мне говорим. Надеюсь это понятно?

Я прекрасно знаю о контроле стека и прочей ерунде... У меня, на лету определяется вылет если он происходит, диагностируется задаче и место откуда это происходит. Всё это запоминается происходит рестарт проца и информация записывается в виде ошибки с точным указанием времени.

Поэтому... Давайте по делу. Есть что сказать топикстартеру, пожалуйста скажите. А тему про грамотный переход из С в С++ начните с чистого топика и поделитесь своим опытом построения. Многие с удовольствием это почитают. И я в том числе..

[let's see 0]

Уважаемый Forger. Мы вас уже поняли. Надо проект обязательно переписать на C++. Обязательно использовать синглтоны. И, конечно, тогда никаких ошибок не будет. Потому что у программистов пишущих на С++ не бывает ошибок. Особенно у программистов пишущих на С++ и включающих в проект FreeRTOS и LwIP на Си. Понятно, что надо использовать статическое выделение памяти, так как динамическое это смерть.

Хотелось бы спросить...

Что можно спрашивать у того, у кого есть единственный готовый ответ на все случаи жизни?! Вопрос, конечно, риторический, потому что все идут не в ногу, а по сему нас посылают в Ж, хотя весьма почтительно...