[Rst7 5]

3 hours ago, haker_fox said:

Но в целом компилятор не упрекнёшь) Функция dprintf не будет вызвана.

Тут главное не забыть в релизе сделать так:

#define CHECK_PARAM(expr)

Чтобы функция приняла вменяемый вид без насилия над стеком:

   \                                 In section .text, align 2, keep-with-next
    137          uint32_t GPIO_ReadValue( uint8_t portNum ) 
    138          {
    139              CHECK_PARAM(portNum < 8);
    140              return LPC_GPIO_PORT->PIN[portNum];
   \                     GPIO_ReadValue: (+1)
   \        0x0   0x....             LDR.N    R1,??DataTable4  ;; 0x400f6100
   \        0x2   0xF851 0x0020      LDR      R0,[R1, R0, LSL #+2]
   \        0x6   0x4770             BX       LR               ;; return

Ну и, к сожалению, inline - это вообще редкая птица во всяких этих библиотеках для не умеющих прочитать содержимое порта сразу по месту в собственном коде.

[haker_fox 61]

2 hours ago, Rst7 said:

Тут главное не забыть в релизе сделать так:

Я в релизе оставляю. Ибо пусть лучше сработает такая ловушка с последующим логированием, чем причина непонятной работы прибора останется тайной.

2 hours ago, Rst7 said:

Ну и, к сожалению, inline - это вообще редкая птица во всяких этих библиотеках для не умеющих прочитать содержимое порта сразу по месту в собственном коде.

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

[Rst7 5]

26 minutes ago, haker_fox said:

Я в релизе оставляю. Ибо пусть лучше сработает такая ловушка с последующим логированием, чем причина непонятной работы прибора останется тайной.

На каждое чтение порта вот такое вот? Зачем тогда сама тема про анализ листингов? Смысл их анализировать, если быстродействие релиза реально проваливается просто отказом от удаления отладочных пирогов?

И да, неужели настолько сложно написать работу с портами с предсказуемыми последствиями?

[haker_fox 61]

4 minutes ago, Rst7 said:

На каждое чтение порта вот такое вот?

В железяке, для которой программа, работы с GPIO очень мало, и она проводится один раз по-сути, при настройке системы. Далее работают DMA, SSP, SGPIO (LPC4337) и прочая периферия.

4 minutes ago, Rst7 said:

Зачем тогда сама тема про анализ листингов?

Как зачем? Я, кажется, уже говорил: для личного роста. Но это же не значит, что я сейчас брошусь оптимизироваться всё, что попадётся на глаза) Вот сегодня весь день сидел как раз листинги анализировал, почему DMA тормозит при передачи данных. Нашёл проблемы. Оптимизировал код в прерывании: переписал функции так, чтобы компилятор их инлайнил, соответственно убирал вызовы, прологи, эпилоги; оптимизировал работу с кучей данных. Асм здесь очень хорошо помог. Всё работает теперь. Но GPIO... да фиг с ними. Дёргались бы из прерываний, тогда да.

7 minutes ago, Rst7 said:

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

Гм... у вас такой огромный опыт, а вы делаете безосновательные выводы. Простите за резкость. Но как вы так можете говорить не зная ничего о проекте, кроме одной функции?

8 minutes ago, Rst7 said:

И да, неужели настолько сложно написать работу с портами с предсказуемыми последствиями?

Нет. Я могу и по адресам напрямую писать. И написать "инлайниющиеся" функции. Могу и на Си++ что-то сделать) Просто в данном проекте не хочу трогать GPIO. Будем считать, что это моя личная неприязнь. Не люблю я порты ввода-вывода обычные) И ещё: я программы пишу для работы на фирме. и для себя лично дома) Во втором случае я делаю всё тщательно. В первом (не думайте, что я хреново отношусь к обязанностям) случае мне иногда просто запрещают...

[Rst7 5]

1 minute ago, haker_fox said:

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

Там же небось такой рукопашный assert один на всех. И прекрасно живет и во всех остальных библиотечных процедурах, в том числе и тех, которые

5 minutes ago, haker_fox said:

Далее работают DMA, SSP, SGPIO (LPC4337) и прочая периферия.

 

[haker_fox 61]

1 minute ago, Rst7 said:

Там же небось такой рукопашный assert один на всех.

Добавляется запись в аварийный журнал в энергонезависимую память.

[Rst7 5]

Just now, haker_fox said:

Добавляется запись в аварийный журнал в энергонезависимую память.

Я не об этом. А о том, что куча таких же кривых проверок и насилия над стеком есть и в других процедурах библиотеки. Или у Вас только GPIO через библиотеку, а упомянутая остальная периферия - вся аккуратненько врукопашную?

[haker_fox 61]

1 minute ago, Rst7 said:

Я не об этом. А о том, что куча таких же кривых проверок и насилия над стеком есть и в других процедурах библиотеки.

Часть сделана через либы CMSIS, часть лично.

1 minute ago, Rst7 said:

вся аккуратненько врукопашную?

Кстати, а что вы под этим подразумеваете? Стиль кодирования?

[Rst7 5]

5 minutes ago, haker_fox said:

Кстати, а что вы под этим подразумеваете? Стиль кодирования?

Конкретно в данном случае - без использования CMSIS.

Теперь о рукопашности этого ассерта и вообще кривости конкретно данного кода.

Правильно писать вот так, если не отключать ассерты:

  if (portNum>=8)
    return LPC_GPIO_PORT->PIN[portNum];
  else
    Abort();

Потому что ветка true - это более частая ветка, скорее всего с вероятностью 100%.

[haker_fox 61]

1 minute ago, Rst7 said:

Конкретно в данном случае - без использования CMSIS.

Ок.

1 minute ago, Rst7 said:

Правильно писать вот так, если не отключать ассерты:

Надо будет скомпилировать, поглядеть на выхлоп.

Кстати, а как вы делаете Abort(). Не используете SVC и MPU?

[Rst7 5]

16 minutes ago, haker_fox said:

Кстати, а как вы делаете Abort(). Не используете SVC и MPU?

Я - никак не делаю, живу жизнь без ассертов. Конкретно в данном случае это всего лишь пример, там можете строить что хотите сами. Но если бы конкретно мне понадобилась такая конструкция, то я бы сгенерировал исключение каким-то образом, а потом разбирался уже исключительно по PC (например, напечатав его в обработчике исключения). Немногим труднее, чем имя функции и номер строки, но зато куда меньше попутных приколов, например, совершенно не нужной в обычной жизни работе со стеком.