ATmega8 + OLED SSD1306

[JackSmith]

[uquote="BDDW",url="/forum/viewtopic.php?p=4389401#p4389401"]Д и, если не сложно, дайте ссылку на шрифты. Много перерыл, но кроме 6х8 шрифта с русскими буквами не нашел.[/uquote]
прога для конвертации обычных шрифтов в матричные:
https://gitlab.com/riva-lab/matrixFont
статья о ней на хабре https://habr.com/ru/post/575332/

[shonty]

Не знаю в какой теме написать тем по SSD1306 что то много на форуме..

Вобщем проблем с ним нет. Просто он ведь вроде как на 3,3V должен работать.. А я его оформил в "тестовом исполнении", с возможностью быстро подключить к контроллеру, что бы просто использовать в качестве индикатора в процессе разработки.. вместо моргания светодиодами.

Вобщем суть вопроса: иной раз забываю переключить USBASP С 5 на 3,3 В, дисплей молотит на 5-ти вольтах на макетке чуть ли не сутками, пока не спохвачусь, и ничего, исправен

Всем

[Just_Fluffy]

shonty, так там на плате дисплея бортовой стаб есть обычно. И подтяжка и2ц к питанию дисплея (после стаба)


Поэтому если в меге настроить и2ц как открытый сток - то вообще проблем не будет.

[shonty]

так там на плате дисплея бортовой стаб есть обычно. И подтяжка и2ц к питанию дисплея (после стаба)

Just_Fluffy, точно, открутил, посмотрел, так и есть.. Подтяжку после стаба я не учёл

Видимо у меня вперемежку с ILI9341 и ST7735 такое отложилось в голове
На TFT же тоже стабы стоят, тем не менее уровни SPI 3,3 должны быть.
Или я тут тоже что то путаю..?

[Just_Fluffy]

там вроде контроллеры толерантны к 5 вольтам, но SPI/Parallel должны быть не выше 3.6 вольт. Но на атмегах гонять такие дисплеи грустно. Памяти в меге мало, частота низкая....

[shonty]

Но на атмегах гонять такие дисплеи грустно. Памяти в меге мало, частота низкая....

Нее.. мне не грустно..)) Хоть и данные идут 16 бит на пиксель.

Вот старое видео, я шрифты пробовал. Полная загрузка дисплея 240*320, мега328 20МГц +шрифт переменной ширины, а это всё таки ресурсы))



Но и на 16МГц нормально заходит)) ASCII полная, с крякозябрами)) Но контроллер не под завязку. Несколько шрифтов подключено и на всё хватает)

А это st7735, Atmega8 8MHz, но сколлинг аппаратный.



Но на LGT8F328p TFT гонять пробовал.. Там вообще в лёт, даже экономить и выкруживать ничего не нужно

Добавлено after 11 minutes 25 seconds:
PS: Но нужна ведь в основном только начальная загрузка, а потом только определённые поля перезаписываются..
Хотя и с полной сменой экранов вполне вменяемо получается..

Добавлено after 10 minutes 14 seconds:
PS2: на видео с ILI9341 при загрузке применена ещё фишка: подсветка вкючается при уже полной начальной загрузке дисплея. Поэтому переходного процесса заливки экрана не видно..
А на LGT8F328p - даже с подсветкой не видно переходных процессов. Пробовал делать просто циклическую перезаливку всего экрана.. Вообще глаз практически не замечает.. просто цвета меняются и всё..

[Just_Fluffy]

shonty, ну вам повезло, и шрифты поместились, и место для кода. А у меня 8-битное лого 240*240 не поместилось в мегу...
Но тема про ОЛЕД, не отвлекаемся )

[Adrift]

[uquote="shonty",url="/forum/viewtopic.php?p=4669177#p4669177"]на видео с ILI9341 при загрузке применена ещё фишка: подсветка вкючается при уже полной начальной загрузке дисплея. Поэтому переходного процесса заливки экрана не видно..[/uquote]
Это и есть показатель грустности ) 7 фпс на простой заливке экрана, 8, если к USART подключать, где хоть минимальная буферизация есть... У меня есть такой дисплей, он способен работать в 7 раз быстрее, примерно на 70MHz.

[shonty]

shonty, ну вам повезло, и шрифты поместились, и место для кода. А у меня 8-битное лого 240*240 не поместилось в мегу...

ну можно обсудить принципы вывода информации.. если лого, то можно не по пиксельно лить, а индексированно..
В кратце: 8-мью битами в идеале можно залить 256 пикселей)) речь об алгоритмах)

У меня есть такой дисплей, он способен работать в 7 раз быстрее, примерно на 70MHz.

Чисто по визуальным ощущениям задержка только при первоначальной заливке. Не хватает частоты ровно в 1,5 раза. Т.е. 30MHz уже идеально. Дальше разгоняться для себя не вижу смысла. Тем более на асме всё оптимизированно до предела.

[Just_Fluffy]

shonty, можно много обсуждать. Но 256-цветная картинка и так уже индексирована )))) Полноцветное лого. на алгоритмах сжатия без потерь 20-30% получается. а jpeg в мегу328 не впихнуть.

[shonty]

Полноцветное лого. на алгоритмах сжатия без потерь 20-30% получается. а jpeg в мегу328

Да.. тогда согласен. Полноценное фото не впихнуть. Но оно там всё равно с искажением будет. В этих дисплеях кодирование цвета идёт в формате 565, иной раз переходы даже в градациях серого фиг подберёшь) то в зеленоватый съедешь, то ещё куда))

PS:

У меня есть такой дисплей, он способен работать в 7 раз быстрее, примерно на 70MHz.

Спорить не буду, но как то странно, что на 70MHz работает в 7 раз быстрее чем на 20MHz

[Adrift]

[uquote="shonty",url="/forum/viewtopic.php?p=4669200#p4669200"]Спорить не буду, но как то странно, что на 70MHz работает в 7 раз быстрее чем на 20MHz [/uquote]
У вас на меге SPI работает на 20MHz? ) И это только частота SPI, на современных мк и передавать можно сразу по 16 бит с буферизацией, плюс есть DMA.

[shonty]

У вас на меге SPI работает на 20MHz? )

Сорри.. на 10 ))

Но на счёт буферизации вопрос решён. Это конечно не совсем буферизация как таковая, а скорее изврат)) но пиксели льются непрерывно, без задержек)

Добавлено after 1 minute 15 seconds:
а так да, 70/10 = 7


Добавлено after 3 minutes 32 seconds:
А вот в LGT8f328p 32-х битная буферизация SPI.. и работать удобнее))

Спойлер

только ARV-у не говорите, а то опять ругаться будет

[Just_Fluffy]

не совсем буферизация как таковая, а скорее изврат))

в атмегах нет буфера SPI. Единственный вариант - писать на асме (или ассемблерную вставку) и подбирать NOPы в цикле отправки в SPI так, что б загрузка нового байта в SPDR происходила сразу после отправки последнего бита.

Спойлер

Не скажем))

Оффтоп:
Adrift, DMA рулит))) И много GPIO тоже. Тогда можно лить сразу по 16 бит. Единственное, я не знаю, можно ли на параллельный вывод навесить DMA (я про СТМки)

[shonty]

Единственный вариант - писать на асме (или ассемблерную вставку) и подбирать NOPы в цикле отправки в SPI так

Нее.. готовить данные сначала, и только потом выполнять spi_wait.

[Adrift]

[uquote="Just_Fluffy",url="/forum/viewtopic.php?p=4669215#p4669215"]в атмегах нет буфера SPI. Единственный вариант - писать на асме[/uquote]
Там вроде SPI в принципе не умеет биты непрерывно слать, в любом случае будет задержка между байтами в такт или два, не помню точно.

[uquote="Just_Fluffy",url="/forum/viewtopic.php?p=4669215#p4669215"]Единственное, я не знаю, можно ли на параллельный вывод навесить DMA (я про СТМки)[/uquote]
Можно через FMC, но он в 100 пиновых корпусах минимум, за очень редким исключением. Можно гнать при помощи DMA в обычный порт, целиком или одну из половинок(кроме F1), при этом таймер который дергает DMA одновременно шимит другим каналом формирую строб. На F103, у которого медленные порты, у меня получалось байт за 14 тактов отправлять, на F303 вроде 12 было. На новых STM32H5/U5 должно быть быстро, там новый и самый быстрый DMA из всех STM32, из порта в память всего за 2 такта читает.
Есть еще PSSI на новых мк, он как бы слейв, но на вывод работает. Быстро, с FIFO и 8-ми битный порт можно уже в 64-х ногих мк найти.

[shonty]

Там вроде SPI в принципе не умеет биты непрерывно слать, в любом случае будет задержка между байтами в такт или два, не помню точно.

Да, так и есть.

А LGT непрерывно шлёт.

[Starichok51]

Just_Fluffy, нет необходимости делать программный SPI с NOPами - лучше применить аппаратный SPI с прерыванием по окончании передачи, а в прерывании брать из буфера следующий байт. получится мизерная потеря времени между байтами.
я у себя такое делал в моем последовательном программаторе (собственный программатор на замену usbasp), где обмен с пациентом идет по SPI.

[Just_Fluffy]

готовить данные сначала, и только потом выполнять spi_wait.

Мы же говорим об максимально возможной скорости обмена по SPI. Опрос флага SPIF - если повезет - то будет быстро. Если не повезет - можно потерять несколько тактов. Если заранее известна частота тактирования SPI - вместо цикла опроса флага готовности просто ставятся NOPы в нужном количестве. Можно даже не высчитывать, а заведомо поставив больше нопов, чем надо, смотреть логическим анализатором и посчитать, сколько нопов надо выбросить. Но как на буферируемом SPI - на обычном не выйдет. Пауза будет, минимальная. Но будет.
Либо изгаляться с синхронным ЮАРТом.
А вообще - правильней применить параллельное подключение. Тогда
LD R16,X+
OUT PORTB, R16
LD R16,X+
OUT PORTC, R16
SBI бит строба
CBI бит строба
10 тактов против минимум 16 для SPI

LGT - предпочитаю не пользоваться странными китайскими поделиями-однодневками.

Спойлер

Проще тогда уж СТМку взять, F103С8 уже можно найти по 80 центов на али. Заодно получить и отладку, и памяти больше, и скорости повыше...
https://aliexpress.com/item/1005002651134172.html
Только, увы, порог вхождения немножко другой, особенно, если без куба.

Там вроде SPI в принципе не умеет биты непрерывно слать, в любом случае будет задержка между байтами в такт или два

Да, там минимальная задержка должна быть, надо смотреть в ДШ тайминги SPI
ПС. За подсказку про строб ШИМом спасибо. Одна голова хорошо, две - лучше, а три - уже Змей Горыныч выходит....

нет необходимости делать программный SPI с NOPами

А где вы увидели в моих словах программный SPI? Я исключительно про аппаратный.
Речь о том, что после отправки байта в SPDR и загрузки из памяти в регистр следующего байта не нужно крутить цикл ожидания флага SPIF в регистре SPSR, а проще подгадать момент, когда можно загрузить новые данные в SPDR без опроса флагов. При выжимании максимальной скорости SPI экономия пары лишних тактов может дать прирост в скорости.
А По поводу прерывания SPI - пардон, но это самый медленный способ:
Время на вход в прерывание (не помню, сколько тактов)
- сохранить регистры (5 регистров - 10 тактов,
- прочитать и сохранить флаги 1+2 такта,
далее нужно загрузить байт данных из массива для отправки - тут я вообще не знаю, как это сделать быстро, это ж прерывание... (подразумевается, что в регистрах ничего нет, все в памяти)
- загрузить адрес указателя на массив данных в пару Х - 4 такта,
- прочитать в пару Y текущий казатель на массив - 4 такта,
- прочитать байт данных по адресу указателя Y с инкрементом указателя - 2 такта
- наконец то - отправить байт в SPDR - 1 такт
- сохранить обновленный указатель на массив данных Y по адресу Х - 4 такта
- восстановить флаги - 1+2 такта
- восстановить 5 регистров - 10 тактов
выход из прерывания...
Итого чистого времени работы прерывания - 10+1+2+4+4+2+1+4+1+2+10 = 41 такт. Не считая вход-выход

Единственный плюс прерывания - работа SPI в фоновом режиме.

[Adrift]

[uquote="Just_Fluffy",url="/forum/viewtopic.php?p=4669272#p4669272"]Время на вход в прерывание (не помню, сколько тактов)[/uquote]
2 такта сохранение PС, 2 или 3 такта RJMP/JMP, т.е. для mega328 пять тактов получается вход, и 4/5 выход.