mantech

Только в режиме регенерации из фреймбуфера там все равно прет на постоянку, как в LVDS Вот поэтому LVDS и лучше, он тоже скоростной и дифф-й но с одним маленьким отличием - не нужен инит дисплея, как собственно и драйвер)) Нужны только правильные тайминги.

Посмотрел ради интереса)) Делать надо, а мне просто удивительно, что чип с лучшими характеристиками, а простых и дешевых модулей нет, а на худший чип полно...

И как максимум тоже, т.к. больше я ничего не нашел)))

Вот и мне интересно, если этот чип так хорош, что ж на нем никто не делает ничего, кроме дорогущих фирменных плат...

Ну вот и делайте адаптивную передачу, при хорошем качестве 500кбит, при плохом 100. Получите увеличение дальности. Ну и сделать усилитель мощности миливатт на 500, еще в неск раз дальность увеличите, будет больше км... Ну 200баксов за радиоблок это по любому перебор. Можно ведь попробовать сделать отдельный высокочувствительный приемник и простой дешевый мощный передатчик на разных чипах...

Случайно выявил, т.к. на фон бекграунда, который jpeg нужно было наложить анимированную гифку у которой фон должен совпадать с фоном бекграунда, чтоб не было рамки, вот и сказал, что делайте фоны одинаковые по цвету, они сделали, но из-за декодера получился облом - фоны неодинаковые, причем программный декодер делает правильный фон, пришлось корректировать фон гифа, чтобы совпадал, это не катастрофа, конечно, но все-равно что-то не так видимо в параметрах декодера... ну тут да, разница приличная. Всегда делал paint.net-ом, вроде тоже без проблем было)))

Предполагаю, что для мелких дисплеев от телефонов. Хотя согласен - это трэш, стараюсь по возможности в него не вляпываться)))

Может прост о печатку делали неумехи и на на этом все портится, сомневаюсь что силабсы сделали такой говняный чип, если есть другие модули на таком чипе, может стоит их попробовать? ИМХО. А вот это как раз не удивляет, барыги зажрались настолько, что уже сотни процентов накручивают, плюс еще гос-во наше им помогает в этом "импортозамещении", я уже приводил тут пример одной процессорной платки, которая на али 3т стоит, а "наша" в 5-6 раз дороже. Не поощряйте барыг, от них никакой пользы экономике... ЗЫ. На досуге не гляните вот на это, может какие идеи появятся? Нашел проблему в аппаратном jpeg-декодере Т113 го, при декодировании файла основной фон которого 0xff191919 аппаратный декодер выдает 0xff0a0a0a, программный (чановский) выдает корректное значение.

А что там такого предпродажного-то особенного? Если станция работает, то и так все предельно понятно, это ж не какой-то навороченный PnP робот, где только с одним ПО зачухаешься... Разве, что с гарантией какие-то вопросы у официалов решать проще.

Это уже само по себе жуть...

1 895 669.75 Р Вот это цены))) Интересно китайские аналоги почем?))

КПД 96.5 % Вот это немного удивило...

Проверил - не влияет на 1366х768 и 1920х1080 результат одинаковый. Предположу, что там есть какой-то параметр коррекции или что-то подобное, но х.з. какой..

Конечно.

декодер jpeg-а у них находится в блоке mpeg

Video Engine Registers MPEG Engine Registers https://linux-sunxi.org/VE_Register_guide#MPEG_Engine_Registers

Тогда тут ничего не поделаешь. Заметил, что разница нелинейна, т.е. на цвете 0x191919 она 0xf А на 0x252525 уже 0xE... Если цвет оригинала 0x0a0a0a то декодер выдает вообще нулевой цвет... Единственное не проверил пока влияет-ли разрешение картинки на декодирование...

Не понял причем тут периферия, тут декодер и фреймбуфер. Если у вас есть в проге декодер, можете попробовать подкинуть мою картинку и посмотрите, что получилось...

В смысле где? Беру приложенный файл, декодирую аппаратным декодером и получаю в буфере результата такую шляпу, меняю декодер на программный при тех же вводных и получаю норм. Обратил внимание, т.к. пришлось накладывать фон бэкграунда с жпегом с картинкой анимированного гифа, в редакторе фоны одинаковые а на экране есть различие вот и решил посмотреть в чем дело...

Не похоже, исходный файл 24 бит цвет

Нашел проблему в аппаратном jpeg-декодере Т113 го, при декодировании файла основной фон которого 0xff191919 аппаратный декодер выдает 0xff0a0a0a, программный (чановский) выдает корректное значение. Есть идеи?

На драгметаллы что-ли?)))

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

Корпус паябельный, ДДР можно не подключать и использовать как обычный МК с прогой из внешней spi-флешки. Минусы - прога макс 32кБ, ОЗУ 20кБ на сколь помню, питание нужно 1.2В ядро и 3.3В периферия, в принципе, как у СТМ. Периферия у него не богата, есть неск. таймеров, uart, spi и еще чет по мелочи)) Но за-то быстродействие будь здоров))) Хотя сейчас при наличии дешевых v3s и Т113-s3 - это уже прошлый век, конечно...

С первых лет программирования всегда любил, чтобы память была по возможности статически распределена и по конкретным адресам, т.к. часто бывает нужно определенное выравнивание, и не только на 4, 16, бывает и на неск.килобайт, когда все адреса в одном дефайне то я сразу вижу где и что, там же заданы и предельные размеры областей, что тоже сразу выучил, что при любой записи блоков памяти нужно проверять на переполнение. Единственный минус, это при переходе на другой МК приходится эту таблицу пересмотреть и переписать, что изменилось, но это дело 10 минут, и никакие линкеры и пр трогать не надо, а то в иаре они одни, гцц другие, у аврок всяких третьи... Понимаю, что на вкус и цвет, но мне вот так больше нравится...