Вопросы по С/С++ (СИ)

Eddy_Em

На ARM нужно 10 раз подумать прежде чем так делать, чтобы исключить невыровненный доступ там где его нет и в HardFault не улететь. Можно, но с головой!

++
Еще memcpy опасен. Я пару раз нарывался. Вроде код правильный, а в хардфолт уходит. Оказывается, пытался при помощи memcpy копировать часть строки (а memcpy, видимо, оптимизировать пытался и копировать по 4 байта "за присест"). В общем, если строки нужно копировать, то есть strcpy — она не пытается char'ы как uint32_t копировать…
И в packed-структурах приходится очень аккуратно члены располагать.

ARV писал(а):

было бы конструктивно объяснить, как следует поступать, чтобы не нарваться. причем без привзяки к ARM

А смысл тогда о выравнивании думать?

Реклама

matrex

Спасибо коллеги из помощь и советы по существу.

Реклама

ARV

Eddy_Em писал(а):

А смысл тогда о выравнивании думать?

смысл в понимании ограничений С++. я, например, крайне удивлен тем фактом, что функция, копирующая заданное (любое!) количество БАЙТ может куда-то уходить в хардфаулт - она не имеет права оптимизировать что-то так, как нельзя! если это где-то оговорено в стандарте С++, то об этом и стоит говорить на публичном форуме, а не о своей печальной судьбе...

что касаетс ARM, то С++ существует для бОльшего количества платформ, и для разрядностей тоже, чем единственное семейство ARM. поэтому и говорить надо об особенностях С++ для РАЗНЫХ платформ.

я вот еще был очень сильно удивлен, что union в С++ это совсем не тот же union, что в Си. но так и не понял, из-за чего эта разница НЕ ВСЕГДА бывает. тоже хотел бы узнать от сведущих людей...

NStorm

ARV писал(а):

это чем-то отличается от предложенного мной?

Неа. Я до падения форума еще ответ написал, до того как ваш увидел.
Хотя посыл у меня был больше в том, что в таких случаях обычно делают массив структур, а не как ТЫ структуру из массивов (одинаковой размерности).

Добавлено after 5 minutes 46 seconds:
Без мемсета легко как я уже написал инициализировать нулевой локальной переменной, вроде dt = (struct rSENSORS){ 0 };.

Реклама

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

Eddy_Em

ARV писал(а):

смысл в понимании ограничений С++. я, например, крайне удивлен тем фактом, что функция, копирующая заданное (любое!) количество БАЙТ может куда-то уходить в хардфаулт - она не имеет права оптимизировать что-то так, как нельзя!

Вообще-то, stdlib — он на то и stdlib, что там все более-менее оптимизировано, чтобы не приходилось каждому делать свой велосипед-квадратные-колеса для элементарных strcpy и т.п. А вот на микроконтроллеры, к сожалению, это не распространяется, т.к. оптимизация stdlib и других библиотек знать не знает, что есть какая-то говножелезка, разработчики которой были настолько долбанутыми ослами, что сделали обязательным требованием выравнивание переменных в памяти!

Это вам вопрос задавать надо не к разработчикам стандарта С++, а к ослам, которые заложили в архитектуру ARM такой огромный косяк!

Реклама

VladislavS

ARV писал(а):

смысл в понимании ограничений С++.

Причём тут С++? Это вообще стандартные C-ные функции. Проблема не в языке, а в разработчике конкретной библиотеки и конкретного компилятора. Я же не просто так ему передаю параметр "-mcpu=cortex-m0" или "-mcpu=cortex-m4". Он должен это учитывать при компиляции/оптимизации. Это не ограничение языка!

Добавлено after 6 minutes:

Eddy_Em писал(а):

Вообще-то, stdlib — он на то и stdlib, что там все более-менее оптимизировано, чтобы не приходилось каждому делать свой велосипед-квадратные-колеса для элементарных strcpy и т.п. А вот на микроконтроллеры, к сожалению, это не распространяется, т.к. оптимизация stdlib и других библиотек знать не знает, что есть какая-то говножелезка, разработчики которой были настолько долбанутыми ослами, что сделали обязательным требованием выравнивание переменных в памяти!

Это не так. stdlib должна правильно работать на любой железке. Библиотека оптимизируется под конкретную железку. То что в определённых условиях она сбоит - это недоработка, которую разработчик обязан исправлять, особенно если продукт платный.

Реклама

ARV

у меня вопрос на счет union в C++

Код:

typedef union{
   struct{
      uint8_t a;
      uint8_t b;
   };
   uint8_t c;
} my_type;

почему sizeof(my_type) == 3?!

VladislavS

Не верь глазам своим

ARV

Реклама

Eddy_Em

VladislavS, как по мне, так главная ДИЧЬ и недоработка — это требование к выравниванию переменных в ARM.
Вот уж где рукожопы поковырялись!
И почему разрабы stdlib должны за этими лосями-рукожопами косяки исправлять?

VladislavS

Eddy_Em писал(а):

И почему разрабы stdlib должны за этими лосями-рукожопами косяки исправлять?

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

ARV

у меня вопрос по AVR-GCC
делаю вот такие вещи

Код:

typedef const __flash char fstr[];

typedef const __flash char* pfstr;

#define FSTR(x) (fstr){x}

typedef const __flash struct {
   pfstr      name;
   prop_type_t   id;
   bool*      value;
   pfstr       items;
} prop_bool_t;            // определяет тип prop_bool_t

#define PROP_BOOL(n, v, i) &(prop_bool_t){.name = (fstr){n}, .id = PROP_BOOL, .value = &v, .items = i}

потом использую так

Код:

bool b1;

const __flash pfstr pwr_str[] = {FSTR("OFF"), FSTR("ON")};

const __flash void * const __flash prop_array[] = {
   PROP_BOOL("POWER", b1, pwr_str)
}

получаю варнинг initialization from incompatible pointer type [-Wincompatible-pointer-types] на pwr_str в макросе PROP_BOOL

не понимаю - что не так? вроде указатель на память программ... где ошибаюсь?

идея была такая: поле items структуры prop_bool_t должно содержать указатель на первый элемент находящегося во flash массива строк в памяти программ.

Добавлено after 45 seconds:
листинг показывает, что поля содержат правильные значения... но почему тип указателя не совпадает?!

NStorm

ARV, ну так у вас pwr_str получился массив из 2х строковых массивов, а .items такого не ожидает. Т.е. вы даете ссылку на массив из указателей на массивы fstr, а оно ждет ссылку сразу на fstr.

ARV

не понял... массив указателей на __flash char, и item в структуре того же типа - указатель на __flash char...

что не так?

NStorm

Не массив указателей на __flash char у вас там, а массив указателей на другие указатели, которые только уже в свою очередь указывают на __flash char.

ARV

const __flash const __flash char* pwr_str[] - откуда массив указателей на указатели?!

точнее const __flash char * const __flash pwr_str[]

VladislavS

Код:

const __flash char str_on[] = "ON";
const __flash char str_off[] = "OFF";
const __flash char str_power_trm[] = "POWER_TRM";
const __flash char str_power_rcv[] = "POWER_RCV";
const __flash char __flash *strs_pwr[] = { str_on, str_off };

struct prop_bool_t{
   const char __flash *name;
   char  id;
   bool *value;
   const char __flash * __flash *items;
};

bool b1,b2;

const __flash prop_bool_t pwr[] = { { str_power_trm, 1, &b1, strs_pwr },  
                                    { str_power_rcv, 2, &b2, strs_pwr } };

ARV

VladislavS, вот теперь понял! спасибо!

NStorm

ARV, ну так вы ж его не разыменовали. PROP_BOOL("POWER", b1, *pwr_str)
Тоже самое у вас получается, без усложнений в виде флэша AVR: https://godbolt.org/z/xEwVFS

VladislavS

Тут весь смак как раз во __flash

Попросил компилятор показать как он будет добираться, например, к pwr[1].items[b2]

Код:

        LDI     R30, LOW((pwr + 12))
        LDI     R31, HIGH((pwr + 12))
        LPM     R18, Z+
        LPM     R19, Z
        LDS     R16, b2
        LDI     R17, 0
        LSL     R16
        ROL     R17
        ADD     R18, R16
        ADC     R19, R17
        MOVW    R31:R30, R19:R18
        LPM     R16, Z+
        LPM     R17, Z

Ух, забористо! Это AVR.