Перейти к содержанию

    

AlanDrakes

Участник
  • Публикаций

    108
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о AlanDrakes

  • Звание
    Частый гость
  • День рождения 31.01.1988

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Россия, Омск
  1. STM32H7 работа с SDRAM. Проблема

    При использовании SPI интерфейса, чтение пиксельных данных из экрана невозможно. У меня экран висит на 8-ми битной шине FMC контроллера. LTDC не задействовал - у него хоть и имеются интересные возможности, но нельзя использовать запакованые пиксели формата L4. Таких помещается два в одном байте - экономия памяти, которая потребуется в других задачах. Дисплей обладает своей памятью и её даже можно читать, но скорость этого чтения... во всяком случае, в попадавшихся мне экземплярах экранов, значительно ниже скорости записи, и для чтения пикселя приходилось играть с таймингами. Например, на 8-ми битной шине, при частоте ядра контроллера в 100МГц (уточню, что использую STM32F745, а эта частота выбрана как удобная для расчётов), можно получить около 30 заполнений экрана в секунду. Именно заполнений - полноценных выводов нового кадра из памяти в экран. При бОльших частотах, естественно, можно и быстрее отрисовывать, но скорее всего сам контроллер экрана не сможет. Считывания упирались в какие-то внутренние тайминги экрана, и сильно портили картину. Чтение проихсодит, да, но как-то не всегда стабильно, и крайне медленно (1-2 секунды на чтение экрана - это просто что-то в чём-то). Ответил выше, но всё же. FMC позволяет использовать пин RS (выполняет роль D/C) напрямую записывая данные в разные адреса памяти. Например, запись массива пикселей в адреса 0xC0040000...0xC007FFFF приводит к поднятию пина A18 (RS) в 1 и воспринимается контроллером дисплея как поток данных. Запись же в адреса 0xC0000000...0xC003FFFF - опускает пин в 0 и дисплей воспринимает значения как команды. Выглядит сие безумие примерно так: if ((DMA2D->CR & DMA2D_CR_START) == 0) { LCD_SetBounds(0, 0, 319, 239); // Set full screen bounds. DMA2D->CR = 0x00010000; // Mem to Mem with PFC DMA2D->FGMAR = (uint32_t)&(ScreenBuffer[0]); // Frame memory (indexed) DMA2D->OMAR = (0xC0040000); // LCD address DMA2D->FGOR = 0; // Memory Offset DMA2D->OOR = 0; // LCD Offset DMA2D->FGPFCCR = 8; // From L4 DMA2D->OPFCCR = 2; // To RGB565 DMA2D->NLR = (240 << 16) | 320; // Number of lines and rows DMA2D->CR |= DMA2D_CR_START; // Start transmission }; Буфер выдаётся на максимально доступной скорости с помощью встроеного DMA из DMA2D "ускорителя" (от ускорителя там только DMA и преобразование). Мне приходится использовать исключительно внутреннюю память. Из 100 пинов заняты более 90, так что особо не разгуляться. В моём случае проблемы могут быть при одновременном доступе от ядра и DMA2D. Но на практике незаметно. Смотрю я на H743/753 чипы референс в области памяти... и тихонько так выпадаю в осадок. Есть у меня подозрение, что в Вашем случае может оказаться быстрее из внешней памяти. Знаете... Попробуйте оба варианта - буфер в памяти и буфер во внешней памяти. Напишите бенчмарк (я именно так и делал несколько раз ради смеха и попугаев).
  2. Можно ли "убить" STM32 прошивкой?

    Нет. RAM это 0x20000000 А вот 0x00200000 - это обычно флеш (отражёный на нулевые адреса). Но всё же чаще пишут в 0x08000000. Может таки в этом дело?
  3. STM32H7 работа с SDRAM. Проблема

    Помнится, мучался со считыванием пикселей на F7 из LCD на ILI9431 и им подобных. Там ТАКИЕ тормоза требуются для процесса считывания, что скорость шины становится просто смешной. В итоге, плюнул на это неблагодарное дело и подключил LCD так: FrameBuffer -> CromeART -> FMC -> LCD Данные пишутся в экранный буфер (Использую 16 цветов в режиме L4), на дисплей при обновлении кадра автоматически конвертируется в RGB-565 посредством DMA2D (CromeART), затем через FMC пишется на скорости интерфейса прямо в дисплей (но дисплей получает команды X=>0, Y=>0, RamWrite (0x22), а затем поток данных, и так каждый кадр). Из минусов - имею частые обращения к памяти от DMA (должно сказаться на скорости, но пока проект отложен - не могу сказать точных цифр) и собственно, выделение памяти (в моём случае это 320*240/2 = 38400 байт) и динамическое выделение данных под скриншот (дёргаю из кучи, затем освобождаю по готовности). Запись на карту памяти из буфера - в разы быстрее чем из экрана, а так же свободна от артефактов считывания пикселей.
  4. Default Handler вызывается в том случае, когда произошло прерывание, не описаное в коде (имеющее вектор в таблице, но не получившее обработчика). Рекомендую добавить в код строки: void HardFault_Handler(void) { while(1) {} };
  5. stm32f407 SPI обнаружил косяк

    Такое поведение я бы понял при наличии буферов FIFO на кристалле (в частности, для STM32F745 / F3xx / F030 такое поведение нормально. Данные загружаются в регистр данных, но попадают в FIFO буфер, в очередь передачи (размер - 32 бита), и фактически буфер передачи в этот момент становится пуст. Но в указаном Вами кристалле, FIFO не описан, значит его и быть не должно. Если есть логический анализатор - можете попробовать выводить отладку на пины. Сверьтесь с графиком 248 (параграф 25.3.9) по передачи данных со стороны ведомого контроллера. Естественно, внутренние сигналы придётся выводить во вне во время прерываний. И помните, что последние будут отставать от фактического события. Но можно сильно увеличить делитель частоты для SPI, чтобы минимизировать отставание.
  6. Как-то у меня с аналогичным дымом сгорел STM32F103. Просто очень неудачно упал силовой провод (+12V) на тестовую плату. Естественно, щёлк, вспышка, снесло крышу одному сдвиговому регистру, контроллер задымил. Самое странное при этом, что он продолжал работать. Естественно, минус несколько IO портов, но в консоль он продолжал слать отчёты о загрузке системы, видимости части переферии (вокруг него) и даже мог связаться с соседним контроллером по внешней шине. Ток потребления, конечно, ушёл куда-то за 100мА. Но через минуту и это перестало работать. Да, пробой по кремнию прямо внутри кристалла это очень печальная штука. :(
  7. +1 Бэкапы-то сделали? А вообще, какой же он стал страшный :( Шрифты - ладно, читаемы. Переносы в блоке профиля пользователя - позабавили (слово "Микроконтроллеры" слегка порвалось, но это так, менлочи на самом деле). Половина заголовков на русском, половина - на английском. Постоянно запрашивает какие-то разрешения для сайта. Зачем? Раньше такого не было и было нормально (лично мне). И, да. Здравствуй, гигантизм кнопок :(
  8. stm32f4 + Chan's FatFS

    Пилил я как-то свой тест скорости карточек. Не оптимальный до ужаса. Тем не менее, результат был таким: File created. Write test... [0000000030.080] File write done. Total bytes written: 5242880 bytes. Time: 27684 ms. Avg: ~189 kBps Read test... [0000000036.114] File read done. Total bytes read: 5242880 bytes. Time: 6033 ms. Avg: ~869 kBps Здесь кристалл работал на ~96МГц, возможно, меньше. SDIO тактировалось от PLL на 48МГц. Если тактирование SDIO было быстрее тактирования ядра - работать с картой памяти было невозможно. Были у меня ещё какие-то весёлые проблемы с записью больших блоков через FatFS, хотя библиотека собиралась с неправильными параметрами, и объём памяти под неё старательно ужимался. В итоге, при записи огромных буферов из памяти (как раз размером в несколько секторов) получал странные зависания в случайных местах. В причинах не разобрался, добавив костыль, заставив код писать мелкими блоками.
  9. stm32f4 + Chan's FatFS

    Помнится мне, что вся работа с секторами происходит в файле ff.c, а работа с низкоуровнемыми командами записи - в diskio.c, где уже Вы, по желанию, можете делать запись мультисекторно, или посекторно. При наличии больших буферов ФС - драйвер технически может вызывать функцию disk_write с параметром "Количество секторов", отличным от единицы. Фактически, единственный такой вызов я нашёл в функции f_write() в том случае, если ЕСТЬ свободные сектора, куда это поместится, и размер данных больше чем на один сектор. Так что, весь разбор что и куда писать, находится выше. Драйверу же карты передаются только команды "Пиши вот это, вот сюда, в таком-то количестве".
  10. stm32f4 + Chan's FatFS

    Гарантия есть. Она в самой команде CMD25, которая пишет сектора последовательно, не получая номеров в процессе выполнения. Для её окончания даже есть команда CMD12 - STOP_TRANSMISSION. Документ SD Phisical Layer Specification так же говорит: CMD25: [Address (PTP) data transfer command] Args: [31..0] - Data Address Continuously writes blocks of data until a STOP_TRANSMISSION follows. Block length is specified the same as WRITE_BLOCK command. Переводим. "Последовательно пишет блоки данных до получения команды STOP_TRANSMISSION. Длина блока определяется аналогично команде CMD24 - WRITE_BLOCK" Для карт высокой ёмкости длина блока ВСЕГДА равна 512 (размеру сектора). Для карт обычной ёмкости её можно задавать командой CMD16 - SET_BLOCK_LEN
  11. stm32l

    На всех платах STM32* установлен ST-Link V2, которым можно программировать и отлаживать ЛЮБЫЕ кристаллы STM32. Используйте выведеный на отладчике 6-ти пиновый разъём для подключения к другому контроллеру.
  12. 2 stm32 на одну шину fmc

    Судя по рабочим диаграммам в мануалах, сигнал WAIT принимается контроллером в расчёт уже ПОСЛЕ начала обращения к микросхеме памяти. Считается, что микросхема ВСЕГДА готова к обращению после завершения предыдущей операции. По поводу же арбитража - лично я бы предложил использовать бит выбора чипа памяти в качестве сигнала арбитража шины. К сожалению, ведомый контроллер сможет узнать о том, что шина недоступна только косвенно, например, дополнительно перечитав этот самый сигнал. Никакого DMA в этом случае не будет и в помине. Обращение - только атомарное, с логикой контроля ошибки и отказа арбитража. Я бы предположил в этом случае использовать аппаратную логику типа триггера, указывающего, было ли обращение к микросхеме памяти от мастера во время обращения ведомого, или что-то похожее. Либо попробовал поискать двухканальную память, умеющую работать на два устройства паралельно.
  13. У Вас есть кристалл с уникальным ID, прошитым на производстве. Напишите что-то совместимое с CAN шиной, что будет использовать какой-нибудь специфический канал для настройки именно ведомых. Допустим, при запуске все кристаллы одновременно ломятся в шину с сообщением и посылают свой номер в какое-то поле. Происходит коллизия. Коллизия решается, выигравший забирает первый диапазон адресов. Повторить до окончания коллизий. Допустим, адреса 0x00 ~ 0xFF, каналы по 16 адресов (0x10) Посылка -> Коллизия -> Разрешение -> Выигравший забирает адреса 0x00 ~ 0x0F и замолкает. Посылка -> Коллизия -> Разрешение -> Второй выигравший забирает 0x10 ~ 0x1F и тоже замолкает. И так далее. UPD: Я тут подумал. Эту же процедуру можно проводить только в случае возникновения коллизии при ответе контроллера. То есть, сеть может организовываться полностью сама. Разве что мастер не будет знать кто где. Настройка можно хранить в выделеной странице (двух) Flash-памяти, либо на врешней EEPROM микросхеме, а перенастраиваться только при обнаружении ошибки. Я сейчас мыслю, абстрагировавшись от работы шины данных. Есть знатоки работы CAN протокола? Как можно реализовать подобное, используя стандартные методы? Хотя, в моём случае, при построении сети, работа ведётся исключительно между мастером и ведомыми. И он же выдаёт им сетевые адреса. Да, слизано с больших сетей с DHCP сервером. При этом работает по двухпроводной схеме (нет, не RS-485).
  14. SMI протокол

    Поддерживаю вариант с ногодрыгом. Интерфейс хоть и имеет близкого родича - SPI, но момент переключения данных - середина тактового импульса, плюс двунаправленность шины... в общем, когда экспериментировал - написал ногодрыг для AVR кристалла (что было под рукой) и он даже корректно заработал. Во всяком случае, отклики на команды приходили без ошибок. Удалось даже настроить подключеную физику в режим петли... и получить ругань от коммутатора, в который это всё было включено, и блокировку порта. На STM32 изначально имеется возможность подключения к интерфейсу, при наличии Ethernet модуля на борту.
  15. STM32F4. Пишем свой загрузчик.

    [zanuda mode ON] Были варианты двустороннего обмена данными с контроллером (при прошивке) с использованием шифрования и ключём на основе UID чипа. Фактически, прошивка даже клиенту попадает в шифрованом виде. Были варианты обновления прошивки по воздуху (по сети), так же, без использования прошивки в чистом виде. Аналогично, шифрованая по сети. В чём отличие именно этого загрузчика от других? [zanuda mode OFF] Точно так же, можно привязать саму прошивку к UID чипа. Таким образом, её можно сделать бесполезной для всех остальных пользователей. Дело только в сложности алгоритма и проверках.