Jump to content

    
Sign in to follow this  
alexf

STM32F0xxx USB без HAL

Recommended Posts

typedef struct {
    uint16_t value;
} __attribute__((packed)) unaligned_uint16;

((unaligned_uint16*)bla_bla).value = ...;

В вашем решении много битовых операций на ровном месте.

Да ладно вам стращать:) Современные компиляторы отлично оптимизируют конструкции вида

    *(tmpbuf + 2) = totallen & 0xFF;
    *(tmpbuf + 3) = totallen >> 8;

Думаю, что код, сгенерированный компилятором в вашем варианте и в этом будет эквивалентен. Зато этот вариант понятнее, к тому же он переносим.

 

Share this post


Link to post
Share on other sites
memcpy при оптимизациях Os\O3 меня уже пару раз подводила.
Интересно. Когда подведет еще раз - выложите сюда, вероятнее всего вы просто не умеете ее готовить.

 

Share this post


Link to post
Share on other sites
Да ладно вам стращать:) Современные компиляторы отлично оптимизируют конструкции вида

Поинт был не в том. :) Согласен что эффективность будет одинаковая. Но читать код как у ТСа мне хуже чем другие варианты. Я его просто буду раз десять перечитывать что бы точно убедится что не меняется порядок байт, в др. вариантах назначение кода сразу очевидно. Во-вторых в варианте ТСа куча чисел. В спокойной обстановке всё конечно ясно, но порой код редактирует, к примеру, коллега автора и находится он не в лучшем состоянии ума и тогда возможны любые чудеса - уже испытывал это.

 

Зато этот вариант понятнее, к тому же он переносим.

Для упрощения примера я вставил сразу gcc'шный вариант, но в боевом это макросы в зависимости от платформы. Так что упакованная структура так же переносима.

Share this post


Link to post
Share on other sites
Интересно. Когда подведет еще раз - выложите сюда, вероятнее всего вы просто не умеете ее готовить.

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

Помню, что ошибка проявлялась при совместном использовании оптимизации по размеру и LinkTimeOptimization (Os и flto).

Проект был по CooCox и они только добавили опцию LTO у себя в настройках компиляции.

Обошел ее используя не библиотечную реализацию:

__attribute__((used)) void * memcpy(void * d1, const void * s1, size_t n) {
    char * d;
    const char * s;
    volatile size_t n1 = n;
    s = s1;
    d = d1;
    while (n1--)
        *d++ = *s++;
    return d1;
}

"помогало" именно создание volatile'ной переменной и дальнейшая работа с ней.

в противном случае (при использовании аргументной переменной n) бесконечно висел в while - уменьшение переменной не происходило.

причем висело не в моем коде, а внутри функций freertos (тогда то ли 6, то ли 7 версии).

понимаю, что это все выглядит как рассказ про йети, но... :laughing:

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this