Я б написав так

 const uint16_t digitPin[] = {D0_Pin,D1_Pin,D2_Pin,D3_Pin};

і зберіг 8 байт в RAM. і не побоявся б навіть винести за межі функції.

Сильно мерехтить індикація?

Не «не побоявся б», а «обов'язково», інакше різниці з варіантом без const не буде взагалі.

Принаймні, в межах стандарту у тілі функції це буде зроблено константну автоматичну змінну, яка розміщена на стекові, а не деінде. Різниця з варіантом без const лише в тому, що компілятор не дасть її поміняти (також може уоптимізувати звернення з константним індексом, тобто digiPin[1] відразу дасть потрібну константу, а не лізтиме у масив). А так — і те і те на стекові, і те і те ініціалізується там у момент виклику функції копіюванням образу з секції .rodata.

Але речі, потрібні лише одній функції, краще в ній і описувати, не виносити у глобальні. А щоб розмістило не на стекові і не ініціалізувало кожен раз, треба дати static const. За виключенням області видимості це буде те ж саме, що просто const за межами функції, масив так і буде у секції .rodata, зекономиться як глибина стеку, так і код (мінус копіювання flash -> RAM).
Порівняйте (скрізь arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -O2, версія 4.9.3):

int foo(int i)
{
    int  d[] = {0,1,2,3};
    return d[i&0x03];
}

foo:
    push    {r4, lr}
    ldr    r3, .L3  // адреса образу в .rodata
    sub    sp, sp, #16  // резерв місця під локальний масив
    add    lr, sp, #16
    and    r4, r0, #3
    ldmia    r3, {r0, r1, r2, r3}  // ініціалізація масиву
    stmdb    lr, {r0, r1, r2, r3}
    add    r4, lr, r4, lsl #2    // звертання до локального масиву
    ldr    r0, [r4, #-16]
    add    sp, sp, #16
    @ sp needed
    pop    {r4, pc}
.L4:
    .align    2
.L3:
    .word    .LANCHOR0
    .size    foo, .-foo
    .section    .rodata
    .align    2
    .set    .LANCHOR0,. + 0
.LC0:
    .word    0
    .word    1
    .word    2
    .word    3

тепер зі словом const — «знайдіть відмінноcті» ;-)

int moo(int i)
{
    const int d[] = {10,11,12,13};
    return d[i&0x03];
}
moo:
    push    {r4, lr}
    ldr    r3, .L3
    sub    sp, sp, #16
    add    lr, sp, #16
    and    r4, r0, #3
    ldmia    r3, {r0, r1, r2, r3}
    stmdb    lr, {r0, r1, r2, r3}
    add    r4, lr, r4, lsl #2
    ldr    r0, [r4, #-16]
    add    sp, sp, #16
    pop    {r4, pc}
.L4:
    .align    2
.L3:
    .word    .LANCHOR0
    .size    moo, .-moo
    .section    .rodata
    .align    2
    .set    .LANCHOR0,. + 0
.LC0:
    .word    10
    .word    11
    .word    12
    .word    13

А от тепер static const

int kwa(int i)
{
    static const int d[] = {20,21,22,23};
    return d[i&0x03];
}
kwa:
    ldr    r3, .L2
    and    r0, r0, #3
    ldr    r0, [r3, r0, lsl #2]
    bx    lr
.L3:
    .align    2
.L2:
    .word    .LANCHOR0
    .size    kwa, .-kwa
    .section    .rodata
    .align    2
    .set    .LANCHOR0,. + 0
    .type    d.4078, %object
    .size    d.4078, 16
d.4078:
    .word    20
    .word    21
    .word    22
    .word    23

До речі, просто static (або винесення за межі функції) було б з точки зору розміру коду краще, ніж просто const без винесення за межі функції, бо масив ініціалізувався б один раз при старті програми разом з усією секцією .data.

Про const теж не забувайте :-)
Якщо на щось можна навісити const, це варто зробити. Десь вбереже від набажаної зміни, десь додасть простору для роботи оптимізатора.

Хтось може мені допомогти? Бо я мабуть чогось не розумію.
Так як CooCox скоріше мертвий чим живий, став пробувати інші засоби розробки такі як System Workbench for STM32 та TRUE Studio проблема одна й та ж. Ні debugger ні RUN не працюють.

Наприклад в System Workbench

Помилка дебагера:

Помилка RUN:

Підозрюю що треба налаштувати щось там, але я не знаю що. Гугл не помагає в цьому. В CooCox все просто build, debagg, flash. А тут build тільки працює і заливаю прошивку через сторонній прошивач. ST-LINK utility.

System WorkBench і TRUE Studio основані на ECLIPSE і між собою схожі. Думаю проблема одна й та ж. Треба якось налаштувати правильно. А як?

Напишіть файл крос-дефайнів, наприклад:

#define LCD_RS            LCD_RS_Pin
... і так далі

це дає можливість взяти за LCD_RS те, що береться для LCD_RS_Pin.

...буде незручно, але скористуйтеся макросом:

#define MASK2PIN(mask) ((mask&0001)?0:(mask&0x0002)?1:(mask&0x0004)?2:(mask&0x0008)?3: \
  (mask&0x0010)?4:(mask&0x0020)?5:(mask&0x0040)?6:(mask&0x0080)?7: \
  (mask&0x0100)?8:(mask&0x0200)?9:(mask&0x0400)?10:(mask&0x0800)?11: \
  (mask&0x1000)?12:(mask&0x2000)?13:(mask&0x4000)?14:(mask&0x8000)?15:0)

Таким чином, потім треба додати:

#define RS_PIN_NUMBER (MASK2PIN(RS_PIN)) 

Ну так навіть краще ).
Незручності в тому, що цей макрос перетворює одне число в друге тільки у випадку оптимізації. Тобто оптимізатор бачить, що ваша "D5_PIN_NUMBER" залежить лише від констант і перетворює низку поривнянь и масок до одної константи. А якщо ви із якоїсь причини відключите оптимізацію - компілятор завжди буде втикать 16 масок и 16 порівнянь кожен раз, для кожної дії з бітами. Хоча, можливо, він цього и не зробить - я точно не знаю. Різні компілятори діють по-різному. Але я зустрічав такі випадки, коли код був просто геть скаженим після компіляції. Наприклад, GCC може вертати з функції 16-бітне число в регістрах, навіть якщо функція має 8-мибітне зворотнє значення. І навіть у випадку використання inline-асемблера.

Вітання.
Зробив лічильник подій 4х4, всього 16. Подія фіксується контактами реле. Через оптрон на мікроконтролер. Спочатку схема оптопари була як на схемі ліворуч. Іноді один лічильник ловив хибне спрацювання. За добу 10 -20 похибок. Можливо ще один лічильник давав близько 1 похибки на добу.
Щоб виправити ситуацію, додав до схем RC фільтр, схема що праворуч, щоб навіяне в дротах на землю гасив. Стало ще гірше. Тепер вже 4 лічильники з 16 ловлять хибні спрацювання, які рахуються десятками за годину. Як так? Покращив схему, а стало гірше?

На схемі К.Р. - контакти реле. МК - ніжка мікроконтролеру.
Є якісь думки, поради? Програмний антибрязкіт є. Опитуються всі лічильники і виставляється заборона на подальше опитування. Через 50 мілісекунд виставляється дозвіл на опитування. Між було і стало в схемі - програма не мінялась.

Схема ж є! Зразу приліпив. Не видно? А код ні при чому.
Та й вже сам розібрався. Збільшив номінал опору на світлодіоді оптичної пари. Типу збільшив поріг спрацювання. Все нормально.

Хто може буде оновлювати STMCubeMX до 4.17.0 є підводна каменюка http://stm32withoutfear.blogspot.com/20 … -4170.html