[jcxz 184]

12 минут назад, nanorobot сказал:

по своему приступал: пока что для меня главное направление оптимизации - избегать лишней перерисовки, то есть обновлять только изменившиеся элементы, по возможности сокращая площадь перерисовки. "чье то готовое" упомянуто - uGFX...

Тогда:

1. Определить что именно нужно для ГУИ: нужно ли столько цветов (сколько у вас там глубина цветности?) или хватит 16-и? И другие упрощения. И урезать карася. Тогда может быть можно будет рисовать во внутренней памяти МК.

2. Разобраться в используемых процедурах этого uGFX, выкинуть весь ненужный функционал. А лучше - написать полностью своё. Только так можно разобраться глубоко в вопросе.

3. Скомпилить используемые си-процедуры рисования с максимальной оптимизацией, взять их листинг, взять учебник по системе команд Cortex-M и оптимизировать эти процедуры на асме.

4. Да ещё - конечно нужно предварительно определить где именно находятся узкие места. И оптимизировать их.

Для многих алгоритмов ручная оптимизация на асме может дать кратное увеличение скорости. Хотя может конечно и не дать - зависит от алгоритма.

[nanorobot 3]

9 minutes ago, jcxz said:

Тогда:

1. Определить что именно нужно для ГУИ: нужно ли столько цветов (сколько у вас там глубина цветности?) или хватит 16-и? И другие упрощения. И урезать карася. Тогда может можно будет рисовать во внутренней памяти.

2. Разобраться в используемых процедурах этого uGFX, выкинуть весь ненужный функциоал. А лучше - написать полностью своё. Только так можно разобраться глубоко в вопросе.

3. Скомпилить используемые си-процедуры рисования с максимальной оптимизацией, взять их листинг, взять учебник по системе команд Cortex-M и оптимизировать эти процедуры на асме.

Для многих алгоритмов ручная оптимизация на асме может дать кратное увеличение скорости. Хотя может конечно и не дать - зависит от алгоритма.

цвет 16 битовый - 565. Рад бы использовать меньше, например используя CLUT но во превых такие форматы не поодерживает uGFX, а во вторых, и зто главное, в этом случае, как мне кажется, невозможно использование сглаживания шрифтов(antialiasing)

4 minutes ago, nanorobot said:

цвет 16 битовый - 565. Рад бы использовать меньше, например используя CLUT но во превых такие форматы не поодерживает uGFX, а во вторых, и зто главное, в этом случае, как мне кажется, невозможно использование сглаживания шрифтов(antialiasing)

 

UGFX явился итогом долгого выбора, во превых бесплатен, во вторых прост в освоении, в третьих не слишком требователен к железу и в четвертых, для меня главное, поодерживает работу с РТОС ChibiOs.  А с ChibiOs я практически сроднился..  Писать же свою графическую библиотеку, при наличии говых, не готов

Изменено 8 декабря, 2018 пользователем nanorobot

[jcxz 184]

13 минут назад, nanorobot сказал:

цвет 16 битовый - 565. Рад бы использовать меньше, например использую CLUT но во превых такие форматы не поодерживает uGFX, а во вторых, и зто главное, в этом случае, как мне кажется, невозможно использование сглаживания шрифтов(antialiasing)

Как я уже сказал: в оптимальном коде нет uGFX и пр. готового универсального кода. Потому что оптимальный код такой, который заточен под конкретную задачу. В простейшем случае - взято готовое и из него выпилено всё ненужное. В лучшем случае - написано своё под конкретные требования данной задачи. Любое универсальное решение - по определению неоптимально.

Вот Вы сами написали, что там что-то поддерживается или нет. Т.е. - там куча всего поддерживается. Очевидно, из этой кучи действительно никак не обойтись только без части функционала. А остальное - висит мёртвым грузом, утяжеляя, приводя к неоптимальности.

А это сглаживание реально нужно? Что нужнее сглаживание или быстрая работа?    Я уже писал про урезку карася хотелок.

 

PS: Если уж думать о переходе на другие МК и, если выяснено, что узкое место в быстродействии - именно функции рисования (а Вы это выяснили?), то имхо - лучше сменить ядро на что-то более быстрое, умеющее действительно быстро работать с данными в памяти, а не на такой же сам по себе медленный ARM. Взять например какой-нить DSP. Даже относительно простое ядро C55xx с данными в памяти работает много быстрее. А ведь есть ещё TMS320C674x или подобные ядра... 

[nanorobot 3]

4 minutes ago, jcxz said:

А это сглаживание реально нужно? Что нужнее сглаживание или быстрая работа?  

Зная моего работодателя я уверен что сглаживание абсолютно необходимо. Да даже на мой собственный взгляд корявость несглаженного шрифта  зашкаливает

[jcxz 184]

12 минут назад, nanorobot сказал:

Зная моего работодателя я уверен что сглаживание абсолютно необходимо. Да даже на мой собственный взгляд корявость несглаженного шрифта  зашкаливает

Может Вы не тот шрифт выбираете? Не знаю - вот передо мной работает мой девайс, шрифты в него я брал виндовые, стандартные, рисую сам - собственные функции рисования, 4bpp, внутренняя CCM память. Ну да - ступенчатость шрифта заметна, но только если в упор разглядывать. С расстояния ~20 см уже ничего не видно. И это у меня 320x240, а если у Вас экран большего размера, то там скорее всего и точки мельче - дискретность ещё менее заметна должна быть. Ну только если не совсем большая диагональ экрана.

 

PS: Ну так и скажите работодателю - нужно сглаживание? Тогда нужен DSP (ну или другое ядро, быстрее работающее с памятью). Но это будет стоить дороже (в плане скорости перехода на него, изучения его). Если он согласен - вперёд.  

[nanorobot 3]

Just now, jcxz said:

Может Вы не тот шрифт выбираете? Не знаю - вот передо мной работает мой девайс, шрифты в него я брал виндовые, стандартные, рисую сам - собственные функции рисования, 4bpp, внутренняя CCM память. Ну да - ступенчатость шрифта заметна, но только если в упор разглядывать. С расстояния ~20 см уже ничего не видно. И это у меня 320x240, а если у Вас экран большего размера, то там скорее всего и точки мельче - дискретность ещё менее заметна должна быть. Ну только если не совсем большая диагональ экрана.

шрифт Roboto, разные размеры генерируются конвертером от того же автора (uGFX). диагональ 7'' 800x480. Вероятно, если бы не было возможности сравнить сглаженные / несглаженные, я бы тоже так считал, что приемлемо. Но теперь обратной дороги уже нет.

[jcxz 184]

20 минут назад, nanorobot сказал:

шрифт Roboto, разные размеры генерируются конвертером от того же автора (uGFX). диагональ 7'' 800x480. Вероятно, если бы не было возможности сравнить сглаженные / несглаженные, я бы тоже так считал, что приемлемо. Но теперь обратной дороги уже нет.

Не знаю, вот мой девайс:  https://yadi.sk/i/sX7VBDNBiivrMw

Фото сделано с расстояния ~30 см, зум - почти максимальный. Как видите - если развернуть фото на весь экран (т.е. - смотреть в упор), то дискретность да - видна. Но попробуйте уменьшить картинку на экране до реального размера LCD (а реальный размер этого LCD = 73 мм по диагонали) и посмотреть с расстояния скажем 20-30 см - тогда дискретность уже становится не заметна.

[aaarrr 63]

27 minutes ago, nanorobot said:

диагональ 7'' 800x480. Вероятно, если бы не было возможности сравнить сглаженные / несглаженные, я бы тоже так считал, что приемлемо. Но теперь обратной дороги уже нет.

Могу сказать, что для приличной работы с цветом 565 на разрешении 640x480 без аппаратного ускорения еле-еле хватало ARM926 @ 456MHz с 16 битной DDR @ 156MHz (приличной работой считаю возможность полной отрисовки экрана за время меньше периода VSYNC). Использовалось сглаживание, прозрачность и chroma-keying для всяких анимаций.

 

Без сглаживания сегодня никуда, пользователи сразу выскажут свое "фи", и будут правы - лет 15 как это стандартная фича для интерфеса.

[jcxz 184]

10 минут назад, aaarrr сказал:

Без сглаживания сегодня никуда, пользователи сразу выскажут свое "фи", и будут правы - лет 15 как это стандартная фича для интерфеса.

Имхо - пользователи скажут ещё большее Фи, при тормозящем интерфейсе. По-моему задержки визуального интерфейса гораздо сильнее раздражают, чем какие-то там ступеньки.

[nanorobot 3]

3 minutes ago, jcxz said:

Имхо - пользователи скажут ещё большее Фи, при тормозящем интерфейсе. По-моему задержки визуального интерфейса гораздо сильнее раздражают, чем какие-то там ступеньки.

есть и треттий вариант - сглаживание без тормозного интерфейса.

[nanorobot 3]

2 hours ago, Arlleex said:

Я вот когда модули для лаборатории делал, себе одну платку отладочную (макет), естественно, спаял и оставил. На ней я применял F429. Сейчас запаяна туда H753, но допаять десяток конденсаторов и запустить как-то не хватает стимула ИМХО, артефакты пропадут, связанные с медленной прорисовкой. Да и поэкспериментировать не сильно большая проблема, полгода назад H753 вышел мне даже дешевле, чем F429. Покупал в Терраэлектронике, но сейчас у них дороговато. Не думаю, что плату переразводить Вам придется, хотя, вроде,  у них несовместимость в 100-выводных корпусах. У меня LQFP-176...

Верно ли я Вас понял, что у Вас завалялся() STM32H743 /LQFP176? Может уступите - за ценой не постою.

 

 

отмена. в Терре есть...

Изменено 8 декабря, 2018 пользователем nanorobot

[prottoss 0]

Доброго времени суток.

nanorobot - Вы не думали нарисовать все (совершенно все что будет выводится) до того, как потребуется вывод? Вариантов, естественно несколько. Например, первое, нарисовать все вне контроллера и ресурсы встроить в прошивку. Второе - нарисовать все (на некоторый носитель) при старте программы. В итоге выводить только битмапы.

[AlexandrY 2]

2 hours ago, prottoss said:

Доброго времени суток.

nanorobot - Вы не думали нарисовать все (совершенно все что будет выводится) до того, как потребуется вывод? Вариантов, естественно несколько. Например, первое, нарисовать все вне контроллера и ресурсы встроить в прошивку. Второе - нарисовать все (на некоторый носитель) при старте программы. В итоге выводить только битмапы.

В uGFХ это уже сделано. Называется Pixmaps

У меня подозрение, что несуразно большой дисплей TC выбрал чтобы не делать сглаживания.

 

[yes 5]

On 12/8/2018 at 1:59 PM, jcxz said:

3. Скомпилить используемые си-процедуры рисования с максимальной оптимизацией, взять их листинг, взять учебник по системе команд Cortex-M и оптимизировать эти процедуры на асме.

off (так как сам никогда не использовал GUI, ну может в каких-то DIY и давно)  - а как оцениваете этот совет для достаточно хитрого, как я понимаю, С кода библиотеки (ну всякий там антиальясинг, выравнивание по ширине шрифтов, возможно рисование, фильтры и т.п.) и современных компиляторов, которые оптимизируют "в малой окрестности" весьма неплохо ??? я бы, например, начал с ковыряния/профилирования С кода и разбора того что он делает, может быть нашел какие-то ухудшающие качество незначительно изменения и т.п. если что, я помню про Z80 pop push в сравнении со строковыми операциями, но, имхо, те времена уже ушли :(

 

[jcxz 184]

1 час назад, yes сказал:

современных компиляторов, которые оптимизируют "в малой окрестности" весьма неплохо ??? я бы, например, начал с ковыряния/профилирования С кода и разбора того что он делает,

"Весьма неплохо" - это на взгляд тех, кто не хочет напрягать свой мозг и изучать ассемблер. Когда освоите ассемблер в достаточной степени, увидите сколько там возможностей для улучшений.

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

Конечно и ковыряние и оптимизация на уровне алгоритма - тоже необходима, нужно действовать в комплексе.

Вот, для примера как-то у меня была задача - написал я функцию:

Спойлер

union AdcFastData {
  struct {
    u16 ampU;
    u16 ampV;
    u16 ampW;
    u16 voltH;  //UQ0.16
  };
  u16 raw[4];
};
void AdcAvgFastData(u16 const *src, AdcFastData *dst, uint cnt)
{
  if (!cnt) return;
  u32 u = 0, v = 0, w = 0, h = 0;
  do {
    u += *src++ << 2;
    v += *src++ << 2;
    w += *src++ << 2;
    h += *src++ << 2;
  } while (--cnt);
  dst->ampU = u / cnt;
  dst->ampV = v / cnt;
  dst->ampW = w / cnt;
  dst->voltH = h / cnt;
}

 

Скомпилилась она (максимальная оптимизация по скорости или балансная) в:

Спойлер

    436          void AdcAvgFastData(u16 const *src, AdcFastData *dst, uint cnt)
    437          {
    438            if (!cnt) return;
   \                     _Z14AdcAvgFastDataPKtP11AdcFastDataj: (+1)
   \   00000000   0xB902             CBNZ.N   R2,??AdcAvgFastData_0
   \   00000002   0x4770             BX       LR
    439            u32 u = 0, v = 0, w = 0, h = 0;
   \                     ??AdcAvgFastData_0: (+1)
   \   00000004   0xB4F0             PUSH     {R4-R7}
   \   00000006   0x2500             MOVS     R5,#+0
   \   00000008   0x2600             MOVS     R6,#+0
   \   0000000A   0x2300             MOVS     R3,#+0
   \   0000000C   0x2400             MOVS     R4,#+0
    440            do {
    441              u += *src++ << 2;
   \                     ??AdcAvgFastData_1: (+1)
   \   0000000E   0xF830 0x7B02      LDRH     R7,[R0], #+2
   \   00000012   0xEB05 0x0587      ADD      R5,R5,R7, LSL #+2
    442              v += *src++ << 2;
   \   00000016   0xF830 0x7B02      LDRH     R7,[R0], #+2
   \   0000001A   0xEB06 0x0687      ADD      R6,R6,R7, LSL #+2
    443              w += *src++ << 2;
   \   0000001E   0xF830 0x7B02      LDRH     R7,[R0], #+2
   \   00000022   0xEB03 0x0387      ADD      R3,R3,R7, LSL #+2
    444              h += *src++ << 2;
   \   00000026   0xF830 0x7B02      LDRH     R7,[R0], #+2
    445            } while (--cnt);
   \   0000002A   0x1E52             SUBS     R2,R2,#+1
   \   0000002C   0xEB04 0x0487      ADD      R4,R4,R7, LSL #+2
   \   00000030   0xD1ED             BNE.N    ??AdcAvgFastData_1
    446            dst->ampU = u / cnt;
   \   00000032   0x2000             MOVS     R0,#+0
   \   00000034   0xFBB5 0xF0F0      UDIV     R0,R5,R0
   \   00000038   0x8008             STRH     R0,[R1, #+0]
    447            dst->ampV = v / cnt;
   \   0000003A   0x2000             MOVS     R0,#+0
   \   0000003C   0xFBB6 0xF0F0      UDIV     R0,R6,R0
   \   00000040   0x8048             STRH     R0,[R1, #+2]
    448            dst->ampW = w / cnt;
   \   00000042   0x2000             MOVS     R0,#+0
   \   00000044   0xFBB3 0xF0F0      UDIV     R0,R3,R0
   \   00000048   0x8088             STRH     R0,[R1, #+4]
    449            dst->voltH = h / cnt;
   \   0000004A   0x2000             MOVS     R0,#+0
   \   0000004C   0xFBB4 0xF0F0      UDIV     R0,R4,R0
   \   00000050   0x80C8             STRH     R0,[R1, #+6]
    450          }
   \   00000052   0xBCF0             POP      {R4-R7}
   \   00000054   0x4770             BX       LR               ;; return

 

Скажете - "весьма неплохо"? А по мне - как-то не очень. И я, зная что (cnt == 0 || cnt > 4) и что входные данные (*src) - 14-битные (0...0x3FFF) и выровнены на 32бита, оптимизировал её так:

Спойлер

AdcAvgFastData:
        MOVS    R3, R2
        IT      EQ
        BXEQ    LR
        PUSH    {R4-R7,LR}
        MOVS    R6, #0                  ;u = 0
        MOV     R7, R6                  ;v = 0
        UMULL   R12, LR, R6, R6         ;w = h = u
pp_01:  SUBS    R3, #1
        LDMIA   R0!, {R4,R5}
        UXTAH   R6, R6, R4              ;u += *src++;
        ADD     R7, R7, R4, LSR #16     ;v += *src++;
        UXTAH   R12, R12, R5            ;w += *src++;
        ADD     LR, LR, R5, LSR #16     ;v += *src++;
        BNE.N   pp_01                   ;while (cnt--)
        MOVS    R0, #1 << 31            ;вычислим 0x100000000 / R2
        UDIV    R2, R0, R2
        LSLS    R2, R2, #1+2            ;первое слагаемое - для корректировки множителя до (0x100000000 / R2); второе слагаемое - сдвиг 14бит вх. данных в старшие биты
        UMULL   R7, R0, R7, R2          ;R0.l == v
        LSLS    R0, R0, #16             ;R0.l == 0; R0.h == v
        UMLAL   R6, R0, R6, R2          ;R0.l == u; R0.h == v
        UMULL   R5, R3, LR, R2          ;R3.l == h
        LSLS    R3, R3, #16             ;R3.h == h
        UMLAL   R5, R3, R12, R2         ;R3.l == w; R3.h == h
        STMIA   R1!, {R0,R3}
        POP     {R4-R7,PC}

 

Как видно - разница очень даже заметная.