Имеешь в виду, что вместо 50 там где-то вдвое ниже?
Но я бы еще хотел обратить внимание на то, что расстояние между пакетами в несколько раз больше, чем длина пакета.
На stm32 разница еще больше - там реальная скорость передачи где-то в 7 раз меньше, чем теоретически возможная. У меня вообще появилось желание переписать библиотеку SPI для stm32, чтобы добиться от нее вменяемой скорости и, в частности, ввести режим передачи не по 1 байту, а длинными последовательностями через DMA.
Имеешь в виду, что вместо 50 там где-то вдвое ниже?
на 30 мегагерц в 100 наносекунд умещается ровно 2 импульса, но я про другое, библиотеку использую с заявленной адаптацией к RP2040 в которой скорость SPI устанавливается, в скетче она выставлена в 50 мегагерц, а на осциллограммах в постах которые выше она 1 мегагерц...и как тут не быть дураком...
2. На той осциллограмме, что вверху, если я правильно понял, на 10 клеток по 100 нс (т.е. на 1 мкс) приходится 8 импульсов, что и соответствует 8 МГц. Откуда там мегагерц?
2. На той осциллограмме, что вверху, если я правильно понял, на 10 клеток по 100 нс (т.е. на 1 мкс) приходится 8 импульсов, что и соответствует 8 МГц. Откуда там мегагерц?
2. На той осциллограмме, что вверху, если я правильно понял, на 10 клеток по 100 нс (т.е. на 1 мкс) приходится 8 импульсов, что и соответствует 8 МГц. Откуда там мегагерц?
Имеешь в виду, что вместо 50 там где-то вдвое ниже?
Но я бы еще хотел обратить внимание на то, что расстояние между пакетами в несколько раз больше, чем длина пакета.
На stm32 разница еще больше - там реальная скорость передачи где-то в 7 раз меньше, чем теоретически возможная. У меня вообще появилось желание переписать библиотеку SPI для stm32, чтобы добиться от нее вменяемой скорости и, в частности, ввести режим передачи не по 1 байту, а длинными последовательностями через DMA.
Пишите на регистрах, получите максимальный потолок скорости.
Всё таки добавление контурных цветов улучшает восприятие двухцветной картинки :) А тусклая подсветка правого нижнего угла экрана ещё даёт отсутствующий на самом деле голубой цвет.
а я упёрся, не могу найти источник установки скорости SPI для библиотеки Adafruit_ST7735... отследил от ядра, должна быть не менее 16 мегагерц, ан нет )))
Ждём'c может более компетентные товарищи подтянутся...не люблю я непоняток...
а я упёрся, не могу найти источник установки скорости SPI для библиотеки Adafruit_ST7735... отследил от ядра, должна быть не менее 16 мегагерц, ан нет )))
Ждём'c может более компетентные товарищи подтянутся...не люблю я непоняток...
В библиотеке в 361 строке файла "...._ST7735".cpp строка
Она каждый раз вызывается при отправке данных (как я понял :) и 8000000 это скорость. Её нужно в библиотеке исправить, я ж писал. Увеличить скорость по факту не удалось, но уменьшить - пожалуйста :)
а я упёрся, не могу найти источник установки скорости SPI для библиотеки Adafruit_ST7735... отследил от ядра, должна быть не менее 16 мегагерц, ан нет )))
Ждём'c может более компетентные товарищи подтянутся...не люблю я непоняток...
В библиотеке в 361 строке файла "...._ST7735".cpp строка
Она каждый раз вызывается при отправке данных (как я понял :) и 8000000 это скорость. Её нужно в библиотеке исправить, я ж писал. Увеличить скорость по факту не удалось, но уменьшить - пожалуйста :)
в моей библиотеке,а я скачал самые свежие, такого нет...
Пишите на регистрах, получите максимальный потолок скорости.
Ну, может, оно и так, но в большинстве случаев максимальной скорости удается добиться, лишь изменив идеологию работы.
Т.е. "регистры" - необходимое, не достаточное условие.
как может человек не запустивший чужой код, писать что-то своё, это я о себе ежели что )))
Можно было бы предположить, что spi1 (он у меня используется для вывода на дисплей), не умеет работать на высоких скоростях, ан нет,выше приводил код скетча, где частоту можно легко изменить и оно работает, в оригинале автор использует spi0 и код не для IDE, для проверки чуток поправил, результат spi1 умеет работать на высоких скоростях...
Загадка в том, где выставляется скорость в 400кГц, прошёл всю связку от харда ядра, не нашёл, увы...
меня сейчас интересует CLK - где устанавливается в моём случае, библиотеки свежие, RP2040 в них прописан!!
Как говорил известный персонаж -"Ульри, где у него кнопка?"
Симпатишно!!!
А я вот в поисках истины SPI залил пробный скетч (благо там изменений почти никаких делать не надо было) под ядром
Mbed OS RP2040 и, тактовая частота поднялась до порядка 600 килогерц, библиотеки те же
То-есть проблема точно в библиотеках, там низкая скорость устанавливается для этого чипа...скорее всего...
ua6em а отдебажить не получается ? Сдаётся мне что там через ногодрыг происходит вывод.
я это умею только для Intel )))
Залил скетч под микроПитоном, там всё красиво, правда ПО Хантека пока еще сильно кривое, проверил до частоты 35 мегагерц, работает!!! Вот картинка для CLK 1 мегагерц - как в аптеке )))
lilik вижу какие то лишние телодвижения у вас с setAddrWindow ...
/*!
@brief SPI displays set an address window rectangle for blitting pixels
@param x Top left corner x coordinate
@param y Top left corner x coordinate
@param w Width of window
@param h Height of window
*/
/**************************************************************************/
void Adafruit_ST77xx::setAddrWindow(uint16_t x, uint16_t y, uint16_t w,
uint16_t h) {
x += _xstart;
y += _ystart;
uint32_t xa = ((uint32_t)x << 16) | (x + w - 1);
uint32_t ya = ((uint32_t)y << 16) | (y + h - 1);
writeCommand(ST77XX_CASET); // Column addr set
SPI_WRITE32(xa);
writeCommand(ST77XX_RASET); // Row addr set
SPI_WRITE32(ya);
writeCommand(ST77XX_RAMWR); // write to RAM
}
Еще - почему везде стоит pushColor ?
/*!
@brief Essentially writePixel() with a transaction around it. I don't
think this is in use by any of our code anymore (believe it was
for some older BMP-reading examples), but is kept here in case
any user code relies on it. Consider it DEPRECATED.
@param color 16-bit pixel color in '565' RGB format.
*/
void Adafruit_SPITFT::pushColor(uint16_t color) {
startWrite();
SPI_WRITE16(color);
endWrite();
}
Один раз вызываем startWrite, потом в цикле вместо pushColor используем SPI_WRITE16 и в конце один раз вызываем endWrite.
Если одно устройство начало вывод на экран - какой смысл его дергать ? Если много устройств на шине и всем нужно одновременно что то слать, тогда другое дело ...
для микроПитона фактическая скорость SPI шины в 23 мегагерца видимо предел, не удалось повысить даже разгоном процессора до 250 мегагерц (точнее до 273, далее модуль встряёт)
А на С++ оверклокать вроде можно аж до 300 мегагерц, оценивал только по работающему или нет дисплею, скорость шины SPI снижал значительно, на порядок...
Осталось найти где в драйверах задаётся скорость шины, под микропитоном при инициализации SPI прямо в строке инициализации
для микроПитона фактическая скорость SPI шины в 23 мегагерца видимо предел,
есть куда стремиться:
For example, at the maximum SSPCLK (clk_peri) frequency on RP2040 of 133MHz, the maximum peak bit rate in
master mode is 62.5Mbps. This is achieved with the SSPCPSR register programmed with a value of 2, and the SCR[7:0]
field in the SSPCR0 register programmed with a value of 0.
для микроПитона фактическая скорость SPI шины в 23 мегагерца видимо предел,
есть куда стремиться:
For example, at the maximum SSPCLK (clk_peri) frequency on RP2040 of 133MHz, the maximum peak bit rate in
master mode is 62.5Mbps. This is achieved with the SSPCPSR register programmed with a value of 2, and the SCR[7:0]
field in the SSPCR0 register programmed with a value of 0.
я не знаю как это сделать, особенно в питоне это раз, во вторых и стандартными средствами ардуино на этой библиотеке (Adafruit_ST7735) через костыли (правил параметры хардового SPI) добиться реальной скорости свыше 12MHz не удалось...
Я вот подумал о написанном... действительно удалось существенно увеличить скорость вывода в область экрана, фактически отказавшись от штатных функций библиотеки. Но именно вывод "пикселя в пиксель экрана" основа использования функций графических примитивов. Посмотрел ещё раз цепочку его реализации... многократные открытия-закрытия сеанса передачи данных в функциях цепочки. То есть можно применить подход и свести к последовательности SPI.transfer(c); в одном сеансе?
Не, все зависит от задачи, функция закраски одного пикселя неким цветом она не так часто используется.
Более распространено например вывод символа, или прямоугольника или спрайта и т д.
Соответственно выкидываются все эти биьлиотечные функцию, берём логику/напрягает мозг + математика =готовим некий буфер его подготавливаем к выводу и тупо по spi кидаем весь массив /часть экрана, чем сильно ускоряем работу.
Тогда думать надо :)
Хотя если ранний вариант работает, должен и этот работать. Может в другом дело?
Тогда думать надо :)
Хотя если ранний вариант работает, должен и этот работать. Может в другом дело?
Прежний скетч заработал, когда я перед выполнением loop включил очистку экрана
Осциллограмма работающего скетча:
Осциллограмма не работающего скетча
А частота смены картинок какая?
Фотка слева 4 цвета - чёрный, белый, два серых, справа исходник ч\б.
не идёт, у него SPI 32-х разрядный, по 4 байта сразу кидает, это не отрабатывает:
Что-то я сомневаюсь: польза от SPI, не поддерживающего байтовый обмен, немногим отлична от нуля.
Вряд ли кто-то будет делать заведомо бесполезную железку.
Речь о RPi?
Что-то я сомневаюсь: польза от SPI, не поддерживающего байтовый обмен, немногим отлична от нуля.
Вряд ли кто-то будет делать заведомо бесполезную железку.
тут скорее проблема в адаптаторе )))
Что-то со скоростью SPI не то!
SPI c заявленной 8 мегагерц:
И с заявленной в 50 мегагерц:
Скетч сдёрнул отсюда:
Имеешь в виду, что вместо 50 там где-то вдвое ниже?
Но я бы еще хотел обратить внимание на то, что расстояние между пакетами в несколько раз больше, чем длина пакета.
На stm32 разница еще больше - там реальная скорость передачи где-то в 7 раз меньше, чем теоретически возможная. У меня вообще появилось желание переписать библиотеку SPI для stm32, чтобы добиться от нее вменяемой скорости и, в частности, ввести режим передачи не по 1 байту, а длинными последовательностями через DMA.
Имеешь в виду, что вместо 50 там где-то вдвое ниже?
на 30 мегагерц в 100 наносекунд умещается ровно 2 импульса, но я про другое, библиотеку использую с заявленной адаптацией к RP2040 в которой скорость SPI устанавливается, в скетче она выставлена в 50 мегагерц, а на осциллограммах в постах которые выше она 1 мегагерц...и как тут не быть дураком...
1. 2 импульса за 100 нс - это 20 МГц.
2. На той осциллограмме, что вверху, если я правильно понял, на 10 клеток по 100 нс (т.е. на 1 мкс) приходится 8 импульсов, что и соответствует 8 МГц. Откуда там мегагерц?
1. 2 импульса за 100 нс - это 20 МГц.
2. На той осциллограмме, что вверху, если я правильно понял, на 10 клеток по 100 нс (т.е. на 1 мкс) приходится 8 импульсов, что и соответствует 8 МГц. Откуда там мегагерц?
я про пост #152, это библиотека Adafruit_ST7735
1. 2 импульса за 100 нс - это 20 МГц.
2. На той осциллограмме, что вверху, если я правильно понял, на 10 клеток по 100 нс (т.е. на 1 мкс) приходится 8 импульсов, что и соответствует 8 МГц. Откуда там мегагерц?
я про пост #152, это библиотека Adafruit_ST7735
Внутри неё есть строчка
mySPISettings = SPISettings(8000000, MSBFIRST, SPI_MODE0);
Вот её то я и мучал :), в итоге оставил как есть. Но на скорости 200000 и вправду картинка стала реально тормозить на выводе.
Имеешь в виду, что вместо 50 там где-то вдвое ниже?
Но я бы еще хотел обратить внимание на то, что расстояние между пакетами в несколько раз больше, чем длина пакета.
На stm32 разница еще больше - там реальная скорость передачи где-то в 7 раз меньше, чем теоретически возможная. У меня вообще появилось желание переписать библиотеку SPI для stm32, чтобы добиться от нее вменяемой скорости и, в частности, ввести режим передачи не по 1 байту, а длинными последовательностями через DMA.
Пишите на регистрах, получите максимальный потолок скорости.
Всё таки добавление контурных цветов улучшает восприятие двухцветной картинки :) А тусклая подсветка правого нижнего угла экрана ещё даёт отсутствующий на самом деле голубой цвет.
а я упёрся, не могу найти источник установки скорости SPI для библиотеки Adafruit_ST7735... отследил от ядра, должна быть не менее 16 мегагерц, ан нет )))
Ждём'c может более компетентные товарищи подтянутся...не люблю я непоняток...
а я упёрся, не могу найти источник установки скорости SPI для библиотеки Adafruit_ST7735... отследил от ядра, должна быть не менее 16 мегагерц, ан нет )))
Ждём'c может более компетентные товарищи подтянутся...не люблю я непоняток...
В библиотеке в 361 строке файла "...._ST7735".cpp строка
mySPISettings = SPISettings(8000000, MSBFIRST, SPI_MODE0);
Она каждый раз вызывается при отправке данных (как я понял :) и 8000000 это скорость. Её нужно в библиотеке исправить, я ж писал. Увеличить скорость по факту не удалось, но уменьшить - пожалуйста :)
а я упёрся, не могу найти источник установки скорости SPI для библиотеки Adafruit_ST7735... отследил от ядра, должна быть не менее 16 мегагерц, ан нет )))
Ждём'c может более компетентные товарищи подтянутся...не люблю я непоняток...
В библиотеке в 361 строке файла "...._ST7735".cpp строка
mySPISettings = SPISettings(8000000, MSBFIRST, SPI_MODE0);
Она каждый раз вызывается при отправке данных (как я понял :) и 8000000 это скорость. Её нужно в библиотеке исправить, я ж писал. Увеличить скорость по факту не удалось, но уменьшить - пожалуйста :)
в моей библиотеке,а я скачал самые свежие, такого нет...
:)
Ну тогда должна быть встроенная в иде библиотека TFT, а в ней опять же " ..._ST7735", а в ней к моему удивлению уже в 357 строке стоит:
spisettings = SPISettings(4000000L, MSBFIRST, SPI_MODE0);
:)
Ну тогда должна быть встроенная в иде библиотека TFT, а в ней опять же " ..._ST7735", а в ней к моему удивлению уже в 357 строке стоит:
spisettings = SPISettings(4000000L, MSBFIRST, SPI_MODE0);
там я еще не копал...покопал...и этот гвоздь не в ту стену...чётко 400кгц ))) во задача
Ну, может, оно и так, но в большинстве случаев максимальной скорости удается добиться, лишь изменив идеологию работы.
Т.е. "регистры" - необходимое, не достаточное условие.
Ну, может, оно и так, но в большинстве случаев максимальной скорости удается добиться, лишь изменив идеологию работы.
Т.е. "регистры" - необходимое, не достаточное условие.
как может человек не запустивший чужой код, писать что-то своё, это я о себе ежели что )))
Можно было бы предположить, что spi1 (он у меня используется для вывода на дисплей), не умеет работать на высоких скоростях, ан нет,выше приводил код скетча, где частоту можно легко изменить и оно работает, в оригинале автор использует spi0 и код не для IDE, для проверки чуток поправил, результат spi1 умеет работать на высоких скоростях...
Загадка в том, где выставляется скорость в 400кГц, прошёл всю связку от харда ядра, не нашёл, увы...
Ну, может, оно и так, но в большинстве случаев максимальной скорости удается добиться, лишь изменив идеологию работы.
Т.е. "регистры" - необходимое, не достаточное условие.
Это как так?
Производитель чипа прописал в даташите скорость шины Х МГц, как идеология работы программы может повлиять на эту скорость?
Давайте не путать между собой две скорости:
1. Темп передачи отдельного байта, т.е. по сути частоту CLK.
2. Реальную скорость передачи блока данных - с учетом всех задержек, пауз и прочих накладных расходов.
Так вот, в дэйташите прописана первая скорость, а пользователя, как правило, интересует вторая.
Так что, если иметь в виду именно вторую скорость, то ответ на Ваш вопрос:
Элементарно: ее можно снизить в несколько раз за счет неоптимальной организации работы.
меня сейчас интересует CLK - где устанавливается в моём случае, библиотеки свежие, RP2040 в них прописан!!
Как говорил известный персонаж -"Ульри, где у него кнопка?"
Вот этот вариант должен сработать, он аналог заработавшего.
При подборе цветов можно создавать иллюзию рельефа-объёма изображения.
Картинки:
На RP2040 заработало, если смотреть под углом градусов в 45 (фон станет голубоватым), то выделение по контуру придаёт рисунку объём...
Фото барельефов будут идти отлично
Продолжаю поиски частоты CLK!
В файл Adafruit_SPITFT.h добавил это:
Вывожу в лупе в монитор порта - Serial.println(DEFAULT_SPI_FREQ);
Вижу:
А фактическая частота 400кГц, то-есть SPI работает не с дефолтными установками... ищем дальше )))
На RP2040 заработало, если смотреть под углом градусов в 45 ...
Добавил градиент и рельеф пошёл :)
На RP2040 заработало, если смотреть под углом градусов в 45 ...
Добавил градиент и рельеф пошёл :)
можно свой логотип делать )))
На RP2040 заработало, если смотреть под углом градусов в 45 ...
Добавил градиент и рельеф пошёл :)
можно свой логотип делать )))
Фантазия у меня не ах.
Симпатишно!!!
А я вот в поисках истины SPI залил пробный скетч (благо там изменений почти никаких делать не надо было) под ядром
Mbed OS RP2040 и, тактовая частота поднялась до порядка 600 килогерц, библиотеки те же
То-есть проблема точно в библиотеках, там низкая скорость устанавливается для этого чипа...скорее всего...
ua6em а отдебажить не получается ? Сдаётся мне что там через ногодрыг происходит вывод.
ua6em а отдебажить не получается ? Сдаётся мне что там через ногодрыг происходит вывод.
я это умею только для Intel )))
Залил скетч под микроПитоном, там всё красиво, правда ПО Хантека пока еще сильно кривое, проверил до частоты 35 мегагерц, работает!!! Вот картинка для CLK 1 мегагерц - как в аптеке )))
ЗЫ крайняя частота SPI 62'499'999!!!
lilik вижу какие то лишние телодвижения у вас с setAddrWindow ...
Еще - почему везде стоит pushColor ?
Один раз вызываем startWrite, потом в цикле вместо pushColor используем SPI_WRITE16 и в конце один раз вызываем endWrite.
У меня функции такой вид имеют. Со вторым замечанием вроде понял - не надо на каждую пару байт цвета писать CS_LOW, CS_HIGH ?
я библиотеку смотрю свежую на гитхабе ...
beginTransaction endTransaction тоже ...
Если одно устройство начало вывод на экран - какой смысл его дергать ? Если много устройств на шине и всем нужно одновременно что то слать, тогда другое дело ...
нет конечно, задается координаты прямоугольника для заполнения и сплошным потоком дисплею массив цветов загоняется
нет конечно, задается координаты прямоугольника для заполнения и сплошным потоком дисплею массив цветов загоняется
Ну да, не самый быстрый вариант, зато штатными функциями библиотеки. Но я два варианта || веду :)
На одну полезную операцию вывода в порт SPI байтов цвета у вас прилипает десяток комплектов CALL PUSH POP RET, а это одни из самых долгих команд ...
На одну полезную операцию вывода в порт SPI байтов цвета у вас прилипает десяток комплектов CALL PUSH POP RET, а это одни из самых долгих команд ...
Попробую интуитивно по аналогии, как уже делал.
Это лучше уже ...
Вот вместо transfer и вставьте цикл вывода всей картинки заменив pushColor на два spiwrite
Протестировал два варианта, новый и предыдущий, самый быстрый. Новый выиграл со счётом 9:8 :)
новый
Быстрый:
Ну и буфера в дин.памяти для строки ему не надо.
для микроПитона фактическая скорость SPI шины в 23 мегагерца видимо предел, не удалось повысить даже разгоном процессора до 250 мегагерц (точнее до 273, далее модуль встряёт)
Думаю это предел скорости переключения выходных ключей.
А на С++ оверклокать вроде можно аж до 300 мегагерц, оценивал только по работающему или нет дисплею, скорость шины SPI снижал значительно, на порядок...
Осталось найти где в драйверах задаётся скорость шины, под микропитоном при инициализации SPI прямо в строке инициализации
коды цветов
Тогда может и дисплей тонет в потоке ...
А просто оценить скорость SPI, по факту? 9 картинок в 1 сек, 160*128 пикселей, по 2 байта, по 8 бит...
для микроПитона фактическая скорость SPI шины в 23 мегагерца видимо предел,
есть куда стремиться:
для микроПитона фактическая скорость SPI шины в 23 мегагерца видимо предел,
есть куда стремиться:
я не знаю как это сделать, особенно в питоне это раз, во вторых и стандартными средствами ардуино на этой библиотеке (Adafruit_ST7735) через костыли (правил параметры хардового SPI) добиться реальной скорости свыше 12MHz не удалось...
Картинко кликабельна...
Я вот подумал о написанном... действительно удалось существенно увеличить скорость вывода в область экрана, фактически отказавшись от штатных функций библиотеки. Но именно вывод "пикселя в пиксель экрана" основа использования функций графических примитивов. Посмотрел ещё раз цепочку его реализации... многократные открытия-закрытия сеанса передачи данных в функциях цепочки. То есть можно применить подход и свести к последовательности SPI.transfer(c); в одном сеансе?
Не, все зависит от задачи, функция закраски одного пикселя неким цветом она не так часто используется.
Более распространено например вывод символа, или прямоугольника или спрайта и т д.
Соответственно выкидываются все эти биьлиотечные функцию, берём логику/напрягает мозг + математика =готовим некий буфер его подготавливаем к выводу и тупо по spi кидаем весь массив /часть экрана, чем сильно ускоряем работу.