alexp74

Должны быть из хэдеров на stm32. Hal сам пропишет в физику.

Ковырял stm32f4xx_hal_eth.c и нашел интересный момент. Много записей в MAC регистры сделаны таким макаром: static void ETH_FlushTransmitFIFO(ETH_HandleTypeDef *heth) { __IO uint32_t tmpreg1 = 0U; /* Set the Flush Transmit FIFO bit */ (heth->Instance)->DMAOMR |= ETH_DMAOMR_FTF; /* Wait until the write operation will be taken into account: at least four TX_CLK/RX_CLK clock cycles */ tmpreg1 = (heth->Instance)->DMAOMR; HAL_Delay(ETH_REG_WRITE_DELAY); (heth->Instance)->DMAOMR = tmpreg1; } Т.е. в регистр происходит запись, потом он же читается, потом задержка на от ~0 до 1-го systick и запись прочитанного опять в регистр. Напрягает плавающая задержка. В мануале на stm32 не нашел требований по задержке...

Да, согласен. Проще убрать const. Спасибо.

Добрый день. Возникла необходимость перенести проект для AVR с AtmelStudio (GCC) на IAR AVR. Столкнулся с такой проблемой. Нужно инициализировать массив объектов с константным членом внутри. Вроде как правильно это делать в списке инициализации. В GCC нет проблем. Правда студия предупреждает "extended initializer lists only available with -std=c++11 or -std=gnu++11". А как можно в IAR? Кто сталкивался? Пример кода для AtmelStudio: class A { private: char * const portx; public: A() : portx(0) {}; A(char * const port) : portx(port) {}; }; class B { private: A m_b[2]; public: B(); }; char port; char * const pport = &port; B::B() : m_b { A(pport), A(pport) } { } int main() { B b(); return 0; }

Also depending on the port and development environment it may be necessary to use the pre-processor to prevent the configuration file from being included from assembly files. For example, in IAR this can be done as follows... /* The IAR C compiler automatically defines __ICCARM__. */ #ifdef __ICCARM__ #include "trcKernelPortFreeRTOS.h" #endif Preventing the RTOS trace header file from being included from assembly files when using the IAR compiler http://www.freertos.org/FreeRTOS-Plus/Free...tructions.shtml

Тема увлекательная, только библиотека IAR так писана, что вроде как строка TZ парсится только первый раз, а потом только через танцы с бубном. И это не переносимо. Так что лучше самому реализовать...

если в IAR - то C/C++ Compiler -> Extra Options поставить галку Use... и добавить --enum_is_int

Возможно. Но тогда это проблема MAC контроллера. Он заведует наполнением Tx FIFO из буфера в памяти.

пока помогает flush TX Fifo осталось решить, когда его дергать наверное сделаю пока профилактически перед отправкой пакета, если весь TX тракт отдыхает...

Если смотреть лог, то в пакете 451 уже нет CRC TCP, а в следующем пакете нет и контрольной суммы заголовка. Не суть важно, как их автор назвал. контрольные суммы и CRC считает аппаратно MAC. Можно конечно это отключить, и считать ручками или встроенным CRC. Но проблема в том, что MAC неожиданно перестает считать. Состояние канала роли не играет. После закрытия сокета, создания нового и вызова connect - формируется пакет SYN без CRC.

Добрый день Столкнулся с такой проблемой. Система на stm32f217 работает под FreeRTOS. Использую LWIP и самопальный вэб сервер. Помимо этого идет двунаправленный поток UDP пакетов и отдельно медленный TCP коннект к другому серверу. Если вэб сервер хорошо нагрузить, например с помошью JMeter, то через некоторое случайное время MAC начинает отправлять пакеты с нулевой CRC. Естественно комп их дропает. Все рвется. Потом медленный TCP коннект пытается подключится к компу и шлет повторно SYN пакет с CRC0 в попытке восстановить соединение. Пока помогает только перезагрузка. Дискрипторы в норме. TDES0: 0x30D00000. Нашел жалобу на это, но без решения... http://lwip.100.n7.nabble.com/CRC-of-each-...F4-td23334.html