Здравствуйте, господа!
Такой вопрос: можно ли обращаться к 32-разрядным регистрам LPC22xx как к 4 отдельным байтам?
Например, регистры Tx данных модуля CAN1, если задать массив по абсолютному адресу:
unsigned char DataA[4] _at_ 0xE0044038;

то при дальнейшей записи в этот массив записывается только элемент DataA[0], то есть

DataA[0] = 0x11;
DataA[1] = 0x22;
DataA[2] = 0x33;
DataA[3] = 0x44;

далее в регистре по адресу 0xE0044038 записывается только значение 0х11 или вообще "левое" значение.
В Юзер Мануале на 2294 в разделе CAN ничего про это не сказано, а вот в разделе про VIC сказано, что к регистрам VIC можно обращаться только как к слову (нельзя читать или записывать 1 байт или 2 байта, то есть полуслово), это относиться и к регистрам CAN?

Естественно нет.

Блин, круто, но пожалуйста поподробнее, что вы имеете в виду: "Естественно нет"?

Даже не знаю как и обьяснить-то Вы железки никогда не пробовали рисовать? Если да, то вопрос
почему - странный. Если нет, то:
1. железяка к которой можно одновременно обращатся, как 8-16-32 битной просто элементатно сложнее получается и без всякой на то надобноcти никто сие делать не будет.
Я лично за многие годы ни одного чудака сделавшего такую периферию не видел.
Для меня совершенно очевидно, и что и Ваша "надобность" совершенно необдуманная.
2. Дальше - имеем дело с 32bit контроллером - да он вообще с 8bit крайне ограниченный набор команд имеет - если и сделать 8bit шину, то трахаться он будет с обращениями мучительно.
3. Ну и третье - на периферийной шине вообще двух младших адресов нет Даже массовая восьмибитовая периферия занимет в адресном пространстве по четыре байта.
И следует только возблагодарить филипсовцев, что они позволили по четыре байта зараз загружать
а не растягивать сие удовольствие работы с мееееедленной периферией на четыре обращения.
Не вижу ни малейших причин не взять из буфера сразу четыре байта (путсть даже среди них лишние окажутся) и одним движением положить.

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

И ИМХО формировать/разбирать пакет желательно в памяти, а с периферией только быстро посылать/принимать.

Видимо, проще практически попробовать, что будет при обращении как к 8-битному регистру.
Если оно того так хочется.

Спасибо всем откликнувшимся, особенно про "железки".
Было бы неплохо обращаться к каждому байту отдельно, но раз нельзя, тогда придётся городить огород, что-то типа:
C1TDA1 = (unsigned char)*data;
*data++;
C1TDA1 |= ((unsigned char)*data)<<8;
*data++;
C1TDA1 |= ((unsigned char)*data)<<16;
*data++;
C1TDA1 |= ((unsigned char)*data)<<24;

Ещё обнаружил следующий трабл: требуется отправить 4 сообщения подряд - с одного модуля CAN1 на скорости 1000 Мбит/с, с другого модуля CAN3 на скорости 125 кбит/с, при передаче с CAN1 всё проходит отлично, а модуль CAN3 передаёт 16 раз первое сообщение и виснет, хотя по программе оно должно отправиться только один раз. Функции обслуживания этих модулей одинаковые с поправкой на номер модуля, настройки сети корректные, потому что, если в модуле CAN3 поставить скорость 1000Мбит/с, то 4 сообщения передаются также корректно. В эратте нет никаких ошибок, которые бы могли повлиять эту ситуацию. Если кто сталкивался с такой проблемой, подскажите - на что надо обратить внимание? Перед передачей следующего сообщения проверяется флаг готовности передатчика, прерывания от передатчиков запрещены.

А приемники в этом CAN сегменте есть? Они настроены на ту же скорость?

Огород не нужен:

C1TDA1 = *(unsigned int *)data;

Только с выравниванием для data поосторожней.

Если мне не изменяет память настройка скорости производиться через один регистр CxBTR и для приёмника и для передатчика. К тому же, если задействован только передатчик, то конфигурировать приёмник не требуется.



Согласен с вами. Но у меня массив из 8 unsigned char, поэтому есть 2 пути - или собирать посылку сразу в регистры данных (как показано у меня), или собрать в какой-нибудь промежуточный регистр и переписать как показано у вас. В принципе с этим вопросом разобрались сообща, но вот может по второму вопросу есть какие-нибудь идеи. Почему на одной скорости всё ок, а на другой непонятка такая:-(.

Имеется ввиду, кто принимает передаваемые этим узлом CAN сообщения?

Показан был ПРАВИЛЬНЫЙ путь - кладете прямо из Вашего массива любого размера по четыре байта зараз. Где узрели в примере чего-то "промежуточное" а?

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

Насчёт массивов и регистров - конечно ручками оно правильнее, но поначалу я предполагал, что за меня это сделает компилятор. Вот у Микрочипа dsPIC 16 разряный, но с помощью компилятора позволяет обращаться отдельно к полуслову (1 байт) и даже применимо побитное обращение. Ну раз уж такая петрушка, то будем переучиваться.

Ничего Вы не поняли
1. Компилятор это делает за Вас.
2. Память и периферия с точки зрения байтовых и битовых обращений есть две большие разницы и сваливать их в кучу

Давайте разберёмся вместе .
Я хотел сказать, что модуль CAN в dsPICах 16-разрядный, но тем не менее там есть возможность обратиться к регистрам модуля CAN как к полуслову, так и побитно (это периферия, а не память). А у LPC надо делать по-другому.

А если я чего не понял, ну объясните, пожалуйста, чего я недопонимаю?

Я бы взял скоп и смотрел, для начала без приемников на шине. Посчитал бы реальную битовую скорость.
И потом не понятно, что вы подразумеваете под "виснет".



Ну сделано в dsPIC так, а в LPC так (почему это выгоднее, уже объясняли).
Примите как данность, реализуйте драйвер для этото CAN контроллера с нужным API и забудте, как оно там обращается к этим регистрам.

Недообъясняете - предыдущее письмо было:

Всуе поминалаись не относящинся к делу разрядность контролера, компилятор. И вообще пробитное обращение - а что за каким-то хреном в CAN от микрочипа сделаны регистры для установк/сброса и отдельных битов с буфере передачи????

Блин, "ниасилил аффтар твою грамматику":(



Под "виснет" я подразумеваю, что LPC вообще после 16 передач одного и того же сообщения никак не реагирует ни на что. Дальше не изменяя текста программы меняю скорость с 125 на 1000 и всё работает как часы без зависонов и глюков. Завтра попробую без приёмников поюзать, а то уже 4 дня на больничном был, под руками LPC не было.

Посмотрите, в какой-нибудь аборт сваливается, наверное.
По LR можно проследить, с какого адреса, ну а дальше ставить там брейкпоинты, и разбираться.

Уффф, всё сегодня наконец-то со всем разобрался - и скорости нормально стали переключаться и с регистрами всё получилось пока лучше некуда. Огромное всем спасибо, пока вопросов нет ;-)

Отчет в студию!
По крайней мере так принято, даже если он в стиле "сам был дурак".

Отчёт.
Насчёт регистров, попробовал как посоветовали - работает!
Хотя немного поковырявшись, заделал новый тип - структурка
typedef struct
{
unsigned long TFI;
unsigned long ID;
unsigned long Data[2];
} CAN_TxObj, *pCAN_TxObj;
и с ней изгаляюсь, получилось коротко и ясно.

Насчёт скоростей, во-первых, у меня монитор шины CAN фирмы IXXAT был настроен на скорость 125CIA, но 1 бит состоял из 16 квантов, а в LPC из 10 квантов - осциллографом посмотрел битовая скорость совпадала, но почему то сообщения передавались некорректно, изменил скорость на просто 125 в IXXAT - всё стало нормально. А во-вторых, у второго приёмника на шине CAN битовая скорость немного отличалась на единицы микросекунд (время 1 бита), и уже глючило. Выставил точно битовую скорость на втором приёмнике, и с ним работа наладилась.
Пока вот так.......