Шаманъ

Я вас немного дезинформировал про Vcom - померял у себя Vgh=16.49В, Vgl=-7.44В, Vcom=3.819В. Оптимальное значение Vcom зависит от Vgh/Vgl и от конкретной панели.

Геннадий приветствую. Такой формат не позволит использовать DMA2D в полную силу. Ну и внутренняя память намного быстрее SDRAM, особенно при random write/read Да, в реальности там 16.104МГц

#define TFT_HSW 40 //Horizontal Sync Width #define TFT_HBL 46 //Horizontal Blanking Width #define TFT_AW 800 //Active Area Width #define TFT_TW 863 //Total Width #define TFT_VSH 20 //Vertical Sync Width #define TFT_VBL 23 //Vertical Blanking Width #define TFT_AH 480 //Active Area Height #define TFT_TH 649 //Total Height Тайминги немного отличаются от общепринятых, но все в рамках допустимого (по датащиту). Сделано так, чтобы было больше времени между кадрами и меньше между строками (можно выиграть немного в производительности), но внешний вид не меняется если использовать стандартные 1056точек на горизонтальную линию и 525 строк на кадр. Два буфера - один показываете, во втором рисуете, когда нарисовали переключаете LTDC, чтобы он показывал второй (свеженарисованный), а рисуете теперь в первом (который не показывается), потом все повторяется. В некоторых очень специфических случаях может понадобиться третий буфер, но про это долго рассказывать, и обычно это не слишком актуально. Оптимальный Vcom у меня был помнится в районе 3.4В. Если интересно могу померять точно.

В реальности, когда я экспериментировал он работал нормально и на 15fps. Никаких бросающихся в глаза проблем не наблюдалось. Если сильно присматриваться, то на градиентах (а может и просто на определенных цветах) было заметно слабое мерцание, эффект минимизировался правильным выбором напряжения Vcom. Не, с этим было все ок. Даже если отключить LTDC, то он "белеет" до пропадания изображения в течении нескольких секунд, начиная с 20fps изображение невозможно отличить от 30 или более fps. Остановился на 29fps по одной причине - при более низком анимации в интерфейсе выглядели хуже. Нет, так будет тормозно - рисуется в одном буфере, показывается другой, потом буфера переключаются. Промежуточная буферизация иногда используется в анимациях и спец. эффектах. У меня в некоторых случаях накладывается очень много слоев (до 6 слоев) и некоторые части могут рисоваться не в основном потоке. Ваш вариант очень сильно просадит производительность.

Шумноваты они и ЧФД тормозной. Я как-то присматривался - для моего применения очень красивый вариант, но не с 8МГц макс. частотой ЧФД и -91дБн/Гц@10k ГУН...

Не надо ничего переделывать. Младшие выводы занулить и все. Ну потеряете какой-то мизерный процент от макс. яркости - не беда. Ну где-то так... В некоторых случаях и похуже может выйти :) Открою секрет AT070TN92 (или TN90, не помню точно) тоже умеет работать при 8МГц :) Может кому 1024х768, но L4 достаточно, а другому 320х240, но ARGB8888 и в два слоя :) ARGB8888 бывает очень полезен в DMA2D операциях в качестве промежуточного буфера. А вообще DMA2D весьма шустр - у меня успевает прорисовывать весь кадр (800х480хRGB565) с довольно сложной графикой за 10..15мс (при одновременной работе LTDC с частотой 29к/с). Самое интересное, что загрузка процессора при этом от 4 до 35% в зависимости от кадра.

Тут не подскажу, поскольку использую только то, что доступно (ADF4002, ADF4106). В принципе и они подходят, но как по мне, то шумноватые они, правда требования по этой части Вы не написали. Вот в плане цены/потребления с ними все хорошо :)

Главное, что меня поняли :)

Не хватает полосы памяти. Прикиньте сами - ARGB8888 это 132МБ/сек ИМХО, ничего Вы особенно не упускаете. Есть некоторые приемы работы с SDRAM, которые позволяют поднять производительность по максимуму, но в целом для таких разрешений полосы памяти недостаточно (плюс арбитр шины по всему не без проблем для такого применения). Могу посоветовать перейти на RGB565, тем более Ваш экран 24битный цвет скорее всего не поддерживает.

Тут было много примеров, где использовалась перманентная установка битов сброса и запись данных в биты установки. В таком варианте фактически получаем регистр ODR с маской или атомарный доступ к любой группе битов. Если ввести аппаратный тоггл, то эту полезность потеряем.

Да, если пакет помещается в одну операцию, то возможно, хотя и несколько "притянуто". В этом варианте аппаратный тоггл рулит.

Не, я не про то, подредактировал свой вопрос и уточнил про какой "порт" я говорил:

Умножаются на N.

Что у стм не знаю, извиняюсь, но не пользовался никогда. Проверка (если Вы про ? или if) не обязательна, я уже приводил пример: Если же Вы про чтение порта, то я уже писал, что это плюс для аппаратного тоггла. Пример несколько футуристический и вызывает много вопросов "зачем?", самый главный - зачем писать данные из двух потоков в один порт без синхронизации (порт в данном случае не GPIO порт, а Ваш "виртуальный" а-ля DDR канал)? Мне кажется такое построение это некоторая ошибка в построении всей архитектуры системы или "синтетический пример".

Это понятно, но я смотрю немного на более высокий уровень - какой смысл управлять одним и тем же пином из разных задач без какой-либо синхронизации? Как по мне, то никакого, а если делается синхронизация, то и проблемы нет. Вот когда речь идет про порт и управление разными пинами, то это очень реальный вариант, а с одним пином...

Атомарность внутри процессора. Для внешнего устройства по идее достаточно (скажем для битов 0 и 7): GPIOx->BSRR = (~GPIOx->IDR & 0x81) | 0x00810000; Ну и изначально должно быть правильное состояние битов (например, GPIOx->BSRR = 0x00800001). Этот пример мимо, ибо в данном случае идет речь о регистре BSRR и операциях с одним пином. Если изменение состояния пинов сделано через BSRR, то все будет прекрасно работать в двух потоках :) Проблема может быть только если оба потока пытаются управлять одним и тем же пином, но это без какой-либо синхронизации не правильно по своей сути.

Инвертирование за один такт пожалуй единственная реальная польза. Атомарность инвертированию одного пина не особо нужна, или у Вас есть пример, где она реально может понадобиться? Что-то я не совсем понимаю, а в чем проблема при наличии BSRR регистра проделать то же самое? Подготовили в памяти массив слов и шлем в BSRR, в конце блока прерывание. У того stmа, что сейчас лежит передо мной 8 UARTов, не уверен получится ли все их задействовать одновременно (в смысле распределения по ногам), но у меня не самый многоногий корпус ;)

Т.е. имея шум делителя на частоте 10МГц порядка -165дБн/Гц@10кГц я могу ожидать того же и от ФД? Интересно, получается ФД на 74LVC86 будет на 10..15дБ лучше по шумам, чем та же ADF4002?

А кто-нибудь случайно не встречал каких-нибудь замеров/исследований по шумам ФД на базе логического элемента XOR?

Господа, нужно просто делать внимательно RTFM. BSRR регистр имеет замечательное свойство: Поэтому задача решается очень просто без проверок: GPIOD->BSRR = GPIO_BSRR_BR9 | ((b & 0x80) << 2); GPIOB->BSRR = GPIO_BSRR_BR4 | ((b & 0x20) >> 1); Это свойство полезно и в других задачах, обсуждаемых на последней паре страниц :). Как по мне, то если переинициализация не производится в процессе работы, то логично собрать все в одном месте. Особенно по части GPIO.

Не могу таки понять в чем проблема - инициализация всего собирается в одном месте, там и макросы не нужны (для доступа к портам они тоже кстати не слишком нужны ;)). Обсуждается какой-то конь в вакууме. По поводу переносимости, это не проблема - инициализация правится отдельно, обращение к портам отдельно.

Умеет. Да и чего бы ему не иметь, если это одно из его обычных расширений https://gcc.gnu.org/onlinedocs/gcc/Binary-c...inary-constants . Кстати умеет в чистом С. Только не забудьте ему ключик указать, чтобы он расширения включил. P.S. Позабавили меня рассуждения последних нескольких страниц - столько внимания пину, можно подумать контроллер помощнее выбирался, чтобы ногами дрыгать через С++ классы :)

Спасибо за ссылку! Но хотелось бы найти те...

Я использую, но без куба. Помнится все заработало сразу так, как и описано в мануале.

Приветствую всех! А кто-нибудь случайно не встречал эти книги в PDF или другом "читабельном" формате: SPECTRAL AUDIO SIGNAL PROCESSING, JULIUS O. SMITH III https://ccrma.stanford.edu/~jos/sasp/ PHYSICAL AUDIO SIGNAL PROCESSING, JULIUS O. SMITH III https://ccrma.stanford.edu/~jos/pasp/ А то, в таком виде, как они выложены читать неудобно, гугль спросил без особого успеха.