Starichok51 писал(а):"inc count_SPI" у меня в приемной части прерывания, которую я удалил, а в скопированный кусок кода не вставил.
это код для АТмега8, и там у меня ZH всегда равен 1, для обращения в блок памяти 0x100-0x1FF. то есть все данные хранятся в этом блоке и изменять ZH мне никогда не нужно.
Ага, т.е. это не весь код прерывания. Соответственно, не 15 тактов, а больше. Я после того, как "потрогала" DMA и вывод в SPI без участия основной программы, задумалась, а можно ли такое сделать на АВРках... И анализ показал, что можно. Но это не будет независимым от ядра параллельным процессом, как DMA, это будет отправка данных с долгими прерываниями и маленькими перерывами на основную программу. И годится такое только для какого то медленного SPI, когда сидеть и ждать окончания отправки слишком расточительно. Но как правило SPI - это либо внешняя память, либо дисплей, либо другая достаточно скоростная периферия, для которой частоты AVR - вполне себе средненькие, если не медленные. И гонять этот SPI приходится на 1/4..1/2 от тактовой. Для дисплеев рабочая частота SPI запросто может быть 50-100 МГц и выше... И вот тогда тормознутость прерывания и покажет себя во всей красе.
Но я не отговариваю, ваш подход имеет право на жизнь. У меня в каком то проекте именно так опрашивается тачскрин дисплея. Но там реально SPI на 500 кГц крутится. И опрос запускается сколько то там раз в секунду от системного таймера, далее работает автономно и машина состояний при нажатии на тач генерирует событие. Т.е. все в фоне, там опрос тача - десяток байт.
shonty писал(а):У меня алергия на озу. Крайне редко использую
Ну да... один тут доказывал, что прерывания - зло, они вызывают глюки... Теперь вы утверждаете, что использовать ОЗУ - плохо для вас )))))
Давайте вернемся в русло темы OLED1306. Дисплей имеет 1 бит на пиксель, организация - горизонтальными блоками высотой 8 пикселей (1 байт).
Любой вывод, который не идет сразу в 8 пикселей одного блока - сразу становится интересным - задача комбинирования уже отрисованного изображения и выводимого без доступа к данным отрисованного - становится нетривиальной.
Обычно для таких дисплеев выделяется буфер в ОЗУ. В нашем случае 64*128 = 8192 бита или 1 килобайт.
И все рисование производится в этом буфере, который потом можно выплюнуть в дисплей.
Можно уменьшить размер буфера, например, до 8 пикселей по вертикали, но это менее удобно.
Хотя, если писать на асме и стараться использовать только регистры, то, наверное, можно минимизировать использование ОЗУ. Но... зачем?