[Neo_Matrix 0]

Вы меня не так поняли. Такой подход как у вас у меня тоже используется в драйвере i2c. Я пытался сказать, что не вижу других способов кроме как использовать указатель на структуру или просто номер. Для меня номер в данном случае был предпочтительнее. Но на самом деле изначальный вопрос несколько иной

Изменено 16 мая, 2019 пользователем Neo_Matrix

[VladislavS 29]

2 часа назад, Neo_Matrix сказал:

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

Ну ёшкин кот! Давай разберём построчно эту чушь:

volatile uint32_t tmp_reg;

Тут мы создали локальную переменную tmp_reg целого беззнакового 32-битного типа. В стеке, вестимо, так как локальная и volatile.

tmp_reg = read_reg(uart_data->uart_typedef, DR);

Из регистра USARTx->DR в эту переменную прочитали значение с обязательным сохранением в место хранения, так как она volatile.

(void)tmp_reg;

Прочитали значение переменной tmp_reg из места хранения, так как она volatile и результат выкинули.

 

Мой код, естественно, будет лучше

USARTx->DR;

Просто прочитаем из DR данные, так как регистры определены как _IO (читай volatile), а результат выкинем.

[Neo_Matrix 0]

6 минут назад, VladislavS сказал:

Мой код, естественно, будет лучше

Я абсолютно не спорю. Но подобный подход использую не только я, пример:

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

Изменено 16 мая, 2019 пользователем Neo_Matrix

[VladislavS 29]

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

        
// USART1->DR;
        LDR.N    R0,??DataTable2_1  ;; 0x40011004
        LDR      R1,[R0, #+0]

Для сравнения

  volatile uint32_t tmp_reg;
  tmp_reg = USART1->DR;
  (void)tmp_reg;

//   volatile uint32_t tmp_reg;
//   tmp_reg = USART1->DR;
        LDR.N    R0,??DataTable2_1  ;; 0x40011004
        SUB      SP,SP,#+4
        LDR      R1,[R0, #+0]
        STR      R1,[SP, #+0]
//   (void)tmp_reg;
        LDR      R0,[SP, #+0]
        ADD      SP,SP,#+4

 

Всё ещё есть желание индусский код за образец брать?

[jcxz 181]

2 часа назад, VladislavS сказал:

 

volatile uint32_t tmp_reg;

Тут мы создали локальную переменную tmp_reg целого беззнакового 32-битного типа. В стеке, вестимо, так как локальная и volatile.

На кой ляд локальной автоматической переменной атрибут volatile? Разве тока если адрес на неё передаётся в другую задачу, чего вроде как нет.

2 часа назад, Neo_Matrix сказал:

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

Индусский код уже стал у нас образцом качества?  

2 часа назад, VladislavS сказал:

Всё ещё есть желание индусский код за образец брать?

хе! только сейчас прочитал. прям те же слова  

[Neo_Matrix 0]

В итоге упростил обработчик, написал его на голом доступе к регистрам, по рекомендациям выше. В итоге абсолютно нечего не изменилось. При этом, если тот же код использовать на USART2 - все отлично работает и "подвесить" периферию не получается. Вкрадываются подозрения, что это связано с разными модулями периферии APB2\APB1.

ПС: А с чего вдруг lwip стал внезапно индусским?

Изменено 21 мая, 2019 пользователем Neo_Matrix

[Neo_Matrix 0]

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

[aaarrr 61]

22 minutes ago, Neo_Matrix said:

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

Я бы не спешил с выводами. Проверьте очень внимательно тактирование, настройки WS флеш и т.п. А то как бы на очередной партии проблема не вернулась.

[Neo_Matrix 0]

С тактированием все нормально, уже проверял. Косвенно можно судить о нормальном тактировании по ЮСБ который достаточно критичен к частоте. Задежки чтения флеша тоже правильные. Буду надеяться, что проблема решена. Есть еще вероятность, что в прошлой партии неправильно смонтажили компоненты, допустим керамику вокруг проца. Но выпаивать все и проверять - пока не готов.

[VladislavS 29]

В 21.05.2019 в 19:11, Neo_Matrix сказал:

А с чего вдруг lwip стал внезапно индусским?

Термин "индусский код" характеризует не гражданство/национальность программиста, а его квалификацию. И если вы нашли подобные примеры кода в lwip (я его не изучал, врать не буду), то он таки и есть индусский.

[Neo_Matrix 0]

5 часов назад, VladislavS сказал:

Термин "индусский код" характеризует не гражданство/национальность программиста, а его квалификацию. И если вы нашли подобные примеры кода в lwip (я его не изучал, врать не буду), то он таки и есть индусский. 

Я в курсе, что такое "индусский код". Просто стек популярный и достаточно навороченный, при своей нетребовательности к ресурсам(тут конечно все относительно).

Причина проблемы полностью выяснена. Виной странная партия процов. Как и писал ранее в новой партии устройств данной проблемы нет, потому я просто перекинул процы между 2мя устройствами, глюк перекочевал на другую плату вместе с процом, старая же плата с новым процом заработала нормально. Ревизия процов везде "2". Внешне процессора имеют небольшое отличие, глючные имеют блестящие выводы(похоже на покрытие ПОС), новые имеют более коричневый оттенок выводов(возможно иммерсионное золото, но не уверен).

[adnega 10]

14 часов назад, Neo_Matrix сказал:

Причина проблемы полностью выяснена. Виной странная партия процов.

Чтобы так категорично заявлять нужно как минимум сделать наипростейшее ПО для данного МК и попытаться воспроизвести ошибку.

Ощущение, что проблема в чем-то другом ничуть не уменьшилось.

[Neo_Matrix 0]

Лажа таки в МК была, добавил костыль в код, для "отвисания". Проверено на всей новой партии более 100шт, такого глюка нет.

[GenaSPB 11]

1. А в двух словах можно опсисать?
2. А на старой партии процессоров костыль не помешал?

[Neo_Matrix 0]

1 час назад, GenaSPB сказал:

• А в двух словах можно опсисать?
• А на старой партии процессоров костыль не помешал?

Сама проблема была описана ранее(в первом посте). Переферийный модуль UART4 вис намертво пока не записать в DR любую инфу. На остальных юартах этой проблемы не наблюдалось.

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