0
А что страшного в том, чтобы вытащить элементы из лент? В своих проектах я по возможности стараюсь использовать резисторы Е12. Конечно есть элементы из Е24, есть кондеры, тоже в лентах. Они лежат в отдельной коробочке. Но найти нужную детальку среди десятка лент не сложно. Зато поиск элемента из этой кассы занимает пару секунд, и это просто не передать словами как приятно.
Изначально я планировал сделать 3 кассы: резисторы Е12, Е24 (не входящие в первую кассу), конденсаторы Е6 + идуктивности + много свободных ячеек. Но пока нет острой необходимости.
0
В данном случае для AVR, испытывал на Atmega16. Думаю пойдет и на других AVR. В крайнем случае нужно будет подправить инициализацию под конкретный таймер, надо ДШ смотреть
0
Позор мне! Не додуматься до самого логичного решения! Спасибо
0
попробовал

void RTOS_DeleteTask (void (*taskFunc)(void))
{
   u08 i;
    
   for (i=0; i<arrayTail; i++)                        // проходим по списку задач
   {
      if(TaskArray[i].pFunc == taskFunc)              // если задача в списке найдена
      {
         
         DISABLE_INTERRUPT;
         if(i != (arrayTail - 1))                     // переносим последнюю задачу
         {                                            // на место удаляемой
            TaskArray[i].pFunc  = TaskArray[arrayTail - 1].pFunc;
            TaskArray[i].delay  = TaskArray[arrayTail - 1].delay;
            TaskArray[i].period = TaskArray[arrayTail - 1].period;
            TaskArray[i].run    = TaskArray[arrayTail - 1].run;
         }
         arrayTail--;                                 // уменьшаем указатель "хвоста"
         RESTORE_INTERRUPT;
         return;
      }
   }
}

В тестовом проекте со светодиодами работает. В проекте паяльной станции не могу проверить, у меня там некоторые модификации начались.
0
Я 2 раза пробовал разобраться с этими протопотоками, безуспешно. Ну не могу я понять их прелести, хоть убейте. По-моему, программа еще более нечитабельна с ними.
0
В том то и дело, что в исходном варианте задачи не могут самоудалиться. Это было реализовано в этом диспетчере в первую очередь
0
Ради интереса написал простенькую программу на С: моргание светодиодом в основном цикле. Размер программы 152 байта. 0 байт занятой ОЗУ.
Затем добавил диспетчер, но установил максимальное количество задач в 0. Размер программы составил 542 байта + 2 байта в оперативке.
После этого выставил размер очереди в 1. Оформил инвертирование состояния порта как функцию и запустил ее через диспетчер. Размер программы 718 байт + 9 байт в ОЗУ.
2 функции и размер очереди 2 — 810 байт + 16 байт в ОЗУ.
Оптимизация установлена как Os. В принципе представление о размере диспетчера это дает.

2Mihail. Неплохая мысль, можно попробовать.
0
Чтобы была возможность дублировать, достаточно просто удалить первую половину функции RTOS_SetTask. Просто я не смог придумать ни одной ситации, где бы это пригодилось. Зато повсюду придется писать 2 строчки вместо одной.
0
Переделал функцию проверки нажатия кнопки. Я и сам понимал, что моя реализация была довольно кривой, но на момент написания ничего другого в голову не пришло.

void TestButton(u08 butDef, volatile u08 *pressCount, void (*taskShortPress)(void), void (*taskLongPress)(void))
{
   if(!IsBit(BUT_PIN, butDef))
   {
      *pressCount = *pressCount+1;
      
      if(*pressCount ==  BUT_FACTOR) 
      {
         BEEP;
      }
      else if(*pressCount == (BUT_FACTOR * 10))
      {
         BEEP;
         BEEP;
         BEEP;
      }
   }
   else
   {      
      if(*pressCount > (BUT_FACTOR * 10))          
      {
         RTOS_SetTask(taskLongPress, 0, 0);        // вызов функции при длительном нажатии
      }
      else if(*pressCount > BUT_FACTOR)            
      {
         RTOS_SetTask(taskShortPress, 0, 0);       // вызов функции при коротком нажатии
      }
      *pressCount = 0;
   }
}

Теперь вызовы связанных функций происходят по отжатию кнопки. Но BEEP логичней делать в нажатом состоянии, создается иллюзия, что действия выполняются именно по нажатию.