[jcxz 184]

16 минут назад, artemkad сказал:

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

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

Расскажите нам - как именно вы собираетесь выводить страницу, отправленную HTTPS-сервером не скачав и не дешифровав полный AES-кадр???

Надеюсь - что такое TLS слыхали? Как работает - в курсе?

Расскажите нам - как парсить "по чанкам" страницу, сжатую gzip-ом и шифрованную например AES-256? Я думаю - тут всем это будет интересно. Да ещё и на мировую премию по математике думаю сможете претендовать, за открытие века. 

23 минуты назад, artemkad сказал:

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

Т.е. - предлагаете начинать обрабатывать, даже не проверив корректность (целостность)? не подсчитав контрольную сумму/CRC?

А без приёма кадра полностью, его корректность никак не определить.

Типичный быдлокодерский стиль - обрабатывать входящие данные даже не проверив их корректность.

26 минут назад, artemkad сказал:

Если для котла критичны 100мс, то что мешает отработать аварийные цепи в прерываниях? Судя по тому, что у камня хватает ресурсов для парсинга зипованных web-страниц, время подобной реакции будет исчисляться микросекундами. 

Как видно - вы даже не удосужились почитать условия задачи. Или не поняли их. Повторю ещё раз:

3 часа назад, jcxz сказал:

А если к тому же эти две задачи ещё и обращаются к общему разделяемому ресурсу? (флешка или ФС или т.п.) Драйвер которого имеет API, вызываемый с уровня задачи ОС.

Внимательно перечитайте. Особенно выделенное жирным. И расскажите - каким именно образом этой задаче (засунутой в прерывание) следует обращаться к такому сервису? Например - к FatFS?

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

 

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

[artemkad 53]

1 час назад, jcxz сказал:

Расскажите нам - как парсить "по чанкам" страницу, сжатую gzip-ом и шифрованную например AES-256?

AES отдельно, gzip отдельно и парсер отдельно. Разными задачами. Причем видится мне, что парсер можно даже разделить на несколько задач для прохода по дереву. Опять-же и AES и GZIP обрабатываются кусками после обработки которых можно заняться чем угодно. Несколько задач каждая из которых начинает серьезно работать после появления у нее на входе достаточного куска данных.

Впрочем, я подозреваю, что в Вашем коде для РТОС для "парсинга HTML" я увижу то, что вы же выше назвали как  

2 часа назад, jcxz сказал:

Если у программера задача "тупо ожидает в цикле", то такой программер очевидно не знает - что такое РТОС и как в ней работать.

Т.е. громадный цикл в надежде на то, что РТОС сама время на остальное нарежет.

1 час назад, jcxz сказал:

Т.е. - предлагаете начинать обрабатывать, даже не проверив корректность (целостность)? не подсчитав контрольную сумму/CRC?

А что мешает обрабатывать, а затем уже принимать решение корректно принятое  и обработанное или нет? В противном случае тупо потратишь вполне реальное время.

1 час назад, jcxz сказал:

И расскажите - каким именно образом этой задаче (засунутой в прерывание) следует обращаться к такому сервису? Например - к FatFS?

Т.е. Вы хотите задачу которая отвечает за безопасность оборудования поставить в зависимость от ее блокировки заглючившей флешкой? Боюсь тут задержкой в  100мс можно не отделаться. Напомните, вы что-то там говорили про быдлокодинг?

1 час назад, jcxz сказал:

А самое сложное - это разделяемые ресурсы.

И что мешает разделить мух от котлет или  работу с разделяемыми ресурсами и работу с критически важными по времени событиями? С чего вдруг это надо объединять в одну задачу? У вас в доме телевизор автоматом на щитке тоже управляет? Почему нет - там ведь мощный процессор и почти наверняка с ОС(может даже с РТОС)?

[Ruslan1 16]

14 часов назад, artemkad сказал:

Т.е. громадный цикл в надежде на то, что РТОС сама время на остальное нарежет.

Какой цикл? при чем здесь цикл?

Задача говорит системе: "я буду спать до того как произойдет такое-то событие". Шедулер усыпляет задачу и передает ей снова управление только тогда, когда указанное событие произойдет. Если в этот момент выполняется задача с большим приоритетом- то шедулер подождет, пока это высокоприоритетная задача отдаст управление шедулеру, и наконец-то запустит эту задачу.

Никаких циклов и поедания ресурсов в этой ожидающей задаче нет.

А если Вам нужно просто задержку организовать- так это опять же через RTOS: задача говорит системе "разбуди меня через столько-то системных тиков", и все. Если ожидание меньше системного тика- то задача взводит аппаратный таймер и из прерывания этого таймера посылается сигнал. А задача говорит системе "разбуди меня, когда пришел сигнал от таймера".

 

И Вы как-то зациклились на расходе ОЗУ. Вам действительно настолько критичны те 64 байта на задачу плюс стек, и разово 236 байт на шедулер, которые нужны, например, freeRTOS?

Scheduler Itself: 236 bytes (can easily be reduced by using smaller data types).

For each queue you create, add:  76 bytes + queue storage area

For each task you create, add: 64 bytes (includes 4 characters for the task name) + the task stack size.

Про стек на задачу: это зависит. У меня, например,  128 элементов (128*4 байт), но тут можно и оптимизировать. 

[artemkad 53]

1 час назад, Ruslan1 сказал:

Какой цикл?

Который 

20 часов назад, jcxz сказал:

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

И все в одной задаче.

1 час назад, Ruslan1 сказал:

И Вы как-то зациклились на расходе ОЗУ.

Пытаюсь предположить, откуда у пишущих на РТОС такое желание запихнуть как можно больше в одну задачу вместо того, что-бы разбить ее на десяток. Подозреваю, что ОЗУ не резиновое.

1 час назад, Ruslan1 сказал:

Вам действительно настолько критичны те 64 байта на задачу плюс стек, и разово 236 байт на шедулер, которые нужны, например, freeRTOS?

.....

Про стек на задачу: это зависит. У меня, например,  128 элементов (128*4 байт), но тут можно и оптимизировать. 

Т.е. 576 байт на задачу. Если запустить под сотню задач, это примерно 60кБ ОЗУ тупо на обслуживание вытесняющей многозадачности.

[jcxz 184]

1 час назад, Ruslan1 сказал:

Какой цикл? при чем здесь цикл?

Задача говорит системе: "я буду спать до того как произойдет такое-то событие". Шедулер усыпляет задачу и передает ей снова управление только тогда, когда указанное событие произойдет. Если в этот момент выполняется задача с большим приоритетом- то шедулер подождет, пока это высокоприоритетная задача отдаст управление шедулеру, и наконец-то запустит эту задачу.

Никаких циклов и поедания ресурсов в этой ожидающей задаче нет.

Это бесполезно всё. Разве не видите? - человек совершенно не понимает что такое ОСРВ и как в ней работать. Мыслит исключительно в парадигме суперцикла. Всё время талдычит о каких-то циклах и т.п. Пытается применять приёмы суперциклов к работе в ОСРВ. Не понимает что такое event-driven программирование.

Вот о таких я и говорил выше:

В 10.01.2024 в 18:10, jcxz сказал:

ЗЫ: Если люди, которые когда-то что-то освоили. Давно. Чуть-чуть. И потом, даже под страхом пытки не хотят изучать ничего нового, лучшего. И никакие разумные аргументы не действуют.  

упёртые суперлуперы.

Потребует от него заказчик написать что-то обязательно на ОСРВ. Напишет. Но там тоже окажется всё тот же суперцикл, впустую жрущий ресурсы CPU.  

[x893 35]

25 minutes ago, jcxz said:

упёртые суперлуперы.

Толерантнее будет- гуру программирования.

[artemkad 53]

8 минут назад, jcxz сказал:

Мыслит исключительно в парадигме суперцикла.

Смотрим на "парадигму суперцикла"

1 час назад, Ruslan1 сказал:

"я буду спать до того как произойдет такое-то событие"

StopTask ( task_ht t)

1 час назад, Ruslan1 сказал:

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

SleepTask ( task_ht  t, tt_state_t n)

Отдать управление остальным:

return;

И все в рамках суперцикла.

Причем я тут глянул task_list на моем средненьком проекте на xmega32A4 (32+4кБ флеши и 4kB оперативки) на почти вышеупомянутом диспетчере было 20+24=44 задачи ...

[jcxz 184]

8 минут назад, artemkad сказал:

Смотрим на "парадигму суперцикла"

2 часа назад, Ruslan1 сказал:

"я буду спать до того как произойдет такое-то событие"

StopTask ( task_ht t)

И...? А как же остальные "задачи", которые ваш суперлуп обслуживает? Они тоже перестанут выполняться, когда в какой-то задаче заснёте?

8 минут назад, artemkad сказал:

SleepTask ( task_ht  t, tt_state_t n)

Как именно собираетесь усыплять одну задачу, при условии того, что она - часть вашего суперцикла?

Заснёт ваш суперлуп целиком. И проспит все события прочих задач.

[artemkad 53]

47 минут назад, jcxz сказал:

Они тоже перестанут выполняться, когда в какой-то задаче заснёте?

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

Как писал выше - тут всего лишь разный подход к написанию задач.

47 минут назад, jcxz сказал:

Как именно собираетесь усыплять одну задачу,  при условии того, что она - часть вашего суперцикла?

void SleepTask ( task_ht  t, tt_state_t n)
{	
 	n++;
	task_table_state[t] = n;
}

после чего отдать управление дальше(выйти)

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

[Arlleex 131]

3 часа назад, Ruslan1 сказал:

For each task you create, add: 64 bytes (includes 4 characters for the task name) + the task stack size.

И все-таки, Вы, скорее всего, взяли описание типового порта для какого-то Cortex-M, у которых два указателя стека.

А для МК с одним общим стеком требования к ОЗУ задач несколько повыше будут.
 

1 час назад, artemkad сказал:

Т.е. 576 байт на задачу. Если запустить под сотню задач, это примерно 60кБ ОЗУ тупо на обслуживание вытесняющей многозадачности.

Сложно придумать проект софта под МК, где реально потребуется сотня задач. У меня самый максимум - в районе 15 задач было. Непростых, и даже тяжелых развесистых задач.

Другое дело, если в динамике (в зависимости от режима работы устройства) может сильно меняться функционал: тогда нужно приплюсовать эти самые задачи.

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

1 час назад, jcxz сказал:

Заснёт ваш суперлуп целиком. И проспит все события прочих задач.

В таких случаях никакие суперлупы не помогут, разумеется. Поэтому я для себя когда-то накидал простейший кооперативный планировщик (планировщик это еще мощно сказано), чтобы можно было сохранить стилистику независимого кодирования задач, в бесконечном цикле каждая, работающая по событиям. Задача не потребляет времени, если выполняется другая (через нее не "пролетает" выполнение CPU). Только при возникновении событий планировщик может передать управление той задаче, которая это событие ждала. Разумеется, свойственное кооперативке требование отдавать время планировщику самостоятельно никуда не делось.

Вот вместо лапши суперлупа отдаю предпочтение такой самописной планировке, ну а в остальных случаях - FreeRTOS. Но когда кода с гулькин хвост - пишу в суперцикле, не заморачиваюсь.

[x893 35]

https://dunkels.com/adam/pt/examples.html

18 лет тому назад

The example shows two protothreads, one for the sender and one for the receiver.

#include "pt.h"
 
PT_THREAD(sender(struct pt *pt))
{
  PT_BEGIN(pt);  
  do {
    send_packet();
    /* Wait until an ackowledgement has been received, or until the
       timer expires. If the timer expires, we should send the packet
       again. */
    timer_set(&timer, TIMEOUT);
    PT_WAIT_UNTIL(pt, acknowledgment_received() ||
                      timer_expired(&timer));
  } while(timer_expired(&timer));  
  PT_END(pt);
}
 
PT_THREAD(receiver(struct pt *pt))
{
  PT_BEGIN(pt);
  /* Wait until a packet has been received, and send an
     acknowledgment. */
  PT_WAIT_UNTIL(pt, packet_received());
  send_acknowledgement();  
  PT_END(pt);
}

 

[Ruslan1 16]

2 часа назад, jcxz сказал:

Пытается применять приёмы суперциклов к работе в ОСРВ. Не понимает что такое event-driven программирование.

Кстати да, это сложный переход. Я тоже через это прошел, когда после турбо-си и суперлупов начал писать в С++Билдере. Это был шок: вообще никакого "суперлупа", у каждого окошка/кнопочки/компонента свои события и функции их обработки. Очень тяжело было, первые пару дней, но зато потом как понял! 🙂

Но это вечная тема, что-то мы принимаем, а что-то нет или с большим скрипом. Вот мне, например, не дается идеология C++ с объектами/классами. А кто-то проникся и вовсю пользует.

2 часа назад, artemkad сказал:

Т.е. 576 байт на задачу. Если запустить под сотню задач, это примерно 60кБ ОЗУ тупо на обслуживание вытесняющей многозадачности.

"Сотня задач" подразумевает какую-то очень непростую обработку каких-то данных. А эти данные где-то тоже хранить нужно. При таком сложном алгоритме и устройстве, никогда не поверю, что 60 килобайт на служебные нужды будет серьезным вкладом в общее необходимое количество RAM. И если Вы возъметесь организовывать свои сервисы, на это тоже уйдет память, природу не обмануть. 

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

[Arlleex 131]

1 час назад, x893 сказал:

https://dunkels.com/adam/pt/examples.html

18 лет тому назад

А Вам самому удобно ими пользоваться? Я когда-то попробовал, фишку понял, но не оценил.

Их при описании стейтмашин еще можно как-то приплести, но как по мне, проще уж реально кооперативный режим ОС использовать и не мудрить.

[x893 35]

1 hour ago, Arlleex said:

А Вам самому удобно ими пользоваться? Я когда-то попробовал, фишку понял, но не оценил.

Их при описании стейтмашин еще можно как-то приплести, но как по мне, проще уж реально кооперативный режим ОС использовать и не мудрить.

Я не пользуюсь. Вернее чем удобно, тем и пользуюсь.

[artemkad 53]

8 часов назад, Ruslan1 сказал:

Это был шок: вообще никакого "суперлупа",

Не, не, не - никакой лапши в коде. Есть отдельный файлик task_list.h в котором между  #ifdef SYSTEM_TASK #endif  и  #ifdef TASK #endif вписывается те процедуры, что становится частью суперцикла. Заодно по этому файлу создаются все требуемые служебные массивы и идентификаторы битов таймеров и задач. Примерно так:

#ifdef SYSTEM_TASK
SYSTEM_TASK(task_System_mgr)				//
SYSTEM_TASK(task_sys_events)				// задача обмена данными между sys  и i2c_temp
SYSTEM_TASK(task_timer_sys)					//
SYSTEM_TASK(init_configOut_bm)				// обновление битовых масок выходов

SYSTEM_TASK(EVENTS_to_FIFO_system_task)

///  ...................................
#endif
  
#ifdef TASK
#ifdef TRACE_TASK
TASK(test_trace,tt_NULL,1)				// тестовая задача
#endif

TASK(task_send_MSG,tt_250ms,0)			// отправка сообщения

#ifdef GPS_INC
TASK(task_gps_test,tt_1s,0)				// тест GPS-модуля
TASK(task_gps_send,tt_1s,0)
TASK(task_gps_backup_off,tt_1s,0)
#endif

/// .....................................
#endif

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

8 часов назад, Ruslan1 сказал:

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

Почему сразу данных? Обработка общения с несколькими устройствами чем не устраивает? Вышеупомянутый проектик на 44 задачи это по сути шлюз между i2c на основной процессор и gps-приемником, gsm-модемом(с другой стороны сервер), i2c датчиком, spi-памятью, неким внешним блочком с uart-ом и своим протоколом, плюс несколькими входами/выходами. Данных там не много и почти все после обработки  пролетают транзитом.

8 часов назад, Ruslan1 сказал:

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

Сейчас там используется "2 796 bytes of DATA  memory" большая часть которых это буфера и очереди. 

8 часов назад, Ruslan1 сказал:

Сейчас внутреннюю память микроконтроллеров сотнями килобайт считают,

Смотрю на ширпотребные STM32 и только у топа вижу 128кБ ОЗУ. А в основной массе до 32кБ. Где сотни?