Jump to content

    

MX_Master

Участник
  • Content Count

    52
  • Joined

  • Last visited

Community Reputation

0 Обычный

About MX_Master

  • Rank
    Участник
  • Birthday 01/12/1985

Контакты

  • Сайт
    Array

Информация

  • Город
    Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. STM32H7 RMII

    Ethernet MAC имеет доступ не ко всем доменам ОЗУ. Могу ошибаться, но, возможно, RX/TX буферы находятся в недоступном домене. ЗЫ рабочий пример (создан на скорую руку) - https://gitlab.com/MX_Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP
  2. Вот и я не увидел, а в структуру таки массив не внесли Я лентяй ещё тот. Собсна, как и многие другие. Однако, все согласятся с тем, что изучать доки гораздо приятнее, когда рядом есть хотя б какой-то пример. Пример может быть хорошим или плохим. Но благодаря ему понимание логики работы устройств приходит быстрее Второй плюс кода из под кубика - готовый набор макросов для правки регистров. Ими я пользуюсь с удовольствием. А вот тяжеловесных кубовых функций я стараюсь избегать. Единственное, место, где они остаются - в начальной инициализации. Ибо скорость старта устройства не так важна, как скорость в работе. Но иногда, даже в простых кубовых функциях бывают ошибки. На одну из них я и попался Причём, ошибка неявная, пока глыбже в код не нырнёшь, непонятно /** * @brief ETH Init Structure definition */ typedef struct { uint32_t AutoNegotiation; uint32_t Speed; uint32_t DuplexMode; uint16_t PhyAddress; uint8_t *MACAddr; uint32_t RxMode; uint32_t ChecksumMode; uint32_t MediaInterface; } ETH_InitTypeDef;
  3. Разобрался. Оказыцца, в новый кубик за 2 года завезли новых багов 2 года назад кубик делал так /* ETH init function */ static void MX_ETH_Init(void) { uint8_t MACAddr[6] ; heth.Instance = ETH; heth.Init.AutoNegotiation = ETH_AUTONEGOTIATION_ENABLE; heth.Init.PhyAddress = PHY_USER_NAME_PHY_ADDRESS; MACAddr[0] = 0x00; MACAddr[1] = 0x80; MACAddr[2] = 0xE1; MACAddr[3] = 0x00; MACAddr[4] = 0x00; MACAddr[5] = 0x00; heth.Init.MACAddr = &MACAddr[0]; heth.Init.RxMode = ETH_RXINTERRUPT_MODE; heth.Init.ChecksumMode = ETH_CHECKSUM_BY_HARDWARE; heth.Init.MediaInterface = ETH_MEDIA_INTERFACE_RMII; /* USER CODE BEGIN MACADDRESS */ /* USER CODE END MACADDRESS */ if (HAL_ETH_Init(&heth) != HAL_OK) { _Error_Handler(__FILE__, __LINE__); } } А сейчас вот так static void MX_ETH_Init(void) { /* USER CODE BEGIN ETH_Init 0 */ /* USER CODE END ETH_Init 0 */ /* USER CODE BEGIN ETH_Init 1 */ /* USER CODE END ETH_Init 1 */ heth.Instance = ETH; heth.Init.AutoNegotiation = ETH_AUTONEGOTIATION_ENABLE; heth.Init.PhyAddress = DP83848_PHY_ADDRESS; heth.Init.MACAddr[0] = 0x00; heth.Init.MACAddr[1] = 0x80; heth.Init.MACAddr[2] = 0xE1; heth.Init.MACAddr[3] = 0x00; heth.Init.MACAddr[4] = 0x00; heth.Init.MACAddr[5] = 0x00; heth.Init.RxMode = ETH_RXINTERRUPT_MODE; heth.Init.ChecksumMode = ETH_CHECKSUM_BY_HARDWARE; heth.Init.MediaInterface = ETH_MEDIA_INTERFACE_RMII; /* USER CODE BEGIN MACADDRESS */ /* USER CODE END MACADDRESS */ if (HAL_ETH_Init(&heth) != HAL_OK) { Error_Handler(); } /* USER CODE BEGIN ETH_Init 2 */ /* USER CODE END ETH_Init 2 */ } Ошибку видно?
  4. Года 2 назад экспериментировал с голыми (raw) Ethernet фреймами собственного типа (ethertype=0x80AB) на связке STM32F407VET6 + LAN8720. Всё работало как часы. Портировал недавно тот же код на связку STM32F207VCT6 + DP83848. На этой связке те же самые фреймы теперь отбрасываются в мусор. Очевидно, что их отбрасывает какой-то фильтр. Не могу понять только какой именно. Сквозь фильтр прекрасно просачиваются ARP, UDP, TCP пакеты с любым MAC (destination) адресом. Broadcast тоже пролетают на ура. А вот фреймы неизвестных типов (ethertype=0x80AB), даже с точным МАС адресом STM'ки, отбрасываются. Стессна, если в MAC регистрах включить PromiscuousMode или ReceiveAll , все фреймы приходят на ура. Можно, канеш, фреймы фильтровать и в коде, но интересно разобраться какой именно фильтр мешает. Если кто-то сталкивался с подобным поведением, дайте, пожалуйста, в нужную сторону пинка Попробую завтра что-нибудь ещё. Но было бы интересно выслушать пару советов.
  5. Вариант с подменой адреса reset вектора гениален Спасибо, друзья. Бум пробовать... ЗЫ помониторить правку флэша из оригинала тоже не помешает
  6. В контексте задачи можно оригинал разместить и с 0x08000000, а загрузчик в другом месте. Главное, чтобы первым стартовал именно загрузчик (:
  7. Никогда ещё не дизассемблировал бинарники от STM32, с чего можно начать?
  8. Название темы, канеш, непонятное. Не знаю как точно назвать. ДАНО: есть готовый бинарник прошивки под STM32F207VCT6, исходников нет. По таблице векторов прерываний видно, что базовый адрес флэхи = 0x08000000. ЗАДАЧА: хочу разместить в начале флэхи (0x08000000) свой загрузчик, а следом за ним разместить 2 прошивки - оригинал и свою версию. В зависимости от настроек, загрузчик должен передавать управление одной из них. Свой проект можно собрать, указав линкеру смещенный адрес флэхи. А как быть с уже собранным оригиналом? Есть ли какой-то способ найти в бинарнике все адреса с флэхи и махнуть их на другие?
  9. STM32MP1 - bare metal

    Всё придумано до меня, для настольных ПК. Я лишь пытаюсь запустить сие на мобильных процессорах, вынося всякие ногодрыги в аппаратную часть МК. Получается, канеш, с горем пополам. Но, на мой взгляд, это лучше чем телебонькать пины обычным процессором. Если делать полностью своё ЧПУ (что займёт не один год), можно смело юзать и MP1. Его ресурсов, при грамотном подходе, более чем достаточно.
  10. STM32MP1 - bare metal

    Там кроме собственно LinuxCNC ещё и обычная ОС, типа Ubuntu/Debian, давит на проц. Большинство интерфейсов у LinuxCNC - OpenGL'евые. А этого добра в MP1 нет (OpenGLES не в счёт), так что графика тоже падает на проц. Ну и частенько используются Python скрипты, чему процессор никак не рад. Всё переписывать и оптимизировать - дело неблагодарное. В данный момент использую алвинеры H3 + внешнюю F429. Присматриваюсь постепенно к RK3399. Там внутре 2 многоядрёных проца, один из которых можно в теории заточить под bare metal.
  11. STM32MP1 - bare metal

    Всякие 4-х вёдерные алвинеры H3 при работе на схожих частотах (650мгц) могут спокойно остывать через плату. Вангую, эти MP1 будут ещё холодней. Эх, если б не ограничение в 650мгц, я б с удовольствием применил эти MP1 в своём ЧПУ проекте (на основе LinuxCNC). Но, к сожалению, ниже гигагерца никак низя. Кстати, насчёт HDMI в ЧПУ.. Мой будущий 3Д принтерный проект будет как раз с HDMI дисплеем (с тачем) + orange pi. Банально удобно
  12. STM32MP1 - bare metal

    Раз пошла такая пьянка, есть для экспериментов ещё пара модулей. Опционально можно выбрать размер ОЗУ (256mb - 1gb) и размер флэшки (4-16gb) https://item.taobao.com/item.htm?id=602435481019 https://item.taobao.com/item.htm?id=598786390664 https://www.openembed.com/products/53.html http://snailboard.com
  13. STM32MP1 - bare metal

    Глаза боятся, а пальцы тыкают (: http://wiki.i2som.com/plugins/servlet/mobile?contentId=19923153#content/view/19923153
  14. STM32MP1 - bare metal

    Возможно, кому-то пригодится. Недавно наткнулся на недорогую китайскую макетку с STM32MP157 на борту. Для ЧПУ (CNC) применений и прочих опытов вполне себе подойдёт. цены: https://item.taobao.com/item.htm?id=599303130310 https://item.taobao.com/item.htm?id=592121183085 инфа: http://wiki.i2som.com/pages/viewpage.action?pageId=19922956
  15. Для разделения есть STM32MP1xx (: Там под линями можно с веб-серверами и прочим gui развернуться намного шире. В то время как вся RT часть будет крутится на М4.