Флоаты в STM32F303

Reflector

Тогда зачем IAR стек в функциях выравнивает? Просто так? :))

ARM много чего рекомендует и запрещает, например, у M0 есть инструкция DMB которая не делает ничего, но ARM все равно рекомендует ее использовать. Примерно то же и с выравниванием на 8, оно нужно только когда при прерываниях сохраняются регистры FP, но в этом случае такое выравнивание включается автоматически, независимо от настроек. В документации даже картинка есть и псевдокод:

Код:

PushStack(integer ExceptionType)
   if HaveFPExt() && CONTROL.FPCA == '1' then
      framesize = 0x68;
      forcealign = '1';
   else
      framesize = 0x20;
      forcealign = CCR.STKALIGN;
   .....

Это и M7 касается, тем не менее ARM deprecates implementation or use of 4-byte SP alignment

Реклама

jcxz

Eddy_Em писал(а):

Мужики! Мне тут в ЖЖ товарищи подсказали наилучший перевод слова "быдлокод"

Видимо они это сказали когда увидели такое:

Код:

    // now convert float to 1.xxxE3y
    while(x > 1000.f){
        x /= 1000.f;
        pow += 3;
    }
    if(x > 0.) while(x < 1.){
        x *= 1000.f;
        pow -= 3;
    }

Добавлено after 1 minute 1 second:

Reflector писал(а):

По большому счету даже правильность работы любительских функций форматирования для чисел с плавающей точкой под большим вопросом...

Это точно! Когда видишь такое, как выше.... :facepalm:

Реклама

Eddy_Em

jcxz, а у тебя есть лучше вариант, как легко и просто получить десятичную степень флоата?

jcxz

Eddy_Em писал(а):

jcxz, а у тебя есть лучше вариант, как легко и просто получить десятичную степень флоата?

Подсмотреть как делает printf()? Не?

Например по школьной формуле:

a = 2; c = 10; b = число.

Реклама

Эиком - электронные компоненты и радиодетали

AVI-crak

Не знаю как лучше, но деление в цикле явно самый провальный вариант. Например для 3.40282346639e+38 накопится значительная ошибка. А для чисел ниже 1.00000011116e-06 ошибку будет видно сразу.
Eddy_Em - чем таблицы не угодили?

Реклама

Eddy_Em

jcxz писал(а):

Например по школьной формуле

Не хватало еще логарифм табулировать ради этого!

Добавлено after 3 minutes 41 second:

AVI-crak писал(а):

Например для 3.40282346639e+38 накопится значительная ошибка. А для чисел ниже 1.00000011116e-06 ошибку будет видно сразу.

Вывод 2.473829e31 с 0-4 цифрами после точки:

Код:

Вывод -1.23456789e-37:

Код:

-123E-39
-123.5E-39
-123.46E-39
-123.457E-39
-123.4568E-39

Я ж проверил сразу несколько разных чисел.

Добавлено after 2 minutes 43 seconds:
У меня сейчас другая беда: USB настраиваю (в тактировании проверил - PLL делится на 1.5 для USB), активирую подтяжку - и тишина. В прерывание не входит.
Ищу, где ж я накосячил.
Причем, здесь практически полностью USB можно с F103 содрать за исключением имени обработчика прерывания.

Реклама

Reflector

Eddy_Em писал(а):

проверил сразу[/url] несколько разных чисел.

Точность выше всяких похвал получилась, у себя делю минимальные 1.1754943E-38 на 2 и получаю 0, а у тебя делю на миллион и получаю 11.2104E-45

Осталось бесконечность починить, на ней тоже виснет

jcxz

Eddy_Em писал(а):

jcxz писал(а):

Например по школьной формуле

Не хватало еще логарифм табулировать ради этого!

Зачем его "табулировать"?
Включите голову!

Добавлено after 3 minutes 32 seconds:

Eddy_Em писал(а):

Я ж проверил сразу несколько разных чисел.

Чтобы проверить, надо немного голову задействовать.
Проверяют на критичных (граничных) условиях, а не на каких попало. Критичные условия будут на таких числах, на которых ошибка округления скажется. А ваша "проверка" - профанация. В утиль. :dont_know:

AVI-crak

Reflector писал(а):

у себя делю минимальные 1.1754943E-38 на 2 и получаю 0

Кхм, минимальное это 1.40129846432e-45.
https://www.h-schmidt.net/FloatConverter/IEEE754.html
Поиграйся немного.

Реклама

VladislavS

Eddy_Em писал(а):

У меня сейчас другая беда: USB настраиваю (в тактировании проверил - PLL делится на 1.5 для USB), активирую подтяжку - и тишина. В прерывание не входит.
Ищу, где ж я накосячил.

Осталось конфигурацию ног проверить.

Eddy_Em

VladislavS, В точку! Я пошел погулять (благо, у нас тут вероятность во время прогулки людей встретить очень низкая, а то в каком-нибудь говногороде я со своей короной сидел бы дома круглосуточно!), стал обдумывать - и вспомнил, что ноги не настроил на альтернативную функцию!

Вот все-таки не понимаю инженеров ST: они взяли вроде бы лучшее от STM32F0 и засунули в 303. Но USB оставили тот самый убогий, который у F103. Ну, благо, хоть CAN и USB одновременно работать могут (я, кстати, глянул внимательно даташит: у B и C 512 байт буфера USB не делятся с CAN - и на том спасибо).
Но, блин, нет HSI48 и внутренней подтяжки — вот что за ë-моë?!
Да и эти убогие регистры USB'шные, где часть флагов set/reset, а часть — toggle! Это ж что они там курили-то? Но, видать, т.к. решили оставить наследие (чтобы не переписывать USB), в более поздних моделях те же самые косяки оставили. Мудаки, блин!

jcxz

Reflector писал(а):

jcxz писал(а):

Тогда зачем IAR стек в функциях выравнивает? Просто так? :))

ARM много чего рекомендует и запрещает, например, у M0 есть инструкция DMB которая не делает ничего, но ARM все равно рекомендует ее использовать. Примерно то же и с выравниванием на 8, оно нужно только когда при прерываниях сохраняются регистры FP

Сделаем маленький тест:

Код:

__packed struct {
  float x;
  double y[2];
} static t __align64 = {1.f, {1., 2.}};
Zf2((double *)t.y);

...

void Zf2(double *p)
{
  u32 m[8];
  memset(m, 0xEE, sizeof(m));
  LogCR0("addr = %08X; SP = %08X; m = %08X", p, __get_SP(), m);
  LogCR0("1: y1 = %f; y2 = %f", p[0], p[1]);
  __set_SP(__get_SP() + 4);
  LogCR0("2: y1 = %f; y2 = %f", p[0], p[1]);
  __set_SP(__get_SP() - 4);
}

Функции LogCR0() имеют printf()-подобный интерфейс вызова (изнутри вызывают библиотечную _Printf()) и печатают в поток отладочного вывода.
Результат работы Zf2((double *)t.y) (напечатанный результат):

Цитата:

addr = 1000DB44; SP = 1000CF98; m = 1000CFA0
1: y1 = 1.000000; y2 = 2.000000
2: y1 = 0.000000; y2 = 0.000000

Как нетрудно заметить - в случае с SP не выровненным на 8 (а только на 4) получаем неверный результат.
Листинг Zf2() (на всяк случай):

Спойлер

Код:

void Zf2(double *p)
{
        _Z3Zf2Pd: (+1)
 0xB510             PUSH     {R4,LR}
 0xB08A             SUB      SP,SP,#+40
 0x4604             MOV      R4,R0
  u32 m[8];
  memset(m, 0xEE, sizeof(m));
 0x22EE             MOVS     R2,#+238
 0x2120             MOVS     R1,#+32
 0xA802             ADD      R0,SP,#+8
 0x.... 0x....      BL       __aeabi_memset4
  LogCR0("addr = %08X; SP = %08X; m = %08X", p, __get_SP(), m);
 0x466A             MOV      R2,SP
 0xAB02             ADD      R3,SP,#+8
 0x4621             MOV      R1,R4
 0x.... 0x....      ADR.W    R0,?_14
 0x.... 0x....      BL       _Z12ServiceLogCRPKcz
  LogCR0("1: y1 = %f; y2 = %f", p[0], p[1]);
 0xED94 0x0B02      VLDR     D0,[R4, #+8]
 0xED8D 0x0B00      VSTR     D0,[SP, #+0]
 0xE9D4 0x2300      LDRD     R2,R3,[R4, #+0]
 0x.... 0x....      ADR.W    R0,?_15
 0x.... 0x....      BL       _Z12ServiceLogCRPKcz
  __set_SP(__get_SP() + 4);
 0x4668             MOV      R0,SP
 0x1D00             ADDS     R0,R0,#+4
 0x4685             MOV      SP,R0
  LogCR0("2: y1 = %f; y2 = %f", p[0], p[1]);
 0xED94 0x0B02      VLDR     D0,[R4, #+8]
 0xED8D 0x0B00      VSTR     D0,[SP, #+0]
 0xE9D4 0x2300      LDRD     R2,R3,[R4, #+0]
 0x.... 0x....      ADR.W    R0,?_16
 0x.... 0x....      BL       _Z12ServiceLogCRPKcz
  __set_SP(__get_SP() - 4);
 0x4668             MOV      R0,SP
 0x1F00             SUBS     R0,R0,#+4
 0x4685             MOV      SP,R0
}
 0xB00A             ADD      SP,SP,#+40
 0xBD10             POP      {R4,PC}

IAR ANSI C/C++ Compiler V7.80.4.12462/W32 for ARM

Вывод: Выравнивание SP на 8 необходимо! А не просто рекомендуемо. Как минимум - если используются функции стандартной си-библиотеки (семейство ...printf() и т.п.). И IAR не просто так выравнивает стек во всех функциях, из которых вызываются другие.

Reflector

AVI-crak писал(а):

Кхм, минимальное это 1.40129846432e-45.

Да, стандартная функция numeric_limits<float>::min() ввела меня в заблуждение поскольку выдает минимум для нормализованных чисел, однако аппаратно кортексы только их и поддерживают(denormalized numbers are flushed to 0 before floating-point operations), видимо потому моя функция 0 и выдает...

Добавлено after 22 minutes 21 second:

jcxz писал(а):

Как нетрудно заметить - в случае с SP не выровненным на 8 (а только на 4) получаем неверный результат.

А если написать:

Код:

__set_SP(__get_SP() + 8);

то результат будет правильный?

Eddy_Em

Интересненько: перед инициализацией USB пишу:

Код:

SYSCFG->CFGR1 |= SYSCFG_CFGR1_USB_IT_RMP;

И… Фигвам! Все равно вместо usb_lp_isr срабатывает прерывание usb_lp_can1_rx0_isr! Вот что за труляля?!!
А ведь, судя по даташиту, должно работать! Иначе как я разделю прерывания для USB и CAN?

Судя по тому, что после установки этот бит отсутствует, китайцы продали какой-то очень странный чип, выдающий себя за F303, но таковым не являющийся!

Reflector

Eddy_Em писал(а):

Код:

SYSCFG->CFGR1 |= SYSCFG_CFGR1_USB_IT_RMP;

И… Фигвам!

Может тактирование SYSCFG не включил?

Eddy_Em

Reflector, да что ж такое! Я уже в который раз на этом попадаюсь!..
Кстати, в F0x2 не нужно было альтернативные функции на ноги включать, да и тактирование SYSCFG тоже… В общем F303 — это просто жесть какая-то!..

jcxz

Reflector писал(а):

А если написать:

Код:

__set_SP(__get_SP() + 8);

то результат будет правильный?

Естественно:

Код:

addr = 1000DB44; SP = 1000CF98; m = 1000CFA0
1: y1 = 1.000000; y2 = 2.000000
2: y1 = 1.000000; y2 = 2.000000

PS:

Код:

void Zf2(double *p)
{
  u32 m[8];
  memset(m, 0xEE, sizeof(m));
  LogCR0("1: addr = %08X; SP = %08X; m = %08X", p, __get_SP(), m);
  LogCR0("1: y1 = %f; y2 = %f", p[0], p[1]);
  __set_SP(__get_SP() + 4);
  LogCR0("2: addr = %08X; SP = %08X; m = %08X", p, __get_SP(), m);
  LogCR0("2: y1 = %f; y2 = %f", p[0], p[1]);
  __set_SP(__get_SP() + 4);
  LogCR0("3: addr = %08X; SP = %08X; m = %08X", p, __get_SP(), m);
  LogCR0("3: y1 = %f; y2 = %f", p[0], p[1]);
  __set_SP(__get_SP() - 8);
}
static void DteZf1()
{
  __packed struct {
    float x;
    double y[2];
  } static t __align64 = {1.f, {1., 2.}};
  Zf2((double *)t.y);
}

Вывод:

Цитата:

1: addr = 1000DB44; SP = 1000CF98; m = 1000CFA0
1: y1 = 1.000000; y2 = 2.000000
2: addr = 1000DB44; SP = 1000CF9C; m = 1000CFA4
2: y1 = 0.000000; y2 = 0.000000
3: addr = 1000DB44; SP = 1000CFA0; m = 1000CFA8
3: y1 = 1.000000; y2 = 2.000000

Eddy_Em

Эх, не выходит цветочек каменный: не подошел код от F103 — не проходит энумерация… Чую, что что-то не так с этими дебильными обращениями к памяти (где-то нужно их к uint16_t приводить, где-то — к uint8_t…)
Придется сравнивать мануалы на F103 и F303. А в апноуте по миграции с F103 на F303 ни хрена про USB не сказано ☹
Но оно даже до стадии USB_ISTR_CTR не доходит! В ISTR постоянно флаги ERR и ESOF…

VladislavS

Ничем они не отличаются вообще. Под спойлером кусочек кода, в котором отражена вся разница в реализации USB на шести семействах (те что не OTG). Всё запускается влёт, даже скучно как-то.

Спойлер

Вложение:

pma.png [40.69 KiB]
Скачиваний: 112

Кроме как nigger-code твои проблемы трудно объяснить.

Eddy_Em

VladislavS писал(а):

Кроме как nigger-code твои проблемы трудно объяснить.

Эт точно. Только быдлокод один и тот же, но на F103 работает, а на F303 вызывает ERR…
ХЗ, копаюсь в этом Г дальше.

Флоаты в STM32F303

Кто сейчас на форуме