Jump to content

    

SapegoAL

Свой
  • Content Count

    2754
  • Joined

  • Last visited

Everything posted by SapegoAL


  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 запущу эти задачи?
  16. Если честно, то и не подумал об этом. Собственно всё правильно. Проц туда только пишет, и радости от кэша будет немного. Спасибо.
  17. Да я и не собираюсь рекорды ставить. Думал немного разгрузить шину. Просто видеоозу, естественно, во внешней микрухе расположено. Понятно, что обращение к ней будет медленное. Ясно, что проц значительную часть своего процессорного времени будет на гуёвину тратить. При этом в видеопамять писать и простаивать. И из-за работы LTDC и из-за дополнительных тактов ожидания. Если кэш и нужен, то как раз при обращении к внешней ОЗУ. А если сквозную запись включить? Или пойдут косяки и я впустую потрачу кучу времени? У меня такое ощущение, что мне что-то недоговаривают. )) Скрывают правду от меня. )) Не может быть, чтобы никто с этим не возился. На мой взгляд выглядит примерно так: 1. LTDC работает только на чтение и данные берёт прямо с памяти. 2. Когда я отрисовываю какой-то виджет, то я делаю flush\invalidate по завершению. 3. Аналогичная картина когда я отрисовываю виджет с использованием DMA2D. Если что-то будет в процессе не одновременно отображаться, это не критично, как при работе с ethernet, хотя может резать глаз. И по факту придётся от этого отказаться.
  18. Всем спасибо за ответы. Про DTCM понял. А что по видеоОЗУ? Там же тоже и LTDC и DMA2D? Хотя по сути LTDC только читает, а по DMA2D после записи можно делать очистку кэша. Или я что-то не так понимаю?
  19. Начинаю проект на 767 камне. Образец будет только через месяца 1.5 - 2. Не работал ни с MPU ни с кэш. Почитал - вроде бы всё понятно. Загрузил cube - смотрю пример. Есть вопросы. В примере st буфера ETH размещают по фиксированному адресу, расположенному в конце ОЗУ. И отключают кэш на этот регион. Хотелось бы услышать тех кто с этим разбирался. А может целесообразнее буфера в DTCM разместить? Вроде бы как работать будет побыстрее. DMA функционирует. Или я чего-то не учитываю? Кто как делал? Можно, наверное и драйвер ETH поправить, на предмет синхронизации работы с памятью. Вроде бы как там не очень много должно быть. Думаю, они этого не сделали, чтобы драйвер был независимым от камня. Конечно тестировать много. Наверное проще пойти по их пути... )) Какие соображения по этому вопросу?
  20. Походу, тому программисту, который после вас будет работать придётся ещё сложнее ...
  21. Практически один в один. )) У меня 2 проги. Одна для программирования на предприятии. Там сразу запрашивается серийный номер. Заливается загрузчик вместе с приложением. Вторая для обновления прошивки. При обновлении прошивки, серийный номер устройства не меняется.
  22. Думаю никуда они не замахивались. Крупному клиенту ST понадобился такой камень под конкретную задачу. Был реализован ST и появился в общем доступе - типа, авось кому-нибудь ещё приглянётся... С другой стороны, сам камень H7 весьма недёшев пока... При том, что я планировал его применять - переиграл на F7. Именно из-за цены. Если цена на этот камень будет сопоставима с H7 (максимум +5%), а всё семейство подешевеет слегка, то применять будут.
  23. Да и такие, двухядерные, скорее не для уменьшения потребления, а для разделения.... М7 основное приложение например гуёвина и прочее, а М4 обслуживание периферии. Например ethernet, USB, SD, UART-ы, SPI там всякие... М0 для ethernet слабоват будет. ))
  24. Что за процессор? Что за память? Что за флэш? Тайминги проверили? Где у Вас "сыплется"? Ну, смотрите. Я так понимаю, что у Вас LTDC работает с RGB. Соответственно LTDC отображает оперативную память на экран только и всего. По сути LTDC закрытый специализированный встроенный DMA2D. Таким образом для начала Вам надо разобраться на каком этапе у Вас разрушаются данные. Для этого, для начала я бы попробовал копировать в чистое озу (а не в видео область). Потом попробовал бы в видеообласть копировать из другого места. Ну чтобы выяснить где проблема. Попытался бы выяснить при обращении к какому устройству (адресу) происходит Hard Fault. Ну а дальше начал разбираться непосредственно со сбоящим устройством. Если это ОЗУ, то проверил бы тайминги. Если флэш, посмотрел бы настройки. Аппаратно бы глянул. В общем, пока картина не ясна. Я с qspi пока не работал. И mapped-memory не использовал. Сейчас делаю модулёк на базе процессора stm32f767. Но он ещё в процессе разводки. Изготовление макета думаю будет только к концу лета. Работой завален, поэтому пока некогда этим заниматься.