Jump to content

    

SapegoAL

Свой
  • Content Count

    2754
  • Joined

  • Last visited

Community Reputation

0 Обычный

About SapegoAL

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

Контакты

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

Информация

  • Город
    Беларусь, Витебск, Строителей 18-4-220

Recent Profile Visitors

6803 profile views
  1. STM32 + графический интерфейс

    С чего бы это? RGB есть во всех stm имеющих LTDC модуль. Это и 32F4, F7, H7 и даже MP1. В последнем разрешение чуть побольше, хотя и не критично. Жаль конечно что LVDS нет. Но вполне себе есть микрухи от TI которые преобразуют из RGB в LVDS. Сам не пробовал, но китайцы предлагают...
  2. STM32CubeIDE

    Возможно синхронизируется по другому.
  3. Проблема с кубом в том, что с ним тоже надо разбираться. Это просто один из инструментов. Если хочешь его использовать, то надо его знать. Например по началу появилась либа. С описанием. Описание либы - ссылалось на биты. То есть чтобы понять как она работает надо было ВСЁ РАВНО изучить даташит на проц. Потом они взяли и никому слова не говоря похезали эту либу и появился HAL. Сейчас, я совершенно случайно увидел вот такое... stm32f7xx_hal_adc.c stm32f7xx_ll_adc.c С описанием "@brief ADC LL module driver". (Почти по всем модулям МК) К чему готовимся? Опять переформатирование? Короче сложно на это всё ориентироваться тому, кто профессионально работает и у кого много проектов и/или они крупные. Ещё одна причина в том, что универсальные драйвера они "универсальные". А синоним этому - громоздкие и избыточные.
  4. STM32CubeIDE

    Работаю с процессорами ST. Начинал со 103. Серийно использую 407, 051, 031, 030. Из старых используются 103, 105, 107. На 051, 031 наблюдал случаи некорректного программирования из под Demonstrator GUI. Разбираться не стал. Мелкие процы отлаживаю под SWD. Не было ни одного случая, ни на одном проце, чтобы проц стопорнулся из под JTAG или из под SWD. Ну и я не верю, что вы смогли угробить проц без прямой подачи запредельных напряжений. Думаю, что проц был жив. И следующий раз за паяльник надо браться в последнюю очередь. Я уже писал, что в одном проекте схемотехники ошиблись и подали на несколько ножек 12В ч/з резисторы. Я успел полностью отладить проект, пока сдох процессор. Примерно неделю он пыхтел.
  5. STM32 External loader SPI-flash

    Я делаю следующим образом. В процессе работы пишу образ во флэху. Зашифрованный файл прошивки. Запись производится без остановки работы устройства. Конечным шагом записывается общая контрольная сумма всей прошивки. После рестарта, загрузчик проверяет наличие этой контрольной суммы. Это является признаком, что требуется обновление прошивки. Если КС есть, то выполняется обновление прошивки. После обновления, загрузчиком контролируется целостность прошивки и стирается КС. Осуществляется старт приложения.
  6. stm32f767. MPU, DTCM, кэш и прочее...

    /** * @brief Writes 8-bit data buffer to SDRAM memory. * @param hsdram pointer to a SDRAM_HandleTypeDef structure that contains * the configuration information for SDRAM module. * @param pAddress Pointer to write start address * @param pSrcBuffer Pointer to source buffer to write * @param BufferSize Size of the buffer to write to memory * @retval HAL status */ HAL_StatusTypeDef HAL_SDRAM_Write_8b(SDRAM_HandleTypeDef *hsdram, uint32_t *pAddress, uint8_t *pSrcBuffer, uint32_t BufferSize) { __IO uint8_t *pSdramAddress = (uint8_t *)pAddress; uint32_t tmp = 0; /* Process Locked */ __HAL_LOCK(hsdram); /* Check the SDRAM controller state */ tmp = hsdram->State; if(tmp == HAL_SDRAM_STATE_BUSY) { return HAL_BUSY; } else if((tmp == HAL_SDRAM_STATE_PRECHARGED) || (tmp == HAL_SDRAM_STATE_WRITE_PROTECTED)) { return HAL_ERROR; } /* Write data to memory */ for(; BufferSize != 0; BufferSize--) { *(__IO uint8_t *)pSdramAddress = *pSrcBuffer; pSrcBuffer++; pSdramAddress++; } /* Process Unlocked */ __HAL_UNLOCK(hsdram); return HAL_OK; } Собственно так весь HAL написан. По моему комментировать не требуется.
  7. FreeRTOS и спецы ST

    Ну я имел ввиду, что проблема возникает, только если размер дыр, меньше чем размер запрашиваемых данных. Но поскольку, память выделяется и освобождается порциями, то увеличивая размер данной порции до уровня максимального запрашиваемого куска, можно принципиально устранить данную проблему, без сбора мусора. Со сбором мусора, похоже погорячился. В одной своей задаче, я решал такую проблему. Но здесь стороннее ПО. Переписывать его действительно будет и затратно и много ошибок привнесёшь. Плюс сложности с переходом на новые версии этого ПО. Отладка времени займёт. Короче, перспективы не очень радужны.
  8. stm32f767. MPU, DTCM, кэш и прочее...

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

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

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

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

    Это FreeRTOS с "обёрткой". Сейчас ST так делает. Скорее всего в последствии планируют переходить на CMSIS-RTOS. Я за CMSIS_RTOS не слежу, но как я понял, пока её ещё нет. Думаю авторы FreeRTOS над ней работают, или привлекаются. Будет под флагом CMSIS выходить. StartThread является задачей, а не функцией. И ей выделяется стек из кучи. При удалении, очевидно появляется дырка. Понятно стек выделяется куском, и, в принципе, он может быть использован. Спасибо. Понял.
  13. 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 запущу эти задачи?
  14. stm32f767. MPU, DTCM, кэш и прочее...

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

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