[mantech 42]

1 час назад, __inline__ сказал:

И софтовые вэйты после каждого цикла чтения-записи.

Чет какая-то фигня вообще, это ж аппаратно должно быть или я что-то путаю?

 

1 час назад, __inline__ сказал:

Нужен дисплей 400x240 с RGB-интерфейсом

Таких не видал, были только 320х240. Стоял такой в КПК, даташит находил, помню... Единственное - разъем там был уг полное, шаг 0.4 да еще и 2х рядный шлейф в шахматном порядке...

Изменено 25 июня, 2020 пользователем mantech

[Arlleex 160]

10 минут назад, mantech сказал:

Таких не видал, были только 320х240...

На али найдется что угодно. С китайца ток стрясти распиновку надо будет.

[repstosw 17]

2 hours ago, mantech said:

Чет какая-то фигня вообще, это ж аппаратно должно быть или я что-то путаю?

 

Эта фигня была выдрана из сорцов линукса(работа с TCON в режиме I8080 CPU BUS).  Как я понял из сорцов,  в режиме 16 бит биты сильно перекручиваются (таблицу прикладывал в предыдущем посте в спойлере) и необходимо будет ручками корректировать.   Плюс к этому - опрашивать биты занятости по чтению и записи после каждого чтения-записи TCON.   Ни о каком DMA тут речи не может и быть, поэтому про быструю отрисовку через CPU i8080 BUS на оллвиннерах можно забыть!

 

На китайском форуме мне намекнули, что этоот режим они не используют, и он был сделан как запасной, на всякий случай.  Китайцы работают с дисплеями по RGB-интерфейсу.  Поэтому с маленькими матрицами облом выходит, так как большинство из них как правило подключаются по i8080 интерфейсу (или SPI).  Лишь только малая часть может работать в RGB, но это их не дефолтный режим, часто требуется перевод матрицы в RGB режим, через SPI или I2S.

 

Но есть и исключения из правил:

 

1)

 

1 hour ago, Arlleex said:

На али найдется что угодно. С китайца ток стрясти распиновку надо будет.

 

2) Дисплей от Sony PSP.   Чисто RGB, для игр, хорошие цвета и динамика. Как раз для игр.  Но 480x272, что чуть больше требуемых 400x240 (формат WQVGA).

 

За ссылку, Arlleex, спасибо!

Изменено 25 июня, 2020 пользователем repstosw

[mantech 42]

45 минут назад, __inline__ сказал:

2) Дисплей от Sony PSP.   Чисто RGB, для игр, хорошие цвета и динамика.

Кстати, да, вполне норм выбор, и разъем вроде лучше, чем у моего был, ну а эти 32 строки ну будут незадействованы, ничего страшного, можно фоном залить каким-нить , как бордюр у спектрума был

[repstosw 17]

18 minutes ago, mantech said:

Кстати, да, вполне норм выбор, и разъем вроде лучше, чем у моего был, ну а эти 32 строки ну будут незадействованы, ничего страшного, можно фоном залить каким-нить , как бордюр у спектрума был

Проанализировал оба дисплея что выше.

Время отклика 30..35 мс,  настораживает.  Ведь мазать будет при движении???

 

 

 

 

Тот что ниже - от Sony PSP.  Даташиты нашёл и скачал от обоих!

 

Кстати, у того который  400x240 - яркость, контрастность выше и с антибликовым покрытием.  По сравнению с PSP'шным.

 

Изменено 25 июня, 2020 пользователем repstosw

[repstosw 17]

11 hours ago, __inline__ said:

Время отклика 30..35 мс,  настораживает.  Ведь мазать будет при движении???

 

Будет однозначно! Не годятся.  1/35мс = 28 FPS всего.  При 60 будут дико шлейфить.

Более подробнее расписал тут, чтобы не оффтопить:

 

 

[GenaSPB 11]

Итак, вроде последние проблемы запуска (и запуска в моногядерном варианте) моего проекта преодолены.
Последняя вот такая:
С чего бы - без выделенной зеленым строчки - иногда мы тут попадаем во что-то вроде bus fault ? Отладчиком не полдсоединиться в таком состоянии.

 

Если дадите ссылку на работающую реализацию для Cortx-A7 будет здорово.
Привеленная в заголовке ссылка не совсем про него...
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0321a/BIHEJCHB.html

Изменено 10 сентября, 2020 пользователем GenaSPB

[GenaSPB 11]

Отвечу на заданый в другой теме вопрос:

Можно ли отлаживаться с STM32MP1 через SWD или нужен JTAG.

Через SWD можно, но есть отличия:
Для SWD пришлось указать точный Segger-овский тип процессора.
С JTAG удавалось абсолбтно нормально и через generic Cortex-A7.
К какому-то одному ядру прицеплялось...

Точный тип к регистрам периферии не имеет отношения, это обеспечиват файл STM32MP157x.svd

 

 

Изменено 12 ноября, 2020 пользователем GenaSPB

[GenaSPB 11]

bare-metal обслуживание USB HOST на EHCI начало подавать признаки жизни... В составе ST USB HOST Middleware.
Помогла дока от ColdFire с примерами дескрипторов для EHCI. И недавняя поездка к коллеге у которого есть LeCroy с блоком анализа USB сигналов. Дальше уже на более высоком уровне решать проблемы придется. А то в течении долгого времени получал после некоторых своих действий остановку передачи SOF пакетов. Сделал диагностическое USB device на это состояние и за день всё заработало.
Так что обслуживание USB FLASH в составе Аиста скоро уже...

Изменено 25 сентября, 2021 пользователем GenaSPB

[mantech 42]

10 часов назад, GenaSPB сказал:

bare-metal обслуживание USB HOST на EHCI начало подавать признаки жизни...

Для меня было настоящей проблемой запустить сам интерфейс (физику, плюс контроллер), дальше по работе с EHCI, его очередями и дескрипторами, искал в инете, там немало примеров по работе собственно с контроллером...

[GenaSPB 11]

Интерфейс используется на один канал OTH_HS - потому это оттестировать удалось ранее..

Я вот уткнулся в то что транзакция IN по не контрол EP не стартует... OUT нормально.
Енумерация по EP0 в лёт идет... Могу предоставить дамп - содержимое единственного элемента очереди асинхронных транзакций.

 

Изменено 26 сентября, 2021 пользователем GenaSPB

[GenaSPB 11]

Уточняю вопрос...

ПРоисходит вот что: посде енумерации и выбора конфигурации в USB FLASH накопитель через BULK OUT endpoint идет первый INQUIRY запрос... Судя по статусу успешно. Но последующее чтение из IN endpoint не дожидается ответа.
Вчитавшись в документацию, увидел рекомендацию HIGH SPEED OUT запросы предварять PING. Соответствующий флаг middleware даёт.
Вопрос - EHCI transfer descriptor имеет флаг включения PING протокола - иадо ли разбивать такой обмен на два transfer descriptor - один без данных и с флагом PING и  второй обычный OUT - или контроллер сам обрабатывает такое - и достаточно в OUT выставить соответствющий бит?
Старз скажу - мне не помог второй вариант получить ответ от USB FLASH...

Изменено 28 сентября, 2021 пользователем GenaSPB

[mantech 42]

15 часов назад, GenaSPB сказал:

EHCI transfer descriptor имеет флаг включения PING протокола - иадо ли разбивать такой обмен на два transfer descriptor - один без данных и с флагом PING и  второй обычный OUT - или контроллер сам обрабатывает такое - и достаточно в OUT выставить соответствющий бит?

Ммм, чет у меня на IMX все куда проще было, единственный прикол был в выборе EPIN и EPOUT, чтобы соотв. конфиг дескриптору, и все пожалуй... Все TD были по умолчанию.

На счет запросов SCSI, трабл был в их правильной последовательности.

[GenaSPB 11]

Разобрался... Надо не мешать самому EHCI toggle выполнять. В пределах каждого ендпоинта.
Последовательность обеспечивает ST Middleware.
Первая попытка - получилась скорость записи на флешку около 400 килобайт в секунду.
Осталось раз в дсять ускорить.

Изменено 1 октября, 2021 пользователем GenaSPB

[mantech 42]

3 часа назад, GenaSPB сказал:

Первая попытка - получилась скорость записи на флешку около 400 килобайт в секунду.

Какой размер блока? Я по 16к писал, скорость >10 Мбайт\сек на флешке 8и летней давности...

3 часа назад, GenaSPB сказал:

Осталось раз в дсять ускорить.

Ну в десять-то еще вполне возможно)))  Макс. на чтение 27Мбайт\сек, на запись будет меньше...

Важно еще сделать правильное "выгребание" полученных данных, по первости больше 5М на чтение не получалось, пришлось использовать переключение контекста и реорганизовать взаимодействие потоков данных в самой ОС.

Изменено 1 октября, 2021 пользователем mantech