Ну кто теперь напаивает модули, Эдди!?

Я ж дал специально ссылку на медиатек чтобы вы уловили тренд.
Тренд в перемещении всего в один SoC. Там уже и либы GNSS и Wi-Fi AP, и аудиообработка, и облако сенсоров и т.д. и т.п.

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

Но PI вам не поможет с облаком сенсоров.
И тут вы втихаря от нас купите очередную борду с STM32F7 или F8, не знаю что они завтра придумают, и начнете обречённо ковырать FreeRTOS.

Прошу не приписывать мне свои догадки, мы с Вами не знакомы.

Увы, УЖЕ знакомы. Заочно, но уже настолько, что я могу абсолютно точно судить о Вашей квалификации в области GSM протоколов и их реализаций. Так что никаких догадок.

микроконтроллер - это м(от, видимо, микроконтроллер), а процессор, как вы говорите - это а(видимо, от апликейшн)
основное отличие - наличие mmu, а оно не таракан, просто так на ровном месте не заведётся
это к слову о применимости к использованию или нет разных rt и не очень os

Я, чтобы подешевле было.

Зачастую у этого ужаса совершенно невменяемый SDK, поэтому ну его нафиг!

Скорости передачи данных небольшие — можно даже поочередно коммутировать при желании. Ну или взять STMку с нужным количеством UART'ов.

Не, PI я беру, чтобы там Nginx поднять, потому как на STM32F407 веб-сервер — жуть какая-то. У всех этих "малинок" и т.п. слишком убогая периферия, они по сути — слабенькие компьютеры. Вот я как слабенькие компьютеры их и использую, оставляя работу с периферией микроконтроллеру (разве что в редких случаях, когда нужно тупо парой-тройкой шаговиков порулить, можно подключить драйверы непосредственно к "малинке").

Ни в коем разе!

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

Вы точно уверены, что число 299.6 Mbit/s это "небольшое число" ?

Я точно уверен, что нет интерфейсов с такими скоростями в круге требующихся для меня железяк.
У тех же GSM/GPS модулей скорость обычно 9600. Да, есть возможность увеличения скорости интерфейса при использовании GPRS, но все равно там таких диких мегабит никогда не будет.
Да и вообще, откуда взялось это дурацкое число? Даже гигабитный ethernet фактически редко такую скорость выдает!

А зачем "оппонент" начал говорить о GSM (типа берем модуль с полмегабайтом-мегабайтом софта, не знаю, что в нем, но операционные системы не нужны) в контексте НЕНУЖНОСТИ операционных систем? Какой подтекст Вы видите в этом?



Это "дурацкое число" это пиковая скорость до которой сейчас докатилась "Enhanced Data rates for GSM Evolution".

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

Я вообще не понял, каким боком содержимое ЧЯ к ртоси? Я в его нутро не влезаю!

В таком случае, Вам категорически не следовало провозглашать ненужность операционных систем в микроконтроллерах. Домохозяйке тоже не нужны не только операционные системы, но и микроконтроллеры с конечными автоматами. Ей тоже достаточно "Черного Ящика" и интерфейса-кнопки, и она тоже "в нутро не влезает". Имеет ПОЛНОЕ право. Только вот если она будет разглагольствовать о ненужности операционных систем, то это будет глупо. Так не уподобляйтесь такой домохозяйке.

Ужас, какой упоротый товарищ попался!
Может, кто-то без ртоси не может обойтись. Мне она не нужна.
Я же вас не заставляю сносить свою пиратскую мастдайку и ставить линукс!

Просто мало имели дело с модулями.

Я реверсил телефоны еще по заказу Мотороллы ( в смысле фирмы)
Там была RTOS с 30-ю задачами. На ARM7 без MMU.
Т.е. еще задолго до вас Эдди люди осознали важность RTOS даже на простейших микроконтроллерах без всяких признаков MMU.

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

TI сейчас для своих чипов IoT выкладывает сорсы для embedded хостов, которые без RTOS хрен запустишь.
AT команды это анахронизм, удел ардуинщиков.

Верю. Я просто посчитал нужным объяснить читающим эту тему при каких условиях RTOS не нужна и почему конкретно Вам, а не вообще всем, она "не нужна".

К делу совершенно не отностися, но отвечу.
C Линуксом, будучи его активным сторонником, завязал лет 15-16 назад, когда понял, что все это катится в мутную десктопную помойку в стиле "секс по телефону", полузакрытые любительские поделки и закрытые коммерческие. Ну и Win в своей 2000 реинкарнации к тому времени уже не вызывал сколь-нибудь критичных нареканий. С тех пор держу только CoLinux для поддержки старых проектов. Хватает.
"Масдайки" сностить не буду. Они у меня лицензионные, ибо давно покупаю железо с прошитой Software Licensing Description Table и лицензией на все WIN операционки. Удобно и абсолютно необременительно - пару десятков евро. Ну и здесь вам не в горах Кавказа - с вороованым софтом строго.

Похоже, что Вы не очень поняли суть проблемы. DMA - это для отображения статической картинки.
Чтобы картинка изменялась, ее нужно перерисовывать. При хорошем разрешении это длительный процесс даже на 32-х разрядном контроллере.
Второй длительный процесс - это (например) работа с SD-картой.
Если в бесконечном цикле Вы поочередно будете вызывать эти функции поочередно, пользователю будет сложно работать с таким прибором из-за "рваной" реакции.
Да, можно побить функции на части, но это трудоемко.

Вот собственно и вся коллизия, если Вы с ней пока не столкнулись, это не значит, что она не существует.
Если повезет, так и будете всю жизнь на STM8 датчики считывать

Хотел написать еще 10 страниц назад по поводу эффективных реализаций автоматов состояний и обмена информацией между ними.
Советую установить такой продукт как Matlab/Stateflow и почитать документацию к нему, чтобы узнать как там строятся автоматы состояний. Узнаете много чего нового.
Ну и советую набросать там свой автомат, промоделировать, а потом сгенерировать Си код для своего, хоть даже 8-и битного микроконтроллера. Писать автоматы состояний на Си после этого больше не захочется. И проблемы со switch-case, глобальными флагами, и событиями исчезнут сами.

Эт точно.
А еще RTOS приносит удачу.

Поностальгирую.
Вот к примеру мой дивайс сделанный на msp430F149C. Напомню, там всего 2К RAM-а!
Нажмите для просмотра прикрепленного файла
Я поставил туда uCOS-II и сделал 5-ть задач.
Это шлюз охранных централей в телефонные и GSM сети способный сам работать как охранная централь.

Дивайс выставлялся на одном стенде с NOKIA на CeBIT в Ганновере.
Дал начало одному из самых успешных наших региональных стартапов.

Не, на единичных экземплярах цена МК не важна. Поэтому STM32.
Промышленные драйверы на десятки киловатт мне собирать не надо, только фотометрами/спектрографами управлять, телескоп двигать, да данные собирать, передавать, обрабатывать и хранить. Ничего сложного.
Ну, иногда какую-нибудь простую железку пореверсить приходится (к сожалению, обычно бывает так: покупает один, а работать это должен заставить другой, и случается, что к протоколам железки не то, чтобы API с исходным кодом, а вообще никакой документации нет; либо есть API, но сильно навороченные и только под мастдайку — тут, конечно, реверсить не надо, но чужой код приходится довольно сильно перелопачивать, чтобы что-то работающее собрать).


Чушь-то какая! Ну вот не надо мне рассказывать, что монохромный дисплей от Nokia долго перерисовывается!
Мы говорили о мобильном телефоне, а не о неведомом монстре. А у мобилки задача: показать на экранчике телефонную книгу/выбрать номер, показать набираемый номер, отобразить принятые смски, дать набрать и отправить смску. Опционально — часы. Но это уже сложно (нужно копать глубже АТ-команд, т.к. для получения времени по GSM они не помогут).

Прямо, Эпиграф к Теме..

Плохой пример. Слишком элементарная железка, чтобы хвастаться необходимостью установки туда ртоси. Ее и без ртоси легко забульбенить. И займет это не больше 5-7 тысяч строк кода!

Странный вывод. Все на автоматах делаю уже лет 10, особых трудностей с protothreads не испытывал и не испытываю.
Причины неиспользования ртос просты: индивидуальная работа и законченные железяки невысокой сложности. При том, что кода может быть и много - больше 64к при задействовании всей имеющейся периферии например stm32 - относить сие к "сложным" программам не могу - слишком хорошо все разбивается на части, штатная периферия выполняет штатные задачи, прерывания легчайшие итд итп

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

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

Не напрягайтесь.
Это во-первых музейный экпонат.
Во-вторых проект открытый и были в свое время в SOEL выложены все исходники.
Если не поленитесь, то найдете и сможете увидеть как RTOS реально помогает жить.

И да, все сдел я сам, даже паял.


А я бы советовал зайти там в закладку Robotics System Toolbox -> ROS или Similink RealTime и убедится что роботов и реальное время программируют исключительно с RTOS.
А в Stateflow делают только лабуду типа вкл-выкл.

Так в банальном чипе на базе Cortex-M0 есть скоростные интерфейсы для работы с периферией: SSP, UART, I2S. Это же не зависит от ядра. FPU тоже никем не удивишь: технически вы его можете хоть к AVR прикрутить, если свой камень делаете А MMU вам чем поможет при установки операционной системы?

Тем, что операционная система (я о линуксе говорю, а не о фигне неведомой) без MMU не будет работать!

Эдди, над вами ржёт весь форум!

Все знают, что линукс работает и на без MMU-ушных процах. Он даже на STM32 портирован.
Я имею сертификат о прохождении учебного курса по работе с линуксом на STM32.

А можно поподробнее, что за курс?

https://habrahabr.ru/post/177425/

И я там даже смогу запустить gcc, скомпилировать что-то и запустить многопотоковую задачу?
Ну-ну...
И да, какому ядру хватит оперативки средненького STM32F103?

Я с большим уважением к Вашим постам всегда относился и отношусь. Не понимаю конечно о чем Вы пишите на самом деле, так как не работал с такими системами, но видно что Вы как минимум в теме. И хватит уже о ОС Верим!

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

Есть поле и для своих дивайсов на базе IO-Link. Подключаются через слэйвы EtherCAT и там уже можно творить что хочешь.

Ядром системы будет один ПЛК Omron серии NJ1.
Имеется плагин даже к Matlab, однако.

AlexandrY, плату критиковать или фиг с ней!?

Зря вы про этер кэт.
Тут его НИКТО И НИКОГДА НЕ ЮЗАЛ.
И даже не знают что это такое.
Потому что среди нескольких сотен тысяч тем тема про этар кат всего одна


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

так можно даже до i4040 докатиться


боюсь, что там можно сделать без rtos, без мк и без квази

Вы вообще читали, что такое Robotics System Toolbox или Simulink RealTime?


Оба этих тулбокса - это только надстройки, которые позволяют исполнять модели, сделанные в Simulink(а Stateflow является его частью) на системах реального времени, дополняя эти модели нужными драйверами или как вы называете фреймворками. Сами же алгоритмы управления, как обычно, разрабатываются в Simulink, а автоматы состояний - только в Stateflow.
Про Simulink Realtime вообще смешно - знали бы вы сколько раз ко мне приставали товарищи из Speedgoat... Simulink Realtime работает только с ихним железом и мы одно время даже думали с ними скооперироваться по поводу реализации ихнего реал-тайм движка на нашей системе, но в итоге оказалось, что наша архитектура, которую я описывал, ничуть не хуже. Только Host/Target Communication у нас пока еще нет, а у них есть.

Вас это удивляет? В Matlab есть генератор кода IEC 61131-3 - Simulink PLC Coder из моделей. Такой же как и для Си.



Ну будет второй человек после меня.
У меня в ближайших планах сделать тестовый стенд для моделирования внешних сигналов при приемочных испытаниях устройств - а-ля симулятор реальной среды.
Будет на Малине + Codesys + EtherCAT. Там реал-тайм не обещают пока, но джиттер и так в районе 50мкс, Вебвизуализация, протоколы типа Modbus, CANopen, логи, отладка и прочее присутствуют, и все это за смешные 50€ - очень дешевый контроллер со всеми плюшками получается.

Очень странно вы пишите. Давно-то Matlab открывали?

Simulink Real-Time работает на любом PC совместимом компьютере с DOS.
Он туда грузит специальную RTOS называемую Simulink Real-Time kernel.
Speedgoat да они упоминаю, но посмотрите всю палитру блоков Simulink Real-Time, там даже есть карты от National Instruments, их конкурентов.

Stateflow не часть Simulink-а, а только один из его тулбоксов.
Все тулбоксы имеют в себе блоки с оригинальными алгоритмами, потому они и ценны, вне связи с матлабом. А вот Stateflow пустышка.


Давайте, критикуйте если это будет не скучно.

Почему? Контексты не будет переключать? Межсервисное взаимодействие будет отсутствовать? И что вы понимаете под "фигнёй?"

Ну, я просто не представляю себе, как это будет работать. malloc/free на статическом массиве? А параллельные задачи на многоядерных системах — как синхронизировать (правда, здесь уже не совсем к mmu вопрос)?
А под фигней я понимаю всяких кастратов вроде микрортосей и uClinux'ов.

Причем тут malloc, статический массив, и все остальное?

Ну как без mmu каждой задаче выделить свой блок памяти, чтобы не было конфликтов?

Ну вот установили Вы Simulink Real-Time на свою target машину или робота. А дальше что? Как вы собираетесь для нее алгоритмы программировать?
Вот картинка тулбокса Simulink Real-time. Вы видите в нем "оригинальные алгоритмы", чтобы чем-то управлять?

По поводу пустышки советую заглянуть в Examples. Различные Automotive и Redundancy примеры там не просто так, а скопированы из живых реализаций.
У нас в проекте в Stateflow крутится наверное под сотню автоматов состояний, начиная от простой логики для устранения дребезга контактов и всяких Do Not Beleive It обработок, до менеджмента аварийных ситуаций и выбора режимов работы. Stateflow как раз задает состояние контроллера в той или иной ситуации и подает сигналы на Симулинковские модели, активируя и деактивируя нужные подсистемы.

Да без проблем! Гляньте исходный код этих функций


Батенька, да вы всё перемешали в кучу Что делает malloc? Предоставляет вам указатель на память запрошенного размера. Ну, как вы эту память получите (выделите) дело десятое. Алгоритмов выделения - море. MMU вам только поможет склеить память в одно линейное пространство из разбросанных кусков, да сгенерит исключение, если кто-то захочет попортить её.
Ещё раз: посмотрите исходники аллокаторов. Их море. Хотябы в тойже "недоси" FreeRTOS. Их там 4 штуки (всего 5, но одна просто обёртка над "стандартными").


Вы такую фигню сначала создайте сами. Или даже попроще, что-то на подобии scmRTOS, FreeRTOS, us/OS. А потом посмотрим, сможете ли назвать это "фигней", т.к. поймёте, что там не два пальца об... а вполне себе теория, по которой книжки написаны

Вот алгоритмы -
Нажмите для просмотра прикрепленного файла

Собственно из-за них matlab и нужен.

Мелкие функций типа подавления дребезга я реализую в блоках S-function на C-и.
А использовать Stateflow для такой ерунды вас заставляет скорее всего корпоративные правила.
Но это неэффективная потеря времени.

Мне и так нужно за год столько понаписать, что думаю — на что бы такое забить!
А уж нафиг не нужную неведомую фигню писать — так вообще смысла нет! Мне ртось не нужна.

Ну знаете я был у истоков запуска матлаба/симулинка/стейтфлоу в нашей далеко не самой мелкой фирме, которая является номером 3 на рынке HVDC/FACTS, если это что-то говорит вам о сложности программ.
По результатам запуска у нас сократилось время программирования тестирования и отладки логики и управляющих алгоритмов на 50% по сравнению с Си-кодингом + позволило убрать данный этап вообще из разработки, значительно сократив количество привносимых ошибок. Т.е. дизайнер алгоритма фактически является автором и Си-кода, хотя последний он даже не учил.

Ну а у меня для этого вообще не нужен Си-программист.

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

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

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

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


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

По моему вы просто не понимаете, что такое mmu и как работает malloc.

Так Буратино правильно и сказал - "Сложные люди". В данной теме есть несколько людей которые пишут свои программы сами - от начала и до конца. И полностью отвечают за их разработку. Таким людям не нужны системы контроля версий и баг треккеры и вообще лучше, чтобы никто не мешал - это такие одиночки. У них есть свой определенный стиль и сложившиеся подходы к разработке своего ПО. Я знаю, я сам таким был.
Но проблема в том, что начиная с определенных размеров проекта в одиночку проект не поднять никак. Нужно разделять работу между разными людьми (и у каждого свой подход) и в конце концов их направлять в нужное русло, чтобы они там не напилили бог знает что.
И вот тут приходит понимание и SVN и баг-трекеров и самое главное, что начинаешь понимать и свои ошибки в прошлом, как одиночника. Вспоминаешь, как днями в одиночку крутил танцы с бубнами вокруг своего же софта, пытаясь заставить его работать, а теперь понимаешь, сколько времени терял впустую - сейчас я ни одному своему программисту такого просто не позволяю. Также начинаешь понимать, что есть продукты, которые действительно значительно повышают производительность труда и уменьшают вероятность ошибок, а есть и такие, что нет. В одиночку такие вещи даже и не узнать, так как времени на обучение попросту нет, ведь "Индивидуальные разработчики работают гораздо быстрее", а заставить кого-либо позаниматься и поизучать продукт - индивидуальному разработчику попросту некого.
Вот сидит мне AlexandrY и доказывает, что Матлаб/Симулинк - это фигня для эмбеддера, а я прихожу на совещания MAAB и общаюсь там с чуваком, который говорит, что у БМВ что-то вроде 150 лицензий на Embedded Coder, и думаю WTF? И думаете они там на 8-и битных контроллерах не программируют?

Ну чтож, выбор за вами. Словам "нафиг" и "фигня" говорят сами за себя: Пастернака не читал, но осуждаю)