[haker_fox 60]

5 hours ago, alexan300 said:

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

Сказки. Во встраиваемом ПО так не бывает (бывает, но изредка) что мы только "трогаем" модуль A, а модули B, C, D остаются незамеченными. Вы же не для компьютера программу пишите, где разные программы работают действительно более-менее изолированно друг от друга. В вашем случае может оказаться так, что какое-нибудь прерывание или процесс из другого куска кода блокирует наше рабочее прерывание сбора данных. И придётся лезть в него, чтобы это поправить. Или придумывать обходной путь. И это я ещё про проблемы с железом молчу. Только не говорите, что их нет. Не поверю. Они почти всегда вылазят в виде помех от импульсника, или, в случае шины, срабатывающих TVS от выбросов на фронтах импульсов, или паразитной запитки микроСД и т.п. и т.д. Если вы программируете для встраиваемых систем и у вас есть хороший опыт (сомневаюсь), вы просто должны знать об этом. И 9 тысяч за такую работу, извините - смех. При стоимости рабочего дня 5 тысяч рублей я не уверен, что справлюсь с вашей задачей (где нет даже ОСРВ) за 1.8 рабочих дня (9 тысяч / 5 тысяч) или 14.4 часа. На одно только понимание, как устроена ваша система может потребоваться часов 8 рабочего времени. Минимум, на 40 тысяч вам стоит расчитывать, это стандартные 5 рабочих дней по 8 часов.

[alexan300 0]

5 hours ago, haker_fox said:

Сказки. Во встраиваемом ПО так не бывает (бывает, но изредка) что мы только "трогаем" модуль A, а модули B, C, D остаются незамеченными. Вы же не для компьютера программу пишите, где разные программы работают действительно более-менее изолированно друг от друга. В вашем случае может оказаться так, что какое-нибудь прерывание или процесс из другого куска кода блокирует наше рабочее прерывание сбора данных. И придётся лезть в него, чтобы это поправить. Или придумывать обходной путь. И это я ещё про проблемы с железом молчу. Только не говорите, что их нет. Не поверю. Они почти всегда вылазят в виде помех от импульсника, или, в случае шины, срабатывающих TVS от выбросов на фронтах импульсов, или паразитной запитки микроСД и т.п. и т.д. Если вы программируете для встраиваемых систем и у вас есть хороший опыт (сомневаюсь), вы просто должны знать об этом. И 9 тысяч за такую работу, извините - смех. При стоимости рабочего дня 5 тысяч рублей я не уверен, что справлюсь с вашей задачей (где нет даже ОСРВ) за 1.8 рабочих дня (9 тысяч / 5 тысяч) или 14.4 часа. На одно только понимание, как устроена ваша система может потребоваться часов 8 рабочего времени. Минимум, на 40 тысяч вам стоит расчитывать, это стандартные 5 рабочих дней по 8 часов.

Благодарю Вас за ответ, наконец то увидел желаемые суммы за оплату. Но я уверен что Вам 8 часов не понадобится на изучение нашей системы. Там реально все не сложно, и взято из даташитов. и потом проверенно и перепроверенно.  Операционная система реального времени, мне импонирует все больше и больше. так как ранее высказывающие товарище, верно заметили, что после записи на карту понадобятся доп функции. экраны, блютузы и тд.

Пока не могу понять, FREERtos она на ESP32 работает с двумя ядрами, или все же с одним? и потоки лишь псевдо распарралеливаются? Сейчас у меня впечатление, о том что работает ОС на одном ядре.  например:

xTaskCreatePinnedToCore(
21                     Task1code,   /* Функция задачи */
22                     "Task1",     /* Название задачи */
23                     10000,       /* Размер стека задачи */
24                     NULL,        /* Параметр задачи */
25                     1,           /* Приоритет задачи */
26                     &Task1,      /* Идентификатор задачи,
27                                     чтобы ее можно было отслеживать */
28                     0);          /* Ядро для выполнения задачи (0) */     

и 

xTaskCreate(

anotherTask, /* Task function. */

"another Task", /* name of task. */

10000, /* Stack size of task */

NULL, /* parameter of the task */

1, /* priority of the task */

NULL); /* Task handle to keep track of created task */

 

Видно, в первой инициализации, указанно ядро, во второй же, нет. 

 

 

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

[_3m 4]

7 минут назад, alexan300 сказал:

ESP32 работает с двумя ядрами, или все же с одним? и потоки лишь псевдо распарралеливаются?

Free rtos на esp32 работает с двумя ядрами.

xTaskCreatePinnedToCore нужна если вы хотите явно указать ядро на котором должна выполняться эта задача тогда как по xTaskCreate ос сама будет решать на каком ядре её выполнять .

[AlexandrY 3]

11 hours ago, alexan300 said:

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

Тут честно ничего нового вы уже не скажете.
У проектов есть middleware и оно вам требуется серьезное. 
Оно всегда сложнее и труднее в реализации чем весь уровень приложения.
Что бы ваш дивайс ни делал самая трудная его часть абсолютно ясна.  
Но проблема в том что платформу вы выбрали скверную с бедными средствами отладки. На такой платформе разработка обходится дороже. 

 

[Linker 6]

Хочу предупредить потенциальных исполнителей, кто захочет работать с alexan300. Данную задачу мы решали с ним год назад. Начали тоже с ESP32, потом я убедил его, что все-таки такие вещи нужно делать на более проверенных платформах, о чем здесь и пишут опытные разработчики. В результате эта самая задача была решена на STM32, однако данный заказчик отказался платить причитающиеся деньги, причем не большие. Отказ от оплаты им объяснялся тем, что записываемые данные от АЦП оказались не такими, как он ожидал!!. Проект большой и не простой и задача записи на карту лишь не большая часть. Естественно, что весь проект был разбит на этапы и что должно быть на выходе каждого этапа оговаривались в письменном виде.
Задача конечно решаема и на ESP32, хотя вести разработку здесь без отладчика весьма не просто. Заказчик этих вещей не понимает и вряд ли заплатит адекватные деньги.  

[Lelikk 0]

On 8/8/2020 at 4:31 AM, haker_fox said:

Это голословное утверждение. Вы никогда не применяли ОСРВ. А я применяю. С 2006 года)

Осталось только найти хорошо оттестированный код такого автомата из 100 строк? Ссылочку на гитхаб дадите?) И потом, почему вы говорите о кооперативной многозадачности (невытесняющей)?

А я с 2012 - будем меряться?)))

Ссылочку не дам, так как такой код пишу сам, код сертифицирован. Почему о кооперативной многозадачности - потому что она дешевле в реализации, при следующих условиях:
- диспетчеризуются фоновые задачи;

- код фоновых задач не написан третьей стороной, и соответственно, не содержит неожиданных блокировок;

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

[haker_fox 60]

1 hour ago, Lelikk said:

Почему о кооперативной многозадачности - потому что она дешевле в реализации, при следующих условиях:
- диспетчеризуются фоновые задачи;

- код фоновых задач не написан третьей стороной, и соответственно, не содержит неожиданных блокировок;

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

1 hour ago, Lelikk said:

один поток у нас за blinker отвечает, а другой байтики в UART шлет - это студентам в университет

Так и делаем в реальных приложениях, а что вам так не нравится в данном примере?

1 hour ago, Lelikk said:

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

Т.е. в низкой компетентности сотрудников вы вините исключительно операционные системы реального времени с вытесняющей многозадачностью? Абсурд.

[AlexandrY 3]

1 hour ago, Lelikk said:

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

Скорее всего проблема в документированности оси и консистентности ее API.
Скажем FreeRTOS отвратительно документирована. На ее применение разработчики убъют больше времени чем на ту же Azure RTOS
О мультипроцессорности во FreeRTOS можно узнать только из каких-то отрывочных блогов. Консистентность API в плане мультиядерности вызывает большие вопросы.  
Понятно что уважаемый TC бъется о FreeRTOS как рыба об лед . 

С другой стороны кто сказал что на UART нужна одна задача? Хорошая практика на каждый коммуникационный интерфейс иметь две задачи: на RX и на TX.
На TCP может и 4-х задач нехватить. Мигалка тоже требует свою задачу помимо основной. Красивые RGB мигалки с переливами требуют двух задач.
Кооперативность имеет место в бизнеслогике основной задачи. Она автоматически реализуется если вы используете среду разработки с поддержкой нотации иерархических диаграмм состояний. Но для беспроблемной реализации диаграм состояний опять же нет ничего лучше вытесняющей RTOS. 
Словом даже если вам кажется всего одна задача все равно используйте RTOS. 

[Lelikk 0]

6 hours ago, haker_fox said:

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

Так и делаем в реальных приложениях, а что вам так не нравится в данном примере?

Вы все с ног на голову перевернули.

Изначально я сказал, что для решения исходной задачи (поставленной ТС в том виде, как он ее описал, без неизвестных подробностей) не нужна RTOS.

Так же она не нужна для того, чтобы реализовать  элементарные связки задач. Если у вас уже есть RTOS, которая другие задачи диспетчеризует, то реализовывать в виде задач LED и UART - это нормально, так все делают. А вот если вы ничего сложнее этого (образно выражаясь) не реализуете - то применение RTOS туда - это смешно.

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

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

[haker_fox 60]

7 hours ago, Lelikk said:

Вы все с ног на голову перевернули.

Знаете, у меня то же самое мнение по поводу ваших ответов)

7 hours ago, Lelikk said:

А вот если вы ничего сложнее этого (образно выражаясь) не реализуете - то применение RTOS туда - это смешно.

 

7 hours ago, Lelikk said:

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

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

7 hours ago, Lelikk said:

Поэтому во многих случаях вытесняющая RTOS не нужна

Вывод, построенный непонятно на каких критериях: "смешно" и "элементарные связки".

 

Давайте пойдём следующим образом. У нас есть микроконтроллер уровня Cortex-M0, 8 кБ ОЗУ, 16 кБ ЭСПЗУ. Нам нужно мигать 8 (восьмью) светодиодами. Просто мигать с разными частотами. Что мне мешает взять ОСРВ, такую кроху, как scmRTOS? Естественно, что задачу в приведённом виде можно решить и без ОС, и даже без МК, построив восемь генераторов на к155ла3) Теперь вопрос, а что выбрать? Я привык смотреть немного в будущее, и мой опыт говорит о том, что редко задача ограничивается просто миганием светодиодами. Вполне возможно, что завтра для изменения режима мигания понадобится интерфейс пользователя. Это может быть как одна кнопка, висящая на GPIO, так и любой другой, например тач-скрин, старый добрый RS-232 или даже Wi-Fi. При наличии любого интерфейса сложнее кнопки мы сразу пролетаем с любым железным решением, будь это генераторы или ПЛИС (не спорю, на ПЛИС можно сгородить всё необходимое, но это может оказаться дороже, чем использование МК). На микроконтроллере же добавить необходиму функциональность не так сложно, при умении программировать его периферию и ориентироваться в стандарте необходимых интерфейсов. Вот только сложность ПО возрастает многократно, если работать в концепции конечных автоматов и без вытесняющей многозадачности, которая, как вы сами сказали

7 hours ago, Lelikk said:

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

Учитывая, что у автора темы задача хоть и "простая", всё же это не мигание светодиодами. Там есть сбор данных, там есть какая-то обработка. Так зачем себя изначально загонять в угол? Более того, никто же не призывает туда присобачивать ucLinux или ecos. Системы уровня TNKernel, scmRTOS, FreeRTOS со статической сборкой вполне достаточно. У меня у самого с FreeRTOS работает система сбора данных на частоте сэмплирования 1 МГЦ, оцифровывая три канала квадратурных датчика, 8 аналоговых 12-битных каналов и 8 дискретных каналов. Микроконтроллер LPC4337, задействован модуль SGPIO, упрощающий обработку дискретных данных. При этом в системе поднята сеть, выполняется математика (знаю, звучит абстрактно), имется работа с файлами.

[smart_pic 7]

10 hours ago, Lelikk said:

Изначально я сказал, что для решения исходной задачи (поставленной ТС в том виде, как он ее описал, без неизвестных подробностей) не нужна RTOS.

Вот и я подумал : а зачем RTOS?

Вот например этот прибор  http://cvg.ru/tovar/diga/power_logic/   : ВЕБ управление, причем ВЕБ на AJAX, облачный сервис,FTP загрузка выгрузка файлов,  логирование событий и действий пользователя, снятие показаний с электросчетчика, управление ДМХ512 светом, продвинутое управление с кнопок на панели , СД индикация режимов работы , управление согласно прописанным сценариям, недельный таймер и работа по расписанию и мнооооого еще чего - и все это без RTOS.

В задании ТС есть одно существенное ограничение:

On 8/5/2020 at 7:49 PM, alexan300 said:

В текущий проект необходимо добавить библиотеку обеспечивающую быструю запись на карту памяти , с файловой системой FAT32 (лучше-больше).

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

 

[haker_fox 60]

7 minutes ago, smart_pic said:

и все это без RTOS.

Враки) Не может столько задач выполняться без ОСРВ. В том или ином виде она там есть.

[smart_pic 7]

1 hour ago, haker_fox said:

Враки) Не может столько задач выполняться без ОСРВ. В том или ином виде она там есть.

Ну если цикл main  и в нем вызовы обработчиков задач - это равно ОСРВ.

Тогда практически любую систему можно считать , что там есть ОСРВ.

Вот реальный main  из этой http://cvg.ru/tovar/diga/power_logic/

системы.

Не мой целевой проц, поэтому не берусь. А так в ТЗ не вижу ничего не выполнимого.

//*********************************************************************************
	while (1)
		{
		WDTCONSET = _WDTCON_WDTCLR_MASK; // Service the WDT

		Relay_Control();
		Test_Power();
		Test_Temperatura();
		Scenariy();
		Prioritet_Logic();
		PowerSceneAlgoritm();
		// мигание СД при выполнении сценария
		if ((is_scene ==1)||(PS_State!=PS_wait) && (ROM_ledset4=='1')) WR_ShiftReg(Panel_LEDS,'1');
      		else WR_ShiftReg(Panel_LEDS,'0');

		// выполняем программы ТСР стека
		ScanKeyboard();
		StackTask();
		HTTPServer();			//программы стека
		FTPServer();			// FTP сервер
		UDPPerformanceTask();	// UDP передача пакетов
		UDPRecvTask();			// UDP прием пакетов
		TCP_Control_Task();		// ТСР соединение для  управления 
		TCP_Cloud_Task();		// ТСР соединение с облаком 
		UART3B_Conyrol();
		PingProc();
		// Два раза в секунду обновляем индикатор
		if(TickGet() - t > TICK_SECOND/2 )
			{
			t = TickGet();
			if (ROM_ledset1=='1' ){LED_WORK^=1; LED_POWER=1;}
			else {LED_WORK=1; LED_POWER=0;}
			}
	
		// Один раз в секунду читаем часики
		if(TickGet() - Trtc > TICK_SECOND )
			{
			SystemReset();
			Trtc = TickGet();
			i2cReadTime();
			Raspisanie();
			Kalibrator();
			EnergyMeter();
			}
		}
	return 0;
}
// END MAIN  ****************************************

 

Изменено 10 августа, 2020 пользователем smart_pic

[haker_fox 60]

10 minutes ago, smart_pic said:

Тогда практически любую систему можно считать , что там есть ОСРВ.

Да можно, почему нет. Одно дело, когда эту ОС каждый пишет сам под себя, другое дело - вы берёте стандартное решение, о которых я уже упоминал, и получаете нормальный , документированный инструмент.

12 minutes ago, smart_pic said:

Вот реальный main 

Жуть) У нас так в конторе тоже раньше писали) Лапша из разного кода, который зависим. Нет изоляции задач. Следовательно, написав что-то в одной задаче, это повлияет по времени исполнения на другую. И зачем смешаны вызовы методов в mainloop с непосредственно кодом?

Ну и комментарию к коду ошибочны, неуместны и избыточны.

[Lelikk 0]

16 minutes ago, haker_fox said:

Да можно, почему нет. Одно дело, когда эту ОС каждый пишет сам под себя, другое дело - вы берёте стандартное решение, о которых я уже упоминал, и получаете нормальный , документированный инструмент.

Жуть) У нас так в конторе тоже раньше писали) Лапша из разного кода, который зависим. Нет изоляции задач. Следовательно, написав что-то в одной задаче, это повлияет по времени исполнения на другую. И зачем смешаны вызовы методов в mainloop с непосредственно кодом?

 

Здесь я полностью с Вами соглашусь по обоим пунктам.

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

А вот в приведенном цикле main не разделены критические и некритические задачи вообще - все работает по принципу "сколько успею", будь это управление аппаратурой или ftp. Поэтому ему не розетками с оборудованием, а только елочной гирляндой я бы доверил управление. Лютый позор.