Форум arduino.ua

Ще може бути, що ваш компілятор виявився розумніший, і згенерував щось типу

        ldi r24,lo8(1)
        out 0x5,r24
        out 0x5,__zero_reg__
        out 0x5,r24
        out 0x5,__zero_reg__
        out 0x5,r24
        out 0x5,__zero_reg__
        out 0x5,r24
        out 0x5,__zero_reg__

Це 8 біт за 0.5 мкс. Але ж це константні дані. Для знакогенерації чи інших фіксованих картинок ок, для довільного зображення вже так не буде.

Внизу під вікном редагування "Завантаження". Там "Upload a file". Потім відкриваєте завантажений файл, копіюєте його адресу і вставляєте в текст.

Тобто 1 біт за 1 такт на atmega328p? Щось тут не те.
(Я маю на увазі довільні дані, а не фіксований патерн)

A, якщо вдається 8 біт за 0.5 мкс, то там явно не атмега. Або розігнана до 32 МГц

Для такої задачі inline assembler - саме воно. Не обовʼязково inline, можна і в окремому source файлі.

Стандартних таких засобів у мовах C та C++ немає.
Навіщо це вам потрібно? У більшості випадків (але не завжди) компілятор знає краще за програміста, де розміщувати змінну. Краще напишіть, яку саме проблему намагаєтесь вирішити використанням регістру для змінної.
Якщо таки потрібно, є власноруч перевірений GCC Inline Assembly.

register - це лише підказка компілятору, причому давно застаріла (deprecated).

Не треба. Примусове вимкнення оптимізації в сучасних компіляторах не має практичного сенсу. До того ж, це скоріш змусить НЕ використовувати регістр, ніж навпаки.

Та хто знає, під якою назвою такий девайс в базі. Який у нього VID:PID? Може у вас встановлено драйвер для якоїсь камери, який асоційовано з таким же ідентифікатором.

Воно раніше на цьому компі працювало, а тепер перестало, чи ні разу ще не прошивали?

При підключенні зʼявляються обидва девайса, "Camera DFU Device" та це "Неизвестное устройство"? Не дуже зрозуміло, чому воно в одному списку з хабами.

Зазвичай неможливість прочитати дескриптор означає апаратну проблему з USB: кабель, розʼєм, живлення, електромагнітні наводки і т.п.

Доречі, майте на увазі, що у вашій програмі шрифт у форматі "вертикальних байтів". Такий формат зручніше виводити на дисплеї з горизонтальними банками, просто передаючи байти послідовно. У більшості стандартних форматів шрифти у вигляді "горизонтальних байтів". Щоб виводити їх на дисплей з горизонтальними банками потрібно транспонувати гліфи, або заздалегідь, або в рантаймі.

Більше того, у таких двокольорових дисплеїв (1 bit per pixel) зображення складається зі смужок ("сторінки" або "банки") висотою 8 пікселів. Або шириною, дивлячись як повернути. Одна з координат обирає сторінку, тобто задається в знакомісцях, а інша - зміщення на сторінці, тобто в пікселях.

setPosition() в коді вище так і реалізована.

Ну він же адекватно реагує на інструкції для PCD8544/PCF8812? Бітмапи, які в нього передаєте, відображає коректно? Значить, як мінімум, сумісний.

Запишіть в нього по нульовій адресі бітмап, що легко вгадується, наприклад:

 0xff, 0x01, 0x03, 0x07, 0x0f, 0x1f, 0x3f, 0x7f

Зрозумієте, де у нього початок координат і в якому порядку йде автоінкремент.

Взагалі, там же в даташитах все намальовано: PCF8812.pdf, стр.8, PCD8544.pdf, стр.8.

Не схоже, щоб у цих контролерів був якийсь апаратний MADCTL (як у ST7735) або row/col remap (як у SSD1306).
Якщо хочете перевернути зображення - реалізуйте це програмно.

Я зазвичай беру лінуксові consolefonts, там є і з кирилицею. Коли не вистачає якихось символів, то домальовую сам.
Є різні тулзи для маніпуляцій зі шрифтами, наприклад Monobit.
Але зазвичай для генерації коду зі шрифтом я пишу свою програмку, що виконує необхідні маніпуляції для конкретної задачі.

Ви ж, сподіваюсь, розумієте, що кодування літералів у програмі має відповідати кодуванню символів у шрифті? Якщо вихідний код в однобайтовому кодуванні, наприклад cp1251, то можна просто відсортувати гліфи в шрифті для cp1251. Але якщо в UTF-8, то потрібно перед компіляцією конвертувати літерали в однобайтне кодування. Для цього зручно зберігати текст повідомлень в окремому файлі, і генерувати вихідний код з повідомленнями автоматично при збірці.

Так, max packet size у ендпоінта 32 байта. Хоча один раз попався екземпляр, що рапортував 64. Ще й у різних версій різна розрядність дільника.
В режим UART я не дуже лазив, для нього є драйвер в mainline. CH341A - це, по суті, три різних девайса на одному чіпі, для кожного потрібен свій драйвер.
В режимі EPP/MEM ще й фіксований clock. Може він насправді й не фіксований, але документації нема.

Так у вас у шрифті тільки великі латинські літери та цифри. Навіть знаків пунктуації нема, не то що кирилиці.

А де попало? Я маю на увазі, як співвідносяться координати, які передаєте, з тими, де виводиться насправді?

В якому форматі той інший шрифт? Ви модифікували getChar() та drawText() відповідно до нього?

Який точно у вас контролер LCD, для которого ця програма? Є на нього даташит? Бо тут уже згадувалось декілька різних контролерів, і незрозуміло, на якому з них проблема з текстом.

Наскільки бачу, ви виводите байти гліфів з шрифта "як є". Якщо це 1-бітний LCD (піксель on/off), то правильно. Якщо ж це кольоровий дисплей, то так не буде працювати. Потрібно відповідно до кожного біта в гліфі виводити піксель (байт або декілька, в залежності від режиму) кольору текста або фона.

Дзеркалить по Y - це ліво з право переплутане, чи верх з низом? Одна картинка з результатом роботи програми допомогла би розібратись.
Потрібно дивитись, які режими автоінкремента у цього контролера. А далі або змінити напрямок автоінкременту, або біти в шрифті перевертати, або бітмап виводити задом наперед, від останнього байта до першого.

В якому він у вас режимі кольорів? Ви ж враховуєте, що при 12bpp непарні пікселі попадають на середину байта? Хоча, якщо пікселі виводяться правильно, то, мабуть, враховуєте. Тоді покажіть, як виглядає "ненормальний" вивід тексту. Ну і код покажіть, яким виводите.