Споры о подходах к программированию МК, ASM vs C, и не только Опции

[_pasha]

каруселько
а что если while заменить на if()?
Проверили, пошли дальше.
Пошли-пошли...
Опять проверили...

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

[Прохожий]

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

Есть еще метод - через программное прерывание.

[_pasha]

Есть еще метод - через программное прерывание.

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

[Прохожий]

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

Это - старая сущность. С ней бороться не надо.
Аналог - обработка исключений.
Что Вы, собственно, и имеете на руках.
Т. е. Вы хотите поступить нетрадиционно в традиционной среде.

А вообще, лично я противник всяких ОС, задач, шедулеров, очередей и прочей ерунды.
От лукавого это и ненужные сущности.
Все это делается на голом железе достаточно быстро без всего этого.

[_pasha]

Т. е. Вы хотите поступить нетрадиционно в традиционной среде.

Ага, вроде как стек наизнанку вывернутый - было бы самое оно
А формирование запросов и простановка их в очередь жрет ОЗУ.

[Гость_MrYuran_*]

Все это делается на голом железе достаточно быстро без всего этого.

Это если один раз сделать и забыть навсегда.
А не получается так.
Приходят товарищи учёные и говорят, мол, замени-ка нам то на это, переделай вот тут и вот там, да побыстрее!
Если всё в железе, обычно очень негибко получается.
Да и пока вспомнишь, что к чему...

[Прохожий]

Это если один раз сделать и забыть навсегда.
А не получается так.
Приходят товарищи учёные и говорят, мол, замени-ка нам то на это, переделай вот тут и вот там, да побыстрее!
Если всё в железе, обычно очень негибко получается.
Да и пока вспомнишь, что к чему...

Все зависит от склада ума.
Мне несложно и на голом железе.
И вообще какая разница, что вспоминать?
Как ты что-то делал несколько лет назад, то ли на железе, то ли на чужой РТОС, скажем?
А насчет негибко можно поспорить.
Абсолютно не факт.

[Гость_MrYuran_*]

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

Код

#ifndef UART0_USED
#define UART0_USED
... юзаем UART0
#else
    #error "UART0 is already used"

То же самое с таймерами, пинами итд.

[_pasha]

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

Числовые значения типа #define UART_USED 1
в комбинации с инлайнами позволяют вообще живучий алгоритм создавать, он и матюкаться не будет, и лишнего кода не вставится.

[Гость_MrYuran_*]

он и матюкаться не будет, и лишнего кода не вставится.

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

[Прохожий]

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

Код

#ifndef UART0_USED
#define UART0_USED
... юзаем UART0
#else
    #error "UART0 is already used"

То же самое с таймерами, пинами итд.

А мне вообще условная трансляция никогда не нравилась.
Лучше уж копипастить...
Условную трансляцию применяю только для отладки.

[_pasha]

А мне вообще условная трансляция никогда не нравилась.

Если ее скрыть уровнем выше, пользуясь каким-нибудь нехитрым скриптом, то без разницы. Беда только в том, что все скрипты какие-то хитрые получаются

[_pasha]

Мутексы вроде как работают в рилтайме

Ну, попытались аналогию провести. "Статический мутекс". А поговорить?

[_pasha]

Хоть один пример с этим чудом можно привести?

Дык пусть MrYuran и приводит По-моему все очевидно - небольшая штучка для убиения корпоративного бардака.

Я вот тут другую штучку подметил.
Предположим, есть прерывание приемника уарта, и оно пишет тупо в очередь - для расширения времени реакции системы. Типо

Код

#define RX_QUEUE_SIZE 8
struct _rx_queue
{
char buffer[RX_QUEUE_SIZE];
char pos_rd;
char pos_wr;
} rx_queue;

*****
rx_queue.pos_wr = (rx_queue.pos_wr + 1) & (RX_QUEUE_SIZE - 1); //указатель поставщика данных
rx_queue.buffer[rx_queue.pos_wr] = RCREG;//прием байта

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

Код

#define QSIG_TIMEOUT15 (2* RX_QUEUE_SIZE)
#define QSIG_TIMEOUT35 (3 * RX_QUEUE_SIZE)
char pos = ++rx_queue.pos_wr  & (RX_QUEUE_SIZE - 1);
rx_queue.buffer[pos] = RCREG;//прием байта
if(timeout15()) rx_queue.pos_wr = QSIG_TIMEOUT15  + pos;
if(timeout35()) rx_queue.pos_wr = QSIG_TIMEOUT35  + pos;

Тогда на приемной стороне

Код

char pos = rx_queue.pos_rd  & (RX_QUEUE_SIZE - 1);// указателем чтения тоже мона сигналить поставщику данных
while(pos != rx_queue.pos_wr)
{
  if(rx_queue.pos_wr >= RX_QUEUE_SIZE)
  {
    обработка сигналов;
    rx_queue.pos_wr &= RX_QUEUE_SIZE -1; // отметка о том, что сигнал обработан
  }
// дальше чтение инфы из очереди
}

Кто-нить такое делает? А то ж хочеццо быть самым вумным

[Гость_MrYuran_*]

Лучше уж копипастить...

Ну уж нет!
Сколько раз сам себе грабли подкидывал...
Скопипастишь, тут поменял, там забыл...
Потом в этой каше вообще все ноги переломаешь.

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

УАРТ будет юзать драйвер уарта
Речь идёт про вещи, определённые на этапе компиляции.
Если несколько потоков интересуются динамически одним и тем же железом, тут надо уже что-то хитрее, типа хэндлов со всем соответствующим оверхедом.
В платной версии FreeModbus'a очень интересно сделано.
Отдельно хендлы физических портов и отдельно хендлы протоколов.
Во время инициализации протокола они взаимно увязываются.
И туда же подмешиваются хендлы виртуальных таймеров.
Красиво, конечно, но на каждый пин такое городить - никакой памяти не хватит.

[_pasha]

В платной версии FreeModbus'a

Вот я его, подлюку, бесплатного только, и перепишу до неузаваемости. Чтоб никаких завязок на прерывания не было.

[_pasha]

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

[Прохожий]

Вот я его, подлюку, бесплатного только, и перепишу до неузаваемости. Чтоб никаких завязок на прерывания не было.

Делал Modbus во всех видах и RTU, и ASCII и вместе и отдельно и на скоростях разных, вплоть до 2,5 Мбод.
Сочленял это дело с PLC ОВЕН 154, панелью ОВЕН ИП320, с частотными инверторами от OMRON (там оно MemoBUS называется).
Там все предельно просто - в документации даже машины состояний приема и передачи разрисованы, алгоритмы расчета контрольных сумм.
Нижний уровень разжеван до соплей.
В течение 3-х дней это лепится самостоятельно на событийной программной модели.
Зачем нужен "дядин" софт?

[_pasha]

В течение 3-х дней это лепится самостоятельно на событийной программной модели.
Зачем нужен "дядин" софт?

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

[Прохожий]

Чтоб никаких завязок на прерывания не было.

С чем связана такая лЫчная нЭпрЫязнь (с) к прерываниям?