Вот такая новость появилась: FreeRTOS перешёл под крыло Amazon и выпущен под лицензией MIT
Раньше была GPLv2 с модификациями, теперь MIT. Кто-нибудь, кто разбирается в лицензия, может пояснить какие это плюсы или минусы даёт? Вроде и раньше можно было исходники не открывать даже при модификации. Из плюсов пока только вижу - в предыдущей версии лицензии был пункт, что нельзя сравнивать производительность ОС по сравнению с другими, теперь, похоже, этот пункт убрали.
Полная версия этой страницы: FreeRTOS 10, теперь под лицензией MIT
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > FreeRTOS
Я тоже на первый взгляд отличий не вижу. Непонятно, зачем тогда меняли? Какие-то свои юридические заморочки?
Цитата(arhiv6 @ Nov 30 2017, 08:37) 
Вроде и раньше можно было исходники не открывать даже при модификации.
А с чего вы взяли что GPL позволяла не открывать исходники? Как раз наоборот, вы обязаны были раскрыть исходники либо вместе с программой либо по запросу.
Правда пишут что у FreeRtos было какое-то исключение на счет раскрытия исходников.
Цитата(arhiv6 @ Nov 30 2017, 10:56)
Я тоже на первый взгляд отличий не вижу. Непонятно, зачем тогда меняли? Какие-то свои юридические заморочки?
Собственно, GPL + их исключения как раз и получается MIT. Просто сделали понятнее для всех.
Думаю, причина в том, что слово "GPL" отпугивает какую-то часть пользователей.
А вот что пункт про запрет сравнений убрали - это хорошо. Ждём весёлых тестов
Думаю Амазон с его ресурсами довольно быстро это исправит.
Вот добавили Message Buffers - уже польза есть
QUOTE (arhiv6 @ Nov 30 2017, 08:56)
Я тоже на первый взгляд отличий не вижу. Непонятно, зачем тогда меняли? Какие-то свои юридические заморочки?
Раньше (GPL+exception clause) можно было скрывать свои сорцы, при условии что саму FreeRTOS вы не меняли. Сейчас можно скрывать свои модификации FreeRTOS.
Кроме того, TCP и FAT раньше были под чистым GPL, т.е. надо было открывать свои исходники в любом случае. Сейчас такого требования нет.
Думаю такое было требование Amazon. Амазонцы лезут во всяческий IoT, а там открытые сорцы могут быть нежелательны по причине безопасности.
Протестировал стрим буфер. Компилятор Keil, максимальная оптимизация по скорости, контроллер STM32F103C8T6. Измерил количество тиков на типовые операции и использование стека в байтах. Получились интересные результаты:
Create / Send / Receive (тики между переходом управления планировщику и получением байта принимающей задачей) / Stack
Стрим буфер = 200 / 572 / 548 / 136
Старая добрая очередь = 290 / 311 / 319 / 176
То есть выигрыш только в стеке? Я надеялся, что и скорость выше будет.
Получается, что есть смысл использовать буферы только если прижимает по стеку, либо ради фишек буферов - Trigger Level для стрим буфера и возможность отправки данных разной длины для буфера сообщений.
Код тестовой программы:
Create / Send / Receive (тики между переходом управления планировщику и получением байта принимающей задачей) / Stack
Стрим буфер = 200 / 572 / 548 / 136
Старая добрая очередь = 290 / 311 / 319 / 176
То есть выигрыш только в стеке? Я надеялся, что и скорость выше будет.
Получается, что есть смысл использовать буферы только если прижимает по стеку, либо ради фишек буферов - Trigger Level для стрим буфера и возможность отправки данных разной длины для буфера сообщений.Код тестовой программы:
Код
#include "stm32f10x.h"
#include "FreeRTOS.h"
#include "stream_buffer.h"
#include "task.h"
#include "queue.h"
StreamBufferHandle_t buf_tmp;
QueueHandle_t que_tmp;
uint8_t i, j, k;
void task_tmp1(void * param) {
while (1) {
i++;
xStreamBufferSend(buf_tmp, &i, sizeof(uint8_t), portMAX_DELAY);
vTaskDelay(100);
i++;
xQueueSend(que_tmp, &i, portMAX_DELAY);
vTaskDelay(100);
}
}
void task_tmp2(void * param) {
while (1) {
xStreamBufferReceive(buf_tmp, &j, sizeof(uint8_t), portMAX_DELAY);
__NOP();
}
}
void task_tmp3(void * param) {
while (1) {
xQueueReceive(que_tmp, &k, portMAX_DELAY);
__NOP();
}
}
int main() {
xTaskCreate(task_tmp1, "tmp1", 128, NULL, 4, NULL);
xTaskCreate(task_tmp2, "tmp2", 128, NULL, 3, NULL);
xTaskCreate(task_tmp3, "tmp3", 128, NULL, 2, NULL);
buf_tmp = xStreamBufferCreate(100 * sizeof(uint8_t), sizeof(uint8_t));
que_tmp = xQueueCreate(100, sizeof(uint8_t));
vTaskStartScheduler();
}
#include "FreeRTOS.h"
#include "stream_buffer.h"
#include "task.h"
#include "queue.h"
StreamBufferHandle_t buf_tmp;
QueueHandle_t que_tmp;
uint8_t i, j, k;
void task_tmp1(void * param) {
while (1) {
i++;
xStreamBufferSend(buf_tmp, &i, sizeof(uint8_t), portMAX_DELAY);
vTaskDelay(100);
i++;
xQueueSend(que_tmp, &i, portMAX_DELAY);
vTaskDelay(100);
}
}
void task_tmp2(void * param) {
while (1) {
xStreamBufferReceive(buf_tmp, &j, sizeof(uint8_t), portMAX_DELAY);
__NOP();
}
}
void task_tmp3(void * param) {
while (1) {
xQueueReceive(que_tmp, &k, portMAX_DELAY);
__NOP();
}
}
int main() {
xTaskCreate(task_tmp1, "tmp1", 128, NULL, 4, NULL);
xTaskCreate(task_tmp2, "tmp2", 128, NULL, 3, NULL);
xTaskCreate(task_tmp3, "tmp3", 128, NULL, 2, NULL);
buf_tmp = xStreamBufferCreate(100 * sizeof(uint8_t), sizeof(uint8_t));
que_tmp = xQueueCreate(100, sizeof(uint8_t));
vTaskStartScheduler();
}
мануал теперь бисплатно и фицыально
Короче реально надо сваливать с FreeRTOS и переходить на что-то более простое и эффективное.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.