Вопросы по С/С++ (СИ)

[Мурик]

Разрешение прерываний внутри прерывания наверное только в древних МК. Нормальный МК должен иметь контроллер прерываний поддерживающий вложенные прерывания и иметь возможность назначать приоритет вложенности. Тогда все действия производятся аппаратно и можно выбрать какие прерывания могут прервать выполняемые на данный момент, а какие будут ожидать своей очереди. Это позволит точно быть уверенным в работе устройства.

[ARV]

Нормальный МК должен иметь контроллер прерываний поддерживающий вложенные прерывания и иметь возможность назначать приоритет вложенности

например, любой из семейства MCS51, включая древность типа КР1816ВЕ31

функционально разрешение прерываний внутри прерывания решает все ничуть не хуже, чем аппаратный контроллер, разве что на нескоько тактов дольше это длится.

[Мурик]

например, любой из семейства MCS51, включая древность типа КР1816ВЕ31

С ними не работал. Даташит или другую документацию где есть описание контроллера прерываний по быстрому найти не удалось. Так что не могу не подтвердить и не опровергнуть.
Я не конкретизировал модель МК. У многих имеется подобный контроллер прерываний. Он точно есть в МК с ядром ARM (контроллер встроен в ядро).
У PIC (10, 12, 16) и AVR (тини, меги) вложенные прерывания не поддерживаются.

функционально разрешение прерываний внутри прерывания решает все ничуть не хуже

Во первых, при неправильно расчете прерывания могут выполнятся рекурсивно, что приведет к сбоям. Во вторых, разрешаются все прерывания, а если нужно разрешить только некоторые? Причем не программно выставляя флаги прерываний, а аппаратно выставляя приоритеты вложенности прерываний.

[ARV]

Даташит или другую документацию где есть описание контроллера прерываний по быстрому найти не удалось

это потому что очень древние МК

только в древних МК

2 уровня приоритетов, независимые маски.

прерывания могут выполнятся рекурсивно, что приведет к сбоям

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

[Мурик]

Предположим имеются 8 источников прерываний (в реальном проекте их может быть гораздо больше).

• 1 - внешнее прерывание, по которому нужно все отключить. Задержка недопустима, иначе электроника потеряет "белый дымок" и это в лучшем случае.
• 2 - внешнее прерывание которое нужно обработать с минимальной задержкой.
• 3 - прерывание от USART. Задержка не должна превышать времени поступления нового байта.
• 4 - прерывание от USB. Некоторая задержка допустима, но она приведет к снижению скрости обмена.
• 5 - прерывание от DMA. Некоторая задержка допустима.
• 6 - внешнее прерывание. Допустима задержка 1 мс.
• 7 - прерывание от таймера. Задержка допустима.
• 8 - прерывание от встроенного RTC. Допустима задержка до 1 секунды.

В случае если приоритеты вложенных прерываний аппаратно поддерживаются, все просто. Назначаем приоритеты 0, 1, 2 3, 4, 5, 6 и 7 соответственно и остальное забота контроллера прерываний. Более высокоприоритетное прерывание в любой момент может прервать прерывание с меньшим приоритетом, но не наоборот.
Если же нет поддержки вложенных приоритетов прерываний и разрешать другие прерывания при входе в прерывание, может произойти более низкоприоритетное, которое не должно обрабатываться пока выполняется код высокроприоритетного. Контроль придется осуществлять программно, из-за чего усложнится код, увеличится время перехода в высокопроиоритетное прерывание и если произойдет низкоприоритетное, нужно будет думать как вернутся назад в вывокоприоритетное, а после его обработки перейти в низкоприоритетное. Когда таких прерываний десяток другой, разрулить будет не просто.

[Starichok51]

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

[Мурик]

А если больше одного приоритета? Выше пример с 8 уровнями приоритетов и это не придел. Может быть больше.

[ARV]

"Может быть" не равно "обязательно потребуется". Изобилие хорошо, но не самоцель. Случаи, когда это изобилие действительно необходимо, пожалуй, единичны, а когда оно вообще не востребовано, имхо, подавляющи.
Все это неоднократно было сказано во множестве тем: 80% потребителей необходимы только 20% предлагаемых продавцом возможностей.

[Starichok51]

пример с 8 уровнями приоритетов и это не придел.

ну, это точно не придел, так как ПРИДЕЛ находится в церкви.

[Z_h_e]

80% потребителей необходимы только 20% предлагаемых продавцом возможностей.

Только у каждого потребителя своя часть 20% хотелок (одному одно надо, другому другое), которая может и меняться, потому чем больше заложено в одном типе чипа возможностей, тем он востребованней, значит дешевле и т.д. Теперь осталось как-то это все притянуть к сабжу топика .

[ARV]

Чем больше заложено в чипе возможностей, тем больше еррата

[Z_h_e]

Плюсы без минусов не бывают в этом деле.

[Reflector]

[uquote="ARV",url="/forum/viewtopic.php?p=3765923#p3765923"]Чем больше заложено в чипе возможностей, тем больше еррата [/uquote]
Далеко не всегда. Например, у самого первого и популярного STM32F1 errata на 48 страниц, а у относительного нового STM32F7 она всего 22 страницы, потому что периферия была обкатана на предыдущих сериях мк.

[Z_h_e]

Я еще студентом помню, как из одной страницы текста сделать десять. Обратно проще

[Эйлер Леонард]

Доброго времени суток уважаемые Коты. Поздравсяю всех с Новым годом.

[Z_h_e]

++

[Shuspano]

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

1. if((Byte<<i)&0x80)
2. return SDA;

в этой функции:

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

bit I2C_Write_Byte(unsigned char Byte)
{
	unsigned char i;		// Variable to be used in for loop
	
	for(i=0;i<8;i++)		// Repeat for every bit
	{
		Set_SCK_Low;		// Make SCK pin low
		
		__delay_us(HalfBitDelay/2);	// Data pin should change it's value,
									// when it is confirm that SCK is low

		if((Byte<<i)&0x80)  // Place data bit value on SDA pin
			Set_SDA_High;	// If bit is high, make SDA high
		else				// Data is transferred MSB first
			Set_SDA_Low;	// If bit is low, make SDA low

		__delay_us(HalfBitDelay/2);	// Toggle SCK pin
		Set_SCK_High;				// So that slave can
		__delay_us(HalfBitDelay);	// latch data bit
    }
		
	// Get ACK from slave
	Set_SCK_Low;
    Set_SDA_High;
    __delay_us(HalfBitDelay);
    Set_SCK_High;
    __delay_us(HalfBitDelay);

	return SDA;
}

[ARV]

if((Byte<<i)&0x80)

проверяется i-й бит в Byte на равенство 1. лично я бы за такое канделябром бы...

return SDA;

функция возвращает значение бита SDA. и за такое бы тоже, но можно не канделябром, а так, ссаной тряпкой...

будете переписывать - не делайте таких глупостей

[Shuspano]

Спасибо. Но в чем собственно, глупость?

[ARV]

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

Добавлено after 33 seconds:
вторая глупость - возвращать нестандартный тип bit