)) Анекдот вспомнил. Ковычки добавил чтоб понятней было.
- Привет. Как дела?
- "+"
- Ты на пары идёшь?
- "-"
- Бл_дь, ты что, с калькулятора пишешь?
:)))))))))
Я многого просто не пишу. Некоторые вещи вроде как само собой разумеющиеся, но не во всём можно быть уверенном на 100%. В одном из минипроэктов есть переменная, меняться значение которой может только i++, или i--, т.е. не больше чем на еденицу. А по факту - уменьшается до (кажется ) 435 и опять 465 и наоборот. Весть исходник поиском перекопал, ну нет больше с этой переменной никаких операций. Это всё в версии 1.0.5.
А если загрузить в версии 1.6.х. Как в исходнике так и работает, но не все библиотеки загружаются. Так в EEPROM записываю нужное мне значение с версией 1.6.х, а потом перезагружаю с версии 1.0.5. Чё как вобще не понятно, но работает и только так. Я к чему - i++ Это i = i+1, уверены на 100%? А я нет. ИМХО
Из представленного мной фрагмента кода (вроде как) явно видно что на пиксель приходится (ну или как правильней) 2 байта в файле RAW и именно по этому буфер, изначальный гемор, в два раза больше ширены картинки по размеру. Это тоже само собо разумеется.
Естесссно я копался в исходниках и поэтому и утверждаю, что функция чтения в буфер и чтения байта, немного (мягко говоря) отличаются.
Да и собственно почему у меня особого интереса нет от буфера избавляться - время. Время вывода увеличивается больше чем в 6 раз. Не думаю что это понравится кому то. Гораздо быстрей выводить из двух частей если сильно широкое изображение. Я оптимизировал до вывода из трёх полной ширины экрана. Этоже и рекомендую.
Тут ещё попутно интересный момент появился. Хотел перенести проект на Mega2560, но оказалось что на этом контроллере вывод всего( и из flash, и из SD) по времени примерно вдвое дольше чем на UNO. На аппаратном SPI SD карта там она и осталась. Другой разници не нашёл. Парни, подскажите если знаете, почему так?
Тут ещё попутно интересный момент появился. Хотел перенести проект на Mega2560, но оказалось что на этом контроллере вывод всего( и из flash, и из SD) по времени примерно вдвое дольше чем на UNO. На аппаратном SPI SD карта там она и осталась. Другой разници не нашёл. Парни, подскажите если знаете, почему так?
к каким пинам подключаете шину данных диспа на UNO и на Меге ?
Какую либу используете ?
Какой дисплей?
поищите в инете pinouts arduino uno , mega и сравните их , на какие порты пины приходят.
Самое быстрое на Уно это цельный порт PortD D0-D7 (UTFT) . Если D2-7 , D8 D9 (Adafruit) то тратися время на распихивание по 2-м разным портам ! Для меги самое быстрое это цельный порт PortA PortC . Если D2-7 , D8 D9 то это раскидывание по 3-м разным портам !!!. Быстрый вариант это дисп на 16бит PortA+PortC .
Можете подключить как хотите. Варианты переключения в либе на нужные порты/пины можно найти.
Если пользуете UTFT , то на форуме есть ускоренная либа (выкинуты повсеместные лишние сравнения с другими контроллерами , оставлен один)
hugoboss317 , tft.load(70, 0, 345, 273, "OPEL.raw"); глядя на эту строчку решил что файлы должны обзываться "ххх.raw", но каким то чудом большую картинку назвал нормально потому она и работала )) спасибо !
Да нет же вы неверно поняли, не настолько я туп, размерность выставил в соответствии с картинкой, файл сохраняя на флешку обозвал "xxx.raw", вместо того чтобы дать ему имя "xxx"... решил что файл нужно именовать так же как он вызывается из программы!
Ну то есть dataFile.read(), оказывается, возвращает не 8-, а 16-разрядное число.
Ну вроде как и да и нет. (всмысле я и вроде как согласен и нет)
Из буфера то читает по 8 бит, хотя 16-ти разрядное как раз в две ячейки и уложиться.
Короче ХЗ.
какова вообще используемая глубина цвета?
Для экрана 5 - 6 - 5 т.е. 16 бит.
RAW (по всей видимости) так и сформирован.
А с картинкой - это на фото плохо видно. Мне больше интересно почему чёрный (0xFFFF) не искажает а остальные "плывут".
Интересно на сам RAW посмотреть, но открыть его ничем не могу.
Ну вроде как и да и нет. (всмысле я и вроде как согласен и нет)
Из буфера то читает по 8 бит, хотя 16-ти разрядное как раз в две ячейки и уложиться.
Короче ХЗ.
Т.е. Вы используете библиотеку и даже не заглянули в ее исходники?
Какое может быть ХЗ при наличии исходников библиотеки!
Для экрана 5 - 6 - 5 т.е. 16 бит.
RAW (по всей видимости) так и сформирован.
Я, в общем-то, тоже посчитал, что это само собой разумеется, но исходя из двух фактов:
- приведенный у Вас фрагмент кода написан так, как будто предполагает, что длина строки в RAW не равна удвоенной длине в пикселях.
- фрагмент, переписанный, исхоодя из того, что на пиксель приходится 2 байта, работает некорректно.
я несколько в этом засомневался.
А с картинкой - это на фото плохо видно. Мне больше интересно почему чёрный (0xFFFF) не искажает а остальные "плывут".
Интересно на сам RAW посмотреть, но открыть его ничем не могу.
Это как? У Вас нет компьютера?
Это как? У Вас нет компьютера?
)) Анекдот вспомнил. Ковычки добавил чтоб понятней было.
- Привет. Как дела?
- "+"
- Ты на пары идёшь?
- "-"
- Бл_дь, ты что, с калькулятора пишешь?
:)))))))))
Я многого просто не пишу. Некоторые вещи вроде как само собой разумеющиеся, но не во всём можно быть уверенном на 100%. В одном из минипроэктов есть переменная, меняться значение которой может только i++, или i--, т.е. не больше чем на еденицу. А по факту - уменьшается до (кажется ) 435 и опять 465 и наоборот. Весть исходник поиском перекопал, ну нет больше с этой переменной никаких операций. Это всё в версии 1.0.5.
А если загрузить в версии 1.6.х. Как в исходнике так и работает, но не все библиотеки загружаются. Так в EEPROM записываю нужное мне значение с версией 1.6.х, а потом перезагружаю с версии 1.0.5. Чё как вобще не понятно, но работает и только так. Я к чему - i++ Это i = i+1, уверены на 100%? А я нет. ИМХО
Из представленного мной фрагмента кода (вроде как) явно видно что на пиксель приходится (ну или как правильней) 2 байта в файле RAW и именно по этому буфер, изначальный гемор, в два раза больше ширены картинки по размеру. Это тоже само собо разумеется.
Естесссно я копался в исходниках и поэтому и утверждаю, что функция чтения в буфер и чтения байта, немного (мягко говоря) отличаются.
Да и собственно почему у меня особого интереса нет от буфера избавляться - время. Время вывода увеличивается больше чем в 6 раз. Не думаю что это понравится кому то. Гораздо быстрей выводить из двух частей если сильно широкое изображение. Я оптимизировал до вывода из трёх полной ширины экрана. Этоже и рекомендую.
Тут ещё попутно интересный момент появился. Хотел перенести проект на Mega2560, но оказалось что на этом контроллере вывод всего( и из flash, и из SD) по времени примерно вдвое дольше чем на UNO. На аппаратном SPI SD карта там она и осталась. Другой разници не нашёл. Парни, подскажите если знаете, почему так?
Тут ещё попутно интересный момент появился. Хотел перенести проект на Mega2560, но оказалось что на этом контроллере вывод всего( и из flash, и из SD) по времени примерно вдвое дольше чем на UNO. На аппаратном SPI SD карта там она и осталась. Другой разници не нашёл. Парни, подскажите если знаете, почему так?
к каким пинам подключаете шину данных диспа на UNO и на Меге ?
Какую либу используете ?
Какой дисплей?
поищите в инете pinouts arduino uno , mega и сравните их , на какие порты пины приходят.
Самое быстрое на Уно это цельный порт PortD D0-D7 (UTFT) . Если D2-7 , D8 D9 (Adafruit) то тратися время на распихивание по 2-м разным портам !
Для меги самое быстрое это цельный порт PortA PortC . Если D2-7 , D8 D9 то это раскидывание по 3-м разным портам !!!. Быстрый вариант это дисп на 16бит PortA+PortC .
Можете подключить как хотите. Варианты переключения в либе на нужные порты/пины можно найти.
Если пользуете UTFT , то на форуме есть ускоренная либа (выкинуты повсеместные лишние сравнения с другими контроллерами , оставлен один)
Ну примерно так и думал. Дисплей на 8 бит. Библиотека Adafruit. На UNO подключен D2-D7 + B0,B1. (А D8 D9 это где?)
На Mega на 3 порта раскинуто,но заметно очень.
Перебросить только на В порт не получмтся. Во первых там аппаратный SPI, как я говорил, на SD.
А вот на меге я бы и перекинул на порт C. НЕ могу найти в каком файле конфиг.
Вся инициализация в MCUFRIEND.
проблема та же только экран 2.4 при определении ридером на экране появляются помехи, красным не становиться.
Приведите сообщение в божеский вид. Поможем...
Hugoboss317 спасибки за #36, очень помогло !
Только один момент не понятен, маленькую картинку не во весь экран вывести не получается....
Только один момент не понятен, маленькую картинку не во весь экран вывести не получается....
Что значит не во весь экран? А во весь экран выводится что ли?
Какое разрешение экрана?
Что именно не получается?
Названия файла .raw в коде правильно написано?
hugoboss317 , tft.load(70, 0, 345, 273, "OPEL.raw"); глядя на эту строчку решил что файлы должны обзываться "ххх.raw", но каким то чудом большую картинку назвал нормально потому она и работала )) спасибо !
Так собственно вышеупомянутое изображение ни разу не на весь экран, по крайней мере по ширине.
Разрешение экрана 320х480, если такой же. А картинка 345х273. Я так понял не верно писали?
Да нет же вы неверно поняли, не настолько я туп, размерность выставил в соответствии с картинкой, файл сохраняя на флешку обозвал "xxx.raw", вместо того чтобы дать ему имя "xxx"... решил что файл нужно именовать так же как он вызывается из программы!
ребята как тут фотку добавить??? какойто двацатый век с интерфейсом.