Мелкие вопросы по МК и ПЛИС.

[КРАМ]

Вопрос не очень понятен. VCO - это генератор управляемый напряжением.
В контроллерах он сделан на основе логических вентилей и RC-цепей. Изменение частоты производится путем изменения порога переключения вентилей.
Примерно так.

[Chettuser]

Знакомая схема
Спасибо,

В контроллерах он сделан на основе логических вентилей и RC-цепей. Изменение частоты производится путем изменения порога переключения вентилей.

принцип понял.

[aam]

Нигде не найду, когда AVRка просыпается, бит SE в MCUCR сбрасывается сам или его надо где-то как-то сбрасывать?

Написал в IAR такой код для перехода в режим IDLE:

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

inline void IDLE()
{
    MCUCR|=1<<5;
     __sleep();  
}

В проге прерывания по таймеру либо по ногам PCINT.

Надо еще что-то?

[Gudd-Head]

If an enabled interrupt occurs while the MCU is in a sleep mode, the MCU wakes up. The MCU is then halted for four cycles in addition to the start-up time, it executes the interrupt routine, and resumes execution from the instruction following SLEEP. The contents of the Register File and SRAM are unaltered when the device wakes up from sleep.

Видимо, не сбрасывается.

[aam]

Интересно...
И где его сбрасывать? В каждое прерывание пихать? Или просто написать за командой sleep в надежде, что в процессе обработки прерывания проц не сглючит и успешно выйдет на точку за командой sleep?
Кстати, а вообще, из прерывания проц заснуть может случайно? Вроде как это нереально - либо он тут же проснется, либо просто не заснет? Тогда достаточно сбрасывать бит SE за командой __sleep().

Вообще, для чего это делаю - мне показалось, что крутить впустую бесконечный цикл - некрасиво. И так как этот цикл у меня тактируется прерываниями таймера, генерящего их с частотой около 30 кГц, то я решил в самом конце итерации цикла усыплять проц, а не бесконечно тестировать флаг из прерывания таймера.
Интересно, "риальные пацаны" так делают или как?

[akl]

Выходом из SLEEP IDLE может служить флаг взводимый в обработчике когда нужно. Например, пользуюсь пользовательским флагом T в SREG.

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

   CLT
   SEI
WAIT:
   SLEEP
   BRTC   WAIT
   CLI
   CLT

[Alexeyslav]

А собственно зачем сбрасывать этот бит? Он как-то мешает?
Случайно контроллер уснуть НЕ МОЖЕТ, продолжает выполнение программы он с обработки прерывания и дальше за командой SLEEP. В прерывании использовать режим сна опасно - ведь из сна контроллер выходит по прерыванию, а из следующего он еще не вышел... прерывания-то запрещены. А если их разрешить перед сном, встает вопрос об реентерабельности этого же прерывания.

[akl]

Это Вы мне? Никогда, без необходимости, не сбрасываю установленный режим работы. Подтверждаю его - да, но не сбрасываю.

[aam]

Я просто в книжке про Тини (перевод ДШ) прочитал такую фразу:
"Во избежание непреднамеренного переключения микроконтроллера в спящий режим рекомендуется устанавливать флаг SE непосредственно перед выполнением команды Sleep".

А если учесть, что

В прерывании использовать режим сна опасно - ведь из сна контроллер выходит по прерыванию, а из следующего он еще не вышел... прерывания-то запрещены

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

Я знаю, что в "опасных" операциях (например, запись в EEPROM), бит разрешения сбрасывается аппаратно за опред. кол-во тактов (4 кажется) и в случае глюка трагических последствий не будет. Я думал, может и тут также сделано?
А запись в ПЗУ вообще чуть ли не целый алгоритм имеет, т. к. крайне опасна.

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

Ну это же не совсем настройка режима. Ведь в принципе, этот бит "лишний" - можно было бы сделать так, что "не хочешь юзать сон - не пиши команду sleep", но его ввели для надежности. Или я что-то не понял?

[ANALOG]

Здравствуйте, у меня такая проблема: делаю связь по UART'у двух AVR. мега48 типа как главный контроллер, шлет 8 байт тиньке2313, к которой подключена светодиодная матрица 8х8. Ну и тинька соответственно рисует их на матрице.
Отправляю вот это:
0b10000000
0b01000000
0b00100000
0b00010000
0b00001000
0b00000010
0b00000001
а приходит вот что:

т.е. байты ужимаются к правому (младшему краю) а слева вылазит полоска единичек.
Я так понимаю что проблема в синхронизации скорости, но инициализация UART'ов практически одинаковая, вот куски кода:
Это на mega48:

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

      outi UBRR0L, low(XTAL/(8*BAUDRATE)-1)
      outi UBRR0H, high(XTAL/(8*BAUDRATE)-1)
      outi UCSR0A, (1<<U2X0)
      outi UCSR0B, (1<<TXEN0)
      outi UCSR0C, (1<<UCSZ01)|(1<<UCSZ00)

А это в tiny:

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

      outi UBRRL, low(XTAL/(8*BAUDRATE)-1)
      outi UBRRH, high(XTAL/(8*BAUDRATE)-1)
      outi UCSRA, (1<<U2X)
      outi UCSRB, (1<<RXCIE)|(1<<RXEN)
      outi UCSRC, (1<<UCSZ1)|(1<<UCSZ0)

А вот константы, одинаковые в обоих МК:

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

.equ XTAL = 1000000
.equ BAUDRATE = 9600

Кто подскажет в чем может быть проблема?

[Alexeyslav]

Может проблема чисто аппаратная? два столбца/строки индикатора подключены на один сигнал.
Если бы произошел сбой передачи по UART, это сопровождалось бы ошибками вроде ошибки окна и контроля четности.

[ANALOG]

Не, проблема точно в УАРТе, аппаратную часть я тестил, загонял в код пустышку с выключенным УАРТом и константной картинкой - индикация работает как надо
А флаги ошибок УАРТа я не проверяю, но суть не в том как распознать ошибку а почему она возникает каждый раз?

[Alexeyslav]

Проверять флаги ошибок. И осциллограф поможет. Ошибки возникают либо из-за сильных помех, или из-за несовпадения скорости передачи более 2% (примерно 5% отклонения если принять за эталон одно из устройств). Ответ на это даст осциллограф или логический анализатор.

[КРАМ]

Проверьте полярность, очень похоже на инвертированный канал...

[vitalik_1984]

Похоже КРАМ прав полярность выставляется битом UCPOLn где n это номер номер порта если их несколько.
При этом бите равном нулю две микры имеют разные настройки странно, конечно где же пресловутая совместимость кода? Или это только для одного семейства справедливо(tiny,mega)?
Видать нужно на каком то из этих камней установить этот бит в 1.

[Alexeyslav]

А у вас синхронный UART? Если нет то бит не играет никакой роли. Осциллограф нам все расскажет.

[vitalik_1984]

У меня? Нет не у меня. Надо смотреть дальше какой там включается весь код в вопросе, как я понял.

[Alexeyslav]

Синхронный UART распознается не кодом а схемотехнически - помимо RX и TX есть еще вывод синхронизации(и вход на прием). Вот если он есть в схеме, тогда можно говорить об синхроне, иначе без этого сигнала он вообще работать не будет.

[vitalik_1984]

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

[Alexeyslav]

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