[HardEgor 63]

Не могу понять что за дичь они написали и как этим планировали пользоваться?
 

  * @param  FlashAddress specifies the address to be programmed.
  * @param  DataAddress specifies the address of data (256 bits) to be programmed

HAL_StatusTypeDef HAL_FLASH_Program(uint32_t TypeProgram, uint32_t FlashAddress, uint64_t DataAddress)
{
  __IO uint64_t *dest_addr = (__IO uint64_t *)FlashAddress;
  __IO uint64_t *src_addr = (__IO uint64_t*)((uint32_t)DataAddress);
  uint8_t row_index = 4;
......
  /* Program the 256 bits flash word */
  do {
    *dest_addr++ = *src_addr++;
  } while (--row_index != 0);

Т.е. они передают как-то адрес в  DataAddres(а почему не указатель?) приводят его к 32 битам, берут с него указатель на 64-бит и записывают 4 раза. А почему не сразу указатель на 64-бит? Чего они хотели добиться? У H7 при записи надо набить внутренний буфер любыми данным(8-, 16-, 32-битными) до 256 бит и тогда начнется запись этого буфера. Почему не передают, как обычно, указатель на 32-битные данные? Или они предполагают использование 64-битных адресов?

[scifi 1]

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

[jcxz 184]

27 минут назад, HardEgor сказал:

Т.е. они передают как-то адрес в  DataAddres(а почему не указатель?) приводят его к 32 битам, берут с него указатель на 64-бит и записывают 4 раза. А почему не сразу указатель на 64-бит? Чего они хотели добиться? У H7 при записи надо набить внутренний буфер любыми данным(8-, 16-, 32-битными) до 256 бит и тогда начнется запись этого буфера. Почему не передают, как обычно, указатель на 32-битные данные? Или они предполагают использование 64-битных адресов?

В списке аргументов функции похоже на то, что забыли звёздочки.

Почему не указатели на 32-битные данные? Видимо хотели чтобы копирование выполнялось 64-битными словами. Т.е. - командами LDRD/STRD. А если компилятор умный - он такой цикл вообще может на одну пару команд LDM/STM заменить. С указателями (uint32_t *) так сделать нельзя - можно получить исключение невыровненного доступа. Поэтому оптимизатор для них не сможет использовать LDRD/STRD или LDM/STM сразу. Ну разве только после анализа в runtime выровненности адресов, а это опять - лишние команды.

Итого - это попытка помочь оптимизатору сделать более быстрый код. Имхо.

 

PS: Хотя конечно делать счётчик цикла 8-битным на ARM - откровенная глупость. Это как раз может навредить оптимальности кода.

 

[HardEgor 63]

2 часа назад, jcxz сказал:

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

В stm32f7xx_hal_flash.c  процедура описана так:

HAL_StatusTypeDef HAL_FLASH_Program(uint32_t TypeProgram, uint32_t Address, uint64_t Data)

Но у F7 понятно почему 64 - максимальный записываемый блок, но тоже непонятно почему не указатели, а значения. Видимо H7 и унаследовал формулу F7, но потребовало доработки "напильником" :).

 

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

[Forger 17]

3 hours ago, jcxz said:

PS: Хотя конечно делать счётчик цикла 8-битным на ARM

Для такого случая существует конструкция вида:

for (auto i = ..... ) 

 

[scifi 1]

10 hours ago, Forger said:

Для такого случая существует конструкция вида:

for (auto i = ..... ) 

 

Это то же самое, что и "for (int i = ...)", только вызывает предупреждение. Короче, ерунда ерундовая.

[Forger 17]

19 minutes ago, scifi said:

Это то же самое, что и "for (int i = ...)", только вызывает предупреждение. Короче, ерунда ерундовая.

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

[scifi 1]

27 minutes ago, Forger said:

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

Практически свежайший gcc. Почитайте, что такое auto, узнаете для себя много интересного.

[Forger 17]

21 minutes ago, scifi said:

Практически свежайший gcc. Почитайте, что такое auto, узнаете для себя много интересного.

Так покажите пожалуйста, где этот auto как вполне рядовая вещь начиная аж с C++11, стала вдруг создавать такие проблемы (на примере цикла for) ?

[antis 1]

А это не спасает от предупреждения?

    for (auto i = 0u;...)

 

[Forger 17]

О каком предупреждении идет речь?

 

[antis 1]

12 часов назад, Forger сказал:

Для такого случая существует конструкция вида:

for (auto i = ..... ) 

 

Это то же самое, что и "for (int i = ...)", только вызывает предупреждение. Короче, ерунда ерундовая.

[Forger 17]

27 minutes ago, antis said:

Это то же самое, что и "for (int i = ...)", только вызывает предупреждение. Короче, ерунда ерундовая.

Есть некое "предупреждение", но никто не может его продемонстрировать... Странно это, мистика 

И на какой стандарт настроен компилятор (ключи компиляции)?

 

Это?

warning: 'auto' type specifier is incompatible with C++98 [-Wc++98-compat]

 

[scifi 1]

48 minutes ago, Forger said:

О каком предупреждении идет речь?

Предупреждение: "так как тип не указан, подразумевается int".

Ну и да, если не хотите почитать, что такое "auto", то и не надо. Так даже лучше: невежество - блаженство, меньше знаешь - лучше спишь, от многой мудрости много скорби, умножающий знание умножает печаль и т.д.

[scifi 1]

1 hour ago, Forger said:

Так покажите пожалуйста, где этот auto как вполне рядовая вещь начиная аж с C++11, стала вдруг создавать такие проблемы (на примере цикла for) ?

А, понятно. У меня C99. С плюсами не связываюсь. Эти редиски начали ломать совместимость с C? Предали заветы Страуструпа