Если ваш вопрос не влез ни в одну из вышеперечисленных тем, вам сюда.
Вс дек 29, 2019 21:15:59
Разрешение прерываний внутри прерывания наверное только в древних МК. Нормальный МК должен иметь контроллер прерываний поддерживающий вложенные прерывания и иметь возможность назначать приоритет вложенности. Тогда все действия производятся аппаратно и можно выбрать какие прерывания могут прервать выполняемые на данный момент, а какие будут ожидать своей очереди. Это позволит точно быть уверенным в работе устройства.
Вс дек 29, 2019 21:41:57
Мурик писал(а):Нормальный МК должен иметь контроллер прерываний поддерживающий вложенные прерывания и иметь возможность назначать приоритет вложенности
например, любой из семейства MCS51, включая древность типа КР1816ВЕ31
функционально разрешение прерываний внутри прерывания решает все ничуть не хуже, чем аппаратный контроллер, разве что на нескоько тактов дольше это длится.
Вс дек 29, 2019 21:54:34
ARV писал(а):например, любой из семейства MCS51, включая древность типа КР1816ВЕ31
С ними не работал. Даташит или другую документацию где есть описание контроллера прерываний по быстрому найти не удалось. Так что не могу не подтвердить и не опровергнуть.
Я не конкретизировал модель МК. У многих имеется подобный контроллер прерываний. Он точно есть в МК с ядром ARM (контроллер встроен в ядро).
У PIC (10, 12, 16) и AVR (тини, меги) вложенные прерывания не поддерживаются.
ARV писал(а):функционально разрешение прерываний внутри прерывания решает все ничуть не хуже
Во первых, при неправильно расчете прерывания могут выполнятся рекурсивно, что приведет к сбоям. Во вторых, разрешаются все прерывания, а если нужно разрешить только некоторые? Причем не программно выставляя флаги прерываний, а аппаратно выставляя приоритеты вложенности прерываний.
Вс дек 29, 2019 22:08:38
Мурик писал(а):Даташит или другую документацию где есть описание контроллера прерываний по быстрому найти не удалось
это потому что очень древние МК
Мурик писал(а):только в древних МК
2 уровня приоритетов, независимые маски.
Мурик писал(а):прерывания могут выполнятся рекурсивно, что приведет к сбоям
если аппаратный контроллер не примет прерывание "при неправильном расчете, сбоев, разумеется не будет
если что-то делается неправильно, говорить о сбоях смысла нет. а если все делается правильно, то и контроллер прерваний не нужен, хотя с ним, естественно, на несколько (допускаю - дестков) тактов быстрее все делается.
Пн дек 30, 2019 00:20:25
Предположим имеются 8 источников прерываний (в реальном проекте их может быть гораздо больше).
- 1 - внешнее прерывание, по которому нужно все отключить. Задержка недопустима, иначе электроника потеряет "белый дымок" и это в лучшем случае.
- 2 - внешнее прерывание которое нужно обработать с минимальной задержкой.
- 3 - прерывание от USART. Задержка не должна превышать времени поступления нового байта.
- 4 - прерывание от USB. Некоторая задержка допустима, но она приведет к снижению скрости обмена.
- 5 - прерывание от DMA. Некоторая задержка допустима.
- 6 - внешнее прерывание. Допустима задержка 1 мс.
- 7 - прерывание от таймера. Задержка допустима.
- 8 - прерывание от встроенного RTC. Допустима задержка до 1 секунды.
В случае если приоритеты вложенных прерываний аппаратно поддерживаются, все просто. Назначаем приоритеты 0, 1, 2 3, 4, 5, 6 и 7 соответственно и остальное забота контроллера прерываний. Более высокоприоритетное прерывание в любой момент может прервать прерывание с меньшим приоритетом,
но не наоборот.
Если же нет поддержки вложенных приоритетов прерываний и разрешать другие прерывания при входе в прерывание, может произойти более низкоприоритетное, которое не должно обрабатываться пока выполняется код высокроприоритетного. Контроль придется осуществлять программно, из-за чего усложнится код, увеличится время перехода в высокопроиоритетное прерывание и если произойдет низкоприоритетное, нужно будет думать как вернутся назад в вывокоприоритетное, а после его обработки перейти в низкоприоритетное. Когда таких прерываний десяток другой, разрулить будет не просто.
Пн дек 30, 2019 09:40:07
ну, а кто тебе мешает в обработчике высокоприоритетного прерывания не ставить разрешение прерываний? не ставь - и оно не прервется.
ставь только в низкоприоритетном - и пусть оно прерывается другим прерыванием.
Пн дек 30, 2019 13:59:25
А если больше одного приоритета? Выше пример с 8 уровнями приоритетов и это не придел. Может быть больше.
Пн дек 30, 2019 16:25:35
"Может быть" не равно "обязательно потребуется". Изобилие хорошо, но не самоцель. Случаи, когда это изобилие действительно необходимо, пожалуй, единичны, а когда оно вообще не востребовано, имхо, подавляющи.
Все это неоднократно было сказано во множестве тем: 80% потребителей необходимы только 20% предлагаемых продавцом возможностей.
Пн дек 30, 2019 16:29:41
Мурик писал(а):пример с 8 уровнями приоритетов и это не придел.
ну, это точно не придел, так как ПРИДЕЛ находится в церкви.
Пн дек 30, 2019 16:36:55
ARV писал(а):80% потребителей необходимы только 20% предлагаемых продавцом возможностей.
Только у каждого потребителя своя часть 20% хотелок (одному одно надо, другому другое), которая может и меняться, потому чем больше заложено в одном типе чипа возможностей, тем он востребованней, значит дешевле и т.д. Теперь осталось как-то это все притянуть к сабжу топика
.
Пн дек 30, 2019 17:07:52
Чем больше заложено в чипе возможностей, тем больше еррата
Пн дек 30, 2019 17:12:44
Плюсы без минусов не бывают в этом деле.
Пн дек 30, 2019 17:19:12
Чем больше заложено в чипе возможностей, тем больше еррата
Далеко не всегда. Например, у самого первого и популярного STM32F1 errata на 48 страниц, а у относительного нового STM32F7 она всего 22 страницы, потому что периферия была обкатана на предыдущих сериях мк.
Пн дек 30, 2019 17:22:08
Я еще студентом помню, как из одной страницы текста сделать десять. Обратно проще
Вт дек 31, 2019 22:47:40
Доброго времени суток уважаемые Коты. Поздравсяю всех с Новым годом.
Вт дек 31, 2019 22:48:24
++
Чт фев 27, 2020 10:32:39
Добрый день.
Пытаюсь переписать си-шную программу на ассемблере. Си не знаю и понимаю его очень плохо, объясните пожалуйста что значат эти строки
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;
}
Чт фев 27, 2020 10:37:40
Shuspano писал(а):if((Byte<<i)&0x80)
проверяется i-й бит в Byte на равенство 1. лично я бы за такое канделябром бы...
Shuspano писал(а):return SDA;
функция возвращает значение бита SDA. и за такое бы тоже, но можно не канделябром, а так, ссаной тряпкой...
будете переписывать - не делайте таких глупостей
Чт фев 27, 2020 10:42:04
Спасибо. Но в чем собственно, глупость?
Чт фев 27, 2020 10:45:38
глупость для анализа очередного бита каждый раз двигать один и тот же байт на разное число позиций - сильно сомневаюсь, что оптимизатор компилятора это сможет улучшить, а если не сможет - это будет вложенный цикл, абсолютно ненужный.
Добавлено after 33 seconds:
вторая глупость - возвращать нестандартный тип bit
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.