STM32 + uIP + enc28j60

Долго облизывался на подключение МК к Ethernet, ходил вокруг цикла статей Lifelover'a, и решил попробовать. Но как в том анекдоте «не в лото, а в покер, не Волгу, а сто рублей и не выиграл, а проиграл» отличия от проекта Lifelover'a будут следующие:

  • камень stm32f103v, флеша у которого аж 512к. Меньше 64к у STM32 — редкость, что не может не радовать
  • tcp стек решил взять готовый, в частности uIP. Пробовал стек от Lifelover'a, но там много AVR-овских особенностей — раздельная адресация как минимум. В итоге запустил, погонял, но решил все-таки перейти на стандартный стек.
  • ОС, естественно, FreeRTOS,
  • Ну а Ethernet-контроллер все тот же enc28j60, подключенный через SPI

В этой статье мы соберем минимальное приложение, которое висит на порту 1000 и что-то там пишет.



Итак, качаем исходники uIP отсюда
Копируем (или подключаем) полностью папку /uIP, там лежат неизменяемые библиотечные файлы

Проект берем из статьи про FreeRTOS, настройку FreeRTOS я здесь опускаю.

В каталог проекта копируем следующие файлы:
uip-conf.h — берем стандартный и потом чуть подправим
clock-arch.c/clock-arch.h – копируем стандартные и закомментируем функцию работы со временем, потом ее допишем
hello-world.с/hello-world.h — это, собственно, приложение, которое и будет крутиться поверх стека
enc28j60.c/enc28j60.h – это драйвер Ethernet контроллера, написаный Lifelover'ом для AVR и адаптированный к stm32. Переписана функция инициализации и работы с SPI

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

Согласно сетевой модели OSI, uIP занимает уровни с третьего по шестой. На нижние уровни не лезет.
Фактически uIP предоставляет буфер для ethernet-фрейма, который мы должны каким-то образом заполнить. Неважно как — получив по сети, скопировав с флешки, почтовыми голубями (кстати, есть rfc1149 по этому поводу).
Все, что переварило uIP. оно потом передает на верхний уровень — приложению. Можно заглянуть в файл hello-world.c — там описаны пару функций-коллбэков, которые вызываются при приходе данных. Если нужно что-то отправить по сети, вызывается соответствующий макрос PSOCK_SEND_STR().

Соответственно, главный цикл будет выглядеть так:

		// принимаем пакет (если есть)
		uip_len = enc28j60_recv_packet((uint8_t *) uip_buf, UIP_BUFSIZE);

		if (uip_len > 0) {
			if (BUF->type == htons(UIP_ETHTYPE_IP)) {
				// если пакет IP, то засылаем в стек
				uip_arp_ipin();
				uip_input();
				if (uip_len > 0) {
					// если есть что-то на выход, засылаем в сеть
					uip_arp_out();
					enc28j60_send_packet((uint8_t *) uip_buf, uip_len);
				}
			} else if (BUF->type == htons(UIP_ETHTYPE_ARP)) {
				// если это касается ARP, то передаем в блок ARP
				uip_arp_arpin();
				if (uip_len > 0) {
					enc28j60_send_packet((uint8_t *) uip_buf, uip_len);
				}
			}
		}


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

Вся остальная настройка сводится к тому, чтобы подключить приложение hello-world в файле uip-conf.h (раскомментировать соответствующую строчку).

Теперь наш файл main.c

Сначала надо проинициализировать все что у нас есть:
// это будет наш МАС-адрес
	struct uip_eth_addr mac = { { 0x00, 0x01, 0x02, 0x03, 0x04, 0x00 } };

	// проинитим наш  enc28j60
	enc28j60_init(mac.addr);

	// инициализация стека
	uip_init();
	uip_arp_init();

	// инициализация приложения, потом втулим сюда веб-сервер
	hello_world_init();

	// установим наш МАС
	uip_setethaddr(mac);

	// установим адрес хоста (не используем dhcp)
	// наш хост будет доступен по адресу 192.168.2.55
	uip_ipaddr_t ipaddr;
	uip_ipaddr(ipaddr, 192, 168, 2, 55);
	uip_sethostaddr(ipaddr);
	uip_ipaddr(ipaddr, 192, 168, 2, 1);
	uip_setdraddr(ipaddr);
	uip_ipaddr(ipaddr, 255, 255, 255, 0);
	uip_setnetmask(ipaddr);

Также есть необходимость периодически дергать еще пару функций uIP – чтобы он вовремя широковещательные пакеты рассылал и таблицы чистил.

В оригинале это все предлагалось делать в процедуре main в бесконечном цикле. Но у нас же RTOS! Оформим это все в виде двух тасков:

void vTask_uIP_periodic(void *pvParameters) {
	uint32_t i;
	uint8_t delay_arp = 0;

	for (;;) {
		vTaskDelay(configTICK_RATE_HZ/2); // полсекунды
		delay_arp++;
		for (i = 0; i < UIP_CONNS; i++) {
			uip_periodic(i);
			if (uip_len > 0) {
				uip_arp_out();
				enc28j60_send_packet((uint8_t *) uip_buf, uip_len);
			}
		}

#if UIP_UDP
		for(i = 0; i < UIP_UDP_CONNS; i++) {
			uip_udp_periodic(i);
			if(uip_len > 0) {
				uip_arp_out();
				network_send();
			}
		}
#endif /* UIP_UDP */

		if (delay_arp >= 50) { // один раз за 50 проходов цикла, около 10 сек.
			delay_arp = 0;
			uip_arp_timer();
		}
	}
}
//--------------------------------------------------------------
void vTask_uIP(void *pvParameters) {



	for (;;) {
		uip_len = enc28j60_recv_packet((uint8_t *) uip_buf, UIP_BUFSIZE);

		if (uip_len > 0) {
			if (BUF->type == htons(UIP_ETHTYPE_IP)) {
				uip_arp_ipin();
				uip_input();
				if (uip_len > 0) {
					uip_arp_out();
					enc28j60_send_packet((uint8_t *) uip_buf, uip_len);
				}
			} else if (BUF->type == htons(UIP_ETHTYPE_ARP)) {
				uip_arp_arpin();
				if (uip_len > 0) {
					enc28j60_send_packet((uint8_t *) uip_buf, uip_len);
				}
			}
		}
		taskYIELD();
	}
}

//--------------------------------------------------------------


Ну, собственно, и все. Компилируем, запускаем — опаньки, все работает :)

D:\>ping 192.168.2.55

Обмен пакетами с 192.168.2.55 по с 32 байтами данных:
Ответ от 192.168.2.55: число байт=32 время=1мс TTL=128
Ответ от 192.168.2.55: число байт=32 время<1мс TTL=128
Ответ от 192.168.2.55: число байт=32 время<1мс TTL=128
Ответ от 192.168.2.55: число байт=32 время<1мс TTL=128

Статистика Ping для 192.168.2.55:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 0мсек, Максимальное = 1 мсек, Среднее = 0 мсек

D:\>telnet 192.168.2.55 1000
Hello. What is your name?
                         User
Hello User


Подключение к узлу утеряно.


Все вместе (RTOS и uIP) заняли чуть меньше 11кб кода. Размер буферов для пакетов, количество соединений и т. п., что влияет на оперативку, можно настроить все в том же uip-conf.h

При компиляции вываливается неожиданно много ворнингов на тему «dereferencing type-punned pointer will break strict-aliasing rules», отключил пока опцией -fno-strict-aliasing компилятора, потом гляну подробнее. Ну и ругань на тему «функция не-void, а return нету». Это особенность используемых в библиотеке protothreads.

PS. и пару слов, что изменилось в драйвере от Lifelover'a:


#define enc28j60_select() GPIO_ResetBits(GPIOB, GPIO_Pin_12)
#define enc28j60_release() GPIO_SetBits(GPIOB, GPIO_Pin_12)

uint8_t enc28j60_rxtx(uint8_t data)
{
	while(SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_TXE)==RESET);
	SPI_I2S_SendData(SPI2,data);

	while(SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_RXNE)==RESET);
	return SPI_I2S_ReceiveData(SPI2);
}


void enc28j60_init(uint8_t *macadr)
{
	uint32_t i;
	// Initialize SPI
	RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB | RCC_APB2Periph_AFIO, ENABLE);
	RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE);
	RCC_APB1PeriphClockCmd(RCC_APB1Periph_SPI2, ENABLE);

	GPIO_InitTypeDef GPIO_InitStruct;

	// MOSI & CLK
	GPIO_InitStruct.GPIO_Pin = GPIO_Pin_13 | GPIO_Pin_15;
	GPIO_InitStruct.GPIO_Mode = GPIO_Mode_AF_PP;
	GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz;

	GPIO_Init(GPIOB, &GPIO_InitStruct);

	// MISO
	GPIO_InitStruct.GPIO_Pin = GPIO_Pin_14;
	GPIO_InitStruct.GPIO_Mode = GPIO_Mode_IPU;
	GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz;

	GPIO_Init(GPIOB, &GPIO_InitStruct);

	// SS
	GPIO_InitStruct.GPIO_Pin = GPIO_Pin_12;
	GPIO_InitStruct.GPIO_Mode = GPIO_Mode_Out_PP;
	GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz;

	GPIO_Init(GPIOB, &GPIO_InitStruct);

	// RESET
	GPIO_InitStruct.GPIO_Pin = GPIO_Pin_7;
	GPIO_InitStruct.GPIO_Mode = GPIO_Mode_Out_PP;
	GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz;

	GPIO_Init(GPIOA, &GPIO_InitStruct);

	SPI_InitTypeDef SPI_InitStruct;

	SPI_InitStruct.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_4;
	SPI_InitStruct.SPI_Direction = SPI_Direction_2Lines_FullDuplex;
	SPI_InitStruct.SPI_Mode = SPI_Mode_Master;
	SPI_InitStruct.SPI_DataSize = SPI_DataSize_8b;
	SPI_InitStruct.SPI_CPOL = SPI_CPOL_Low;
	SPI_InitStruct.SPI_CPHA = SPI_CPHA_1Edge;
	SPI_InitStruct.SPI_NSS = SPI_NSS_Soft;
	SPI_InitStruct.SPI_FirstBit = SPI_FirstBit_MSB;
	SPI_InitStruct.SPI_CRCPolynomial = 7;
	SPI_Init(SPI2, &SPI_InitStruct);


	SPI_Cmd(SPI2, ENABLE);

все остальное — без изменений, поскольку хорошо абстрагировано от железа. Ну и понятно, что enc28j60 висит на SPI2, его reset заведен на GPIOA_Pin_7

UPD: подытожу результаты дискуссии на over 300 комментов:
  1. Так, как написано в топике, работать будет. Но...
  2. задача vTask_uIP никогда не передаст управление задачам с меньшим приоритетом, соответственно она должна крутиться на самом низком приоритете (при такой архитектуре опроса сетевого интерфейса)
  3. применение циклов ожидания флага (коими не брезгуют библиотеки и даже даташиты для демонстрации того или иного способа) в RTOS — моветон. Правильное решение — блокировать задачу (например, ожиданием семафора или другого события, накрайняк ставить vTaskDelay), в прерывании соответственно разблокировать — отдавать семафор.
  4. Система реального времени — это прежде всего система, которая дает гарантированное время реакции на требуемое событие. А что у нее внутри — не важно. Есть там вытеснение, приоритеты, треды или контексты — пофигу. Если гарантирует — значит реального времени.

Цель данной статьи — быстро запустить стек. Потому что я придерживаюсь такого правила: «сначала запусти, чтобы как-то работало, потом постепенно оптимизируй и настраивай». Иначе, если все изначально начать писать «правильно», то получится система с кучей неизвестных параметров, и отладить все скопом представляется невозможным. Например, не приходят прерывания от устройства при приеме пакета. Где ошибка? Неправильно проинициализировал трансивер? Неправильно соединил? Неправильно настроил контроллер прерываний? Оказалось ошибся в таймингах SPI (это другой трансивер был, есличо).

  • +5
  • 17 февраля 2012, 17:34
  • steel_ne
  • 1
Файлы в топике: uIP.zip

Комментарии (335)

RSS свернуть / развернуть
А я смотрю любовь к taskYIELD все осталась.
Как только доберешься до приоритетов и менеджеру питания, то любовь к taskYIELD сразу пропадет.
0
  • avatar
  • a9d
  • 17 февраля 2012, 20:47
Блин. Впечатление, что ты обладатель какого-то тайного сакрального знания про RTOS. Ну что изменится с введением приоритетов?
А менеджер питания чего и каким он боком к РТОС?
Ну не дай же погибнуть в неведении.

Хочешь, я даже отдельную тему открою, подискутируем?
0
О какой ты впечатлительный.
1) Приоритеты.
— используя taskYIELD ты заменяешь состояние idle на «потоптаться на месте». Т.е. усыпить микроконтроллер нельзя.
— используя taskYIELD время реакция процесса на событие значительно ухудшается. Зависимость линейная.
2) Приоритеты. Нахрена РТОС если не используются приоритеты? Кто кого должен вытеснять?
Если не использовать приоритеты, то время реакции на событие будет фактически не контролируемым и зависеть от кода. Т.е. программист помимо разработки еще должен парить мозг над расчетом времени реакции. И это притом, что он использует РТОС!

Почитай уже, что ли теорию по РТОС системам.
0
А и еще юзая taskYIELD и приоритеты, некоторые процессы никогда не получат управление.
0
Строго говоря, в системе с фиксированными приоритетами некоторые процессы могут не получить управление просто по определению.
0
Да. Так как процессы всегда готовы к выполнению. Единственный выход это менять динамически приоритет. Но это уже извращение.
Если приоритетов нет, то это уже будет обычная карусель. Это вообще ужас. Если у одного процесса время реакции 1сек, то и у всех время реакции 1сек. И при этом похер, что задачи клацаются за считанные микросекунды.
0
Прошу сюда
0
Сюда нельзя писать
0
Как я и подозревал. Недостаток теории и понимания принципов работы.

который выдает задаче строго отмеренный квант времени.
Квант в РТОС не строго определен. Прерывание, например от события, может его урезать чутли не до нуля.

И в том и в другом случае есть накладные расходы на переключение контекстов
В кооперативках контекст не переключается.

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

Это вообще не понял. Если контекст не полный, то это и не контекст вовсе. В прототредах это входные параметры.

Разница в подходе порождает некоторые проблемы. Например, в кооперативной (чисто кооперативной!) многозадачности могут быть проблемы с обработкой высокоприоритетных событий. Например — нажали кнопку (вообще, работа с пользователем чаще всего в приоритете). Когда это событие будет обработано и будет обработано ли вообще — в общем случае неизвестно.

Работа с пользователем всегда является низко приоритетной. Человек работает намного медленней чем ядро.

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

Нельзя. Время отклика будет два:
— минимальный. Сумма всех минимальных задержек, включая время выполнения кода задач и прерываний.
— максимальный. Сумма всех максимальных задержек, включая время выполнения кода задач и прерываний.

А теперь про вытесняйку — гарантирует ли она время реакции? Да, только в том случае, если длина тика будет на порядок меньше, чем требуемое время реакции. Почему? Да потому что задача выполняется весь тик, и не может быть прервана ничем (прерывания не в счет, они опять нам ломают всю абстракцию). А поскольку задач с одинаковым приоритетом может быть несколько, то до требуемой задачи очередь может дойти через несколько тиков после события.

Ошибочное утверждение.
Время реакции равно = решение шедуллера(зависит от приоритета задачи) + контекст + тик(тик может быть сокращен прерыванием).

Но это лирические отступления. Итак, глобальный вопрос — чем плохо в вытесняйке то, что задача раньше времени передаст управление диспетчеру?
Ничем. Для этого задача переводится в состояние Idle(в ртос). Но никак не в Ready.

Лишние затраты на переключение контекста? Так ведь они все равно произойдут в конце тика принудительно.
Нет. Это решает шедуллер а не прерывание таймера.

В кооперативке не происходит переключение контекста? Происходит и точно такое же как и в вытесняйке. Мутантов вроде прототредс не рассматриваем, рассматриваем нормальную кооперативку, как у freeRTOS.

Не происходит. Статические переменные это не контекст.
0
упс, что-то напутал с публикацией.

может мы как-то в разных плоскостях живем. Давай синхронизироваться.
freeRTOS, task — переключение контекста происходит всегда, если включено вытеснение или не включено в настройках. Я не прав?

Если задача переходит в режим Blocked, то она переходит и в кооперативке и в вытесняйке. В противном случае квант в конкретной freeRTOS не уменьшается. Правильно?

Перевести задачу в Blocked можно только ожиданием какого-либо события (семафор, очередь, просто задержка), правильно?

Какая кооперативная РТОС не переключает контекст? Еще раз — мутантов вроде прототредс и co-rutines не рассматриваем. Или это именно они?

какие rtos
0
может мы как-то в разных плоскостях живем. Давай синхронизироваться.
freeRTOS, task — переключение контекста происходит всегда, если включено вытеснение или не включено в настройках. Я не прав?
Если есть кого вытеснять и используется соответствующий шедуллер. Иначе это кооператив или гибрид.

Если задача переходит в режим Blocked, то она переходит и в кооперативке и в вытесняйке. В противном случае квант в конкретной freeRTOS не уменьшается. Правильно?


В кооперативке нет простоя. Задача завершается на определенное время. Квант всегда постоянен, но текущий можно отдать если не нужен.

Перевести задачу в Blocked можно только ожиданием какого-либо события (семафор, очередь, просто задержка), правильно?

Смотря как ждать. Если топтаться на месте, то квант не прервется.

Какая кооперативная РТОС не переключает контекст? Еще раз — мутантов вроде прототредс и co-rutines не рассматриваем. Или это именно они?

Все кооператиавки. К примеру OSA (кстати шикарная ОС).
Т.к. процесс завершается а не отдается управление.
0
В кооперативке нет простоя. Задача завершается на определенное время. Квант всегда постоянен, но текущий можно отдать если не нужен.
freeRTOS, в которой диспетчер не вызывается по времени, а только с использованием taskYIELD и все задачи имеют одинаковый приоритет — это кооперативка? Крутиться так будет, проверено.
0
Конечно будет. Задачи ж завершаются.
В OSA тоже есть слип. Но там это означает завершить на определенное время.
0
Что означает завершаются? Не завершаются. Задачи типа vTask_uIP в статье. Где-то в цикле вызывается taskYield.

и кооперативки тоже могут быть приоритетные
0
в прямом смысле. В кооперативках задачи и функции это одно и тоже. В них всегда есть return.
В RTOS return нет. Но в freeRTOS есть аналог, т.к. там задачи можно удалять.

и кооперативки тоже могут быть приоритетные

Приоритет на запуск а не на выполнение.
0
Ну категоричен ты до безобразия. «Все это бред, не говорят ни рыбы ни коты» (с).

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

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

И по поводу реакции на человека тоже слишком категоричен. Если для обработки человеческого действия требуется ресурсоемкая процедура, то можно просто не успеть и визуально все будет лагать. Классический пример — прорисовка скроллинга сенсорного экрана. Если поставить низкий приоритет, то плавности не добиться. Вон эппл вообще тормозит практически всю работу, пока пользователь держит палец на экране, т.е. приоритет функций обработки действий пользователя — наивысший.
0
Эх. Хотел написать длинный ответ. Но это уже лень с твоей стороны. Почитай документацию.
0
Работа с пользователем всегда является низко приоритетной. Человек работает намного медленней чем ядро
.

В эпл подумали иначе и за каких то несколько лет захавали львиную долю рынка смартфонов. Заставив всех высунув язык бежать следом.
0
Тут эпл не причем.
Человек задержку в отклике 50-100мс не заметит. Поэтому и приоритет этой задачи давать высокий не имеет смысла.
0
Когда много процессов, то эти 50мс превращаются в 500, а это уже тупняки. Если интерфейс это главнейшая функция аппарата (телефон, например) то приоритет его должен быть реально выше любой другой задачи. Ну кроме, может быть, совсем уж системных и низкоуровневых. Вроде рефреша оперативной памяти.
0
Нет. Всегда низко приоритетная.
Если улетит на 500 мс благодаря остальным задачам, то это кривые руки разработчика ПО или инженера выбравшего нетот мк.
0
А в чем кривость дать интерфейсу приоритет? Религия не позволяет?
0
Кривость в неправильном распределении процессорного времени.
У человека низкая реакция, поэтому у него всегда будет низкий приоритет.
0
Приоритет может быть высоким, а поллинг низким.
0
Зачем?? Зачем процессу с низкой скоростью реакции вытеснять допустим опрос датчиков или обновление картинки на экране??
Какой в этом сокральный смысл?
0
Может у процесса и низкая скорость (потому надо снизить поллинг), но если что то системное будет забивать реакцию на пользователя, то это будет заметно. А то получается, что пока у нас картинка обновляется мы не можем нажать отмену, например.
Опрос интерфейса должен быть редким (скажем не чаще 100 раз в секунду), но высокоприоритетным. Чтобы гарантированно пробиться через задачи и среагировать на пользователя.
0
Ну или вообще по прерыванию.

Тут есть прикол: можно на высоком приоритете дать понять пользователю, что на него реагируют, а вот остальной процесс можно делать неспешно, лишь бы без явно заметных пауз. Такая комбинация субъективно воспринимается как «мгновенно реагирующий» интерфейс, хотя реально он по скорости ничем не выделяется от ситуации, когда вся обработка идет на низком приоритете.
0
Гм. Еще одно не правельное толкование РТОС систем и ссистемы приоритетов.

Приоритет и процессорное время толком и не связанны. Главная задача приоритетов определить кто кого вытесняет. А не распределить процессорное время.

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

Все процессорное время распределяется между всеми задачами. И это делается не при помощи приоритетов! За распределение процессорного времени отвечает в первую очередь разработчик. А не шедуллер.

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

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

За распределением времени разработчик следит только вы кооперативке. Там именно что нужно максимально быстро отдавать управление шедуллеру, а он уже, на основании приоритетов, решит кому отдать следующему.

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

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


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

За распределением времени разработчик следит только вы кооперативке.
В РТОС тоже. Если не следит, то тогда кто следит? И как называется такой шедуллер который сам умеет предсказывать время нужно процессу?

Вот именно чтобы никакой процесс не мог перебить процесс опроса интерфейса и нужно, чтобы он шел с более высоким приоритетом. Пусть он не занимает много времени, но свое должен получить всегда и в срок.
А мьютексы и критические секции уже куда делись?
0
А мьютексы и критические секции уже куда делись?
Опрашивать интерфейс в критической секции? Зачем? Он должен получить свой десяток микросекунд раз в 10мс, но с гарантией. Тут как раз нужен приоритет, чтобы получил именно он, обработал кнопки и ушел в спячку на следущие 9990мкс.
0
Вот именно чтобы никакой процесс не мог перебить процесс опроса интерфейса и нужно, чтобы он шел с более высоким приоритетом. Пусть он не занимает много времени, но свое должен получить всегда и в срок.
0
Атомарность не напоминает?))
Приоритет такой гарантии не даст. Од даст гарантию на получение управление первым.
0
Гм, нет, не напоминает. Как атомарность может обеспечить гарантию того, что процесс опроса получит свое время сразу, как только истечет срок его спячки?
Хотя в зависимости от процесса — атомарность тоже может потребоваться, но дополнительно.
0
Такую гарантию дает шедуллер. А мьютексы, семафоры, крит. секции дают гарантию, что никто не прервет выполнение.
0
Такую гарантию дает шедуллер.
Ну да. Но для этого и требуется высокий приоритет, не? СОбсно, мы похоже просто по разному поняли «не прерывать». Ты — «не прерывать задачу обработки UI», я — «не прерывать (не нарушать) процесс обработки UI, т.е. периодичность вызова обрабатывающей его задачи».

А вообще в навороченных системах обработка пользователя обычно выполняется как прерывания — зарегистрировали действие юзера, показали ему, что прореагировали (активировали анимацию нажатия кнопки, например) и вышли. Дальше сама задача будет обрабатыватсья на низком приоритете. Если это конечно не кнопка «Авария, глуши все!».
0
За периодичность отвечает шудуллер.
Какую ты ему частоту указал такая и будет.
Если программист напортачит, то и будет тормозить все.
0
1. Квант и делается прерыванием. Т.е. по высокоприоритентнму прерыванию раз в некий тик вызывается шедулер который отбирает управление у текущей задачи и отдает другой. Сохранив контекст прерваной. Причем если в момент окончания кванта есть более высокоприоритетная задача, то управление отдадут ей. А если она не закочнила работу, то при следующем кванте отдадут ей же, т.к. остальные ниже по статусу.

2) Высокоприоритетные прерывания не просто получают управление первыми. Они могут прерывать более низкоприоритетные прерывания, отбирая у них управление и возвращая обратно.

В вытесняющей РТОС шедулер и следит. Он не знает сколько надо времени задаче. Он тупо отбирает управление (сохранив контекст) когда выделеный ей квант истек и отдает дальше. И так по кругу. Задача, конечно, может и раньше отдать, сама. По идее, в вытесняющей RTOS можно пистаь задачу так, словно она вообще одна тут и все время принадлежит ей. А там шедулер разберется.
0
По идее, в вытесняющей RTOS можно пистаь задачу так, словно она вообще одна тут и все время принадлежит ей. А там шедулер разберется.
Собственно, в вытесняющих ОС так и пишут как правило. По крайнйе мере, не-RT.
0
Собственно, в вытесняющих ОС так и пишут как правило. По крайнйе мере, не-RT.
Название такой РТОС?
0
Я не писал под RTOS, поэтому уточнил — «по крайней мере, не-RT». А вот на декстопных все так пишется, т.к. там структура самой ОС способствует тому, что задачи, не требующие себе все время, будут вызывать переводящие в поток режим ожидания функции (применительно к винде, например, это функции обработки цикла сообщений). Если же задаче нужно все время (например, архивирование) — то она в любом случае пишется с расчетом на захавывание максимума доступного времени.
0
RT — я такого сокращения еще не видел.
Там конечно будет работать. Там на это шудуллер рассчитан.
0
RT — Real-Time. Можно и догадаться, учитывая что RTOS — Real-Time OS.
0
1. Квант и делается прерыванием. Т.е. по высокоприоритентнму прерыванию раз в некий тик вызывается шедулер который отбирает управление у текущей задачи и отдает другой. Сохранив контекст прерваной. Причем если в момент окончания кванта есть более высокоприоритетная задача, то управление отдадут ей. А если она не закочнила работу, то при следующем кванте отдадут ей же, т.к. остальные ниже по статусу.

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

2) Высокоприоритетные прерывания не просто получают управление первыми. Они могут прерывать более низкоприоритетные прерывания, отбирая у них управление и возвращая обратно.

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

В вытесняющей РТОС шедулер и следит. Он не знает сколько надо времени задаче.
Не зачем он не следит. Шедуллер только организует работу.

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

Понятно, что работая в RTOS нельзя мешать работе диспетчера, т.е. запрещать прерывания или еще как-либо блокировать возможность вытеснения. Другое дело, что далеко не везде есть механизмы защиты от такого. В том же х86 в защищенном режиме попробуй запретить прерывания в ring3 — хрен у тебя что будет работать. Да и там другие механизмы общения.

А вот всякие вечные циклы и прочий быдлокод — да сколько угодно.
0
Он работает только по тому, что Windows, Linux и MacOS это не РТОС системы.
0
RTLinux — вполне себе hard RT.
0
Там быдло код работать не будет. Будет глючить страшно.
В старом виндовсе шедуллер был максимально приближен к РТОС. И зависание дисковода вызывало зависание всей системы.
0
Та бага не имеет отношения к RT.

P.S. в RT вполне себе будет работать быдлокод, покрутят приоритеты или еще какой костылик поставят и будет, никуда не денется.
0
Совсем старый виндовс — кооперативка.
Менее старый (9х) — полноценная вытесняющая система, но… Из-за обилия критичных атомарных ресурсов заклинивание любой задачи при доступе к ним приводило к мертвому зависанию. И это не есть поведение, соответствующее РТОС — в ней напротив, такая ситуация не привела бы к замораживанию всей системы.
В NT вопрос с этими ресурсами разрулили и система стала резко стабильней, причем не за счет модификации планировщика.
0
«Вытеснение» в смысле переключения задач? Да, может, если в результате какого-то события высокоприоритетный процесс перешел в состояние готовности.

На практике в «больших» ОС наивысший приоритет имеют жизненно важные системные задачи, затем идет интерфейс и только потом все остальное. Правда, в большинстве случаев, благодаря динамическим приоритетам, никаких дополнительных телодвижений для интерфейса не требуется, задача которая ожидает действия пользователя большую часть времени ждет событий от пользователя и ее динамический приоритет вырастает до небес, так что когда происходит событые, этот процесс получает управление максимально быстро.
0
Переключение текущей работающей задачи на более приоритетную.

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

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

P.S. стараюсь не пользоваться словом «шедулер». если пользоваться калькой с английского, то правильнее писать/говорить «скедьюлер». и в русском языке есть вполне адекватный общепринятый термин «планировщик». любой из этих двух, как по мне, годится лучше, чем загадочный «шедулер» :)
0
Прикол в том, что переключение текущей работающей на более приоритетную может произойти только по событию, иначе некому делать переключение контекстов.
Это и так понятно.

В виндовсе не РТОС планировщик. Уже очень давно.
Дай одной из задач высокий приоритет. И что тогда произойдет? Система не зависнет а будет дальше работать.

В линуксе РТОС толком никогда и небыло.
0
Это и так понятно.
Вот не люблю я формулировок типа «это и так понятно» и «это очевидно» в дискуссиях. Это весьма эффективный способ положить на узкой тропинке в лесу грабли и присыпать их листьями, а затем дружно на них наступить.

В виндовсе не РТОС планировщик. Уже очень давно.
Дай одной из задач высокий приоритет. И что тогда произойдет? Система не зависнет а будет дальше работать.
Что там в винде нагородили в свежих версиях не скажу, не в курсе. В полуоси, откуда система приоритетов была передрана в винде чуть менее чем полностью (без новых багов не обошлось), все было именно так — ставишь потоку RT+31 и все становится колом, дальше только ресет.
В линуксе РТОС толком никогда и небыло.
Не только была, но и есть. Об RTLinux я уже упоминал.
0
Не только была, но и есть. Об RTLinux я уже упоминал.
И там же сказано что это не линукс))

Что там в винде нагородили в свежих версиях не скажу, не в курсе. В полуоси, откуда система приоритетов была передрана в винде чуть менее чем полностью (без новых багов не обошлось), все было именно так — ставишь потоку RT+31 и все становится колом, дальше только ресет.

NT и CE это RTOS остальное уже нет. Для них слишком сложно писать ПО.
0
И там же сказано что это не линукс))
Ну для желающих есть rt-scheduler в ядре.
NT и CE это RTOS остальное уже нет. Для них слишком сложно писать ПО.
Откуда такая категоричность? «Неудобно» — возможно. Но не более того. И насчет «остального» это тоже явный перебор. Полуось с отключенным свопом имеет куда меньшее время реакции чем NT (в силу значительно более простых внутренностей).
0
Установи NT систему и оцени простоту разработки ПО.
Ошибка в программе может привести, в лучшем случае, к подвисанию. Разрабатывать ПО геморно. Приходится иногда сбрасывать систему.
0
Еще раз: в полуоси такая возможность была (завесить систему), что не делало разработку под нее сколько-нибудь сложнее, чем под NT.
0
Делало. В РТОС процессорное время конечно. Ты неможешь писать ПО от балды, нужно оценивать производительность а уже потом писать. Это намного сложней.
0
В любой системе процессорное время конечно. И писать от балды можно, другой вопрос, что переписывать потом придется с большой вероятностью переписывать.
0
Нельзя. Написанное от балды ПО в ртос, приведет к загрузки процессора. Это приведет к сбою.
0
Дай одной из задач высокий приоритет. И что тогда произойдет? Система не зависнет а будет дальше работать.
Практически зависнет. Разумеется, приоритет нужно давать не блокноту — он 99% времени проводит в GetMessage (т.е. ожидание события).
А вот обычный while true do при приоритете Real-Time вешает практически намертво (точнее, нужно столько тупящих в цикле потоков, сколько у системы аппаратных потоков исполнения). Другие процессы получают только по 1 таймслоту (до 130мс, если процесс не отдаст слот раньше) раз в 5 секунд (это фишка под названием CPU Starvation Detection, специально чтобы низкоприоритетные процессы не замораживались насовсем). Цифры приведены для WinXP.
Не помню только, удалось ли мне эксперимент такого типа грохнуть диспетчером задач (но на это уходит 5-10 минут), то ли пришлось давить ресет.
0
Вообще-то DI и говорит именно про быстрый отклик процесса, обрабатывающего ввод.
Кстати, у меня в контроллере УЗ-ванны кнопки опрашиваются с периодом 100мс. И это довольно заметно, даже при том, что там всего интерфейса — 2 кнопки и 2 разряда семисегментника.
0
Давай определимся с понятием «вытесняет».

P.S. приоритет и процессорное время связаны самым непосредственным образом, поскольку планировщик стремится отдать очередной квант процессу с наивысшим приоритетом. И только от процесса зависит, потребит ли он весь квант до конца или нет.
0
А какое еще альтернативное может быть понятие у вытеснения?
0
Все-таки, хотелось бы знать, что ты имеешь в виду под этим понятием. Поскольку в рамках моего понимания следующая фраза:
Приоритет и процессорное время толком и не связанны. Главная задача приоритетов определить кто кого вытесняет.

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

Каждая задача в конце концов отработает свое время.
0
Извини, но у тебя формулировка получилась в стиле «масло масляное». Давай без слова «вытеснена» (и производных) попробуем, ОК? Я перепишу, а ты поправишь, если я тебя не правильно понял:
«Текущая работающая задача может быть прервана и управление передано более приоритетной».

Только тут явно не хватает уточнения в результате чего это может произойти, а эта часть меня больше интересует.
0
Давай определимся с понятием «вытесняет».

Это ключевое понятие РТОС. Не нужно его путать с планировщиком.
Задача забирает управление у задачи. Это не передача управление планировщика от одной задачи другой.

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

??????? Это всегда происходит по событию. Какоето еще может быть уточнение?
0
Это ключевое понятие РТОС. Не нужно его путать с планировщиком.
Задача забирает управление у задачи. Это не передача управление планировщика от одной задачи другой.
Ага, похоже вот тут собака порылась (см. ниже)

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

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

Буду признателен, если ты укажешь мне на ошибки в этом описании последовательности действий.
0
вернет управление в ту же задачу, которая выполнялась до начала обработки прерывания.
В ртос системе после события управление получит приоритетная задача которая готова.

После срабатывания прерывания, текущая задача переводится в состояние «готова». А дальше уже может произойти вытеснение.

Системный таймер это тоже прерывание и оно тоже может привести к вытеснению.

Если планировщик распределяет время между всеми задачи поровну на основе приоритетов, то это никакое не вытеснение.
0
В ртос системе после события управление получит приоритетная задача которая готова.
Чудесно. Кто решает, какая из задач наиболее приориетная и какой надо отдать управление?
Если планировщик распределяет время между всеми задачи поровну на основе приоритетов, то это никакое не вытеснение.
Если на основе приоритетов, то это не поровну, а именно на основе приоритетов. В пределах приоритета — поровну.

Вытеснение это принудительное переключение на другую задачу. Именно этим отличается преемптивная или вытесняющая многозадачность от кооперативной. Не задача решает когда отдать управление, а некто внешний принимает это решение. Заметь, ни слова от РТ, и RT и не RT системы являются вытесняющими, то есть в них происходит вытеснение задач.
0
Чудесно. Кто решает, какая из задач наиболее приориетная и какой надо отдать управление?
Конечноже планировщик.

Если на основе приоритетов, то это не поровну, а именно на основе приоритетов. В пределах приоритета — поровну.
Это не вытеснение. Это распределение.

Как без вытеснения обеспечить реалтайм? Это невозможно!
0
Конечноже планировщик.
Замечательно. С планировшика начали им же и закончили. Иначе говоря, кто кого куда и когда вытеснит решает именно планировщик, который вызывается либо по внешним событиям, либо руками через yield().

Это не вытеснение. Это распределение.
Ты собираешься предложить другой вариант поведения в случае наличия задач с одинаковым приоритетом?

Как без вытеснения обеспечить реалтайм? Это невозможно!
Возможно, другой вопрос, что это может оказаться не очень удобно.
0
Ты собираешься предложить другой вариант поведения в случае наличия задач с одинаковым приоритетом?
Приоритет не отвечает за распределение проц. времени в РТОС системе.

Возможно, другой вопрос, что это может оказаться не очень удобно.
Невозможно. Запущенная задача не в РТОС системе изменит скорость реакции для всех процессов. Это уже нарушение реалтайма.
0
Думаю, ты плохо думаешь о человеке. Длительность моргания как раз близка к этой величине (~100ms) и субъективно это заметный интервал времени, хотя и короткий. Программа, которая на все действия будет реагировать с такой задержкой субъективно тоже будет казаться неторопливой, хотя разница в скорости мизерная. Ну и на практике общение с пользователем делается с высоким приоритетом, именно для того, что бы улучшить субъективно воспринимаемое время реакции.
0
А причем здесь моргание?? Это ему клавиатура или кнопка должна подмигивать.

Человек при нажатии на кнопку, либо вводе текста никак не замечает задержку в 50-100мс. А вот если на экране не достаточно быстро обновляется картинка, то тут уже заметит. Но за обновление экрана отвечает другая задача.
0
А если он кратко нажал кнопку, а кнопка не нажалась, т.к. интерфейс в ЭТОТ момент не опрашивался, т.к. картинка картинка обновлялась?
0
А какого хрена процессор всегда мониторит состояние кнопки?
А прерывания для кого? А если их нет то почему триггер не был поставлен?
0
Что значит всегда? Раз 50 в секунду, но ГАРАНТИРОВАННО!

А поставь мне прерывание на нарисованную кнопку на дисплее.
0
Если определенно, что процесс будет вызываться 50раз в секунду, то он и будет так вызываться. В чем проблема?

А поставь мне прерывание на нарисованную кнопку на дисплее.
Это что означает?

Есть платные версии FreeRTOS. В них время реакции гарантированно.
Как они могут давать такую гарантию если ничего не знают о проекте?
0
В том, что если у процесса низкий приоритет, то он не сможет вызываться раз в 50мс, т.к. другой высокоприоритетный запрос его перебьет и займет его время. Он будет выполнен, но после, а время то уже прошло!

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

Легко — отбирая силой управление. Т.е. если у тебя вытесняйка полноценная, то все задачи работают квантами. Диспетчер раз в 10мс, например, силой передает управление другой задаче. И ты точно знаешь, что если у тебя 10 задач (при равном приоритете), то раз в 100мс каждая задача ГАРАНТИРОВАННО получит свою порцию внимания. Как бы чрезжопно эти задачи небыли написаны. Исходя из этого ты можешь строить свои системы, зная, что реакция твоей системы 100мс, что бы там ни случилось. Это и есть суть реалтайма.
0
В том, что если у процесса низкий приоритет, то он не сможет вызываться раз в 50мс, т.к. другой высокоприоритетный запрос его перебьет и займет его время. Он будет выполнен, но после, а время то уже прошло!

Это еще почему??? Это что такая за система при разработке которой не учли время для низкоприоритетных процессов?

То, что далеко не везде можно повесить на аппаратное прерывание.
Ставь триггер. Программируемую логику. Увеличивай частоту опроса. Но приоритет тут никаким боком не поможет.

Легко — отбирая силой управление. Т.е. если у тебя вытесняйка полноценная, то все задачи работают квантами. Диспетчер раз в 10мс, например, силой передает управление другой задаче.
Ничего подобного. Шедуллер у приоритетной задачи не заберет управление никогда и не отдаст его другой.

И ты точно знаешь, что если у тебя 10 задач (при равном приоритете), то раз в 100мс каждая задача ГАРАНТИРОВАННО получит свою порцию внимания.
Это не РТОС система. Это ОС с карусельным шедуллером.
Даже в FreeRTOS карусели как таковой нет, там под эти понимается совсем другое.
Не путайте понятия.

Исходя из этого ты можешь строить свои системы, зная, что реакция твоей системы 100мс, что бы там ни случилось. Это и есть суть реалтайма.
Нет. Время реакции не 100мс. В каруселе это 1секунда.
0
Это еще почему??? Это что такая за система при разработке которой не учли время для низкоприоритетных процессов?
Вот только им оно выдается по принципу «когда есть», а здесь надо «немного, но вовремя». Поэтому в высокоприоритетных задачах приходится задумыватсья о времени, а всякие долгие некритичные процессы уносить на низкий приоритет и там быдлокодить как угодно.
Это не РТОС система. Это ОС с карусельным шедуллером.
Там же уточнение — при равном приоритете. Если у тебя на максимальном приоритете висит пара задач — ты можешь буть уверен, что более 1 кванта такой задаче не придется ждать, когда придет ее время. Про остальные задачи, как бы они ни были написаны — можно не вспоминать.
0
Вот только им оно выдается по принципу «когда есть», а здесь надо «немного, но вовремя». Поэтому в высокоприоритетных задачах приходится задумыватсья о времени, а всякие долгие некритичные процессы уносить на низкий приоритет и там быдлокодить как угодно.
Всегда нужно задумываться о времени выполнения во всех задачах.

Там же уточнение — при равном приоритете. Если у тебя на максимальном приоритете висит пара задач — ты можешь буть уверен, что более 1 кванта такой задаче не придется ждать, когда придет ее время. Про остальные задачи, как бы они ни были написаны — можно не вспоминать.
Перепутаны понятия частоты вызова и распределения времени.
При равном приоритете никто никого вытеснить не может. И соответсвтено будет низкая реакция.
0
Всегда нужно задумываться о времени выполнения во всех задачах.
Да? Даже если одна задача — каждые 10мс проверять перегрев ядерного реактора, а вторая — непрерывно обсчитывать в цикле здоровенный (но некритичный ко времени) массив данных?
РТОС позволяет гарантировать, что первая задача получит свое время и вторая не будет ей в этом мешать, но зато получит все свободное от первой задачи (while(1) if(T>200) shutdownReactor() else sleep(10);) время (т.е. 99%).
0
0
Не вижу противоречия.
0
Если высокоприоритетные прут толпой, то низкий вообще может затеряться. Это везде так.

Как это не отберет? А если их две с равным приоритетом? Приоритет шедулера вообще абсолютный.

Какая нахрен карусель? Карусель предусматривает последовательное выполнение задачи за задачей. Если тут задачи одноприоритетные, то они обрабатываются одновременно (квантами) по очереди пока есть. Отработались — лежат в спячке. Если разный приоритет, то на квантах их начинает тасовать, пока задачи высокоприоритетные не перещелкает, потом остальные.

Откуда 1 секунда? 10 задач, каждая максимум занимает времени 10мс, после чего ее принудительно переключают. Даже если все задачи будут активные, то каждая получит свое управление раз в 10*10мс = 100мс. Если нет, то меньше. Откуда секунда то?
0
Замечу, что 10мс это довольно большой квант, даже для ОС общего назначения, не говоря уже об РТ.
0
Как это не отберет? А если их две с равным приоритетом? Приоритет шедулера вообще абсолютный.
Не отберет. На основании какого правила это должно произойти???
у высокоприоритетной задачи никто не может забрать управление пока она сама не отдаст, либо ее вытеснят.

Какая нахрен карусель? Карусель предусматривает последовательное выполнение задачи за задачей. Если тут задачи одноприоритетные, то они обрабатываются одновременно (квантами) по очереди пока есть.

Это не РТОС. Что угодно но не РТОС.
В РТОС системе приоритетная задача не может быть вытеснена. Во FreeRTOS если приоритеты равные, то у работающей задачи он будет понижет. В тоже время можно выбрать кооперативный режим, в нем задача должна отдавать управление, чтоб выполнелась задача с такимже приоритетом.
Но это уже гибриды.

Откуда 1 секунда? 10 задач, каждая максимум занимает времени 10мс, после чего ее принудительно переключают. Даже если все задачи будут активные, то каждая получит свое управление раз в 10*10мс = 100мс. Если нет, то меньше. Откуда секунда то?
Ага. Если 10 раз в секунду все задачи, то 1000/10 * (10-1) = 900мс.
0
А кто ему помешает если так задумано? Если правило: Каждой задаче, при наличии равной по приоритету — не более кванта за раз. И все. Будут две равных — будут дрыгаться шажками по кванту. Будет одна старше другой — старшая пройдет первой. Захавав все кванты подряд, пока не кончится. Да, речь не о FreeRTOS, а в принципе.

Что же это как не РТОС? В РТОС подразумевается только одно — детерминированность времени отклика на нужные события. Этого можно добиться только принудительно отбирая управления у кого угодно и отдавая более приоритетной задаче. Событие от которой должно быть обработано на 100% в заднаное время.

О_О какие 10 раз в секунду? Откуда там 900мс? Даже если они подряд друг за дружкой идут, то каждая получает внимание раз в 100мс. При условии, конечно, что сама задача выполняется за квант и ей просто нужно внимание.
0
А кто ему помешает если так задумано? Если правило: Каждой задаче, при наличии равной по приоритету — не более кванта за раз. И все. Будут две равных — будут дрыгаться шажками по кванту. Будет одна старше другой — старшая пройдет первой. Захавав все кванты подряд, пока не кончится. Да, речь не о FreeRTOS, а в принципе.
Во FreeRTOS подобного добились за счет смены приоритетов. Но это нужно использовать весьма осторожно. В таком случае, сложно прогнозировать как долго будет выполняться процесс и накладные расходы на переключения контекстов максимальны.
Всегда рекомендуется использовать разные приоритеты. Только в этом случае можно делать прогнозы.

Что же это как не РТОС? В РТОС подразумевается только одно — детерминированность времени отклика на нужные события. Этого можно добиться только принудительно отбирая управления у кого угодно и отдавая более приоритетной задаче. Событие от которой должно быть обработано на 100% в заднаное время.

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

О_О какие 10 раз в секунду? Откуда там 900мс? Даже если они подряд друг за дружкой идут, то каждая получает внимание раз в 100мс. При условии, конечно, что сама задача выполняется за квант и ей просто нужно внимание.


Откуда 1 секунда? 10 задач, каждая максимум занимает времени 10мс, после чего ее принудительно переключают. Даже если все задачи будут активные, то каждая получит свое управление раз в 10*10мс = 100мс. Если нет, то меньше. Откуда секунда то?

Ну хорошо. Сделаем еще большее уточнение.
Задачи идут по очереди. Каждая выполняется 10мс. То это карусель с периодом 100мс + переключение контекста*10+ сохранение контекста*10
Задачи идут не по очереди. То это снова карусель с периодом 100мс + переключение контекста*10+ сохранение контекста*10.

Добавляем всего одну задачу и все время реакции летит к черту.
Добавляем одно прерывание и все время реакции летит к черту.
Добавляет атомарный доступ к ресурсу и все время реакции летит к черту.

Где здесь должна находиться гарантия??
0
Тогда можно взять мощный процессор и карусель тоже станет РТОС.

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

Нет никакого сакрального чуда в RT и для разных задач разные системы будут или не будут считаться RT, именно для этого считают время реакции. Винда вполне себе может быть RT для неспешных задач типа «раз в сутки полить цветочки».
0
mka.ru/?p=41001&PHPSESSID=9dc7829d329421333db9b296381c58d9

Карусель не станет РТОС. И в них есть чудо.
0
Те «чудеса» есть и в обычных ОС. И карусель вполне себе может быть RTOS если она успевает отреагировать на события в допустимый для данного приложения интервал времени.
0
Не будет. Даже если упеет.
Нарушен главный принцип вытеснения.
0
Можно подробнее о главном принципе вытеснения и каким образом он связан с RTOS? Напомню, что «так принято/удобнее» вовсе не значит «иначе сделать принципиально невозможно».
0
Там нет ни слова о главном принципе вытеснения. К тому же, с чего ты взял, что «требования», которые перечислил автор статьи действительно являются таковыми?
0
Есть.

Требование 1: ОСРВ должна быть многонитиевой или многозадачной и поддерживать диспетчеризацию с вытеснением
Поведение ОСРВ должно быть предсказуемым. Это не означает, что ОСРВ должна быть быстрой, но означает, что максимальный промежуток времени для выполнения любой операции должен быть известен заранее и должен быть согласован с требованиями приложения. Например, Windows 3.11 — даже на процессоре Pentium Pro с тактовой частотой 200 МГц — неприменима для построения систем реального времени, поскольку одно приложение может навсегда захватить управление и заблокировать все остальные (Windows 3.11- кооперативная система).

Без вытеснения невозможно обеспечить требуемую скорость реакции. Сам подумай как это возможно ??
Если текущая задача выполняется и произошло событие. То как передать управление?? Ведь приоритеты отвечают только за распределение.

В РТОС произойдет передача. Не в РТОС этого не будет.
0
Дело не в мощном процессоре, а в том, что мы можем вычислить гарантированное время реакции. Если тупая карусель на мощном проце при наихудшем случае обеспечивает нам минимальное выполнение времени, то это полноценная RT система. Проблема в том, что вычислить это сложно. Тогда как RTOS может дать такую гарантию исходя из архитектуры самой OS.

А с какого хера внезапно у нас добавляется еще одна задача? Еще одна задача = совсем другая система. Другое время. Значит надо думать иначе, раскидывать их на разные приоритеты. Оставлять запас. Суть не в том, чтобы уложиться в 100мс, а в том, чтобы ТОЧНО знать во сколько мы уложимся. И от этого уже и плясать.
0
Не станет. В карусели нет приоритетов, вытеснения.

А с какого хера внезапно у нас добавляется еще одна задача? Еще одна задача = совсем другая система. Другое время. Значит надо думать иначе, раскидывать их на разные приоритеты. Оставлять запас. Суть не в том, чтобы уложиться в 100мс, а в том, чтобы ТОЧНО знать во сколько мы уложимся. И от этого уже и плясать.

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

Также мы не будет знать точно время в которое укладываемся. Т.к. задачи влияют друг на друга. Мы добавили одну задачу и пришлось переделать все.
В одной задаче добавился код и все полетело.

Зато есть один плюс. Есть гарантия что все задачи получат управление. Но нет гарантии времени выполнения.
0
RT это не наличие приоритетов и вытеснения, а гарантированное время выполнения реакции на событие — реальное время. ВСЕ. А Как это реализовано — совершенно не имеет значения. Хоть на конечных автоматах, с просчетами по тактам для наихудшего случая.

Добавление задачи идет на этапе создания системы, они не добавляются сами из ниоткуда в процессе эксплуатации. Так? Тогда все гарантировано. Мы точно знаем сколько у нас и когда. Не вписывается? Тогда думаем как вписаться. Но в итоге мы все равно будем знать кто, сколько и когда.

Всегда придется просчитывать время реалтайма, т.к. время у нас одно и на всех может не хватить, как ни крути. Это естественно.
+1
Без приоритетов как это гарантировать?? Без вытеснения зачем приоритеты??

В ртос системах распределяют процессорное время.
В не РТОС задумываются над соседними процессами.

Запусти в Windows 7 много задач и система начнет тормозить. Т.к. это не РТОС система!
В РТОС системе, если приоритеты расставлены правильно и распределено время верно, тормозить ничего не будет с увеличением числа процессов.

Добавление задачи идет на этапе создания системы, они не добавляются сами из ниоткуда в процессе эксплуатации. Так? Тогда все гарантировано. Мы точно знаем сколько у нас и когда. Не вписывается? Тогда думаем как вписаться. Но в итоге мы все равно будем знать кто, сколько и когда.
Нет. Во FreeRTOS они могут появляться динамически. И там будет все гарантированно.
0
Нет. Во FreeRTOS они могут появляться динамически. И там будет все гарантированно.
А ресурсы она из пальца высосет? Чудес не бывает, RTOS создает необходимоые условия для реализации систем, но не более того, именно разработчик системы должен обеспечить необходимое время реакции всей системы (я имею в виду не только OS).
0
Какие еще ресурсу???
За счет вытеснения и получается необходимое время реакции. Соседние процессы не повлияют друг на друга.
Влияние появится если система будет загружена. А это уже сбой.
0
отвечу в корне, а то тут реально неудобно стало писать.
0
Ну так те которых вытеснит в результате фейлят свой реалтайм. Появляются тупняки.
0
А что даст нам правильное распределение приоритетов? Только то, что более приоритетные задачаи отработают вовремя, а менее приоритетные выпадут из реалтайма. Время не резиновое, больше чем оно есть ты его нигде не нароешь. Как ни крути, а обеспечение 100% реалтайма по всем задачам однозначно означает только то, что каждому из них будет гарантировано дано управление в заданном временном окне. Только так, иного не дано. Так откуда оно будет если задач больше чем времени? Придется чем то жертвовать.
0
Правильное распределение даст правильную и прогнозируемую скорость реакции. Тогда можно будет смело говорить у какого процесса какая скорость реакции.
— у приоритета 1 — это скорость переключения контекста
— у приоритета 2 — это скорость переключения контекста, или время завершение приоритета 1.
— у приоритета 3 — это скорость переключения контекста, или время завершения процесса два либо один, или завершение процесса 1 + 2.

Можно дать четкий прогноз по каждой задаче. У каждой задачи всегда гарантированная скорость рекциии. Можно добавить еще один процесс и он никак не повлияет на предыдущих три.
0
Поэтому на платную FreeRTOS дают гарантированное время срабатывание. Он всегда будет одинаков. Вне зависимости от количества процессов.
0
1 — базара нет
2 — уже почти неподсчитываемо. Какая именна 1 задача будет? Сколько процессов 1 типа перед 2 будет?
3 — полный пиздец. Ни о каком пргнозируемом времени речи не идет. Разве что брать по худшему сценарию. Опять же никто не гарантирует, что не возникнет блока, когда 1 и 2 дружно лезут толпой и наглухо отсекают 3.
0
По такому принципу какбы работают все РТОС системы и там все считается элементарно. Время отклика всегда будет одинаковым.
Если это не так, то это уже сбой в работе.

Приоритет это не время работы! Он не имеет отношения к времени работы. Он и не должен на него влиять. Он дает гарантию на время реакции.
0
А как он может давать гарантию на время реакции, если более приоритетные задачи работают долго? Или это уже считается сбоем в работе в результате неправильного планирования? Ну так по такому же принципу можно что угодно рассчитать, хоть автомат, хоть кооперативку, хоть карусель.
0
Потому что, приоритетные задачи производят вытеснения. За счет этого время реакции постоянное.

Да и почему приоритетные процессы постоянно весят в памяти??? Это что за планирование такое??
0
Для приоритетных да — на том и основано. Для низкоприоритетных — нет. Там надо считать наслоения верхних уровней.

Почему постоянно? Но кто мешает случиться моменту когда они встретятся в одно время?
0
Ничего там толком считать не нужно. Это легко определяется в процессе разработки.
Когда завершена разработка процесса, производится замер времени работы и все. Это сделать элементарно. На основе него можно сделать прогноз на отклик для следующего менее приоритетного процесса.
0
В отличии от кооперативок это время будет постоянным. В кооперативках будет зависимость от других процессов.
0
Как раз-таки в твоем примере это время не будет постоянным. Изменили задачу на приоритете 1 — время отклика всех остальных приоритетов поехало.
А если на приоритет 1 еще задач добавить, то и того веселее станет.
0
Оно поедет на прогнозируемую величину. И будет постоянным. Разработчик это должен учитывать всегда.
0
Если в РТОС системе два процесса. У удного приоритет 1 у второго 2.
То это не означает, то процесс с приоритетом 1 будет получать 66% проц. времени, а второй 33%.

Это только приоритеты. Второй процесс может занимать 99% а первый процес с приоритетом 1 может запросто занимать 1% времени. Но у него скорость реакции будет выше чем у процесса 2.

В реальности же каждый процесс лишь занимает считанные проценты от общего процессорного времени. Если процессор загрузить на 100%, то вероятность сбоя резко возрастает.
0
А я где то это утверждал? О том и речь, что вытесняющие перебивают нижние уровни, но именно это не дает нижним работать на гарантированном отклике, т.к. неизвестно сколько потребуется ему времени для получения управления. Возвращаясь к интерфейсам ( ;))) ) Опрос клавиатуры может занимать 1%, но работать должен на высшем приоритете :) Чтобы не тупить. Как то так.
0
Время отклика у все процессов в РТОС системе всегда одинокого и прогнозируемое иначе это не РТОС.
Отклик у всех гарантирован.
Отклик для процесса с приоритетом 2 не может быть, по определению, больше чем время выполнения процесса с приоритетом 1+переключение контекста.
Он всегда будет прогнозируемым. Ничего не потеряется.
0
Время отклика у все процессов в РТОС системе всегда одинокого и прогнозируемое иначе это не РТОС.
Нет. Не нужно это, да и врядли возможно (если, конечно, не выделять каждому процессу свой аппаратный поток исполнения). От системы (не RTOS причем, а от построенной на ней системы) требуется гарантированное время отклика на те воздействия, которые этого требуют. А RTOS — это ОС, предоставляющая необходимые для этого средства.
0
Хммм. Я сейчас доделываю проект. И у меня почему-то время отклика постоянное и не поменялось. У LUFA как было 20мс, так и 20мс и осталось. Это без всякой пляски с бубном.

У меня четыре процесса. И у всех отклик постоянный. Это делается очень легко.
0
Да, это делается легко если ресурсов с избытком.
0
Я знаю. А тогда зачем выбирать микроконтроллер который не справится с задачей?))
0
А зачем выбирать контроллер, который с задачей справляется с диким оверкиллом?
У меня вон в УЗ-ванне задача такая, что даже кооперативный планировщик на AT89C2051 с большим запасом укладывается в требования по времени отклика.
С РТОС же можно прогнозировать время обработки требуемых воздействий (но не всех задач!) при куда меньшем запасе ресурсов.
0
С РТОС же можно прогнозировать время обработки требуемых воздействий (но не всех задач!) при куда меньшем запасе ресурсов.
Гм. Наоборот. Ресурсов будет тратится больше. И у всех задач будет прогнозируемое время.
0
Ты не понял. RTOS позволяет за счет приоритетного распределения ресурсов обеспечить время реакции для требуемых задач даже при близкому к 100% потреблению процессорного времени.
Кооперативка же хоть что-то может гарантировать только при большом запасе производительности.
Поэтому пусть даже вариант на кооперативке будет выполнять 10МИПС полезных операций, а на вытесняющей — 12МИПС, но для первого потребуется проц на 100МИПС, а для второго — на 15. Это и есть запас ресурсов.
Но разумеется, этот выигрыш будет получен за счет низкоприоритетных задач.
0
В условиях избытка ресурсов любая система будет вести себя если не в точности как RTOS, то очень близко к этому. Приколы начинаются при приближении к порогу доступных ресурсов и потребности в них. RTOS его не может перейти (да и не должна, не ее задача), качественные OS общего назначения, чаще всего, не только легко переходит этот порог, но и превышают его многократно, часто в десятки раз. У меня на тестовых серверах если LA < 30 я начинаю искать причину недогруза. LA, если ты не в курсе, это длина очереди готовых к исполнению задач. RTOS в таких условиях не то что ничего не гарантирует, а просто будет не в состоянии что-либо делать. Но, повторюсь, это и не ее задача.
0
Не посмотрев на проект, сложно об этом что-то сказать. А вариантов много, вплоть до того, что ты ошибаешься насчет постоянства отклика.
0
Если я ошибаюсь, то устройство не будет определяться компом. К тому-же юсб дает постоянное тактирование с частотой 1000Гц. Посчитать время отклика очень легко.
0
А если 1 больше одного? Тогда 1+1+переключение. А для третьего уровня? 1*n+2*n+суммарное переключение. А если 1+2 = 100% тогда третье идет нахер и теряется.
0
Тогда неправильно выбран процессор. Он не может обеспечить требуемый отклик.
0
То это не означает, то процесс с приоритетом 1 будет получать 66% проц. времени, а второй 33%.

А что, кто-то такое утверждал?

Это только приоритеты. Второй процесс может занимать 99% а первый процес с приоритетом 1 может запросто занимать 1% времени. Но у него скорость реакции будет выше чем у процесса 2.
Не знаю откуда у тебя появилась такая мысль, но приоритеты вовсе не задают пропорцию в которой делится время процессора. Причем это справедливо для любой ОС в которой есть приоритеты.
0
Перечитай ответы. Тут постоянно проводят взаимосвязь между приоритетами и процессорным временем.
0
Но такого, как написал ты, никто не писал. Ты же утверждаешь, что приоритеты вообще никак с процессорным временем не связаны, что тоже ну очень далеко от истины.
0
Хорошо. Напиши какая у них взаимосвязь??

Есть процесс, он забирает 10мс процессорного времени в секунду. Как повлияет приоритет на это время?
0
Дай ему приоритет ниже, чем у процесса while(1){}; и он не получит времени вообще.
Дай ему приоритет ниже, чем у нескольких процессов, кушающих 50-60% времени — он будет работать 10мс, но отнюдь не каждую секунду.
0
Дай ему приоритет ниже, чем у процесса while(1){}; и он не получит времени вообще.
Дай ему приоритет ниже, чем у нескольких процессов, кушающих 50-60% времени — он будет работать 10мс, но отнюдь не каждую секунду.
Это ты пошутил ??? Ты дал высокоприоритетной задаче все время. И причем здесь приоритет?

Он будет запускаться каждую секунду и работаь 10мс. Т.к. еще остается 40% свободного времени.
0
Это ты пошутил ??? Ты дал высокоприоритетной задаче все время. И причем здесь приоритет?
Нет. Я показал, как приоритет влияет на получаемое процессорное время. Что, ты скажешь что изменилось что-то кроме приоритета? Или что получаемое время не изменилось?
Он будет запускаться каждую секунду и работаь 10мс. Т.к. еще остается 40% свободного времени.
Не совсем. Запускаться он будет с отклонениями — скажем 1.5с паузы — 10мс работы — 0.5мс паузы — 10мс работы. В этом варианте среднее время работы не изменится, появится только джиттер времени получения управления. Но это если процесс запускается по внешнему источнику сигналов.
Если же задача вида «делять что-то 10мс и уснуть на 1с», то картина будет другая — 1.5с ожидания — 10мс работы — 1.05с ожидания — 10мс работы — 1.7с ожидания — 10мс работы. Среднее время уменьшается.
0
Нет. Я показал, как приоритет влияет на получаемое процессорное время. Что, ты скажешь что изменилось что-то кроме приоритета? Или что получаемое время не изменилось?
Это ты показал как высоко приоритетной задаче да 100% времени и ожидаешь получить еще. С такимже успехом можно изобретать вечный двигатель.

Запускаться он будет с отклонениями — скажем 1.5с паузы — 10мс работы — 0.5мс паузы — 10мс работы. В этом варианте среднее время работы не изменится, появится только джиттер времени получения управления. Но это если процесс запускается по внешнему источнику сигналов.

От куда это отклонение возьмется?? Ты же сказал, что все задачи беррут максимум 600мс. Еще ведь свободных остается 400мс! Ей что не хватит времени??
0
Это ты показал как высоко приоритетной задаче да 100% времени и ожидаешь получить еще. С такимже успехом можно изобретать вечный двигатель.
Ты тролль или идиот.
От куда это отклонение возьмется?? Ты же сказал, что все задачи беррут максимум 600мс. Еще ведь свободных остается 400мс! Ей что не хватит времени??
Окей. Временная диаграмма.
0.000-0.360: стартует задача 1, работает 360мс, уходит в спячку на 240мс
0.360-0.500: стартует задача 2, работает 140мс, уходит в ожидание события
0.500-0.510: стартует задача 3, работает 10мс, уходит в спячку на 990мс
0.600-0.960: проснулась задача 1. здесь и далее работает те же 360мс и уходит спать на те же 240мс
1.200-1.560: задача 1
1.560-1.570: задача 3 (время с предыдущего вызова — 1.06с). уснули на 990мс — следущий запуск запланирован на 2.560 (уже поехало...)
1.800-2.160: задача 1
2.390-2.400: по событию проснулась задача 2, ей надо 140мс
2.400-2.760: задача 1. задача 2 вытеснена.
2.760-2.890: задача 2.
2.890-2.900: задача 3. время с предыдущего вызова 1.33с. засыпает на 990мс, следущий вызов запланирован на 3.890.

Как видишь, каждый раз, когда задача 1 или 2 выполняются в то время, когда должна была запуститься задача 3 — ее запуск откладывается. Поскольку зацикливается она засыпанием на 990мс — этот сдвиг не компенсируется и нарастает во времени, в результате задача 3 получает вовсе не 1% времени, который она бы получила на максимальном приоритете, а меньше.
Чуть лучше будет, если задача 3 будет запускаться внешним таймером с периодичностью в 1с. Тогда она будет выполняться сразу, как только проц после срабатывания таймера освободится от задач 1 и 2, и хотя она не будет запускаться точно в N секунд 500мс от старта, но средний период будет равен секунде и она будет-таки получать 1% времени. Но момент получения не гарантирован, поэтому между двумя вызовами задачи 3 может пройти от 0 до 2с.
0
Это ты показал как высоко приоритетной задаче да 100% времени и ожидаешь получить еще. С такимже успехом можно изобретать вечный двигатель.
Ты тролль или идиот.
Ггг. Ты чи слепой? Бесконечный цикл забирает 100% времени. Возьми книгу по программированию и поинтересуйся сколько выполняется бесконечный цикл.

Окей. Временная диаграмма.
0.000-0.360: стартует задача 1, работает 360мс, уходит в спячку на 240мс
0.360-0.500: стартует задача 2, работает 140мс, уходит в ожидание события
0.500-0.510: стартует задача 3, работает 10мс, уходит в спячку на 990мс
0.600-0.960: проснулась задача 1. здесь и далее работает те же 360мс и уходит спать на те же 240мс
1.200-1.560: задача 1
1.560-1.570: задача 3 (время с предыдущего вызова — 1.06с). уснули на 990мс — следущий запуск запланирован на 2.560 (уже поехало...)
1.800-2.160: задача 1
2.390-2.400: по событию проснулась задача 2, ей надо 140мс
2.400-2.760: задача 1. задача 2 вытеснена.
2.760-2.890: задача 2.
2.890-2.900: задача 3. время с предыдущего вызова 1.33с. засыпает на 990мс, следущий вызов запланирован на 3.890.

Где нарушение реалтайма??
Задача с приоритетом 3 будет гарантированно получать доступ с временем реакции работа задачи1+ работа задачи 2 + контекст. Где произошло нарушение? Ты же сам это и доказал.
0
Ггг. Ты чи слепой? Бесконечный цикл забирает 100% времени. Возьми книгу по программированию и поинтересуйся сколько выполняется бесконечный цикл.
Нет, слепой ты. Напомню тебе твои же слова:
Есть процесс, он забирает 10мс процессорного времени в секунду. Как повлияет приоритет на это время?
На что ты получил ответ:
Дай ему приоритет ниже, чем у процесса while(1){}; и он не получит времени вообще.
Какие возражения? Ты хочешь сказать, что изменение приоритета не повлияло на получаемое этим процессом процессорное время? Будь добр, обоснуй мою ошибку требованиями задачи в цитате или уймись.

Где нарушение реалтайма??
Ты опять путаешь задачу. А она была:
Есть процесс, он забирает 10мс процессорного времени в секунду. Как повлияет приоритет на это время?
Задачи 1 и 2 сбивают время между вызовами задачи, она уже не вызывается раз в секунду, и в результате получает меньше процессорного времени. Повысь ей приоритет — и она будет получать больше процессорного времени.

Алсо.
Задача с приоритетом 3 будет гарантированно получать доступ с временем реакции работа задачи1+ работа задачи 2 + контекст.
И кому оно такое нужно? Кооперативка обеспечит в точности то же самое, только минус контекст — т.е. еще и лучший результат.
0
Ггг. Ты чи слепой? Бесконечный цикл забирает 100% времени. Возьми книгу по программированию и поинтересуйся сколько выполняется бесконечный цикл.
Нет, слепой ты. Напомню тебе твои же слова:
Есть процесс, он забирает 10мс процессорного времени в секунду. Как повлияет приоритет на это время?
На что ты получил ответ:
Дай ему приоритет ниже, чем у процесса while(1){}; и он не получит времени вообще.
Какие возражения? Ты хочешь сказать, что изменение приоритета не повлияло на получаемое этим процессом процессорное время? Будь добр, обоснуй мою ошибку требованиями задачи в цитате или уймись.

Это снова шутка? В РТОС системе выполняющаяся задача с высоким приоритетом не может быть вытеснена.
Ты уже отдал 100% процессорного времени.

Где нарушение реалтайма??
Ты опять путаешь задачу. А она была:
Есть процесс, он забирает 10мс процессорного времени в секунду. Как повлияет приоритет на это время?
Задачи 1 и 2 сбивают время между вызовами задачи, она уже не вызывается раз в секунду, и в результате получает меньше процессорного времени. Повысь ей приоритет — и она будет получать больше процессорного времени.

Речь идет об РТОС системе! И только об ней! Нарушения от смены приоритета нет. Время реакции осталось прогнозируемым! Если тебе нужно раз в секунду измени время реакции на соответствующую величину. Ее ты и рассчитал.
Что тут может быть непонятного ???

И кому оно такое нужно? Кооперативка обеспечит в точности то же самое, только минус контекст — т.е. еще и лучший результат.

Кооперативка не даст стабильного результата.
0
В РТОС системе выполняющаяся задача с высоким приоритетом не может быть вытеснена.
Ты уже отдал 100% процессорного времени.
Ага. Именно. Но ведь процессорное время, выделяемое процессу «10мс раз в секунду» изменилось, правда?
Речь идет об РТОС системе! И только об ней! Нарушения от смены приоритета нет. Время реакции осталось прогнозируемым! Если тебе нужно раз в секунду измени время реакции на соответствующую величину. Ее ты и рассчитал.
Что тут может быть непонятного ???
*facepalm.jpg*
0
Ага. Именно. Но ведь процессорное время, выделяемое процессу «10мс раз в секунду» изменилось, правда?
Не изменилось.

*facepalm.jpg*
Еще какой. Определение хотябы внимательно прочитай.
0
Не изменилось.
Что, он по прежнему выполняется раз в секунду по 10мс, несмотря на то, что более высокоприоритетный поток съедает 100%?
0
Если убрать системный сбой который ты вызвал, то да.
0
С такими «если» можно обосновать что процессорное время вообще ни от чего не зависит.
Меж тем, в данном примере:
1) Если поставить бесконечному циклу приоритет выше, чем периодической задаче — она не получает времени вообще
2) Если поставить периодической задаче приоритет выше, чем бесконечному циклу — она получает свое время
Вывод: От приоритета процессорное время зависит.

И я бы не стал называть это системным сбоем. Бесконечный цикл вполне может иметь смысл — например, там может считаться какая-то задача, требующая много времени, но не реалтаймовая. При низком приоритете он будет работать не мешая реалтаймовым задачам и не нарушая реалтаймовость системы.
0
С такими «если» можно обосновать что процессорное время вообще ни от чего не зависит.
Зависит от распределения программистом.

Ты на основе нерабочей системы пытаешься доказать, что приоритет влияет.
Берем рабочую программу и пытаемся запустить на компе разбитым молотком. Программа не работает. Вывод сам напрашивается.

Меж тем, в данном примере:
1) Если поставить бесконечному циклу приоритет выше, чем периодической задаче — она не получает времени вообще
2) Если поставить периодической задаче приоритет выше, чем бесконечному циклу — она получает свое время
Вывод: От приоритета процессорное время зависит.
Нет. Вывод ты подменил понятия и пытаешь делать выводы.

И я бы не стал называть это системным сбоем. Бесконечный цикл вполне может иметь смысл — например, там может считаться какая-то задача, требующая много времени, но не реалтаймовая
Только один и только один процесс в системе имеет бесконечный цикл. он называется Idle. Ты внес в систему Idle процесс.
Поздравляю с изобретением колеса.
0
Зависит от распределения программистом.
Вообще-то, RTOS (точнее, ее диспетчер) затем и нужна, чтобы программиста от этой задачи избавить.
Ты на основе нерабочей системы пытаешься доказать, что приоритет влияет.
Это самый простой пример системы с недостатком ресурсов. Если их в избытке — то процессорное время, выделенное задаче, вообще ни от чего не зависит — каждая задача получит его столько, сколько ей нужно. В таких условиях да — от приоритета оно не зависит. Как впрочем и от чего-либо еще.
0
Вообще-то, RTOS (точнее, ее диспетчер) затем и нужна, чтобы программиста от этой задачи избавить.

От лени от прочтения документации он никак не избавит.
Хотябы по пользуся одной из РТОС а после уже расскажи как там от это программист «избавляется». Хочешь добавить себе уверенности. Создай тему на электрониксе и расскажи о том как РТОС избавляет программиста. Тыж уверен в своих словах? Заодно и расскажешь разработчикам ртос систем как их системы работают. Ато бедные такого бреда в своей документации написали.

Это самый простой пример системы с недостатком ресурсов. Если их в избытке — то процессорное время, выделенное задаче, вообще ни от чего не зависит — каждая задача получит его столько, сколько ей нужно. В таких условиях да — от приоритета оно не зависит. Как впрочем и от чего-либо еще.

В системе с избытком ресурсов все лишнее остается в Idle процессе. Ничего не меняется.
-1
Речь лишь о том, что более приоритетное задание легко может захавать больше процессорного времени, если захочет. И все. Вот и вся зависимость.
0
Может. И это время всегда прогнозируемое.
0
Каким образом? Только разве что суммируешь все пересекающиеся задачи и посчитаешь по худшему сценарию.
0
время переключение+ время работы всех задач с приоритетом выше. Это и есть время реакции.
0
А кто сказал, что за это время задачи с приоритетом выше отработают только по разу? Пока обрабатывается одна задача, другая, уже обработанная может опять перейти в режим готовности.
0
А кто сказал, что эта величина не прогнозируется?
0
Твой расчет для кванта 100мс, а не 10мс.
0
Ага. Лишний нулик.
0
Зачем спорить с человеком, который изо всех сил не хочет понимать (изучать, принимать) о чем идет речь. Из всего прочитанного ранее вывод можно сделать однозначный… Дальше читать спор (ровно как его продолжать и участвовать в нем) не вижу смысла.
+1
FreeRTOS.org
Найди подтверждение своих слов.
google
Найди подтверждение своих слов в концепции РТОС )
electronix.ru/
Спроси у разработчиков значение слова «реал тайм»
0
Ну изредка (правда ближе к началу) в нем проскакивают интересные вещи.
0
Моргание это пример короткого интервала времени, который всем хорошо знаком. И поверь, я замечаю при вводе текста задержки, тем более 100мс. У меня автоповтор стоит 40символов (а это 25мс). И разницу в задержке перед автоповтором между 150-250-350мс я тоже хорошо замечаю.
0
Между временем нажатия и временем появления на экране???
В одной из последних серий разрушителей мифов показанно, что не замечает.
0
Извини, но я как-то больше доверяю себе, чем разрушителям мифов, при всем моем к ним уважении. Да, я не могу назвать точную задержку, но то, что при 350 (которая от моей типичной 250 как раз на 100мс и отличается) у меня быстро возникает желание полезть и поправить настройки. Ровно та же картина с 150, время слишком мало и мне работать некомфортно.
0
Разницу-то в скорости автоповтора заметить несложно, а вот задержку сложнее. В современных системах задержка достаточно значительна. Один лишь монитор добавляет от 20мс между отрисовкой кадра в системе и его появлентем на экране.

Даже в играх задержка между действием и результатом не очень заметна, хотя запросто достигает 100-200мс (порядка 16мс цикл обновления данных игры при FPS=UPS=60, задержка в 1-2 кадра при использовании двойной/тройной буферизации, задержка на несколько кадров в недрах видеокарты, задержка в мониторе). Зато, правда, отлично заметны проседания частоты обновления (опроса клавиш в том числе), если менее 40Гц — игра явно «тормозит».
0
Динамические приоритеты это не извращение, а очень разумное решение. Другой вопрос насколько оно применимо в RT. Да и своих граблей там изрядно.

Обычная карусель гарантирует время реакции не более чем длина тика Х количество готовых задач. Сколько конкретная задача чего делает, тут ни на что не влияет. Другой вопрос, что сама постановка процесса в состояние ожидания события выбрасывает его из списка готовых к выполнению, а значит время реакции начинает плавать. Ну и процесс, событие которого наступило, попадает в конец очереди, а значит отреагирует не ранее, чем отработают все до него.
0
«Динамические приоритеты это не извращение, а очень разумное решение. Другой вопрос насколько оно применимо в RT. Да и своих граблей там изрядно.»

Конечно нет. Это извращение, там где исключается состояние Idle.

Обычная карусель гарантирует время реакции не более чем длина тика Х количество готовых задач.
Нет. Все задачи равны и готовы. Кто должен получить управление? Все по очереди.
0
Конечно нет. Это извращение, там где исключается состояние Idle.
Динамические приоритеты и состояние idle совершенно ортогональны друг другу.
Нет. Все задачи равны и готовы. Кто должен получить управление? Все по очереди.
Правильно, вот потому время реакции и будет «длина тика Х количество готовых задач».
0
Idle — временно.
А динамическое, это уже постоянно до решения программиста.
Лучше пусть этими делами занимается шедуллер.

«длина тика Х количество готовых задач»
Что то типа этого. Но умножить лучше обозначать не буквой Ху.
0
Idle — временно.
А динамическое, это уже постоянно до решения программиста.
Лучше пусть этими делами занимается шедуллер.
Динамические приоритеты это тоже временно, иначе они бы не были динамическими. И это тоже головняк планировщика. Но, повторюсь, в RTOS их применять чревато боком, поскольку они влияют на время реакции непредсказуемым образом.
0
Вот именно. Ртос юзают чтоб избавится от этого головняка.
0
Не надо путать причину и следствие. RTOS и ОС общего назначения решают разные задачи в разных условиях. RTOS работает в, вобщем-то, тепличных условиях фиксированного и контролируемого разработчиком системы набора задач, отсутствии виртуальной памяти и так далее. И точится она под минимальное время реакции. ОС общего назначения работает в условиях непредсказуемого набора задач, почти всегда есть виртуальная память да и задачи требуют разного обращения, одни надо обработать с минимальным временем реакции, а другим обеспечить максимальную пропускную способность. И сложная система приоритетов, часто поддержка классов приоритетов с разными стратегиями планирования, динамическими приоритетами в пределах одного приоритета одного класса, это все инструменты для разруливания всего того зоопарка, который обычно крутится на обычной ОС. Перед RTOS такие задачи даже не ставятся, да и справлялась бы она с ними плохо, просто потому, что не расчитана на них.
0
Здесь речь идет только об ртос. Конкретней об FreeRTOS.
Другие ОС это уже совсем другое дело.
0
В других RTOS тоже не используют динамические приоритеты, так что избавляться, как бы, не от чего.
0
Стоп. Я кажется понял в чем недопонимание.

1. Если идет выбор между
while(FlagIsReset());

и

while (FlagIsReset()) taskYield();

то второй вариант совершенно ничего не испортит, правильно?

2. Оба этих варианта — это быдлокод, правильнее было бы сделать семафор, повесить текущую задачу в Blocked на ожидание захвата семафора (или какой-то таймаут), а по прерыванию отдать ей семафор. Правильно?

3. Приведеный код для данных двух задач верный и он выполняет следующие задачи: как можно чаще проверять, есть ли пакет (таск 1) и периодически (не чаще чем два раза в секунду) выполнять другие регламентные задачи (таск 2)?

4. Если на все вопросы ответ да, то о чем спор? Лишний taskYield? см п.1

О том что это быдлокод и с ним мы не используем энергосберегающие возможности проца? Ну да, даже не спорю. Тут все пропитано мыслью — запустить, а потом оптимизировать.
0
1. Если идет выбор между
while(FlagIsReset());

и

while (FlagIsReset()) taskYield();

Нет. Это все равно, что постоять на месте и по задрачивать шедуллер «спамом». Если нужно спать так спи.

2. Оба этих варианта — это быдлокод, правильнее было бы сделать семафор, повесить текущую задачу в Blocked на ожидание захвата семафора (или какой-то таймаут), а по прерыванию отдать ей семафор. Правильно?
На лукоморье есть определение быдло кода. Это не быдло код.
Симафоры нужды для разделения доступа к ресурсу. Или ограничения доступа.

3. Приведеный код для данных двух задач верный и он выполняет следующие задачи: как можно чаще проверять, есть ли пакет (таск 1) и периодически (не чаще чем два раза в секунду) выполнять другие регламентные задачи (таск 2)?
Весь код не просматривал. Но таймеры нужны для «точных» простоев. И если их дофига, то это тоже самое что и слип.

4. Если на все вопросы ответ да, то о чем спор? Лишний taskYield? см п.1


Этим нужно пользоваться только если понимаешь как. В документации расписано как. Тоже самое есть и scmRTOS, но там сказано без понимания работы шедуллера не соваться в кооператив.
0
Для разделения доступа используются mutex (MUTual EXclusion) семафоры, а для ожидания события — event семафоры. И то и то семафоры, но разные.
0
Еще раз. Без явного ожидания события задачу в idle не перевести. Иначе непонятно, когда ее оттуда вытаскивать. По крайней мере во FreeRTOS так.
Событием может быть захват семафора, получение из очереди, окончание задержки и т.п.

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

Системный таймер его и выводит из сна.
0
Можно перевести в suspend (аналог sleep() scmRTOS), но без пинка извне она не проснется. А пинка давать некому — кто будет вместо нее флаг проверять?
0
Насколько я помню там есть слип. И он работает также как и в scmRTOS.
0
в scmRTOS слип переводит задачу в вечный сон. у freeRtos аналог — suspend. Задачу можно вывести из него только явно вызвав resume(). Кто будет вызывать эту функцию?
0
в scmRTOS слип переводит задачу в вечный сон.

Пруфлинк линк? Документация есть на русском. Там даже раздел называется sleep))
0
0
На элктрониксе есть замечательные статьи собранные в пдф из журнала. Читать обязательно.

vTaskDelay() — это и есть слип.

Также следует ознакомится с критикой в сторону FreeRTOS. Ее критикуют, за то что авторы любят выдумывать новые имена для общепринятых вещей. Так, что к этому нужно привыкнуть.
0
Был неправ, прочитал по диагонали. С таймаутом — аналог taskDelay у freeRTOS
0
Повторюсь, я не колупал потроха freeRTOS, но в не-RTOS yield просто возвращает управление планировщику не дорабатывая свой тик. Если ничего готового к исполнению нет, то планировщик уходит в hlt или нечто аналогичное до конца тика (то самое idle). Что, вобщем, не мешает усыпить систему. Если во freeRTOS это не так, то хотелось бы узнать почему. Если же есть другие готовые к выполнению задачи, то да, управление уйдет им и заснуть не получится. С другой стороны, если процесс допиливает свой тик до конца, он тоже грузит проц и заснуть, опять таки, не получится.
Массовое использование yield на «больших» CPU действительно может ухудщить время реакции в случае большого количества таких задач готовых к исполнению. Это связано с частым переключением контекстов, которое весьма недешевая операция на таких процессорах. Насколько это применимо к STM32 я сказать не могу, поскольку не интересовался «ценой» переключения контекста у него.

С №2 полностью согласен, тут все прозрачно: в системе с одним приоритетом, обычно, все готовые задачи получают время по очереди. Тут никакого криминала нет, в общем случае, но время реакции на события, в таком случае, будет зависеть от количества готовых к исполнению задач в очереди на момент появления события.
0
Повторюсь, я не колупал потроха freeRTOS, но в не-RTOS yield просто возвращает управление планировщику не дорабатывая свой тик. Если ничего готового к исполнению нет, то планировщик уходит в hlt или нечто аналогичное до конца тика (то самое idle).
В freeRTOS задача будет переведена в Ready. Idlе-a никогда не будет.

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

С другой стороны, если процесс допиливает свой тик до конца, он тоже грузит проц и заснуть, опять таки, не получится./blockquote> Он работает а не грузит.
иначе любая работа это бесполезный груз.

Массовое использование yield на «больших» CPU действительно может ухудщить время реакции в случае большого количества таких задач готовых к исполнению. Это связано с частым переключением контекстов, которое весьма недешевая операция на таких процессорах. Насколько это применимо к STM32 я сказать не могу, поскольку не интересовался «ценой» переключения контекста у него.
Это уже заависит от конкретной ОС. В FreeRTOS yield это не означает переключение контекста, а всего лишь передача управления планировщику. Контекст, конечно будут сохранен.
0
В freeRTOS задача будет переведена в Ready. Idlе-a никогда не будет.
Ну да, все верно. Она перейдет в Ready в конец очереди процессов с одинаковым приоритетом и начнет выполняться другая, если она есть. Но раз они есть, то проц и не должен спать.
Если же есть другие готовые к выполнению задачи, то да, управление уйдет им и заснуть не получится.
Если их приоритет меньше, то никогда.
Замечу, что если вместо yield поставить пустой цикл, то результат будет ровно таким же — задачи с меньшим приоритетом не получат управление никогда. Что как бы намекает, что проблема вовсе не в yield, а в том, как организованы процессы в целом и по взаимодействию и по приоритетам. Высокоприоритетная задача, которая все время грызет свой квант до конца и никогда не переходит в состояние ожидания события, всегда будет давить менее приоритетные не давая им выполняться. Вызов yield ничего не изменяет в этой схеме, поскольку задача остается готовой к исполнению. Но это не вина yield, который сам по себе имеет совсем другое предназначение, а именно отдачу текущего тика раньше времени, что сокращает время ожидания для других задач такого же приоритета.
+1
Ну да, все верно. Она перейдет в Ready в конец очереди процессов с одинаковым приоритетом и начнет выполняться другая, если она есть. Но раз они есть, то проц и не должен спать.

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

Замечу, что если вместо yield поставить пустой цикл, то результат будет ровно таким же — задачи с меньшим приоритетом не получат управление никогда. Что как бы намекает, что проблема вовсе не в yield, а в том, как организованы процессы в целом и по взаимодействию и по приоритетам.

Ага. Но блин, зачем пустые циклы в ртос))

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

Это вина неправильного использование ОС.
0
Это вина неправильного использование ОС.
Я бы сказал «возможностей ОС». Но тут все зависит от задач (не в смысле софта, а в смысле целей проекта). Если задача типа «быстренько слепить прототип на коленке, что бы проверить идею», то тут без разницы, лишь бы запустить. В принципе, с прототипами подобного плана я вижу только одну проблему — их ни в коем случае нельзя брать за основу, если идея себя оправдывает и идет в дело. Прототип надо спрятать подальше и делать все с нуля и по уму. Но это, как бы, совсем другая проблема и непосредственно к ОС она отношения не имеет.
0
— используя taskYIELD ты заменяешь состояние idle на «потоптаться на месте». Т.е. усыпить микроконтроллер нельзя.
В данной конкретной ситуации — вариант оставить просто цикл и ждать вытеснения по концу такта? Нет же.
Если стоит цель усыпить контроллер, то все надо переводить на события, те или иные семафоры, потому что другого способа перевести задачу в idle нет. Во freeRTOS нет понятия idle, есть Blocked
0
Слип прервет тикущий тик и переведет процессор в Idle. Документацию почитай.

Если стоит цель усыпить контроллер, то все надо переводить на события, те или иные семафоры, потому что другого способа перевести задачу в idle нет. Во freeRTOS нет понятия idle, есть Blocked

Ничего подобного. Когда все процессы простаивают, тогда и спим.

Blocked — это тоже самое.
0
Все верно. Но простаивать процессы могут только если ожидают события, даже если это событие всего лишь ожидание завершения слипа. Иначе говоря, вы оба говорите одно и то же :)
0
Т.е. программист помимо разработки еще должен парить мозг над расчетом времени реакции. И это притом, что он использует РТОС!
Не понял, а разве используя РТОС, программист не должен парить мозг над расчётом времени реакции? Или имелось в виду, что этим должен заниматься руководитель проекта?
Приоритетная РТОС ведь не освобождает от расчёта времени реакции. Она лишь делает его возможным. Или нет?

Насчёт «карусельной» схемы согласен (нафиг она нужна): ни энергосбережения, ни предсказуемой скороси реакции особо не обеспечить.
0
В кооперативки время реакции зависит от всех процессов в системе. Там его настраивать напряжно, когда процессов штук пять. Особенно когда идет разработка.

В РТОС, с этим дела обстоят куда проще. Для каждой задачи выставляешь приоритеты, и соответственно на глазок раскидываешь слипы. После окончания разработки немного меняшь их. И все.
Т.е. время реакции практически не зависит от алгоритма работы соседних процессов.
0
Т.е. время реакции практически не зависит от алгоритма работы соседних процессов.
Я понял так (может неправильно?) время реакция процесса с приоритетом N не
практически не зависит от алгоритма работы соседних процессов
, а определяется временем работы процессов с приоритетами 0..N-1 (чем меньше приоритет, тем он выше) и плюс время обработки прерываний.
0
Нет. Практически не зависит.
Приоритет лишь определяет очередь срабатывания и возможность вытеснения.
Если в очереди никого нет, то даже процесс с низшим приоритетом будет быстро реагировать.

В правильно настроенной системе у всех процессов будет высокая скорость реакции. Для этого нужно лишь правильно расставить приоритеты и раскидать слипы/события.
В РТОС в сравнении с кооперативкой это сделать намного проще. Но за это удобство нужно заплатить.
0
Нет. Практически не зависит.
Остаёмся каждый при своём мнении.
У вас — не зависят, а меня — полностью определяются. Мог бы сослаться на источник, но не могу точно вспомнить откула я это взял (наверное в книге Labrosse, но где именно?).

Вот это —
Если в очереди никого нет, то даже процесс с низшим приоритетом будет быстро реагировать.
~= Абстрактная задача в вакууме, работающая на процессоре с бесконечной производительность. Я для таких программы не пишу, не знаю где такой проц купить. Когда говорят о системах реального времени, рассматривают случай не когда в очереди никого нет, а когда все задачи готовы к испонению и учитывается их максимальное время исполнения.

В РТОС в сравнении с кооперативкой это сделать намного проще. Но за это удобство нужно заплатить.
Тут — согласен.
0
Остаёмся каждый при своём мнении.
У вас — не зависят, а меня — полностью определяются. Мог бы сослаться на источник, но не могу точно вспомнить откула я это взял (наверное в книге Labrosse, но где именно?).

Почитай об ртос системах. Не зависит и зависеть не могут.

~= Абстрактная задача в вакууме, работающая на процессоре с бесконечной производительность. Я для таких программы не пишу, не знаю где такой проц купить. Когда говорят о системах реального времени, рассматривают случай не когда в очереди никого нет, а когда все задачи готовы к испонению и учитывается их максимальное время исполнения.

Это полное непонимание ртос систем с твоей стороны. Если все задачи готовы к выполнению, то работать будет только задачи с высшим приоритетом.

Тут — согласен.

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

Это полное непонимание ртос систем с твоей стороны.
Всё так плохо?

Если все задачи готовы к выполнению, то работать будет только задачи с высшим приоритетом.
Да, так. Причём запускаться они будут в соответствии с приоритетом. Мне это было ясно И к чему вы это написали?

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

Да, так. Причём запускаться они будут в соответствии с приоритетом. Мне это было ясно И к чему вы это написали?

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

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

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

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

В ртос системе не могут быть все процессы готовыми к выполнению.
Чушь. В общем случае.
Используешь ртос как кооперативку. При этом не зная
как работает кооперативка.
С чего вы взяли?

При этом не зная как работает кооперативка.
Принцип знаю. Но не с одной кооперавной не работал и не разбирался. Если не считать super loop/round robin.
0
Я где-то утверждал обратное? Не было вроде.

Да, так. Причём запускаться они будут в соответствии с приоритетом. Мне это было ясно И к чему вы это написали?

Да. Говорил и неоднократно. Получать управление будет только высоко приоритетная задача. Если все задачи готовы всегда, то всегда будет работать только одна высоко приоритетная задача. Все остальные будут вечно стоять в очереди.

Используешь ртос как кооперативку. При этом не зная
как работает кооперативка.
С чего вы взяли?

Да по коду видно и по ответам. Почитай по коооперативкам и подумай накой лят там нужно контекст сохранять и куда сохранять, если у задач нет стека))

При этом не зная как работает кооперативка.
Принцип знаю. Но не с одной кооперавной не работал и не разбирался. Если не считать super loop/round robin.

Я верю, что ты в это веришь. Но лучше почитай определение кооперативки.
0
Говорил и неоднократно.
Ну… просмотрю свои комментарии (их пока <50).

Да по коду видно и по ответам.

Бегло просмотрел: никакого кода я не писал (разве чей-то код копипастил).
Вы меня с кем-то спутали?

Почитай по коооперативкам и подумай накой лят там нужно контекст сохранять и куда сохранять
?
0
Хех) Я тебя с автором статьи попутал))
0
Хех) Я тебя с автором статьи попутал))
Полегчало.
0
Смотрю и без меня все хорошо ))
0
Давай чуть подытожу результаты перепалки: весь сыр-бор разгорелся не из-за того, что в данном конкретном месте taskYIELD работать не будет, а из-за того, что в правильно спроектированной системе вообще не будет тупого цикла ожидания. Так?
0
да. Либо работай, либо спи.
0
Для каждой задачи выставляешь приоритеты, и соответственно на глазок раскидываешь слипы.
Непонял насчёт слипов. Для низкоприоритетных задач — можно, ну а если частота вызова задачи выше частоты тика, то слипы не помогут.
0
Непонял насчёт слипов. Для низкоприоритетных задач — можно, ну а если частота вызова задачи выше частоты тика, то слипы не помогут.

Гм. А зачем ты тогда так настраиваешь системный таймер или вообще используешь rtos??
0
А зачем ты тогда так настраиваешь системный таймер
А как же его настраивать?
Для примера: cpu=atmega128, самая приритетная задача — чтение/обработка АЦП с частотой 5-15 кГц. Системный таймер — 1 кГц. Мне что таймер на 150 кГц настраивать? И как работать будет. Или набо по другому как-то делать?
0
Ооо… А прерывания для кого?
0
Что всё в прерывании делать? А если обработка долгая.
0
Мда. В прерываниях инфу толкаешь в очередь а в процессах обрабатываешь.
Да почитай ты уже документацию! На электрониксе собраны замечательные статьи.
0
Ладно.
0
Кооперативка никогда и не являлась RTOS в чистом виде. Там строго лимитированное время отклика можно получить только применив мозг. Это скорей удобный способ писать сложную программу, чем способ добиться реального времени.
0
Кстати, мне тоже любопытно послушать. Я не знаток RTOS, но в кишках ОС немного разбираюсь, и все же не могу пока понять, как отдача тика может негативно повлиять на приоритеты.
0
Процесс не переводится в состояние сна.
0
Хмм. Если процессу есть чего делать, то переводить в состояние сна его в любом случае нельзя.
0
В том-то и дело. Он будет топтаться на месте. Т.к. yeld не даст ему простаивать.
0
Ну да. Процесс же не сказал «я хочу подождать чего-нибудь», он сообщил «в этот раз я закончил, если есть кто-то еще с таким же приориетом, пусть он поработает». Если процесс всего один, то его снова и вызовут. То есть винить yield в том, что он не делает того, для чего не предназначен несколько не логично.
0
Про меньше 64К в начале не понятно.
0
С флешем 16-32к STM32 либо недоступны, либо стоят не сильно дешевле чем 64к+. Поэтому их особенно и не рассматриваю как вариант. Может неправ, но пока обилие ресурсов, особенно памяти, впечатляет
0
Я в одно время набрал по 30 р. STM32F100C4 — 16КБ.
0
Соточка же. Там мелюзга и по 16кб есть.
0
сию вкусноту AVR потянет?
0
Да.
0
Интересно что по скррости можно выжать. И сколько ресурсов требуется.
Порт для avr: Your text to link...
0
Сейчас с большим интересом читаю комментарии VGA, a9d, DIHALT, evsi, которые буквально на глазах появляются :) Именно в такого рода дискуссиях можно эффективно изучать какой либо вопрос. Прояснились тонкости RTOS, которые раньше не понимал. Thanks!
0
Итак возьмем твое исходное утверждение:
Нет. Во FreeRTOS они могут появляться динамически. И там будет все гарантированно.

Предположим, что у тебя есть процесс с наивысшим приоритетом, который большую часть времени спит, но часто просыпается и поллит железку на предмет события. Если событие произошло, то кванта времени ему хватает почти впритык, что бы вытащить и обработать данные из железки. Теперь представим, что динамечески создался второй такой же процесс. Внимание вопрос: каким образом система гарантирует время реакции в этом случае? Что будет, если будет создать третий, четвертый и так далее процесс?
0
  • avatar
  • evsi
  • 19 февраля 2012, 17:18
И что тут сложного? Выйдет опросит уснет.
Если создается процесс, и он работает, то он будет вытеснен в соответствии с приоритетами. Если приоритеты равны и время завершения этого процесса превышает время реакции, то произойдет системная ошибка.
Виновен программист.
0
Ресурсов проца и длины кванта хватает впритык, если событие произошло, приоритеты равны. Теперь представь, что события происходят каждый квант времени, а значит процесс догрызает его до конца. Появление второго процесса с таким же приоритетом приведет к потере половины данных. И RTOS этому никак не сможет помешать ибо перегруз по ресурсам. Так что никаких гарантий, на самом деле, нет.

Виновен программист.
Вот-вот, и RTOS ничего не смогла с этим поделать, поскольку нехватает ресурсов. Именно по этой причине я и спросил, откуда RTOS возьмет ресурсы.
0
RTOS наоборот заберет себе часть ресурсов.
Это эффективный способ их распределения. Без нее придется писать весь этот алгоритм самому. На это уйдет очень много времени.

Если ресурсов процессора не хватает, то есть два выхода.
— купить более мощный процессор
— оптимизация существующих алгоритмов.

Обычно купить дешевле времени программиста.
0
Есть.

Нету.

Требование 1
и так далее, не более чем описание требований с точки зрения автора.

Без вытеснения невозможно обеспечить требуемую скорость реакции. Сам подумай как это возможно ??
Хорошо, что ты вспомнил о требуемой скорости реакции (точнее было бы сказать «требуемое время реакции»). В системе с отсутствующей или кооперативной многозадачностью (только там нет вытеснения) время реакции обеспечивается организацией самой обработки событий. Например, можно написать всю систему как конечный автомат, которые только ждет события, а когда оно происходит делает его обработку или часть обработки и снова переходит в ожидание события. Если каждый из обработчиков работает меньше, чем требуемое время реакции всей системы — мы имеем систему реального времени. Замечу, что это не только возможно, но и придумано задолго до того, как я стал писать софт.

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

В РТОС произойдет передача. Не в РТОС этого не будет.
Если события ожидает процесс с более высоким приоритетом, передача управления произойдет в любой вытесняющей многозадачной ОС. RTOS тут ничем не выделяется.
0
  • avatar
  • evsi
  • 19 февраля 2012, 17:35
Если каждый из обработчиков работает меньше, чем требуемое время реакции всей системы — мы имеем систему реального времени. Замечу, что это не только возможно, но и придумано задолго до того, как я стал писать софт.
И где здесь операционная система реального времени? Это не то, даже если оно удовлетворяет требованиям, это не РТОС.

Доработать свой кусок и отдать управление планировщику. Собственно, так и происходит, если задача, событие которой наступило, имеет такой же (или более низкий) приоритет как у текущей.
Если кусок слишком длинный, то не вписываемся. Также на очереде может быть следующая задача. И какой из них дать управление? В РТОС дорабатываться ничего не будет. Задача будет вытеснена.

Если события ожидает процесс с более высоким приоритетом, передача управления произойдет в любой вытесняющей многозадачной ОС. RTOS тут ничем не выделяется.
В любой много задачной сначала будет завершен квант, а уже потом может быть передано управление.
0
И где здесь операционная система реального времени? Это не то, даже если оно удовлетворяет требованиям, это не РТОС.
Хмм. А почему? Свои задачи система решает вполне в real time, чего ж она не RT?

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

Ладно, пора передохнуть и дать всем время переварить написанное и прочитанное. А то выходной на исходе, а я еще не спаял сегодня ничего. Непорядок :)
0
Хмм. А почему? Свои задачи система решает вполне в real time, чего ж она не RT?
Отсутствует многопоточность.

Если текущая имеет такой же приоритет, то не будет.
Да. Но если будет превышено время реакции то будет сбой.
0
Отсутствует многопоточность.

Она не является обязательной. Более того, существовали операционки, которые вполне себе были RTOS, но не имели потоков.

Да. Но если будет превышено время реакции то будет сбой.

Именно. И, заметь, RTOS опять ничего не гарантирует.
0
Она не является обязательной. Более того, существовали операционки, которые вполне себе были RTOS, но не имели потоков.
Что тогда вообще можно мерять у одного процесса?

Именно. И, заметь, RTOS опять ничего не гарантирует.
Гарантирует время реакции постоянное.
0
А кто сказал, что процесс был один? Многозадачность была, а многопоточности не было.
Гарантирует время реакции постоянное.
Она гарантирует только что оно постоянное в определенных условиях. Отключи своп и диски у обычной операционки, запусти N фиксированных задач и время отклика у нее станет постоянным. Собственно, именно из-за наличия высокоприоритетных системных задач у обычных операционок и плавает время реакции, во всяком случае для задач с приоритетом выше дефолтного.
0
Приоритет не отвечает за распределение проц. времени в РТОС системе.
Посуди сам: произошло событие и система отобрала управление у текущего процесса и отдала его более высокоприоритетному. Что по твоему это такое, как не распределение времени? Планировщик не знает (да ему это и не нужно) что собирается делать высокоприоритетная задача. Даже если бы и знал, все, что он может сделать — отдать управление этой задаче как можно быстрее. Другими словами, перераспределить процессорное время в ее пользу.

Запущенная задача не в РТОС системе изменит скорость реакции для всех процессов.
Зависит от ее приоритета. Точно так же как и в RTOS.

Еще раз: нету никакого сакрального знания в RTOS, а ее планировщик если чем и выделяется, так это простотой и аскетичностью.
0
  • avatar
  • evsi
  • 19 февраля 2012, 17:41
Посуди сам: произошло событие и система отобрала управление у текущего процесса и отдала его более высокоприоритетному. Что по твоему это такое, как не распределение времени? Планировщик не знает (да ему это и не нужно) что собирается делать высокоприоритетная задача. Даже если бы и знал, все, что он может сделать — отдать управление этой задаче как можно быстрее. Другими словами, перераспределить процессорное время в ее пользу.

Приоритет никак не повлиял на распределение. Была запущена задача которая его должна обработать. После управление вернется и задача отработает свое законное время.

Зависит от ее приоритета. Точно так же как и в RTOS
В линукс и виндовс такого понятия фактически нет.

Еще раз: нету никакого сакрального знания в RTOS, а ее планировщик если чем и выделяется, так это простотой и аскетичностью.
Он дает гарантию. Другие ее не дают.
0
Приоритет никак не повлиял на распределение.
Как это не повлиял, если время забрали у одной задачи и отдали другой?
Была запущена задача которая его должна обработать. После управление вернется и задача отработает свое законное время.
Отобраного времени ей никто не компенсирует.
В линукс и виндовс такого понятия фактически нет.
Насчет линукса набери в гугле man nice и узнаешь много нового. А насчет винды ты меня здорово удивил. Даже, как-то, в голову не приходило, что все эти ее навороты с классами приоритетов и множественными уровнями в каждом классе, оказывается, вовсе не приоритеты… Век живи, век учись… :)

Он дает гарантию. Другие ее не дают.
Она дает гарантию только в узком диапазоне тепличных условий — проца с запасом, процессы все известны заранее и так далее. В таких условиях любая операционка дает определенные гарантии. Понятно, что эти гарантии будут хуже чем у RTOS, но это связано только с бОльшими накладными расходами (как и у любого универсального решения, вобщем).
0
Как это не повлиял, если время забрали у одной задачи и отдали другой?
Как вытеснение изменит время выполнение обеих задач? Задача 1 выполняется 10мс, задача 2 5мс. Как вытеснение должно изменить это время? Оно перепишет код одной из задач?

Отобраного времени ей никто не компенсирует.
Это еще почему?? Ей вернут управление и она завершит работу.

Насчет линукса набери в гугле man nice и узнаешь много нового. А насчет винды ты меня здорово удивил. Даже, как-то, в голову не приходило, что все эти ее навороты с классами приоритетов и множественными уровнями в каждом классе, оказывается, вовсе не приоритеты… Век живи, век учись… :)
Где на пользовательском уровне там приоритеты?

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

Тогда торгаши uC обманывают всех продавая систему за 100000$
0
Где на пользовательском уровне там приоритеты?
Что значит «на пользовательском»? Они там не нужны, тем более что большинство пользователей даже не знают, что с ними делать.
Но тем не менее, каждый процесс и каждый поток имеет свой приоритет, напрямую влияющий на раздачу процессорного времени.
Это еще почему?? Ей вернут управление и она завершит работу.
В РТОС ключевым понятием является не «дали время», а «дали время вовремя». В утрированном случае задача возможно не завершит работу потому, что из-за отбирания времени не успела ее завершить вовремя и вся система взорвалась. Впрочем, как раз такие задачи и работают с высшим уровнем приоритета.
0
Поток только в процессе имеет силу. На пользовательском зависимости как таковой нет. Ниодин процессор не захватит полный доступ. На системном уровне, любая ошибка приводит к сбою.
В ртос системах аналогичные правила. Но пользовательский процесс может захватить все время.
0
Ничего не понял. Разъясни яснее.
0
Ты когда разрабатываешь программу лезешь в ядро?
В виндовс можно программы запускать с разными правами. Но это не приоритеты как в РТОС.
0
Ты путаешь права и приоритеты. В винде есть и то, и другое.
Приоритет — то же самое, что и в РТОС. Выполняться хотят сразу много программ и потоков, а проц только один (ну ладно, 32. Но потоков 300). Планировщик выбирает самый высокоприоритетный (если их несколько одинакового приоритета — первый в очереди потоков этого приоритета) из желающих работать и отдает время ему. Ну, плюс различные фокусы, чтобы низкоприоритетные не чувствовали себя совсем уж обделенными.
Права — это возможность потока воспользоваться некоторой функцией ОС. Например поток говорит системе — «ну-ка, выруби комп!», а она ему — «обломись, нет у тебя права на отключение компа».

Приоритеты непосредственно пользователем обычно не управляются. Программа сама выставляет себе требуемый приоритет. Большинство программ работают на Normal (8 вроде, чем больше — тем выше приоритет, максимум 31). А вот скажем фоновая архивация работает с приоритетом 4 (Idle) — чтобы занимать все время, оставшееся от пользовательских задач, не мешая им. Если пользователь ничем в это время комп не грузит — она получит почти все время.

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

В ртос хоть тресни. Если сделаешь его низким, то он и будет таким. Если пользователь работает с программой, то это не повысит ее важность.
0
Так, как у активной задачи приоритет становится высокой.
Ну разве что в новых виндах. В XP такого точно нет.
Эти приоритеты повлияют на время реакции. Они толком ни на что не влияют.
Ха-ха. Оно и видно, как ты с виндой и программированием под нее знаком.
0
ничего не понял.
0
У активной задачи приоритет повышается только в рамках своего класса и своего уровня приоритета. И как только задача дождалась события, приоритет ей сбрасывается до изначально установленного. И, если в винде это не сломали, динамические приоритеты есть только в классе NORMAL, все остальные классы работают с фиксированными приоритетами.
0
В RTOS нет пользовательских процессов вообще, все процессы системные.
0
Да. И нет. В систему они не лезут. Но могут повлиять на ее работу.
0
Они системные просто потому, что выполняются с уровнем привилегий (прав доступа) таким же как у ядра. Куда они лезут или не лезут — дело двадцатое.
0
У авр да. На Cortex-m3, задачи не выполняются с правами такими же как у ядра.
0
В РТОС ключевым понятием является не «дали время», а «дали время вовремя». В утрированном случае задача возможно не завершит работу потому, что из-за отбирания времени не успела ее завершить вовремя и вся система взорвалась. Впрочем, как раз такие задачи и работают с высшим уровнем приоритета.
Критическая секция.
0
По хорошему все опасные захваты управления и критичные секции должны делаться ТОЛЬКО через ОС и ее механизмы, а в процессах это табу и ахуй. Иначе в системе будет не многозадачность, а бардак и анархия.
0
Гмм… Нахрена тогда разработчики FreeRTOS и ScmRTOS их запилили?
0
Что поделать, ограничения и упрощения. Иначе эта OS будет размером как QNX какая и совсем уж не микроконтроллерного формата. Мы же в реальном мире живем.
0
крит секция не нарушит реал тайм. может внести коррективы, но не более. Мьютекс дает куда большие задержки.
0
Что значит внести коррективы? РТ Он или есть или его нет. Профачил на 0.0001 секунды — считай, что нет.
0
Нет. Реалтойм это прогнозируемая реакция. С ним можно и на 10мин промахнутся и это будет реалтайм, если время реакции позволяет.
0
Как это не повлиял, если время забрали у одной задачи и отдали другой?
Как вытеснение изменит время выполнение обеих задач? Задача 1 выполняется 10мс, задача 2 5мс. Как вытеснение должно изменить это время? Оно перепишет код одной из задач?
Смотри: выполняется задача 1 с более низким приоритетом, она выполняется 9мс и тут происходит событие, на которое просыпается задача 2 и которая тратит еще 2.5мс на свою работу. Время от начала работы задачи 1 и до завершения исполнения будет не 10мс, а 12.5мс. Как видишь, без какого-либо переписывания кода задача 1 стала выполняться на 25% дольше.
0
Лихо ты ты их суммируешь)))
Значит так.
Задача 1 = 10мс.
Задача 2 = 5мс.

В сумме они дают 15мс.

Но после работы в сумме они забрали 17.5мс. ))
Чудеса математики.
0
Извини, просто почудилась запятая во фразе «задача 2 5мс». Если посчитать с этими данными, то будет и того хуже, задача 1 станет выполняться на 50% времени дольше. Так ты все еще будешь утверждать, что приоритеты не влияют на распределение времени между задачами?
0
Не влияют. Как выполнялись 15мс. Так и будут.

иначе 10+5 = 20мс.
0
Не изменилось суммарное затраченное время процессора, но изменилось полное время работы одной из задач.
0
Не изменилось. Задача была прервана, это не влияет на ее продолжительность.
0
Это не влияет на ее время работы (в смысле сколько она потребила процессорного времени), но влияет на разницу между временем завершения и временем старта.
0
Это уже переходит в разряд бреда! Какая вообще ОС в мире тебе должна это гарантировать???? Зачем это гаранитровать?? Если тебе нужна гарантия непрерывного выполнения, то помещая процессы в крит секцию. Тогда будет все гарантировано.
Появится только обратная зависимость. Процесс будет влиять на все процессы как и в кооперативе.
Если использовать семафоры. То текущий процесс будет влиять на все процессы у которых приоритет выше, но не ниже.
0
Нельзя. Написанное от балды ПО в ртос, приведет к загрузки процессора. Это приведет к сбою.
Написанное от балды ПО создает проблемы в любой ОС, отличия только в последствиях.
0
  • avatar
  • evsi
  • 19 февраля 2012, 17:42
В линуксе и виндовс это не приводит к системному сбою. В ртос это системный сбой.
0
Смотря какое ПО и смотря что считать сбоем.
0
Запускаю новую игру на старом компе. Она работает но жутко тормозит. Все программы работают. Где там сбой в системе?
0
Тормозящая игра сама по себе сбой, для данной задачи. К тому же, криво написанная игра вполне может повесить систему намертво.
0
Это не сбой. После выключения игры, все нормализуется.
В РТОС это аварийная ситуация.
0
Как уже сказано — смотря что считать сбоями и проблемами. При постановке задачи «поиграть в крусис» его торможение — системный сбой, так задача не решена. Системник отправится на помойку — геймеру он уже не нужен.
0
Это сбой системы. После ниго ничего не должно работать.
В виндовс это BOD. Насамом деле она может работать, но считается что она работает неверно и вызывается система аварийного завершения.
0
Сбой — это невыполнение задачи. Домашний комп спасает то, что играть в крусис не единственная его задача, тогда как у компа, управляющего реактором других задач просто нет.
Но для геймера «тормозят новые игрушки» — критический сбой системы, и она отправляется на помойку.

Кроме того, первоначальный тезис —
Написанное от балды ПО создает проблемы в любой ОС, отличия только в последствиях.
В чем именно «от балды» — не уточнено. Может, оно из-за ошибки биос стерло или VRM перенастроило. А это уже серьезное повреждение аппаратного обеспечения. Ну или просто по ошибке несколько лишних файлов снесло… Стоимостью дороже компа, винды и пары автомобилей впридачу.
0
В ртос это сбой. Авария. На этом чудеса и закончатся.

Виндовс, линукс даже не заикнется.
0
То есть, если в результате сбоя ничего не взорвалось — то это не сбой?
0
нахрена системе работать дальше если уже есть сбой?
0
В ртос это сбой.
Нашел чем хвастаться… Задетектить пролет по времени реакции и устроить сбой можно везде.
0
Не везде. На производстве, такой збой и продолжение работы приведут к проблеме.
0
«Везде» в смысле «в операционной системе».
0
РТОС системы используют на производстве. Там отклик критичен. Гикакой линукс без ртос диспетчера не даст такой гарантии. Один сбой и хана производственному процессу.
0
Ну раз обсуждение перешло из области обсуждения понимания механизмов работы RTOS в область веры в чудесные возможности RTOS то, пожалуй, на этом стоит завершить дискуссию.
+1
Еще один бред.
Чудеса были предложены тобой.
РТОС отличается от других систем только детерминированностью времени. Механизм прост и прозрачен. Его можно легко рассчитать.

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

РТОС дает только прозрачный и простой способ для расчета времени! В РТОС все детерменированно!

Если вам так нравится вырубать мозг, то смело выключайте и вперед.
Я кнечно понимаю, что тут планировщик ди любят относить к РТОС. И то что swg всем доказывает, что на микроконтроллере реал тайма не будет. Потому что люди упираются в слово «реал тайм». Это время на часах! Реал тайм может быть каким угодно, но определенным!

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

Vga предоставил расчет, доказывающий реалтайм в РТОС. И сам же этого не увидел. Потому что высосал из пальца 990мс. Не понял, что от этой величены нужно отнять время выполнения старших процессов.
+1
Упс, это я случайно плюсик поставил. Disregard this.
Реально я составил то же мнение, что и lleeloo
Мда. а9d в реальной жизни никто не переспорит и ничего не докажет.)
Хотя, в принципе, это можно было еще в прошлый раз понять…
0
Мда. а9d в реальной жизни никто не переспорит и ничего не докажет.) Топик засран, по теме ничего путного…
+1
я выжимку в конец топика добавил, для тех кто не сможет вникать в 300 комментов :)
+3
Как уже устал.
electronix.ru/forum/index.php?showtopic=99812&st=0&gopid=1029189&#entry1029189

Обращаем внимание на того кто отвечает.
0
  • avatar
  • a9d
  • 20 февраля 2012, 12:54
Я считаю, что это «детерминированное время отклика для каждого процесса в системе». Его можно посчитать.

Оппоненты, насколько я понял, это «непрерывное выполнение задач». Т.е. задача выполняется 10мс и будет выполнятся 10мс и ее никто не прервет.
Второе утверждение «задача будет выполнятся через определенные промежутки времени». Т.е сказали задаче выполнятся раз в секунду, она и будет выполнятся раз в секунду.
Уже достаточно, чтобы увидеть, что никого из оппонентов ты не понял, да и не пытался.
0
Возможно. Не понял. Я предоставил ссылку. Напиши свое понимание.

Если не хочешь регистрироваться. Я могу опубликовать твой ответ.
0
Я устал с тобой спорить. Считай, что я слился.
Но мое понимание примерно такое же — детерминированное время отклика. Правда, я не уверен насчет его детерминированности для каждого процесса, но суть RTOS в любом случае именно в нем.
Спор по большей части был о сложностях с определением времени реакции низкоприоритетных процессов. Но туда обычно отправляются процессы, для которых этот параметр не столь важен.
В споре о взаимосвязи приоритета и процессорного времени я в конце концов согласился — при запасе свободных ресурсов не зависит, а без него РТОС (обычно?) не работают.
+1
Приоритет никак не зависит. Его задача обеспечивать детерменизм.

Если программист, написал процесс который выполняется 10мс. Он будет выполнятся 10мс.
Не прерывность его выполнения РТОС либо другая ОС не гарантирует. Но предоставляет для это API функции, которые могу это обеспечить.
При этом детерменизм не будет нарушен.

Задача может быть прервана хоть на несколько часов. Если нет нарушение во времени отклика, то это нормальная ситуация. Иначе это сбой. Принцип реал тайма нарушен.
Такая система не считается реал таймовой. Именно система а не ОС.

РТОС предоставляет API и сервисы для постройки реалтаймовой системы. Она не «вылючит мозг». Она сделает лишь процесс разработки реал таймовой системы более простым.

На кооперативке можно сделать реалтаймовую систему. Но сама кооперативка от этого не станет РТОС. Кооперативные ОС не предоставляют сервисов и API для этого.
0
Без приоритета невозможно обеспечить детерменизм. Т.к. если разработчик не знает, что в системе важное а что нет. РТОС система соответственно сама не определит, что важно.

Это инструмент и им нужно уметь пользоваться.
0
хочу портировать под stm8, но компилятор ее говорит, что не найдена функция tcpip_output(). В исходниках я ее не нашел. Где ее можно взять или чем заменить? (сверху uip_fw_output() закоментирована)
0
Хочется спросить автора и за одно инициировать доработку примера. Мысль заключается в том, что данный пример не способен отправлять свои запросы, например DHCP, NTP… Причина в том, что обработку входящих и исходящих пакетов разделили на 2 независимые задачи. Отсюда вылезла проблема, что пока идет подготовка исходящего пакета, выывается проверка входящего и иуи происходит порча подготовленного буфера, и обнуление длины подготовленного пакета. Итого имеем, для только входящих запросов это все работать будет, исходящие запросы будут нещадно портиться. Я нигде не ошибся?
0
А кто нибудь в коксе собирал это?
Выложите архив папки проекта а то я вообще «деревяный» в этом, но как писал автор надо хоть как то собрать а потом тыкать пальцем в небо(ну это в моем случае)… буду весьма признателен
0
Вообщем нашел в архиве в папке дебаг хекс(я так понял это тестовый образец прошивки) и залил его в свой дискавери. На второй СПИАЙ подключил китайский модуль который сделан на ЕНЦ28ж60(подключил только СИ, СО, СЦК) провери(пнул в командной строке адрес как в статье) не завелось… потом подключил еще ногу ЦС на НСС(ПБ12 на дискавери)… тоже не заработало =(
Куда копать подскажите???
0
0
0
Ссылка уже не работает
0
Если не трудно, выложите пожалуйста Ваши исходники CooCox_RTOS.rar
старая ссылка не работает
0
У меня с таким модулем были проблемы с питанием. Если запитывал от Дискавери, то чтение из ENC происходило с ошибками. Когда стал запитывать от блока питания и Дискавери и модуль, все нормально заработало.
0
Это да. При питании от USB его может запросто не хватать. Я долго искал ошибки, пока не сообразил глянуть что на питании творится.
0
Добрый день, уважаемые форумчане. Прочел статью, но как раз один момент в нем пройден «вскользь». А именно — как передавать данные с МК на компьютер через Ethernet uIP. В статье есть момент использовать PSOCK_SEND_STR(), но где его надо использовать, как — не описано. Не могли бы Вы подсказать, как осуществлять обратную передачу данных?
P.S. Передавать данные с МК на компьютер по запросу последнего я умею, через uip_send(). Но как не запрашивая с компьютера, передавать пакеты, я не знаю. Помогите решить вопрос, пожалуйста!
0
Когда являюсь сервером uip_listen, все норм и принимаю и передаю.
Но задача, быть клиентом вызываю uip_connect.
uip_ipaddr(&ipaddr, 92,206,200,21);
conn = uip_connect(&ipaddr, HTONS(21)); // conn !=NULL

В сеть ничего не отправляется ( Смотрю через Wireshark. Пинг проходит.
0
  • avatar
  • VIC
  • 28 декабря 2013, 03:32
Уважаемые форумчане! Кто-то собирал связку stm32f4 и enc28j60 в Keil v5?
У меня при сборке вылетают ошибки, хотел с вами проконсультироваться. Если кто собирал, получилось у кого?
0
А разве у F4 нету своего МАС?
0
stm32f401vct6 разве имеет свой mac?
0
Понятия не имею)

Но в любом случае, если у тебя ошибки — следовало для начала лог запостить.
0
ok. При компиляции возникает ошибка
.\1.axf: Error: L6218E: Undefined symbol tcpip_output (referred from uip-split.o).
В самом же файле uip-split.c ошибка описывается так: implicit declaration of function «tcpip_out» is invalid in C99
Вторая ошибка .\1.axf: Error: L6218E: Undefined symbol uxTaskGetStackHighWaterMark (referred from main.o). Сейчас выложу проект в архиве.
0
0
Линкер не может найти требуемый символ. Какие-то библиотеки не подключены (не включены в линковку — напомню, что #include не подключает библиотеку). Также возможно, что это относится к неиспользуемой функциональности, которую ты забыл отключить дефайнами (либо пересобрать после отключения).
0
неиспользуемая функциональность описывается в warning'ах, но все равно еще раз перепроверю. И вопрос, быть может, глупый, но как (если не #include'ом) подключить библиотеку?
0
Я уже писал на эту тему.
Почему никто не удосуживается изучить язык, на котором пишет?
Почему я знаю язык, на котором не пишу лучше, чем те, кто на нем пишет? (это так, ворчание, наследие холиваров с поклонниками С… :)
0
tcp_output — что-то странное. Похоже на левую допилку uIP (все вызовы этой функции сопровождаются закомментированным вызовом uip_fw_output, более того — эта функция даже нигде не объявлена, но компилятор С такие мелочи не колышат). Желательно сверить с официальным релизом uIP. Но, в принципе, собирается и если просто uip_split.c из проекта выпилить — значит, оно все равно не используется.
uxTaskGetStackHighWaterMark нужно включать дефайном (каким именно — указано в task.h). Но не похоже чтобы оно тут было хоть как-то нужно — так что можно просто закомментировать вызовы этой функции (и оответствующие объявления переменной st заодно).
P.S. Я по прежнему нахожу ироничным, что пасквилянт учит сишников их собственному языку.
0
Спасибо вам огромное за информацию и терпение. Буду пытаться собрать — завтра отпишусь о результатах. А всю uIPшную папку я взял из прикрепленного к теме, проекта. Буду пересобирать из оригинала.

P.S. Сильно не пинайте — я не большой профессионал :( только учусь
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.