Кто любит RISC в жизни, заходим, не стесняемся.
Пт окт 15, 2021 15:07:49
У меня ни гигабайтных браузеров, ни игр не получается. Я стараюсь использовать ресурсы экономно.
А вот разработчики браузеров и всякой прочей жирноты - да, похоже вообще болт ложили на пользователей. Они, похоже, априори считают, что у всех мейнфрейм на 256 ядер по 2.5ГГц каждое, а оперативы минимум 1ПБ!
Пт окт 15, 2021 15:20:23
Eddy_Em писал(а):Если он хочет char отобразить как int, так пусть и вызывает printf("%d\n", c)
..и сядет в лужу, о чём я выше написал.
Ты запрашиваешь %d, то есть тип int, который даже на восьмибитках имеет размер 16 бит, а передаёшь char, размером 8 бит. Понимаешь, что получится?
Если МК загружен основной задачей на 90%, то нужно подумать об оптимизации преобразования для печати. А если же загрузка 10%, то используй то, что проще и удобней, лишь бы памяти хватило.
Пт окт 15, 2021 15:27:08
Ничего страшного не будет. Неявно char преобразуется в int, оба типа знаковые, так что косяков не будет.
Пт окт 15, 2021 16:30:06
Кхм, у меня char (символ без терминального нуля) - печатается не Hex коде. Потому как не ограничен в диапазоне видимых знаков. А вот когда это текст с закрывающем нулём - вот тогда велком.
Пт окт 15, 2021 17:30:33
Спойлер
- Код:
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"
Пт окт 15, 2021 19:58:29
Берем код:
- Код:
#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.
Ну и где здесь "нежданчик"?
Пт окт 15, 2021 20:14:16
Eddy_Em писал(а):4294967281
Ну вот, а тут утверждают что в 2 кило за лазит, это на AVR в 2 кило за лазит, а на stm по ширше будет.
Пт окт 15, 2021 21:42:50
Если МК загружен основной задачей на 90%, <> А если же загрузка 10%,
как это? МК всегда нагружен на 100 процентов. Про разную нагрузку на отрезке времени можно говорить только в многозадачных системах (ОС).
Пт окт 15, 2021 22:09:48
parovoZZ писал(а):как это? МК всегда нагружен на 100 процентов.
В наборе инструкций есть wfe и wfi которые отключают процессор до ближайшего события или прерывания. А значит загрузка будет меньше 100%, т. к. часть времени процессор не работает.
Пт окт 15, 2021 22:39:16
это значит, что ядро выключено. Говорить про какую-то нагрузку (даже нулевую) на выключенном ядре как-то глупо.
Пт окт 15, 2021 23:13:39
Следуя вашей логике, все без исключения процессоры всегда при работе загружены на 100%.
Но это же не так.
Сб окт 16, 2021 07:39:20
Мурик писал(а):В наборе инструкций есть wfe и wfi
что-то я не вижу здесь ни каких волшебных инструкций
Спойлер
Может не там смотрю? Или F100-103 не поддерживают? Может надо было в спячку вогнать?
Сб окт 16, 2021 11:13:14
- Код:
./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
Сб окт 16, 2021 11:19:57
Если хочется явно беззнаковое использовать, то зачем вообще с char связываться? Просто сразу же и писать uint8_t.
Сб окт 16, 2021 11:25:55
О чем и речь, с char связываются когда хранят символы, а коды символов всегда положительны и трактовка хранимых в char значений должна быть соответствующей. Если нужно хранить 8-ми битный числа, то для этих целей есть int8_t/uint8_t.
ps. Помимо неопределенной знаковости char еще и char, signed char и unsigned char - три разных типа!
Сб окт 16, 2021 14:12:47
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();
}
}
Сб окт 16, 2021 15:28:11
Следуя вашей логике, все без исключения процессоры всегда при работе загружены на 100%.
Но это же не так.
именно так. Задача при выполнении всегда грузит процессор на 100%.
Рассказывать мне про энергосберегающие алгоритмы не надо - разработать устройство со сроком работы от 5 лет и выше от батарейки я могу по щелчку пальцев.
Чт окт 21, 2021 22:36:06
Кстати, мне после 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 раза деление на одно и то же число. Видимо чтобы как можно больше замедлить выполнение. Иного объяснения не придумать.
Да ещё куча лишних обращение к памяти (buf) совершенно не нужных.
Да ещё и лишнее ветвление, без которого можно обойтись, и которое не факт что будет скомпилено в инструкцию условного выполнения.
Сделали ну просто всё чтобы максимально затормозить функцию!
Чт окт 21, 2021 23:52:43
Для кого я писал оптимизированный вариант... Видимо, для себя.
Откуда-то два деления придумали, "лишние" обращения, "лишние" ветвления.
И все это в псевдокоде, написанном из головы.
Впрочем, ладно: если уж взяли мой пример для произвольного основания, продемонстрируйте свой вариант, решающий эту задачу не хуже. Естественно, в качестве доказательства принимается количество тактов для среднего и худшего случаев в сравнении с тем, что на вашем компиляторе выдает мой "неоптимальный" код.
Пт окт 22, 2021 00:23:05
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, а в своем глазу бревна не вижу!
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.