Arlleex

А я на их триальной 32кБ версии продемонстрирую😉 Щас просто напрочь забыл адрес регистрации аккаунта на arm, поэтому завел новый, жду завершения регистрации.

Напишу, посмотрим, что выйдет.

Следующий баг. Keil uVision 5.36, тулчейн V6.16. Есть такой скрипт компоновщика LOAD1 0x08000000 8192 { ROOT 0x08000000 8192 { *.o (RESET, +first) *(InRoot$$Sections) .any (+ro) } RAM1 0x20000000 UNINIT 16 { *(.bss.bootInfo) } RAM2 0x20000010 20464 { .any (+rw, +zi) } } В проекте есть два различных .c-файла: file1.c и file2.c. В file1.c в глобальной области файла static struct { char key[8]; u32 entryFlags; } volatile BootInfo __attribute__((section(".bss.bootInfo"))); В file2.c тоже в глобальной области файла static struct { u32 isConnected : 1, isWBufFillingMode : 1, : 30; u32 wBufOffset; u8 wBuf[WBUF_SIZE]; u32 memoryOffset; } BootInfo; При любом уровне оптимизации без LTO получаю ошибку компоновки Именование секции .bss.bootInfo в соответствиями с особенностями определения неинициализированных переменных. С галкой LTO-оптимизации компиляция и линковка проходит успешно, в map-файле все ок. Т.е. компилятор никак не "усложняет" имена переменных, чтобы два разных файла экспортировали разные символы пусть даже одинаково названных статических переменных (при явном размещении в секции .bss.bootInfo).

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

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

В смысле кто? Отведенные 8 байтов максимум в кадре CAN. Задействование других каких-то ID недопустимо. Не, FD не во всех железяках в наличии.

Хреновенько. Жаль. Тогда буду отводить байт под некий счетчик последовательности и остальные 7 байт юзать под данные.

Да, очередность выставления для арбитража и т.д. Мне надо передавать данные для записи в массив памяти (программируемой флешки). Я хотел сократить оверхед и задействовать все 8 байтов под куски записи. Хотел друг за другом отправлять массив в килобайт, а потом (через другие ID) проверять, все записались или нет.

Мне надо разработать протокол для пока еще сферического проца/МК, я не знаю возможностей CAN для него. И либо закладываться на гарантию очередности, даваемую самим CAN, либо нет. Это и хочу выяснить. Для STM-ок понятно. Не понятно в целом - на куче разных МК разных производителей.

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

Можно ли гарантировать, что отправляя друг за другом кадры с одним и тем же ID, все участники сети будут получать их в том же самом порядке, в котором отправитель их отправлял? В случае, если у отправителя несколько разных CAN ID - там понятно, нет гарантий. А если ID один и тот же?

Если идти по ветке моей логики в понимании Вашего поста, то ситуация схожа с диалогом Челентано и официанта при выборе вина)) Все, молчу, а то оффтопика налили)

Так я так и сидел😅

😀

@dimka76 прочитайте, что написали и что цитируете)) Вспомнился момент из известной комедии

Самое главное здесь - это то, что компилятор проглотил это и не выдал ошибку (несмотря на то, что выдался варнинг бонусом). Это не дает IAR-у "быть в стороне" - в нем точно так же преобразование допустимо. Вся соль в том, что этот варнинг просто говорит "программист, будь внимательнее, тут ты беззнаковый преобразуешь в обычный char", но скрытых подводных граблей Си в виде каких-нибудь UB здесь точно нету. И это самое главное. Когда программист увидит этот варнинг, он может "подписать уговор", или задуматься и по-другому все это вообще написать. P.S. Насчет ошибки (которую Вы удалили, p045, вроде). Обявление void mm() не является прототипом функции. И в этом вся загвоздка, это из той же оперы, о которой я говорил

Что значит не умеет? Он не может не уметь, ибо это преобразование допустимо в любых компиляторах Си, однако компилятор любезно "наводит на мысль" о том, что автору бы еще на знак обратить внимание. Поместите прототип этой функции в нужное место, и варнинг при приведении указателей останется, никуда не денется. Но это как был, так и останется другим типом варнинга - не как у автора. А у автора что, во-первых, сразу говорит о том, что в точке вызова функции не видно ее объявления, а во-вторых, сразу видно, что функцию автор определил не в том же файле, где ее вызывает. Иначе бы возник конфликт объявлений и это уже не варнинг, а ошибка, и проект не собрался бы.

А причем тут разные типы? Автор спрашивал за конкретный варнинг, а не за (возможные) варнинги неявных преобразований указателей. Именно на отсутствующий прототип я и указал.

Где-то выше точки вызова в глобальном пространстве (например, в заголовочном файле библиотеки) должен быть прототип функции void LongToBytes (long LG, char* BYTES, byte Index);

Предусмотреть отладочный UART и не забивать голову, ибо в ТЗ ни слова конкретики.

К внешней границе никак, про сгиб не понял - если опять же нижний угол по внешним сторонам трека - то тоже никак.

Да с таким подходом и никаких эмулирований ООП в Си нельзя было бы делать, в т.ч. ту самую Glib/GTK))

Каким образом? Я задал вопрос на стековерфлоу - часть гур сошлась во мнении, что это UB, часть - что это определенное поведение. И вот еще. Нужна истина.

Ну в большинстве случаев вопрос поддерживаемой архитектуры не совсем корректен, т.к. он в конечном итоге сводится к конкретному компилятору: опять же, чаще всего это будет GCC. Поэтому я и говорю, что очень много OpenSource кода написано в стиле "проверено в GCC, там работает и точка". Спасибо, посмотрю. Честно сказать, мало какая статья написана настолько грамотно, с отсылками к пунктам стандарта языка. В большинстве случаев я вижу "ну, вот код, который работает, потому что он работает". Вопросы семантики и поведения там не затрагиваются, всякие strict aliasing и UB при приведениях указателей разных типов, для бОльшей части рядовых программистов - вообще "впервые слышу". Не появится. Зачем мне стрелять себе в ногу? Я читаю стандарт: он мне явно говорит, что указатель на структуру можно безопасно привести к указателю на его первый элемент, и наоборот. Вот только это несколько противоречит пункту, где описано, как можно получить доступ к объекту какого-то определенного типа: Подчеркнутая строчка написана так (как обычно в стандартах) - что ее не пойми как правильно трактовать - то ли член должен быть первым, то ли любым.

Об этих библиотеках я читал. Однако очень много исходного кода написано так, что он едва ли гарантированно написан переносимым между компиляторами. В Си полно тонкостей со всякими "эффективными типами" и допустимыми способами доступа к объектам, и шаг влево - и получается неопределенное поведение. И в большинстве случаев компилятор правильно сгенерирует код даже в случае наличия UB, и в этом и проблема - грабли лежат, а не видны.