Neo_Matrix

Спасибо, то что нужно. Странно, что расширение файла большой буквой S должно автоматически интерпретироваться как препроцессинг, но что то пошло не так. Более подробно: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0773a/chr1383143887630.html

Кто нибудь пробовал собирать проект в такой связке: ChibiOS + KEIL + ARM COMPILER V6? Связка ChibiOS + KEIL + ARMСС V5 нормально компилируется. А вот с новым компилятором возникают проблемы с ассемблерными файлами, такими как: cstartup.s, vectors.s....... Внутри которых есть куски СИшного кода из ИНКЛУДОВ и ДЕФАЙНОВ: #if CH_DBG_ENABLE_STACK_CHECK && PORT_ENABLE_GUARD_PAGES bl _port_set_region #endif #if CH_DBG_SYSTEM_STATE_CHECK bl _dbg_check_unlock #endif #if CH_DBG_STATISTICS bl _stats_stop_measure_crit_thd #endif #if CORTEX_SIMPLIFIED_PRIORITY cpsie i #else movs r3, #0 /* CORTEX_BASEPRI_DISABLED */ msr BASEPRI, r3 #endif mov r0, r5 blx r4 movs r0, #0 /* MSG_OK */ bl chThdExit _zombies b _zombies ENDP Может у armclang есть опция которая разрешает использовать такие конструкции?

У Вас есть конкретная ошибка, вот и решайте проблемы с выделением памяти в куче, зачем сейчас разбираться с энтропией. Для теста можете написать простую функцию энтропии, которая в цикле заполняет массив константами, после перепишите под аппаратный RNG. Функции выделения памяти MBEDTLS_PLATFORM_CALLOC_MACRO MBEDTLS_PLATFORM_FREE_MACRO по скольку я помню Вы должны переопределить сами. Если используете ФриРТОС, это будет vPortFree и нужно написать врапер над pvPortMalloc для calloc. Что то вроде этого: void *pvPortCalloc(size_t nmemb, size_t size) { void *x = pvPortMalloc(nmemb * size); if (x != NULL) { memset(x, 0, nmemb * size); } return x; }

Я об этом ранее уже писал

Все верно.

А если следующий байт пока еще не идет, а линия приняла нормальное состояние?

Спасибо. Завтра попробую проверить

Нужно попробовать.

Ошибка кадра приходит единожды при изменении сигнала в 0. Пауза может быть или не быть :)) Неизвесно

По идее можно после LBD флага запустить таймер и EXTI на подъем сигнала. Далее можно понять был ли перепад за время таймера(100мс)

Может кто то пробовал на вход уарта(на джпио) еще включить прерывание exti? будет ли так работать?

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

А LBD флаг нормально работает если порт сконфигурирован на UART, а не на LIN? Это уже проданный товар, нужно скорректировать прошивку под другое оборудование. Я понимаю, что юарт не может измерять длительность, но допустим если использовать ЛИН БРЕЙК, как посоветовали выше, можно запустить таймер софтово и поллить ногу в течении следующих 99мс? Или так не выйдет? Наверное с регистра состояния ДЖПИО можно вычитать текущий уровень 1 или 0, по идее альтернативная функция пина не должна на это влиять.

А как на один и тот же пин таймер повесить и UART? Данные то ведь никто не отменял. Спасибо сейчас посмотрю что за зверь.

Если еще актуально, попробуйте увеличить значение #define MEM_SIZE 1024*40 в файле LWIP lwipopts.h. Для работы мбедтлс требуется 2 буфера по 16кб памяти и еще под другие нужды она тоже нужна, как минимум под прием\отправку пакетов и сам сертификат(после парсинга)

Привет. Может кто то сталкивался с возможностью отслеживать логический 0 на входе UART который длится более 100мс? В общем есть устройства третьей стороны, которое для отправки сигнала сброса использует притягивание линии UART в логический ноль на время близкое к 100мс. Каким образом можно это отследить? Разумеется что нормальное состояние линии логическая 1.

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

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

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

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

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

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

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

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

Как и в ответе выше, у всех подход свой и у всех он разный. Мне показалось, что ваша структура содержит слишком много данных, но для вас это в самый раз. Так что здесь каждому свое. Мне вспомнился подобный подход в портах под разные отладочные платы, которые пишет СТМ(не утверждаю что это плохо или хорошо).