вот код


после этого bufRecive[0] равно 0х25, а bufRecive[1] равно 0х00. Сталкивался с такой проблемой в msp430 в IAR-e. Там нужно адрес массива bufRecive при объявлении выравнивать дерективой, типа #pragma aligment = 2
В Nios-e похоже тоже из-за выравнивания. Как тут массив выравнять? Или если не выравнивание, то что? Как побороть?

как-то так:

не помогло ((
а в какой доке расписаны дерективы процессора, всякие __attribute__, прагмы и т.п.?

погодите, это я ступил выравнивание тут ни причем, NIOS же Little Endian. Можно попробовать Endian Converter Custom Instruction

а насчет __attribute__ и т.п. - смотрите маны по gcc, все утилиты там GNUтые

странно, в другом месте обнаружил такой код ни разу не сбоил.

ну в ниосе компилятор nios2-elf-gcc, линкер nios2-elf-g++. У алтеры про них скудно как-то написанно. Попробую покопаться в манах gnu gcc

а вот это интересней, щя буду пробовать...

Endian Converter Custom Instruction - не помогло ((

ну короче прошагал по коду reinterpret_cast работает как надо. а вот разименование не работает как надо
я вот по такой штуке прошагал

если p указывает на четный адрес, то всё нормально, после*p = 0xХХХХ; меняется два байта по адресам р и р+1. если р указывает на нечётный адрес,то меняется два байта по адресу р-1 и по адресу р

Есть у кого какие мысли?

Мысль такая, что на вашем процессоре так нельзя делать.

И компилятор не виноват. То, что reinterpret_cast порождает адрес, который невозможно корректно разименовать - это ваша вина, а не компиляторы. Потому что reinterperet_cast предназначен для грамотного обхода защит компилятора.

Пишите в память сами по одному байту. Тогда не будет проблем с невыравненным доступом.

мммм.......
а не проще ли так(?):

а если таки охота ворочать little/big-endian то енто надо искать в доках на ниос и гцц.
да... и это не выравнивание. это нормальное положение байтов в памяти отведенной под переменную.
как вариант - написать макросы для переворачивания байтовых последовательностей при присваивании.

а еще лучше - вообще не нагружать CPU такой работой, есть ведь DMA

вобщем проблема в том, скорее всего процессор игнорирует младший бит для указателя на слово. Поэтому если указатель на слово нечетный, например 0х0890015, то он воспринимается как 0х0890014. Однако указатель на char по нечетному адресу работает нормально. Особенности архитектуры. Отчасти есть тут вина компилятора. В стандарте с++ не оговариваются подобные нюансы. И если компилятором заявленно "с++", то компилятор должен придерживаться стандарта. Возможно где-то в доках на компилятор этот нюанс оговорен, но я не нашел. А возможно, что компилятор с каким нибудь ключем, правильно разименует нечетный указатель на слово, ведь возможно же обращение к нечётной ячейке памяти.


Вобщем для себя проблему решиль примерно так, тока не макросы, а вместо char bufRecive[100]; написал класс с 2-мя шаблонными функциями write<class T>(const T& t, int adr) и T read<class T>(int adr), который хранит массив и записывает/читает байты в/из него любого типа, любой длинны и по любому адресу.

Проблема решена. Всем спасибо.