Вытесняющая многозадачная ОС. Практика AVR

[ARV]

Я просто ответил на вопрос и показал, как парсить строки на лету.

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

Вы лукавите. Добавлять новые ключевые слова Вам так же требуется, как и их обработчики. В моем случае, номер обработчика так же можно считать совпадающим с номером найденного ключевого слова. А размерность массивов (не строк, а указателей на строки) контролирует компилятор, а не я.

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

и сортируйте его при сборке проекта своей любимой утилитой

действительно, просто настоящие профессионалы вообще на питоне пишут скрипты, которые на лету генерируют исходники и makefile... я не такой, увы...

[ПростоНуб]

Субьективные вопросы "сложности", "вычислений за счет компилятора" и "потрудиться дополнительно" предлагаю опустить. А сосредоточиться на сути.

Суть в том, что на МК для меня важно приближение к реальному времени и экономия оперативной памяти. А буферизация, позволяющая повысить общую производительность системы за счет бОльшего расхода оперативной памяти и бОльшего времени реакции системы, этой парадигме противоречит. Именно потому я ее не использую (кроме случаев, когда она действительно необходима при DMA или скоростном SPI), получая экономию оперативной памяти и уменьшая время реакции системы на события.
Если у Вас парадигма совершенно иная - наша дискуссия просто ни о чем. В противном случае для меня странно выглядит Ваше желание тратить оперативку на буфера, когда этого можно избежать.

[ARV]

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

[dgrett]

ARV, насчёт длины смс. Ведь в самой смс есть инфо о длине. Так столько и выделяйте памяти. А если избегать кириллицу, то смс будет вдвойне короче. ( Я так понял, Вы работаете с форматом PDU).

[ARV]

Ведь в самой смс есть инфо о длине. Так столько и выделяйте памяти

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

Вы работаете с форматом PDU

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

[ПростоНуб]

[uquote="ARV",url="/forum/viewtopic.php?p=3578519#p3578519"]посимвольный анализ, я так понимаю, вы предлагаете делать в момент приема символа, т.е. в обработчик прерываний.[/uquote]
Ни в коем случае. Обработчик принимает символ и помещает сообщение с соответствующим кодом и этим символом в кольцевой буфер сообщений. На этом прерывание заканчивается.
Фоновый диспетчер сообщений после каждого прерывания (выхода из останова CPU) проверяет этот кольцеовй буфер на наличие в нем новых сообщений. При наличии таковых, вызывает соответствующий обработчик для данного вида сообщения и удаляет сообщение из буфера.
А вот разница в реакции системы достигается за счет того, что после получения последнего символа ключевого слова, выполняемый код минимален и завершится всяко быстрее, чем код проверяющий строку из буфера целиком.

В некоторых случаях, я делаю не один, а два кольцевых буфера: высокоприоритетный и низкоприоритетный. Низкоприоритетный обрабатывается только после опустошения высокоприоритетного. Так как сообщения короткие (1-4 байта), то и кольцевой буфер невелик. Обычно, от 8 до 32 байт.

[ARV]

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

Добавлено after 1 minute 44 seconds:
кстати, с модемом GSM минимальное сообщение таки да, 6 символов, а вот максимальное - для двухбайтных кодировок может достигать примерно 360 байт...

[ПростоНуб]

[uquote="ARV",url="/forum/viewtopic.php?p=3578556#p3578556"]такие муки - чего ради?[/uquote]
Я же просил не обсуждать сугубо субъективное... Для меня проект с таким кодом - развлекуха на полдня на даче в плохую погоду без всяких мук.
А когда источников таких сообщений много (UART, порт ИК-приемника, таймер, какие-то внешние датчики), у меня STM8S103F3 успевает то, что у некоторых ATMega328 не успевает.
Аналогично, для батарейного питания и, для примера, STM8L152C8, эти "микросекунды" могут обозначать в разы больший срок работы от одной литиевой батарейки.

[ARV]

ладно, раз у меня AVR успевает и без мук - на том и остановлюсь.

[dgrett]

ARV, а как Вам идея принимать СМС изначально в СИМ карту? По каким то признакам отсеиваете спам, по ходу узнаёте длину смс, выделяете буфер, обрабатываете. Тогда переключаем модем на работу с памятью МЕ (если надо), отсылаете смс(может случиться, что из того же самого буфера). Как то так, я давно с гсм модемом не работал, а йог его знает, может и сморозил я тут

PS признаком НЕ спама предлагаю использовать номер отправителя СМС, чтоб не всяк кому вздумается мог вообще до системы достучаться. А валидные номера держать в ЕЕПРОМе

[ARV]

признаком НЕ спама предлагаю использовать номер отправителя СМС

гениально! только вот в чем дело: номер отправителя выдается ОДНОВРЕМЕННО с телом самой СМС если бы можно было отдельно считать заголовок, а отдельно - содержимое, как в почте... но увы

[ПростоНуб]

Так все же, Вам хватает памяти для приема SMS или Вы из принципа не желаете парсить эту SMS на лету, не сохраняя сначала ее в памяти?

[dgrett]

Да, почему? Ведь по любому приняв байт вы его «пощупаете» перед тем как впихнете в буфер. А чё не сравнить номер на лету, скорость модема вряд ли высокая.
И ещё вот что. Я имею опыт работы с сигнализациями охранной, пожарной. У нас с самопальной пожарной объект госкомиссии не сдать. И если что, тфу,тфу страховки не видать. Это если только для себя и в целях общего развития чтоб мозги мхом не поросли. Даже датчик нельзя ремонтировать.
Зы и да, не ОДНОВРЕМЕННО, а побайтно.

[ARV]

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

[viiv]

[uquote="ARV",url="/forum/viewtopic.php?p=3579832#p3579832"]памяти для приема мне хватает, но есть опасения, что так будет не всегда.[/uquote]

так Вы же являетесь инициатором обмена. Если временно нет свободной памяти, подождать когда появится

[ARV]

Если временно нет свободной памяти, подождать когда появится

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

[ARV]

если кого заинтересовала методика, которую я описывал вот в этом сообщении https://radiokot.ru/forum/viewtopic.php ... 7#p3578137 , то могу добавить, что я описал более детально этот подход в плане создания программных таймеров вот тут: http://forum.cxem.net/index.php?/blogs/ ... одолжение/

[Demiurg]

Посмотрел вашу реализацию программных таймеров. От такой реализации программных таймеров я ушёл в то время, когда дихальт начал продвигать свой диспетчер на ассемблере. РТОС, как он называл тогда. У меня в то время был период, который проходят все начинающие. Как правильно реализовать взаимодействие программных модулей. Как добиться параллельной работы. И на первый взгляд ртос вроде как бы решала мою проблему. Я внимательно изучил этот диспетчер. Разобрал на атомы, переписал под себя. И въехал в пень. Дело в том, что это мина замедленного действия. Задачей считалось дёрнуть пином, включить светодиод, к примеру. На тот момент я баловался с автоматом световых эффектов. Что получилось: работает один режим, нажали на кнопку, поменяли режим. А в очереди осталась болтаться задача от предыдущего режима. И исправно сработала. Я долго разбирался, почему так произошло. И понял, что проблема кроется в самом диспетчере. Что такое диспетчер и РТОС? Всего лишь обработчики очереди процессов. И эта проблема изначально кроется в них. Обработка программных таймеров в прерывании и Callbak. Ни программист, ни диспетчер, ни ртос не знают, какие процессы болтаются на данный момент в очереди. И какие нужно прибить. Конечный автомат изначально лишён этого недостатка. Состояние. Всегда известно, в каком состоянии процесс. Что интересно, конечный автомат может быть процессом в диспетчере, ртос. Но, если программа реализована по принципу дробления процессов, то и смысла проворачивать очередь нет. Вся программа - список функций.
На том диспетчере я тогда потерял очень много времени. Но я понял, что такое программные таймеры.
В ваших таймерах заложена именно такая мина замедленного действия. Чем опасен такой эффект? Предположим вы занимаетесь проектом, гильотина, станок. Непредвиденная ситуация, смена режима, а у вас в очереди таймеров болтается процесс. Который и выстрелит, хотя, по режиму работы, алгоритму, этого не должно произойти. Отсюда плечи выбора. Придумывать киллеры задач, процессов, таймеров. Но мы не знаем, в каком состоянии программа. И заманаемся придумывать разные ситуации и загромождать программу. Либо изначально, алгоритмически решить эту проблему. Конечный автомат решает эту проблему "автоматом". Режим = состояние.
Моя реализация программных таймеров

[ARV]

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

Если состояние программы изменилось, оно должно выполнить приведение таймеров к тому виду, как ему (состоянию) надо - остановить лишние и запустить нужные. Только и всего.

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

И вы за деревьями леса не увидели... Суть моего принципа в том, как можно отделить объявление таймера от массива таймеров...

И, как мне кажется, у меня писанины раз в 10 меньше

Добавлено after 5 minutes 56 seconds:

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

ну, предположим, программист обязан знать...

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

любая программа - подчеркиваю жирным красным цветом - ЛЮБАЯ ПРОГРАММА - это воплощение конечного автомата. даже та, в которой состояния явно не просматриваются. и нет нужды всегда выделять состояния в самостоятельные сущности кода. понимаете? увлекшись формальным приведением любой программы в ЯВНО ВЫРАЖЕННЫЙ автомат состояний вы ничего, кроме напрасного усложнения кода, не делаете.

[ПростоНуб]

[uquote="ARV",url="/forum/viewtopic.php?p=3581258#p3581258"]любая программа - это воплощение конечного автомата[/uquote]
С определением конечного автомата не сходится. Любая самообучающася программа, теоретически (при неограниченном объеме памяти), имеет бесконечное количество состояний. То бишь не является конечным автоматом.