Опять же какой МК взять. На блюпиле каждое чтение команды программы из флеша задержки даёт. Особо скоростные куски в сначала в ОЗУ переписывают и управление передают туда.
Опять же какой МК взять. На блюпиле каждое чтение команды программы из флеша задержки даёт. Особо скоростные куски в сначала в ОЗУ переписывают и управление передают туда.
Komandir, Цифры то случайно из масива шрифта берутся, это большие символы 16х24, нет никакой возможности держать их в ОЗУ, поэтому их и толкают в PGM и оттуда постоянно читают.
использование pgm_read_* на 6% снижает производительность программы. Но без pgm никуда.
Можно ознакомиться с текстом программы, производительность которой страдает от использования pgm_read_*?
Код большой, выкладывать сюда не рационально, да и найти надо ещё в ворохе версий. Краткий смысл: из модема sim800 каждый приходящий байт обрабатывается в realtime, ищется нужная команда/ответ + обработка логики. Модем работает через hardware uart. При использовании progmem, т е каждая строчка поиска читалась для поиска совпадения с входящими данными, стали появляться непредсказуемые зависания :( Пришлось отказаться от pgm при приёме данных.
Изначально LPM (3 такта) на 50% медленнее чем LD (2 такта). Изначально ясно что хранение данных в памяти программ не бесплатно. Но и перекачка их в ОЗУ то же не бесплатная операция (все не PROGMEM данные после каждого Reset копируются в ОЗУ и это тоже не мгновенно происходит). Так что все как в жизни - где-то теряем, где-то находим ...
Так что надо учится работать с экраном без буфера в ОЗУ ... FPS резко подскочит ...
Так что надо учится работать с экраном без буфера в ОЗУ ... FPS резко подскочит ...
У меня первая версия как раз без буфера была, FPS конечно до 200 на небольших областях, но там другие проблемы появились, что пришлось вернуться к буферу. А на буфер и массив шрифта памяти и не хватило. Да для больших TFT экранов у ардуины не хватит даже на буфер.
Конечно не кино, ФПС это просто время отрисовки экрана 1/46 = 21 мсек.
Для мультиков, абычна, предназначены другие устройства, а тут надо использовать шаблон с блоками информации на определенных местах. Изменилось чонить, стёр/закрасил блок - вывел нужную информацию, зачем остальное-то трогать? Осциллографы на Ардуинах я не рассматриваю, это извращение хуже чем хоккей на траве, для этого STM есть, а там проблем ни с буфером, ни с FPS нету.
А в машштабах всей программы?
;))))))) поставь кварц на 17 МГц, то на то будет!
---------------------------------
ЗЫ: опять в психушке день открытых дверей? Может справку при входе на форум начать требовать?
ddr2 это от кода зависит. Если у вас одно чтение памяти на +100500 строк кода, то тогда какой процент ???
Опять же какой МК взять. На блюпиле каждое чтение команды программы из флеша задержки даёт. Особо скоростные куски в сначала в ОЗУ переписывают и управление передают туда.
В цикле обновляю экран и вывожу символы. При копировании из памяти было 50 FPS, после pgm_read 47.
Опять же какой МК взять. На блюпиле каждое чтение команды программы из флеша задержки даёт. Особо скоростные куски в сначала в ОЗУ переписывают и управление передают туда.
использование pgm_read_* на 6% снижает производительность программы. Но без pgm никуда.
Можно ознакомиться с текстом программы, производительность которой страдает от использования pgm_read_*?
Код большой, выкладывать сюда не рационально, да и найти надо ещё в ворохе версий. Краткий смысл: из модема sim800 каждый приходящий байт обрабатывается в realtime, ищется нужная команда/ответ + обработка логики. Модем работает через hardware uart. При использовании progmem, т е каждая строчка поиска читалась для поиска совпадения с входящими данными, стали появляться непредсказуемые зависания :( Пришлось отказаться от pgm при приёме данных.
Изначально LPM (3 такта) на 50% медленнее чем LD (2 такта). Изначально ясно что хранение данных в памяти программ не бесплатно. Но и перекачка их в ОЗУ то же не бесплатная операция (все не PROGMEM данные после каждого Reset копируются в ОЗУ и это тоже не мгновенно происходит). Так что все как в жизни - где-то теряем, где-то находим ...
Так что надо учится работать с экраном без буфера в ОЗУ ... FPS резко подскочит ...
А какой глубокий смысл в FPS на микроконтроллере ? Вы что там кино показываете ?
Конечно не кино, ФПС это просто время отрисовки экрана 1/46 = 21 мсек.
А зачем вам >25 раз в секунду его обновлять то ? Думаю что даже 5-10 раз в секунду уже достаточно для 99.99% задач !
Конечно не кино, ФПС это просто время отрисовки экрана 1/46 = 21 мсек.
Для мультиков, абычна, предназначены другие устройства, а тут надо использовать шаблон с блоками информации на определенных местах. Изменилось чонить, стёр/закрасил блок - вывел нужную информацию, зачем остальное-то трогать? Осциллографы на Ардуинах я не рассматриваю, это извращение хуже чем хоккей на траве, для этого STM есть, а там проблем ни с буфером, ни с FPS нету.
В этой ветке спрошу. Почему
астериск(*) в sprintf перед s не работает? .* - тоже пробовал
http://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html#gaa3b9...
Это официальная страница avr-libc. Самая что-ни-на-есть оригинальная. Найди там формат, который ты пытаешься применить. Плз.
Реализация printf для AVR несколько специфична. Например - в дефолте нет работы с float (чтобы память не жрало). Видимо и этот спецификатор подрезан.
(The variable width or precision field (an asterisk * symbol) is not realized and will to abort the output.)
Понятно... Т.е. в АрдуиноСи это не реализовано :(