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

[FreshMan]

Просто число вывести?

да

[*Trigger*]

Тогда смотрите последний мой пример. Такая конструкция проверена во многих часах на ГРИ с той же целью.

[ARV]

Тогда смотрите последний мой пример. Такая конструкция проверена во многих часах на ГРИ с той же целью.

и в последнем, и в двух предпоследних макросы написаны с ошибками - не смотрите на такие примеры чтобы ошибок не было, надо "аргумент" макроса заключать в круглые скобки в "теле" макроса. см. пример знаменитого макроса:
#define _BV(x) (1 << (x))

[a_skr]

Вы PORTB считывать пробовали? Одни нули читаются. То, что записано в порт, читается через PINB...

То, что записано в PORTB - читается через PORTB.
Через PINB читается реальное состояние пинов.
Допустим, пин PB7 настроен на вход и подтянут внутренним pull-up ( PORTB |= (1<<PB7) ), но внешним устройством притянут к нулю.
PORTB & (1<<PB7) даст единицу в PB7 - правильное состояние, а
PINB & (1<<PB7) даст ноль,
и если мы, считав PB7 через PINB&(1<<PB7) нулём, выдадим туда ноль - отключим внутренний pull-up. Неправильно.

ps. ARV, совершенно правы.

[*Trigger*]

Проверил в Proteus`е таким кодом:

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

#include <tiny2313.h>
void main(void)
{
   DDRB|=0b111111;
   PORTB.0=1;
   PORTB.1=PORTB.0;
   PORTB.2=PINB.0;
   PORTB.3=0;
   PORTB.4=PORTB.3;
   PORTB.5=PINB.3;
}

В итоге:
На PORTB0,1,2 единицы, а на PORTB3,4,5 - нули. Значит, все были правы. Читать можно откуда угодно, если нужные биты настроены на выход (как в нашем случае)

и в последнем, и в двух предпоследних макросы написаны с ошибками - не смотрите на такие примеры

Спасибо, забыл совсем. Исправил.

[ARV]

Значит, все были правы. Читать можно откуда угодно, если нужные биты настроены на выход (как в нашем случае)

читать можно откуда угодно, как и писать, причем не взирая на настройки.

[*Trigger*]

Насчёт "не взирая на настройки" выше a_skr привёл пример, когда нельзя.

[ARV]

Насчёт "не взирая на настройки" выше a_skr привёл пример, когда нельзя.

можно всегда. нужно - по необходимости

[*Trigger*]

С этим согласен. Другой вопрос - что мы получим.

[ARV]

Другой вопрос - что мы получим.

иногда - весьма интересное: вывод 1 в порт PINx приводит к инвертированию уровня на пине PORTx, вывод 0 не меняет состояние пина. это, например, верно для многих AVR последнего поколения...

[*Trigger*]

Где-то читал об этом, но сам никогда не использовал. Проще и понятнее написать в несколько действий (считать - инвертировать - записать), пригодится, наверное, только там, где памяти не хватает.

[ARV]

пригодится, наверное, только там, где памяти не хватает.

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

[FreshMan]

и в последнем, и в двух предпоследних макросы написаны с ошибками - не смотрите на такие примеры чтобы ошибок не было, надо "аргумент" макроса заключать в круглые скобки в "теле" макроса. см. пример знаменитого макроса:
#define _BV(x) (1 << (x))

странно
но когда я пишу так
#define TurnOff_Nixie (PORTB=0x0A;PORTD&= ~(1<<4 | 1<<3))
то эклипс ругается
а когда так
#define TurnOff_Nixie PORTB=0x0A;PORTD&= ~(1<<4 | 1<<3)
то нет

[ua1arn]

макрос ( что-то ; что-то ещё) не применить. Сделайте так ( что-то , что-то ещё)

[FreshMan]

спасибо

[ARV]

когда я пишу так
#define TurnOff_Nixie (PORTB=0x0A;PORTD&= ~(1<<4 | 1<<3))
то эклипс ругается

правильно: скобка воспринимается, как начало "параметров" макроса. кроме вашего второго варианта можно так:
#define TurnOff_Nixie() (PORTB=0x0A;PORTD&= ~(1<<4 | 1<<3))

[ua1arn]

Да, позднее время Про макрос-функцию забыл. Для макросов (с параметрами или без) есть хорошее правило оформления:

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

	#define spi_select(target, spimode) \
		do { prog_select(target); hardware_spi_connect(SPIC_SPEEDFAST, (spimode)); } while (0)	// начало выдачи информации по SPI 
	#define spi_select2(target, spimode, speedcode) \
		do { prog_select(target); hardware_spi_connect((speedcode), (spimode)); } while (0)	// начало выдачи информации по SPI 
	#define spi_unselect(target) \
		do { hardware_spi_disconnect(); prog_unselect(target); } while (0)	// заверщение выдачи информации по SPI  - поднять чипселект
	#define spi_complete(target) \
		((void) (target), hardware_spi_complete())		// ожидание выдачи последнего байта в последовательности

По последнему примеру - что в выражении делает semicolon (точка с запятой)? Компилер при использовании будет ругаться. А вообще? окончательный вариант такой:

#define TurnOff_Nixie() do { PORTB = 0x0A; PORTD &= ~ (1U << 4 | 1U << 3); } while (0)

[Мikа]

Доброе субботнее утро! Иkи обед
Помогите, пожалуйста, понять логику внешних прерываний ATmega, по восходящему фронту.

Суть вопроса такова: нога даёт прерывание, когда "чувствует" восходящий фронт. Но следующее прерывание будет дано только при появлении восходящего фронта после возвращения в изначальное состояние, которое было до первого прерывания? Или же Второе прерывание по восходящему фронту будет дано сразу же, как только первый восходящий фронт перейдёт в постоянную величину и после этого появится новый?

Я приложил некую иллюстрацию для наглядности вопроса.



Как мне кажется, истиным является второй вариант. Или подводные камни?

[КРАМ]

Вход прерывания является ЦИФРОВЫМ, то есть поддерживает только ДВА логических уровня. Прерывание генерируется при изменении этого уровня.
Например.
При питании МК +5 вольт уровнем логической единицы на входе будет напряжение в диапазоне примерно 4...5 вольт. Уровнем логического нуля - 0...1 вольт. Все остальные значения входного напряжения являются неопределенными.
Схема формирования сигнала прерывания должна обеспечивать гарантированные уровни логических 0 и 1.
Таким образом, нижняя эпюра НЕРАБОТОСПОСОБНА.

[Мikа]

Таким образом отличие прерывания по восходящему фронту от прерывания по ЛОГ 1 заключается в том, что прерывание по возрастающему фронту срабатывает 1 раз при переходе в ЛОГ 1 и не будет повторно взводить флаг, пока не вернтся в ЛОГ 0 и потом обратно в ЛОГ 1, а при прерывании по ЛОГ 1 флаг будет подниматься постоянно, пока на ножке присутствует ЛОГ 1? Так правильно?