Лучше не использовать типы char в stm32?

Eddy_Em

У меня ни гигабайтных браузеров, ни игр не получается. Я стараюсь использовать ресурсы экономно.
А вот разработчики браузеров и всякой прочей жирноты - да, похоже вообще болт ложили на пользователей. Они, похоже, априори считают, что у всех мейнфрейм на 256 ядер по 2.5ГГц каждое, а оперативы минимум 1ПБ!

Реклама

tonyk

Eddy_Em писал(а):

Если он хочет char отобразить как int, так пусть и вызывает printf("%d\n", c)

..и сядет в лужу, о чём я выше написал.
Ты запрашиваешь %d, то есть тип int, который даже на восьмибитках имеет размер 16 бит, а передаёшь char, размером 8 бит. Понимаешь, что получится?
Если МК загружен основной задачей на 90%, то нужно подумать об оптимизации преобразования для печати. А если же загрузка 10%, то используй то, что проще и удобней, лишь бы памяти хватило.

Реклама

Eddy_Em

Ничего страшного не будет. Неявно char преобразуется в int, оба типа знаковые, так что косяков не будет.

AVI-crak

Кхм, у меня char (символ без терминального нуля) - печатается не Hex коде. Потому как не ограничен в диапазоне видимых знаков. А вот когда это текст с закрывающем нулём - вот тогда велком.

Реклама

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

Dimon456

Спойлер

Код:

char str[4];

str[0] = 0x35;
str[1] = 0x36;
str[2] = 0x33;
str[3] = 0;

printf("%d\n", (int)str);         //"201"      

printf("%s\n", str);            //"563"      

puts(str);                     //"563"

Спойлер

Код:

char str[4];,

str[0] = 5;
str[1] = 6;
str[2] = 3;
str[3] = 0;

printf("%d\n", (int)str);         //"201"      

printf("%s\n", str);            //"   "      

puts(str);                     //"   "      

Спойлер

Код:

char str[4] = "-35";

printf("%d\n", (int)str);         //"96"

printf("%s\n", str);            //"-35"

puts(str);                     //"-35"

Реклама

Eddy_Em

Берем код:

Код:

#include <stdio.h>

int main(){
  char x = 15, y = -15;
  unsigned char ux = 25, uy = -25;
  printf("signed: %d, %d, %d, %d\n", x,y, ux,uy);
  printf("unsigned: %u, %u, %u, %u\n", x,y, ux,uy);
  return 0;
}

Запускаем:

Код:

./a.out
signed: 15, -15, 25, 231
unsigned: 15, 4294967281, 25, 231

Поведение на МК будет отличаться лишь при попытке вывести -15: на некоторых МК это будет 65521.

Ну и где здесь "нежданчик"?

Реклама

Dimon456

Eddy_Em писал(а):

4294967281

Ну вот, а тут утверждают что в 2 кило за лазит, это на AVR в 2 кило за лазит, а на stm по ширше будет.

parovoZZ

tonyk писал(а):

Если МК загружен основной задачей на 90%, <> А если же загрузка 10%,

как это? МК всегда нагружен на 100 процентов. Про разную нагрузку на отрезке времени можно говорить только в многозадачных системах (ОС).

Мурик

parovoZZ писал(а):

как это? МК всегда нагружен на 100 процентов.

В наборе инструкций есть wfe и wfi которые отключают процессор до ближайшего события или прерывания. А значит загрузка будет меньше 100%, т. к. часть времени процессор не работает.

Реклама

parovoZZ

это значит, что ядро выключено. Говорить про какую-то нагрузку (даже нулевую) на выключенном ядре как-то глупо.

Мурик

Следуя вашей логике, все без исключения процессоры всегда при работе загружены на 100%.
Но это же не так.

Dimon456

Мурик писал(а):

В наборе инструкций есть wfe и wfi

что-то я не вижу здесь ни каких волшебных инструкций

Спойлер

Может не там смотрю? Или F100-103 не поддерживают? Может надо было в спячку вогнать?

Reflector

Eddy_Em писал(а):

Код:

./a.out
signed: 15, -15, 25, 231
unsigned: 15, 4294967281, 25, 231

Поведение на МК будет отличаться лишь при попытке вывести -15: на некоторых МК это будет 65521.

Еще 241 может быть, если char по умолчанию unsigned. В любом случае даже -15 - это обычно не то, что ожидается увидеть, т.к. скорее всего в char будут хранить не отрицательные числа, а символы которые могут превращаться в отрицательные числа, но коды то у символов положительные... По этой причине Clang-Tidy при преобразовании char в int советует сначала приводить к unsigned char и моя либа форматирования так и делает:

Код:

char x = 'Y', y = 'Я';
int8_t ix = 'Y', iy = 'Я';
unsigned char ux = 25, uy = -25;
rtt.println(x, y, ix, iy, ux, uy);         // Y, ?, 89, -33, 25, 231
rtt.print<"{}, {}, {d}, {d}">(x, y, x, y); // Y, ?, 89, 223

Eddy_Em

Если хочется явно беззнаковое использовать, то зачем вообще с char связываться? Просто сразу же и писать uint8_t.

Reflector

О чем и речь, с char связываются когда хранят символы, а коды символов всегда положительны и трактовка хранимых в char значений должна быть соответствующей. Если нужно хранить 8-ми битный числа, то для этих целей есть int8_t/uint8_t.

ps. Помимо неопределенной знаковости char еще и char, signed char и unsigned char - три разных типа!

Мурик

Dimon456 писал(а):

что-то я не вижу здесь ни каких волшебных инструкций

Откуда им взятся если вы не переводите МК в режим пониженного потребления?
Из CMSIS

Код:

/**
  \brief   Wait For Interrupt
  \details Wait For Interrupt is a hint instruction that suspends execution until one of a number of events occurs.
 */
#define __WFI()                             __ASM volatile ("wfi")


/**
  \brief   Wait For Event
  \details Wait For Event is a hint instruction that permits the processor to enter
           a low-power state until one of a number of events occurs.
 */
#define __WFE()                             __ASM volatile ("wfe")

Код:

int main(void)
{
    while(1)
    {
        __WFI();
    }
}

parovoZZ

Мурик писал(а):

Следуя вашей логике, все без исключения процессоры всегда при работе загружены на 100%.
Но это же не так.

именно так. Задача при выполнении всегда грузит процессор на 100%.
Рассказывать мне про энергосберегающие алгоритмы не надо - разработать устройство со сроком работы от 5 лет и выше от батарейки я могу по щелчку пальцев.

jcxz

COKPOWEHEU писал(а):

Кстати, мне после AVR не нравится сдвиг на (4*j), лучше бы исходное число двигать, как в выводе десятичного:

Код:

do{
  buf[0] = val % base;
  if(buf[0] < 10)buf[0] += '0'; else buf[0] = buf[0] - 0x0A + 'A';
  buf--;
  val /= base;
}while(val);

Сдвиг, который на ARM вообще ничего не стоит - напрягает, а деление, которое раз в 15 медленнее - нет. Да ещё зачем-то 2 раза деление на одно и то же число. Видимо чтобы как можно больше замедлить выполнение. Иного объяснения не придумать. :dont_know:

Да ещё куча лишних обращение к памяти (buf) совершенно не нужных.
Да ещё и лишнее ветвление, без которого можно обойтись, и которое не факт что будет скомпилено в инструкцию условного выполнения.
Сделали ну просто всё чтобы максимально затормозить функцию! :)))

COKPOWEHEU

Для кого я писал оптимизированный вариант... Видимо, для себя.
Откуда-то два деления придумали, "лишние" обращения, "лишние" ветвления.
И все это в псевдокоде, написанном из головы.
Впрочем, ладно: если уж взяли мой пример для произвольного основания, продемонстрируйте свой вариант, решающий эту задачу не хуже. Естественно, в качестве доказательства принимается количество тактов для среднего и худшего случаев в сравнении с тем, что на вашем компиляторе выдает мой "неоптимальный" код.

Eddy_Em

jcxz, блин, у меня такой же косяк был! Исправился (для STM32F0, где нет деления):

Код:

void printu(uint32_t val){
    char buf[11], *bufptr = &buf[10];
    *bufptr = 0;
    if(!val){
        *(--bufptr) = '0';
    }else{
        while(val){
            register uint32_t o = val;
            val /= 10;
            *(--bufptr) = (o - 10*val) + '0';
        }
    }
    addtobuf(bufptr);
}

А для вывода hex никаких делений использовать не нужно:

Код:

void printuhex(uint32_t val){
    addtobuf("0x");
    uint8_t *ptr = (uint8_t*)&val + 3;
    int i, j, z=1;
    for(i = 0; i < 4; ++i, --ptr){
        if(*ptr == 0){ // omit leading zeros
            if(i == 3) z = 0;
            if(z) continue;
        }
        else z = 0;
        for(j = 1; j > -1; --j){
            uint8_t half = (*ptr >> (4*j)) & 0x0f;
            if(half < 10) bufputchar(half + '0');
            else bufputchar(half - 10 + 'a');
        }
    }
}

Да уж, ругаю всех за деление на F0, а в своем глазу бревна не вижу!

Лучше не использовать типы char в stm32?

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