Если ваш вопрос не влез ни в одну из вышеперечисленных тем, вам сюда.
Ответить

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

Вс дек 29, 2019 21:15:59

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

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

Вс дек 29, 2019 21:41:57

Мурик писал(а):Нормальный МК должен иметь контроллер прерываний поддерживающий вложенные прерывания и иметь возможность назначать приоритет вложенности
например, любой из семейства MCS51, включая древность типа КР1816ВЕ31 :)))

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

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

Вс дек 29, 2019 21:54:34

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

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

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

Вс дек 29, 2019 22:08:38

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

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

Пн дек 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 соответственно и остальное забота контроллера прерываний. Более высокоприоритетное прерывание в любой момент может прервать прерывание с меньшим приоритетом, но не наоборот.
Если же нет поддержки вложенных приоритетов прерываний и разрешать другие прерывания при входе в прерывание, может произойти более низкоприоритетное, которое не должно обрабатываться пока выполняется код высокроприоритетного. Контроль придется осуществлять программно, из-за чего усложнится код, увеличится время перехода в высокопроиоритетное прерывание и если произойдет низкоприоритетное, нужно будет думать как вернутся назад в вывокоприоритетное, а после его обработки перейти в низкоприоритетное. Когда таких прерываний десяток другой, разрулить будет не просто.

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

Пн дек 30, 2019 09:40:07

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

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

Пн дек 30, 2019 13:59:25

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

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

Пн дек 30, 2019 16:25:35

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

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

Пн дек 30, 2019 16:29:41

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

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

Пн дек 30, 2019 16:36:55

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

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

Пн дек 30, 2019 17:07:52

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

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

Пн дек 30, 2019 17:12:44

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

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

Пн дек 30, 2019 17:19:12

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

Далеко не всегда. Например, у самого первого и популярного STM32F1 errata на 48 страниц, а у относительного нового STM32F7 она всего 22 страницы, потому что периферия была обкатана на предыдущих сериях мк.

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

Пн дек 30, 2019 17:22:08

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

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

Вт дек 31, 2019 22:47:40

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

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

Вт дек 31, 2019 22:48:24

++

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

Чт фев 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;
}

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

Чт фев 27, 2020 10:37:40

Shuspano писал(а):if((Byte<<i)&0x80)
проверяется i-й бит в Byte на равенство 1. лично я бы за такое канделябром бы...
Shuspano писал(а):return SDA;
функция возвращает значение бита SDA. и за такое бы тоже, но можно не канделябром, а так, ссаной тряпкой...

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

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

Чт фев 27, 2020 10:42:04

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

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

Чт фев 27, 2020 10:45:38

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

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