Форум РадиоКот

ARV писал(а):

PILS1396 писал(а):Извиняюсь, ошибся темой пишу в cvavr. Но в прерывании (при переполнении буфера приема) каждый байт записывается в массиве rx_buffer [], а нумерации начинается с нуля.
То есть как я понимаю переданы 150 записываются в массиве как:
rx_buffer [0] = 1
rx_buffer [1] = 5
rx_buffer [2] = 0

так вот хренушки! если вы послали "150" из терминальной программы, то у вас будет
rx_buffer [0] = '1'
rx_buffer [1] = '5'
rx_buffer [2] = '0'
а это совершенно не то!
с другой стороны, я не знаю, что у вас за терминалка, но ежели она вдруг посылает именно ЧИСЛО 150, то у вас будет еще лучше:
rx_buffer [0] = 150
rx_buffer [1] = неизвестно что
rx_buffer [2] = неизвестно что

собственно, о чем я и писал: вы не знаете Си и своих собственных инструментов. бегом читать букварь!

AlexFisher писал(а):Ошибок может быть по крайней мере 2:
1. Группа операторов начнет работать, когда передан всего один символ из трех (то есть уже не правильно)
2. Группа операторов не вычищает за собой вышеозначенный буфер, то есть не заносит туда 0х00

alexval2006 писал(а):есть нужда обозвать порт PORTC как нибудь по другому и по #define его чтобы все порты разом пенять по необходимости а то во многих местах менять приходиться как это сделать правильно а то мои эксперименты нечем хорошим не увенчались компилятор либо ругается либо нечего не работает

// Выводим данные на DataPin (PC0)
PORTC &=~_BV(DataPin); // установим DataPin в "0"
else // иначе
PORTC |=_BV(DataPin); // установим DataPin в "1"
asm("nop"); // задержка в один такт

alexval2006 писал(а):да еще немного о правилах размещения цикла майн в программе почему он должен быть обязательно в самом низу кода? иначе чущ начинаетса

alexval2006 писал(а):спасибо поюзаем

alexval2006 писал(а):обявляютса так?
//Прототипы подпрограмм
void USART_Transmit( unsigned char data );
void USART_Init( unsigned int ubrr);

ARV писал(а):1. не нужно писать #include <avr/iom128.h> - если вы настроили проект правильно, нужный модуль микроконтроллера будет подключен автоматически изнутри #include <avr/iо.h>
2. правильно висит на бесконечном цикле, ничего не делая: вы в своей программе что-то сделали?! ваш цикл while(1){a++;} не делает ничего, что хоть как-то может повлиять на что-то - вот оптимизатор компилятора и выбросил изменение переменной, как явно бесполезное действие, и остался только бесконечный цикл.
3. по стандарту Си функция main() - это именно функция, а функции вызываются при помощи CALL. согласен, это перебор для AVR - но в сущности никакой проблемы не представляет: вам оно не все равно, будет там JMP или CALL? лишних пара байт в коде, но ведь работать будет нормально!
4. в листинге из-за работы оптимизатора порой возникают чУдные вещи, например, повторение кусков исходного текста в разных местах листинга. эта проблема известна, но ее не могут побороть (или не хотят) разработчики avr-gcc. главное, что в коде нет лишних повторов, а листинг, хоть и слегка замусоривается, тем не менее вполне читабельный... смиритесь

Reset писал(а):Всё бы хорошо, но симулятор по этой дряни не ходит нормально.
И что значит "ни чего не делает"? А а++ - это он считает "ничего"м?

AlexFisher писал(а):

Reset писал(а):Всё бы хорошо, но симулятор по этой дряни не ходит нормально.
И что значит "ни чего не делает"? А а++ - это он считает "ничего"м?

Дело в том, что после инкремента эта переменная нигде не используется (не влияет на другие переменные) - поэтому операция выброшена.
Симулятор "ходит" уже по готовому коду - дизассемблируя на ходу и сопоставляя код согласно сишному. Отключите оптимизацию или пишите логичную программу.

ARV писал(а):вы сами решите для себя: какой смысл изменять ячейку ОЗУ, если результат этого изменения нигде никому не требуется?!

ARV писал(а):история возникновения volatile, как мне кажется, вами несколько искажена, но тем не менее, если вам необходимо, чтобы делалось что-то бессмысленное и бесполезное - вы просто обязаны об этом уведомить оптимизатор - он поймет более того: volatile просто необходимо указывать для всех глобальных переменных, которые используются и в прерываниях, и в обычных функциях.

На уровне железа многие процессоры просто резервируют блок адресов памяти для портов ввода-вывода. Большинство процессоров имеют отдельное пространство адресов ввода-вывода, со специальными инструкциями для доступа туда, но это не универсально (на PDP-11 такого не было, например) и даже сейчас, производители железа могут предпочесть использовать для этого адресное пространство памяти, по разным причинам. Я сомневаюсь, что кто-то так делает на архитектуре 8086 - различные адресные ограничения делают это очень сложным. Я видел это на 8080, это очень частое решение на старой TI 9900. И это был единственный способ организовать ввод-вывод на наборе инструкций PDP-11, там просто не было отдельного адресного пространства ввода-вывода (Я думаю, то же самое верно и для VAX. И не забывайте, что большинство работы на С раньше проходило именно на этих двух процессорах).
//-------------------------------
Теперь рассмотрим один из первых последовательных портов, что я использовал: Intel 8051. Нормальным способом его инициализации было записать 0 три раза в порт управления. Если у вас MMIO, то код на С мог бы выглядеть примерно так:

Код: Выделить всё

unsigned char* pControl = 0xff24 ;
*pControl = 0 ;
*pControl = 0 ;
*pControl = 0 ;

Что прекрасно работало на всех компиляторах С. Но вы можете себе представить, что могла бы с этим сделать сама простая оптимизация.

ARV писал(а):что касается не хождения симулятора, то это опять-таки из-за оптимизатора: если коду в строке исходника ничего в реальности не соответствует (выкинуто) - по чем ходить-то прикажете?! отключите оптимизацию -O0 и ходите по каждой строчке, сколько влезет

Reset писал(а):Вот что волетайл животворящий делает!