Jump to content

    

SapegoAL

Свой
  • Content Count

    2747
  • Joined

  • Last visited

Community Reputation

0 Обычный

About SapegoAL

  • Rank
    Гуру
  • Birthday 08/06/1966

Контакты

  • Сайт
    https://alphamera.by
  • ICQ
    0

Информация

  • Город
    Беларусь, Витебск, Строителей 18-4-220
  1. stm32f767. MPU, DTCM, кэш и прочее...

    Спрошу здесь, чтобы темы не плодить. Просматривал HAL библиотеки работы с внешней SDRAM. Они ставят программную блокировку от доступа. Не совсем понятно... Ну, допустим, они хотят разрулить, попытку из разных задач одновременного доступа по одному и тому же каналу DMA. Ну или доступ и конфигурирование контроллера. Но они блокируют и доступ самому CPU. Это зачем? Я что не могу прочитать произвольные данные, пока у меня идёт DMA операция? Зачем вообще делать процедуру доступа к внешней ОЗУ? Насколько я понимаю, она в общем адресном пространстве. Ну я не знаю. Может они на воду дуют или от дурака пытаются защититься? Обычно инициализация делается до запуска ОС, а доступ разруливается правильным построением задач. Если это невозможно, то устанавливаются семафоры. Или я что-то упускаю?
  2. FreeRTOS и спецы ST

    Ну по-моему это очевидно. Работа с динамической памятью сложнее и объёмнее. Загрузка проца, непроизводительной работой выше. Приходится непрерывно работать с косвенной адресацией. Требуется обеспечить корректную работу в многозадачных системах при выделении/ удалении. Если в этом нет необходимости, то зачем притягивать за уши? Если при статическом распределении у Вас хватает памяти, то это самый лучший выход.
  3. stm32f767. MPU, DTCM, кэш и прочее...

    Там несколько зон есть. Причём можно с перекрытием работать. Лучше документ почитать
  4. FreeRTOS и спецы ST

    Ну у меня динамически выделяется. Прибор коммерческого учёта. Работает годами. Ничего не перезагружается. Правда у меня, после старта, только LwIP динамически с памятью работает. Я не делал удаление/ запуск задач "на лету". Да, если какая то задача запрашивает размер памяти, который отсутствует в системе одним куском, то крах произойдёт. Но тут у Вас 2 выхода. Либо размер кластера увеличить. Либо запускать дефрагментацию периодически. Дефрагментация - решаемая задача.
  5. FreeRTOS и спецы ST

    Это FreeRTOS с "обёрткой". Сейчас ST так делает. Скорее всего в последствии планируют переходить на CMSIS-RTOS. Я за CMSIS_RTOS не слежу, но как я понял, пока её ещё нет. Думаю авторы FreeRTOS над ней работают, или привлекаются. Будет под флагом CMSIS выходить. StartThread является задачей, а не функцией. И ей выделяется стек из кучи. При удалении, очевидно появляется дырка. Понятно стек выделяется куском, и, в принципе, он может быть использован. Спасибо. Понял.
  6. FreeRTOS и спецы ST

    Ребята, прошу разъяснения. При просмотре примеров, которые создают ребята из ST, у меня какой-то диссонанс возникает. Что-то я упускаю, или чего-то недопонимаю глубинного... Вот типовой пример: (кусок из main) // Init thread osThreadDef(Start, StartThread, osPriorityNormal, 0, configMINIMAL_STACK_SIZE * 2); osThreadCreate (osThread(Start), NULL); // Start scheduler osKernelStart(); // We should never get here as control is now taken by the scheduler for( ;; ); Ну и сама задача static void StartThread(void const * argument) { // Create tcp_ip stack thread tcpip_init(NULL, NULL); // Initialize the LwIP stack Netif_Config(); // Initialize webserver demo http_server_netconn_init(); // Notify user about the network interface config User_notification(&gnetif); // Start DHCPClient osThreadDef(DHCP, DHCP_thread, osPriorityBelowNormal, 0, configMINIMAL_STACK_SIZE * 2); osThreadCreate (osThread(DHCP), &gnetif); for( ;; ) { // Delete the Init Thread osThreadTerminate(NULL); } } Мне вот непонятно, зачем запускается задача, из которой апускается ещё несколько, и удаляется стартующая задача. Ведь ка минимум, при этом появится дырка в памяти. В чём преимущество такого подхода, по сравнению скажем, если я сразу из main запущу эти задачи?
  7. stm32f767. MPU, DTCM, кэш и прочее...

    Если честно, то и не подумал об этом. Собственно всё правильно. Проц туда только пишет, и радости от кэша будет немного. Спасибо.
  8. stm32f767. MPU, DTCM, кэш и прочее...

    Да я и не собираюсь рекорды ставить. Думал немного разгрузить шину. Просто видеоозу, естественно, во внешней микрухе расположено. Понятно, что обращение к ней будет медленное. Ясно, что проц значительную часть своего процессорного времени будет на гуёвину тратить. При этом в видеопамять писать и простаивать. И из-за работы LTDC и из-за дополнительных тактов ожидания. Если кэш и нужен, то как раз при обращении к внешней ОЗУ. А если сквозную запись включить? Или пойдут косяки и я впустую потрачу кучу времени? У меня такое ощущение, что мне что-то недоговаривают. )) Скрывают правду от меня. )) Не может быть, чтобы никто с этим не возился. На мой взгляд выглядит примерно так: 1. LTDC работает только на чтение и данные берёт прямо с памяти. 2. Когда я отрисовываю какой-то виджет, то я делаю flush\invalidate по завершению. 3. Аналогичная картина когда я отрисовываю виджет с использованием DMA2D. Если что-то будет в процессе не одновременно отображаться, это не критично, как при работе с ethernet, хотя может резать глаз. И по факту придётся от этого отказаться.
  9. stm32f767. MPU, DTCM, кэш и прочее...

    Всем спасибо за ответы. Про DTCM понял. А что по видеоОЗУ? Там же тоже и LTDC и DMA2D? Хотя по сути LTDC только читает, а по DMA2D после записи можно делать очистку кэша. Или я что-то не так понимаю?
  10. Начинаю проект на 767 камне. Образец будет только через месяца 1.5 - 2. Не работал ни с MPU ни с кэш. Почитал - вроде бы всё понятно. Загрузил cube - смотрю пример. Есть вопросы. В примере st буфера ETH размещают по фиксированному адресу, расположенному в конце ОЗУ. И отключают кэш на этот регион. Хотелось бы услышать тех кто с этим разбирался. А может целесообразнее буфера в DTCM разместить? Вроде бы как работать будет побыстрее. DMA функционирует. Или я чего-то не учитываю? Кто как делал? Можно, наверное и драйвер ETH поправить, на предмет синхронизации работы с памятью. Вроде бы как там не очень много должно быть. Думаю, они этого не сделали, чтобы драйвер был независимым от камня. Конечно тестировать много. Наверное проще пойти по их пути... )) Какие соображения по этому вопросу?
  11. Походу, тому программисту, который после вас будет работать придётся ещё сложнее ...
  12. Практически один в один. )) У меня 2 проги. Одна для программирования на предприятии. Там сразу запрашивается серийный номер. Заливается загрузчик вместе с приложением. Вторая для обновления прошивки. При обновлении прошивки, серийный номер устройства не меняется.
  13. Новые STM32H7 - два ядра (M7+M4), 480 МГц

    Думаю никуда они не замахивались. Крупному клиенту ST понадобился такой камень под конкретную задачу. Был реализован ST и появился в общем доступе - типа, авось кому-нибудь ещё приглянётся... С другой стороны, сам камень H7 весьма недёшев пока... При том, что я планировал его применять - переиграл на F7. Именно из-за цены. Если цена на этот камень будет сопоставима с H7 (максимум +5%), а всё семейство подешевеет слегка, то применять будут.
  14. Новые STM32H7 - два ядра (M7+M4), 480 МГц

    Да и такие, двухядерные, скорее не для уменьшения потребления, а для разделения.... М7 основное приложение например гуёвина и прочее, а М4 обслуживание периферии. Например ethernet, USB, SD, UART-ы, SPI там всякие... М0 для ethernet слабоват будет. ))
  15. STM32H7 - LTDC + DM2D (ChromART)

    Что за процессор? Что за память? Что за флэш? Тайминги проверили? Где у Вас "сыплется"? Ну, смотрите. Я так понимаю, что у Вас LTDC работает с RGB. Соответственно LTDC отображает оперативную память на экран только и всего. По сути LTDC закрытый специализированный встроенный DMA2D. Таким образом для начала Вам надо разобраться на каком этапе у Вас разрушаются данные. Для этого, для начала я бы попробовал копировать в чистое озу (а не в видео область). Потом попробовал бы в видеообласть копировать из другого места. Ну чтобы выяснить где проблема. Попытался бы выяснить при обращении к какому устройству (адресу) происходит Hard Fault. Ну а дальше начал разбираться непосредственно со сбоящим устройством. Если это ОЗУ, то проверил бы тайминги. Если флэш, посмотрел бы настройки. Аппаратно бы глянул. В общем, пока картина не ясна. Я с qspi пока не работал. И mapped-memory не использовал. Сейчас делаю модулёк на базе процессора stm32f767. Но он ещё в процессе разводки. Изготовление макета думаю будет только к концу лета. Работой завален, поэтому пока некогда этим заниматься.