OberonCore

В проекте LPC2103, там, не помню, 16 бит, кажется, размер буфера.
Используемая скорость Modbus - 40-с-чем-то КБод. В принципе, учитывая производительность LPC-шки, даже без умножителя частоты, переполнения быть не должно.

Разумеется, не абсолютизирую режим "без прерываний" - но никто не мешает ввести обработку прерываний отдельно от основной логики, пусть по прерыванию забирается в более крупный буфер, а основная логика пишется в стиле неблокирующем.
Это позволило хорошо и надежно описать основную логику. Разрабатывалось несложное, но с запутанными режимами устройство - выносной пульт управления контроллером перекрёстка (программатор для перекрёстка, по сути).
И там сочетание конечноавтоматности с неблокирующей логикой и абстракциями типа классом контроля нажатий-отпусканий, классом, абстрагирующим целиком органы управления и т.п. помогло получить надёжный код и почти не отлаживаться.

Кстати, поскольку с дин. памятью работы нет, то С++ оказался терпим.
И однозначно рулил в сравнении с простым С, ибо хоть защита и абстракция какая-никакая )

Илья тут уже подробненько ответил, от себя добавлю, что Модбас запрос байт5-6, Модбас ответ столько же. Работает по схеме "запрос-ответ" (пассивный протокол, потом прикрутили и активную фазу, но не взлетело). Поэтому буфер на 16 байт целиком перекроет потребность в буфере приёма. Я практически не встречал в полевых устройствах скорости выше 18 кБит (практически везде 2,4-9,6 кБит, и одно устройство на линии [хотя видел реальные решения на 4-8 устройств, но там скорость была не важна -- автомобильные и железнодорожные весы]). При пакете в 4 байта необходимо опрашивать буфер приёма примерно 600 раз в секунду. Вполне выполнимое условие. А если буфер приёма 16 байт, то всего 150 раз. При тактовой частоте процессора 7 МГц:
1. Вызвать подпрограмму -- 11 тактов.
2. Считать байт из порта ввода -- 7 тактов.
3. Закинуть в память -- 4 такта.
([2, 3] повторяем ещё три раза -- 33 такта)
4. Возврат назад 11 тактов.
Итого: 66 тактов.
При 600 опросах в секунду: 39600 тактов из 7 млн. -- 0,6% от общей вычислительной мощности.

При 150 опросах и 16 байтах буфера опрос займёт 198 тактов. 29700 тактов в секунду. Из 7 млн. примерно 0,4%
Как видно, разница всего в 1,5 раза, и служебные расходы на опрос в любом случае смешные) На обработку данных средствами полевого устройства остаётся 99% времени. Да я за 6,9 млн тактов ещё успею Эйнштейн@Хоум посчитать)))
А если опрос асинхронный, тупая молотилка по кругу, то в буфере 146% по жизни ничего не будет.

Коллеги подскажите профану.
При показе окна через OpenAuxTool предварительно выставляю флаг bShow. Он нужен для того, что бы обновлять только те данные, которые отображаются через окно.
Оператор может закрыть окно в любой момент, а флаг bShow остаётся поднятым.
Я подозреваю, что у окна есть собственные средства контроля видимости ))))
Ткните пальцем где копать, плиз.

Не совсем понятен вопрос.

Оператор может закрыть окно в любой момент, за ненадобностью.
Признак "отображённости окна" остаётся.
И программа пытается обновлять данные на экране, которого уже нет. Можно, конечно, вообще отвязать этот модуль для формы через DoLater, из которого ББ берёт экспортированные данные....
Надо тут додумать.

Косвенный признак присутствия окна на экране - это вызов Guard-ов.

Т.е., по идее, из какого-то Guard-а окна можно обновлять переменную времени:
lastWindowOpened := Services.Ticks().

А на обновление:
IF Services.Ticks() < lastWindowOpened + openedInterval THEN...

Ага. Т. е. если объявить глобальную переменную в другом модуле, и засечь, что она не обновляется, значит Guard не срабатывает?
Хм, Илья.... ))) Оригинально!
Хотя... Переменную можно объявить в том же модуле (для отображения формой).

Только Guard также может не вызываться по причине скрытости всего ББ, и т.п.

Т.е. нужна вторая ветка логики:
- как только вдруг Guard вызвался первый раз после долгого простоя, форсировать Update для всех данных.

Ну, я так и понял. Guard сработал -> метка времени обновилась -> планировщик проверил, что всё в ажуре, форма видна -> Dialog.Update
или вариант два (чуть более грамотный): всё-таки DoLater встроить в сам модуль для отображения формы: проверил метку времени, если отличается больше, чем на delta_t, значит не обновляем форму. Второй частью DoLater проверяет флаг bEndProg из modGlob, и если поднят, тогда все переменные модуля в NIL и прервали цикл (я правильно понимаю, что сборщик мусора выгрузит модуль сам?)
Сработал Guard -- Dialog.Update(NOW).
Связность тут будет ниже.

Сообщения рассылаются по видимым вьюшкам.

Научите свою вьюшку реагировать на специальное сообщение.
Среагировала -- значит, видна.
Как-то так.

Да, но если у человека не вьюшка, а тупо форма )

Надо, наверное, форме сделать обёртку.

Ну, не факт, что захочется делать новый тип вьюхи...
Хотя, видимо, да, это будет гарантировано.
Именно обёртка вокруг - чтоб не было ситуации, что часть окна не видна - и всё, типа, не видно целиком...
А в случае в гвардом, наверное, так и будет.

Надо один раз насобачиться -- и лепить эти обёртки как пельмени.
Удобная штука.

Не знаю куда запихнуть, пихаю тут -- нашёл косяк.
В System/Docu/Math (версия ББ 1.6, Красноярская сборка) в документации по описанию гиперболических и тригонометрических функций приведена формула "(1 рад = 180/pi градусов)", что имхо, слегка неправда. 1 рад = pi/180 градусов < вот так результат верный. Формулку из документации не думая переписал в код ОИК "Восход" и десятка два минут тупо смотрел на монитор, не понимая, что происходит.

Думаю, что Вам решительно возразят

Эээ... Если делить пи на градусы, то получим соотношение 1 радиана на какое-то количество градусов. Если 180 градусов на пи -- то какое-то количество градусов на каждый радиан.
У меня исходные данные в градусах, которые нужно привести к радианам. Если я напишу 180/pi*grad = [хрен поймёшь чему равно]?

Новая Система Ебиниц от prospero78?

1 радиан = 57.2958 градусов.
Но я признаю ваше право на иное мнение.

Сколько градусов в радиане, я в курсе))) И это сомнению не подлежит (по крайней мере, при существующих физических константах в нашем пространстве-времени). Я не понимаю, почему делаю 180/pi*grad -- получается ерунда. Когда делаю pi/180*grad = правильный ответ.
Размерности, будут правильные при [рад/град]*град. На выходе чистые радианы. И это правильно!
Размерность [град/рад]*град будет [град^2/рад]. Это равно радиану???
Получается, что документация содержит ошибку в приводимой формуле?



Я же не придумал это?


Кемет, как всегда очень остроумно). Обхохочешься.
И какой полёт инженерно-технической мысли! Ажна до пояса достаёт!