Jump to content

    

SapegoAL

Свой
  • Content Count

    2754
  • Joined

  • Last visited

Community Reputation

0 Обычный

About SapegoAL

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

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

6972 profile views
  1. А я согласен с Jcxz. Всё прозаично, на самом деле: По крайней мере HAL и тп - это драйвера. Причём написанные универсально. Собственно к ним нет претензий.. Но, как правило в текущем проекте требуется не универсальность, а конкретика. Иными словами либо приходится править сам HAL (что явно не лучший вариант), либо писать промежуточный слой - переходной от фирменного к своей задаче. При этом надо ознакомится с построением их библиотек, принципами их организации, подходами и т.д. И тут я ещё раз хочу подчеркнуть мысль Jcxz. Как правило, драйвера, составляют от 1 до 10% объёма от реального проекта. Пишутся и вылизываются довольно быстро. Поэтому преимуществ их использования я не вижу. Вот Вы уже поработали с AVR и теперь на STM перешли. Где гарантия что завтра MSP не будет? Или NXP? Но в целом, я претензий к ST не вижу. Порой можно "подсмотреть" их библиотеку. Порой можно воспользоваться их плюшками (например CubeMX). Короче ребятам респект.
  2. Дискавери просто использует половину микрухи ОЗУ. Зачем так? Кто его знает. Может просто постоянно применяют 32 бита, а 16 бит уже не применяют (нет в применяемости). А при разводке легче было развести 16 бит. Если вы развели всё правильно, то вам просто нужно, там где инициализация контроллера внешней памяти сделать следующее: 1) Проинициализировать верхние пины шины данных (Посмотрите даташит на кристал а не семейство, чтобы правильно альтернативную функцию пина узнать). 2) Правильно указать размерность шины данных при инициализации контроллера данных и количество банков. Ну и дальше осциллограф поможет. ))
  3. С чего бы это? RGB есть во всех stm имеющих LTDC модуль. Это и 32F4, F7, H7 и даже MP1. В последнем разрешение чуть побольше, хотя и не критично. Жаль конечно что LVDS нет. Но вполне себе есть микрухи от TI которые преобразуют из RGB в LVDS. Сам не пробовал, но китайцы предлагают...
  4. STM32CubeIDE

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

    Работаю с процессорами ST. Начинал со 103. Серийно использую 407, 051, 031, 030. Из старых используются 103, 105, 107. На 051, 031 наблюдал случаи некорректного программирования из под Demonstrator GUI. Разбираться не стал. Мелкие процы отлаживаю под SWD. Не было ни одного случая, ни на одном проце, чтобы проц стопорнулся из под JTAG или из под SWD. Ну и я не верю, что вы смогли угробить проц без прямой подачи запредельных напряжений. Думаю, что проц был жив. И следующий раз за паяльник надо браться в последнюю очередь. Я уже писал, что в одном проекте схемотехники ошиблись и подали на несколько ножек 12В ч/з резисторы. Я успел полностью отладить проект, пока сдох процессор. Примерно неделю он пыхтел.
  7. Я делаю следующим образом. В процессе работы пишу образ во флэху. Зашифрованный файл прошивки. Запись производится без остановки работы устройства. Конечным шагом записывается общая контрольная сумма всей прошивки. После рестарта, загрузчик проверяет наличие этой контрольной суммы. Это является признаком, что требуется обновление прошивки. Если КС есть, то выполняется обновление прошивки. После обновления, загрузчиком контролируется целостность прошивки и стирается КС. Осуществляется старт приложения.
  8. /** * @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 написан. По моему комментировать не требуется.
  9. Ну я имел ввиду, что проблема возникает, только если размер дыр, меньше чем размер запрашиваемых данных. Но поскольку, память выделяется и освобождается порциями, то увеличивая размер данной порции до уровня максимального запрашиваемого куска, можно принципиально устранить данную проблему, без сбора мусора. Со сбором мусора, похоже погорячился. В одной своей задаче, я решал такую проблему. Но здесь стороннее ПО. Переписывать его действительно будет и затратно и много ошибок привнесёшь. Плюс сложности с переходом на новые версии этого ПО. Отладка времени займёт. Короче, перспективы не очень радужны.
  10. Спрошу здесь, чтобы темы не плодить. Просматривал HAL библиотеки работы с внешней SDRAM. Они ставят программную блокировку от доступа. Не совсем понятно... Ну, допустим, они хотят разрулить, попытку из разных задач одновременного доступа по одному и тому же каналу DMA. Ну или доступ и конфигурирование контроллера. Но они блокируют и доступ самому CPU. Это зачем? Я что не могу прочитать произвольные данные, пока у меня идёт DMA операция? Зачем вообще делать процедуру доступа к внешней ОЗУ? Насколько я понимаю, она в общем адресном пространстве. Ну я не знаю. Может они на воду дуют или от дурака пытаются защититься? Обычно инициализация делается до запуска ОС, а доступ разруливается правильным построением задач. Если это невозможно, то устанавливаются семафоры. Или я что-то упускаю?
  11. Ну по-моему это очевидно. Работа с динамической памятью сложнее и объёмнее. Загрузка проца, непроизводительной работой выше. Приходится непрерывно работать с косвенной адресацией. Требуется обеспечить корректную работу в многозадачных системах при выделении/ удалении. Если в этом нет необходимости, то зачем притягивать за уши? Если при статическом распределении у Вас хватает памяти, то это самый лучший выход.
  12. Там несколько зон есть. Причём можно с перекрытием работать. Лучше документ почитать
  13. Ну у меня динамически выделяется. Прибор коммерческого учёта. Работает годами. Ничего не перезагружается. Правда у меня, после старта, только LwIP динамически с памятью работает. Я не делал удаление/ запуск задач "на лету". Да, если какая то задача запрашивает размер памяти, который отсутствует в системе одним куском, то крах произойдёт. Но тут у Вас 2 выхода. Либо размер кластера увеличить. Либо запускать дефрагментацию периодически. Дефрагментация - решаемая задача.
  14. Это FreeRTOS с "обёрткой". Сейчас ST так делает. Скорее всего в последствии планируют переходить на CMSIS-RTOS. Я за CMSIS_RTOS не слежу, но как я понял, пока её ещё нет. Думаю авторы FreeRTOS над ней работают, или привлекаются. Будет под флагом CMSIS выходить. StartThread является задачей, а не функцией. И ей выделяется стек из кучи. При удалении, очевидно появляется дырка. Понятно стек выделяется куском, и, в принципе, он может быть использован. Спасибо. Понял.
  15. Ребята, прошу разъяснения. При просмотре примеров, которые создают ребята из 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 запущу эти задачи?