fshp: Да, в таком случае баг бы решился еще несколько недель назад) К сожалению, этот баг появился сразу. Не все работают в git как нужно, и из за этого приходится работать с коммитами, в которых появляется куча файлов и тонной кода. Что откуда появилось уже не отследить.
>>1. Возможно это блокировки шины памяти.
Они бывают если что-то занимает озу или флешь надолго или уарт очень быстрый, 500кБод и выше.
Классика жанра - прошивка параметров в флеш или самого флеша. Или работа другого канала ДМА на макс скорости
<< Uart работает на 115200, про остальное, сложно сказать.
>> 2. Возможно ошибки приёма уарта, советую глянуть осцилографом стабильность уровней напряжения и временную стабильность фронтов.
<< Я проверял просто uart, данные передаются без проблем. Прогонял 45 минут данные и поломанных не было.
<< 3. в Keil есть "Scatter file", с помощью которого можно линкеру указать что куда писать. Попробую этот вариант.
>> 4. Попытаться по кускам поотключать бизнес код.
<< В очередной раз сделаю это.
<< 5. это очень дорогой вариант) все завязано на средства RTOS
<< 6. Попробую
<< 7. понимаю о чем вы, было и такое. Но в данном случае никаких ассоциаций не возникает.
Спасибо за предложенные варианты! Отпишу более подробно по результатам.
x67: Это устройство, которое взаимодействует с другими устройствами. Под бизнес логикой я понимаю не платформозависимую обработку данных, для достижения неких бизнес задач.
WorldEn: не выдается ошибка потому что при обращении к ячейки памяти не происходит проверки на выход за границы массива. И если у нас есть доступ к этой памяти (а в данном случае, мы просто обращаемся к следующей ячейки памяти стека main()) то нам ничего не мешает распечатать значение этой ячейки.
в общем виде, там может быть что угодно. Так же, там могли бы быть аргументы функции printf. Это зависит от компилятора.
Дмитрий: Да, это понятно. А где можно было бы по подробнее почитать о том, как именно это делает компилятор? хотя бы на примере gcc. Возможно книга "Полное руководство GCC" имеет ответы на вопросы типа "как поведет себя компилятор в такой то ситуации...?" Быть может вы знаете какие то интересные источники по поведению компилятора?
Я помню, еще в книгах читаешь (не важно какую), бывает пишут, что - то типа "если эта переменная нигде не используется, то компилятор оптимизирует ее... бла бла бла". Было бы здорово изучить чей нибудь труд по поведению компилятора.
Да, видимо нужно изучать не механизмы самого Си, а как работает ассемблер. Это знание даст возможность читать скомпилированный код и анализировать что куда девается и как работает. Спасибо, хороший совет.
Подскажете как войти в тему ассемблера наиболее безболезненно?
Честно говоря, не очень понятно зачем.
Я сейчас разговор идёт только о чистом СИ. В проектах я никогда не встречал подобного описания типа, по этому и решил поднять тему и разобраться что к чему.
если мы пишем функцию типа
void f(int * arr){...}
то когда мы выполняем:
int a[5] = {1,2,3 };
f(a);
мы передаем копию только указателя на первый элемент массива. Причем тут копирование массива и его размер?