Arlleex

Следующий баг. 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() не является прототипом функции. И в этом вся загвоздка, это из той же оперы, о которой я говорил

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