repstosw

Говорите очевидные вещи. Вопрос: зачем? Речь о том, что я вообще передумал форм-фактор AA ставить.

У кого-нибудь есть опыт по использованию модулей на базе микросхемы IP5306 или её китайского клона MH-CD42? Это контроллер зарядки питания liIon + повышающий DC/DC до 5V. Обещают ток 2А. Но есть сомнения. На моём повербанке тоже написан ток отдачи - 1.5А, однако напряжение просаживается с 5V до 4.6V уже при токе 0.75A. Я считаю, раз пишут ток 1.5A, значит должна быть гарантия от производителя, что при таком токе ещё не будет ощутимой просадки напряжения питания (не более 1%). Вот и закрались у меня сомнения, сможет ли этот модуль(фоты ниже) дать хотя бы 4.95V при токе 0.75A ? P.S. Решил всё-же не использовать в проекте допотопные NiMeH аккумуляторы в форм-факторе AA. Потому что 4-5 таких батареек - сильно громоздко выходит.

связываться особо нет желания. Использование эклипса (впрочем, как и другие IDE) не освободит от раскуривания ключей компилятора/ассемблера/линковщика. Иначе, вот этих ошибок мы бы от вас не услышали: Затем, чтобы избежать проблем вроде ваших: Наличие лицензии на компилятор и полного конфига(оверлея) на HiFi4 DSP от T113-s3 не отменяет того факта, что придётся разбираться с этим ядром и понять что и по каким адресам памяти должно быть. Кроме того, вангую, что это всё завязано на FREERTOS, а это значит, чтобы использовать это на BareMetal, необходимо будет выкорчёвывать RTOS произвести рефакторинг кода и переделку стартапа. У меня эти шаги уже позади. Возможно, у меня тоже скоро появится лицензия на компилятор Cadence (XCC/Clang) и полноценный конфиг (оверлей). Будет интересно натравить эти компиляторы на мой SDK и сравнить скорости выполнения некоторых критичных фрагментов кода от выхлопов компиляторов: Free GCC XGCC Clang

Спасибо! Вот это я и хотел узнать. А как это визуально скрыть, я и сам знаю 🙂

А нужно свои либы писать. Или хотя-бы портировать чужое и осмысливать. Мой код под Xtensa компилируется обычным батником. Либы - тоже. Не испытываю таких трудностей. Выставляю режим - остановить компиляцию после первой ошибки. Описание ошибки + строка/столбец - достаточно, чтобы её устранить и перейти к следующему исправлению ошибки. На любой непонятный параметр есть RTFM на GCC тулчейн. Если они у меня стояли, значит в моих проектах они были нужны. У меня нет времени заниматься чисткой проектов для других. У вас, как я полагаю, тоже времени не вагон!

Вот именно по этой причине не использую в своих проектах всякие IDE, эклипсы и прочий хлам, снижающий прозрачность режимов построения проекта. Для простых проектов использую батники, для сложных - make-файлы. И каждый ключик компиляции и линковки ставлю осознанно, без лишнего. Для редактирования кода Notepad++.

так проблема возникает, если после выключения быстро включить. при этом программа пока не загружена (отладка через USB, программа в ОЗУ). вспыхивает предыдущий кадр, изъеденный мошками и плавно быстро гаснет. если после выключения выдержать 10 секунд, то такого нет. Reset дисплея притянул резистором к GND, чтобы при подаче питания LCD был в сбросе.

речь идёт о внезапном отключении питания, которое возникло не по вине пользователя. и о внезапной подаче питания. Не сильно хочется усложнять схему, если это не вредит дисплею

Возможны несколько опций: 1) Hardware Data Whitening (со стороны трансивера) 2) AES, SHA (со стороны T113-s3) 3) Псевдо-случайный интерливинг байт пакета Ну и плюс к тому же, видео передаётся не тупо JPEG'ами, а только полезная часть. хедер и таблицы Хаффмана - не передаются, они восстанавливаются в приёмнике (заранее просчитаны). Со звуком аналогично - передаётся только тело сжатия.

Использую LCD от Nokia E72, который как я понимаю, отностится к топовым TN. Заметил, что если выключить питание в момент работы этого дисплея, то на экране остаются артефакты которые быстро гаснут. При включении аналогично - появляются остатки изображения, которые потом стираются, и рисуется новая картинка программой. При включении, которое сразу же последовало после выключения - до 10 секунд. Насколько это опасно или вредно для дисплея? Могут ли выгорать со временем столбцы или колонны пикселей? Ведь импульсов напряжений на жидкий кристалл нет. Не всё ли плачевно? P.S. С OLED та же ситуация: там целые полоски светятся по несколько секунд очень ярко после выключения питания. Тоесть интересуют: 1) LCD TN 2) LCD IPS 3) OLED Вредность/опасность для каждого отдельно взятого случая..

Запустил второй SPI (SPI1), который на старших битах TCON LCD. Подключил к нему трансивер на базе Si4463. На SPI0 висит Flash. SD карта больше не нужна. И ножек хватает на всю периферию. Без аппаратных и программных уродств, что радует. Тестовый макет фулл-дуплексного видео-чата на 430 - 440 МГц:

Жуть какая. Есть же аппаратный JPEG декодер. Когда я делал кодирование H264 Full HD 1920x1080 на V3s, то у меня получилось 30 FPS. Причём легко! И это кодирование! И это H264. С JPEG декодированием должно быть ещё быстрее и проще! Есть же G2D. Операция Blt Rectangle. Можно заливать память этой командой. Установил прерывание, вызвал команду, и CPU пошёл другими делами заниматься. После прерывания, делаем новую команду G2D. Можно даже список задач организовать для G2D - в обработчике прерывания будут выполняться команды из списка параллельно на G2D, без загрузки CPU.

Актуально.

Актуально.

Добил TCON и E72 LCD. Сделал синхронизацию TCON с LCD RAM через Tearing Pin (VBlank). TCON здесь в режиме i8080, срабатывание по триггеру. Запуск происходит по возрастающему фронту внешнего прерывания с ножки LCD Tearing. Видеобуферы находятся в памяти Allwinner T113-s3. Доступно несколько слоёв, альфа-блендинг и преобразования CSC (YUV=>RGB). В обработчике прерывания происходит переключение видеобуфера: пока один показывается, во втором можно рисовать. 262K цветов (RGB 6:6:6). Алишные дисплеи с ардуин (OEM и ODM) здесь и рядом не валялись! 🤣

Для нано-поделий, использую дисплеи с разрешениями: 160x128 320x240 400x240 Больше для моих целей не нужно. Для тамагочи выше написал разрешения. Дисплеи разные нужны. Дисплеи разные важны!

Пыхтонрасты. Краем уха услышал, что новые камни Allwinner будут программироваться исключительно на языке Rust. Китайская инициатива. Так что есть вероятность, что C/C++ вскоре будет вытеснен из этой ниши. Ногодрыг очень медленный у AW. даже под голым железом. Искуственный интеллект, распознавание образов, работа с большими пластами данных: парсинг, сортировка... Всё это набирает обороты, чтобы установить тотальный контроль над каждым человеком, и не дать ему уйти в случае чего... Понимаете, куда всё идёт?

Реанимировал свой старый телефон Nokia E72-1, дисплей там как раз имеет хорошие углы обзора, картинка насыщенная. 320x240, 2.4" Landscape orientation. Лучше не придумаешь 🙂 Шина i8080, 8 бит. Есть ножка LCD_TE как раз для синхронизации. Попытаюсь его запустить на TCON T113-s3. Подключение, исходники: https://andybrown.me.uk/2013/05/29/nokia-e73-qvga-lcd/

На счёт кратности высоты 16. На всякий случай лучше проверить, что декодер не пишет в память за пределы буфера. Возможна порча памяти при декодировании, если проигнорировать требование кратности 16: декодер может записать недостающие строки ниже (за пределами выделенного буфера).

Освоил. Всё работает. Теперь кадр читается из видео-памяти автоматически без участия CPU. Кроме этого, доступны все навороты Display Engine: слои, альфа-блендинг и преобразование YUV в RGB. Из-за того, что дисплей от X503 не имеет ножки FMARK или VSYNC, не могу синхронизировать вывод кадра с TCON на дисплей. Поэтому вывод пикселей на дисплей идёт автоматически без синхронизации .

Завитки на денежных купюрах без лупы видите? Я вижу. ))) Сделал чтение ID чипа из регистра. Нужно было запретить вывод на линии D0..D23 перед чтением:

Уже запускал его: Он не IPS. Обычный TN. Но контраст хороший 400:1, достаточно яркий 350 кд/м^2. даже анти-бликовое покрытие есть (обнаружил не сразу - была наклеена защитная плёнка). Но не дотягивает до идеала углами обзора. Если смотреть сбоку, то цвета немного меняются и освещение падает. На Али есть модификации этого дисплея, и даже с пометкой "IPS". Но к сожалению, контакты на шлейфе урезаны - его в Serial RGB надо загонять через инит SPI. Оригинал LQ035NC111 можно использовать в Serial RGB специальными контактами на шлейфе. Да. Подтверждаю: особенно малый угол выходит снизу (если смотреть со стороны шлейфа). С IPS такого безобразия нет. Я бы его поставил в конструкцию, если не найду решения лучше. И 3,5 дюйма диагональ - многовато... Мне бы 2 - 2,4". Нано-девайс хочется Как Nano-Player, который сделал в 2019 г.

Хороший сайт! В своё время нашёл там IPS LCD 400x240 для консоли Cobura Portable на Parallel RGB interface. Но вот на разрешение 320x240 IPS с интерфейсом Serial RGB выдаёт около десятка результатов, и ни один не ищется на aliexpress ((( Поэтому - озадачился освоением TCON в режиме CPU IF i8080. Так как для маленьких разрешений подавляющее большинство дисплеев на i8080. И на телефонах типа Nokia E71/E72, Samsung S5230 - отличные IPS дисплеи, но все на i8080 :))) Когда делал H264 кодер для V3s, то попробовал убрать требование кратности 16 по высоте - заработало. 1080 не кратно 16 ))) Итак, я запустил TCON в режиме i8080 🙂 По крайней мере, инит контроллера дисплея(от телефона Philips Xenium X503) и картинка выводится. Пока в "ручном" режиме - запись данных через регистр. В перспективе - довести до ума: сделать чтобы кадр читался из видео-памяти и автоматически рисовался на дисплей. Что касается времянок(запись в регистры с помощью CPU i8080), то они завязаны на DCLK. И ничего менять нельзя: Исходя из описания: строб WR - проинвертированная копия DCLK. Остальные сигналы привязаны к нему. Тоесть, пространства для манёвра - нет. А строб RD всё время =1. Тоесть чтение запрещено. И это непонятно: как тогда делать чтение? Пробовал считать ID с регистра 0 дисплея - не возвращается код 0x9328, возвращается 0. Максимальная частота DCLK = 24 МГц. Выше, данный дисплей уже не работает. Далее надо освоить AUTO/FLUSH, чтобы заполнять картинки не через запись регистра, а автоматически с памяти. В спойлере рабочий код для дисплея X503 (контроллер ILI9328) через TCON CPU/i80 (не включая настройку TCON):

Проделал замеры, в ходе которых пришёл к выводу, что TCON пишет отдельным байтом. Он не производит аппаратного расщепления слова на байты шины. Выясняется элементарно: путём записи в регистр LCD_CPU_WR_REG значений: 0xFF, 0xFF00 и 0xFFFF. И вольтметром смотрим напряжения на ножках, в программе циклическая запись. Кроме того, обнаружен бит-свопинг на шине данных (что я собственно и предвидел): при записи и чтения команд/данных нужно учитывать положения бит. Тоесть чтобы послать байт на шину дисплея через TCON, нужно сделать следующие манипуляции над байтом: #define CONVERT(b) ((((b)&0x1F)<<3)|(((b)&0xE0)<<5)) Биты идут так: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 0 0 0 D7 D6 D5 0 0 D4 D3 D2 D1 D0 0 0 0 - биты байта в регистре LCD_CPU_WR_REG D7 D6 D5 D4 D3 D2 D1 D0 - биты байта на шине LCD_D12/LCD_D11/LCD_D10/LCD_D7/LCD_D6/LCD_D5/LCD_D4/LCD_D3 Хотя они могли этот свопинг делать аппаратно, с учётом битов 28...31 регистра LCD_CPU_IF_REG : 1110 - 8 bit 65K mode. При чтении из регистров биты нужно просвопать в обратном порядке. Кроме того, обнаружено следующее: CS,RD,WR вначале всегда =1, D0..D7 = 0, RS = 0. Никаких Z-состояний шины данных! RS - устанавливается только при начале цикла чтения/записи (запись в регистр LCD_CPU_WR_REG или чтение регистра LCD_CPU_RD0_REG) Это всё хорошо, но я не увидел где устанавливается ширина стробов чтения, записи. И прочие вещи, которые немаловажны.

Нужно размеры JPEG округлить в бОльшую сторону до 16. А на дисплей вывести через BitBlt G2D, вырезав ровно нужную область под дисплей. Пытаюсь запустить TCON в режиме IF CPU/i80. Чё-т пока не получается((( Дисплей рабочий - через ногодрыг работает, а через TCON не хочет. Осциллографа нет, времянки и сигналы посмотреть не могу. Пытался вольтметром определить уровни активного: делал цикл чтения и цикл записи. Определил, что линии должны быть проинвертированы: pdat.timing.h_sync_active = 1; //RD ---\___/--- pdat.timing.v_sync_active = 1; //CS ---\___/--- pdat.timing.den_active = 1; //RS pdat.timing.clk_active = 1; //WR ---\___/--- Мэпинг для 8-битной шины такой: IO0 VSYNC => CS (выбор устройства, активный 0) IO1 HSYNC => RD (строб чтения, активный 0) IO2 DCLK => WR (строб записи, активный 0) IO3 DE => RS (0 - индекс(команда), 1 - данные) D12 - R4,G2 - LCD D15 (в дисплее используются линии D15..D8 для шины 8 бит) D11 - R3,G1 - LCD D14 D10 - R2,G0 - LCD D13 D7 - R1,B4 - LCD D12 D6 - R0,B3 - LCD D11 D5 - G5,B2 - LCD D10 D4 - G4,B1 - LCD D9 D3 - G3,B0 - LCD D8 Проверил уровни в моменты чтения и записи вольтметром. Они соответствуют тем, что в программе. Цикл записи: void LCD_Index(u32 index) { LCD_Wait(); LCD_CPU_IF_REG&=~(1<<25); //CA=0 LCD_CPU_WR_REG=index; } Цикл чтения: void LCD_Data(u32 data) { LCD_Wait(); LCD_CPU_IF_REG|= (1<<25); //CA=1 LCD_CPU_WR_REG=data; } Запись в регистр: void LCD_IndexData(u32 index,u32 data) { LCD_Index(index); LCD_Data(data); } Всё остальное: #define LCD_CPU_IF_REG (*((IO u32*)(T113_TCONLCD_BASE+0x60))) #define LCD_CPU_WR_REG (*((IO u32*)(T113_TCONLCD_BASE+0x64))) void LCD_Wait(void) { while(LCD_CPU_IF_REG&(1<<23)); //WR wait while(LCD_CPU_IF_REG&(1<<22)); //RD wait } И ещё непонятно, этот TCON самостоятельно разруливает 16-битные записи на две 8-битные, или надо самому это делать? Ну тоесть чтобы отправить 16-битную команду через 8-битную шину: надо сначала отправить старший байт команды, потом младший байт команды. Затем отправить старший байт данных, потом младший байт данных. Тоесть - 4 записи. Столько же записей должно быть и через TCON? Или он сам разделяет одну 16-битную запись в две 8-битных? И вообще, учитывая бешеную популярность матриц на шине i8080 у китайцев, особенно на контроллерах ILI9325 и им подобных, неужели никто не озадачился как их подружить с Allwinner ? Может есть фрагменты кода в Линуксе, которые подскажут как работать с TCON в режиме CPU/i80 ? Второй немаловажный вопрос: как установить времянки через TCON в режиме CPU/i80 ? Ширина стробов чтения, записи. И прочие вещи. Вижу там только времянки развёртки дисплея через RGB-итерфейс.