Да, реализация действительно красивее :) Особенно понравилось решение с маской, избавляемся от условного перехода, что есть гут ) Да и от лишней переменной…

Вот кстати не мог вспомнить 3й пункт в вопросы, а это как раз были потоковые обращения… Да, на данный момент отключаю прерывания перед вызовом функций, внутрь библиотеки это не вносил, т.к. считаю что про манипуляции с прерываниями нужно помнить в контексте проекта… И кстати без count тоже вопрос… Конструкция вида

fifo->data[fifo->tail++] =((u8*) data)[i];

тоже ведь может быть не атомарной, управление может быть перехвачено уже после обращения к массиву, но до инкремента «хвоста»… Или я не прав?
Вот кстати на данном этапе почитываю C# Троелсена, и действительно в С хочется иметь плюшки ООП =) Теперь понимаю, почему ты на плюсах пишешь… Наверное тоже попробую, только пока углубиться в изучение не получится, боюсь что вместе с шарпом в голове каша получится — буду путать нюансы…
А по поводу длины буфера внутри структуры — вот как-то проскакивала такая мысль, но потом решил что не получится, и даже не проверил…
Как это должно выглядеть? Что-то вида:

typedef struct {
  u8 const len;
  u8 data[len];
  u8 head;
  u8 tail;
  u8 count;
} fifo_t;

Но подозреваю что не совсем так, компилятор то должен знать длину массива уже на этапе объявления… (Сейчас IAR не стоит, точнее стоит только для STM8)
Все, мне пора убегать :) Спасибо за пояснение.

Так куда уже полушаговее =) Приглядитесь к коду…

Кстати поздравляю :) Долго, но таки дали :) Значит по мере наличия времени будут еще уроки?

Сергей, обрати, плз, внимание на формат коммента: после редактирования кнопкой «изменить» в форме вылазит много мусора и после сохранения вылазит в видимость тэг «code»…

А не связано это с тем, что приоритет операции логического отрицания выше, чем побитовое «и»? Мб скобки переставить:

if (EncPortData[1]&0x01 && !(EncPortData[0]&0x01))//нарастающий фронт по А!
if (EncPortData[1]>>1)&0x01 && !(EncPortData[0]>>1)&0x01)//нарастающий фронт по B!

В первой строчке вообще не понятно зачем скобки вокруг элемента массива…

Такс, не внимательно простомтрел, пункт 2 более не актуален :) разницы то нет…

Человек описал один из методов обработки данных с энкодера, что здесь странного? Или ему для этого нужно было прикупить УЧПУ или ПЛК, и на нем показывать? :) Что как раз странно, так данное замечание :)

Только появляются два спорных момента:

1. Неточности при сдвиге между сигналами отличном от 90 градусов (такое бывает, допустим в наших станках хорошую долю энкодеров составляют ВЕ178 различных вариантов, так вот при ремонте их даже регулировать приходится чтобы получить нормальный сдвиг)
2. Помехоустойчивость… Я понимаю, что у взрослых энкодеров выход дифференциальный, но суть кода грея как раз в том что без «форсирования» счетному устройству пофиг на мелкие помехи...

Вот только несколько дней назад была мысль попросить тебя написать об этом! Здорово, спасибо!

Шаговика кстати за счет мягкого подвеса не слышно вообще, даже стоя рядом на табуретке… Шаги слышны только по вибрации если взяться за двиг. Движение шара тоже плавное, за счет цепочки, которая рывки демпфирует…

По стабилизатору тока — просто учту на будущее, если буду делать RGB контроллер… За совет по RC-цепочке пасибы, попробую посимулировать на досуге чтобы прочувствовать что к чему…

По логарифмической зависимости в курсе (из твоей же статьи про лампочку), реализую это в программе в любом случае…

И свитер одеть еще надо )

Поздравляю с приобретением! Удачного дальнейшего развития :)

Дейсьвительно мощную ведь изобразил один товарищ:
www.youtube.com/user/aquaticinstruments
вот в такому стремиться надо ))