Комментарии 18
поток сознания
Тема интересная, но читать такое очень сложно — постоянно возникает ощущение, что переводили автоматическим переводчиком или русский язык для автора не родной. Много ошибок. Пожалуйста, пишите еще на такие темы, но по возможности воспользуйтесь услугами редактора/корректора.
Согласен с критикой, действительно очень редко пишу по-русски. Отсюда ошибки (что-то не так с пунктуацией? орфографию вроде-бы редактор проверил), и печатаю медленно. Единственный способ не разучиться — писать такие топики, наверное.
Было любопытно, интересно ли вообще кому-то читать про то, на сколько микросекунд может задержаться прерывание, чтобы станок не сломался, и как это измерить. Кто этим занимается — и так все знают, а большинству разработчиков, которые занимаются Веб, базами данных, эта информация бесполезна.
Было любопытно, интересно ли вообще кому-то читать про то, на сколько микросекунд может задержаться прерывание, чтобы станок не сломался, и как это измерить. Кто этим занимается — и так все знают, а большинству разработчиков, которые занимаются Веб, базами данных, эта информация бесполезна.
Интересно, но не хватает примеров, особенно уровня «Вася сделал себе для дома realtime и у него всё стало хорошо» ;)
В том-то и дело что _такой_ риалтайм себе для дома делать абсолютно незачем. Так что статья в чистом виде о бесполезном знании.
Если область любопытна, можно, например, скачать по ссылке из поста Twincat и сделать 2 вещи.
1. Измерить, можно ли использовать текущее железо, если вдруг найдется доступ к станкам. Если все ок, можно гордиться.
2. Попробовать написать и запустить какую-нибудь PLC программу, которая правда все равно ничего полезного делать не может, т.к. комп ни к чему не подключен.
Если область любопытна, можно, например, скачать по ссылке из поста Twincat и сделать 2 вещи.
1. Измерить, можно ли использовать текущее железо, если вдруг найдется доступ к станкам. Если все ок, можно гордиться.
2. Попробовать написать и запустить какую-нибудь PLC программу, которая правда все равно ничего полезного делать не может, т.к. комп ни к чему не подключен.
Ваше определение RealTime потрясает новизной!!! А уж «применительно к x86»…
Это не RealTime! Определение RealTime вообще от платформы не зависит. Что х86, что ARM, что RISC…
То что Вы написали кое как тянет на latency. Но это лишь один из параметров. И вовсе не всегда самый важный, имхо.
Существует много систем, где 100 микросекунд задержки вполне допустимы, правда не «раз в неделю»…
Это не RealTime! Определение RealTime вообще от платформы не зависит. Что х86, что ARM, что RISC…
То что Вы написали кое как тянет на latency. Но это лишь один из параметров. И вовсе не всегда самый важный, имхо.
Существует много систем, где 100 микросекунд задержки вполне допустимы, правда не «раз в неделю»…
Отлично, первый коммент по сути статьи, спасибо.
Согласен с Вашим комментом: 1. определение realtime не имеет ничего общего с latency прерывания.
Специально в самом начале написал, что realtime — это «удовлетворение многим критериям». Если брать готовое приложение — то это в трех словах «гарантия времени реакции». 2. Есть много систем, где задержка прерывания в 100 микросекунд допустима.
Но пост о железе E-линейки Атомов, поэтому я взял самую первую latency, которая, если может иногда быть больше некоторого предела, гарантирует бесполезность платформы, вне зависимости от ОС и приложения. Пост был о том, как это измерять, и немного коснулся того, как с этим бороться.
Согласен с Вашим комментом: 1. определение realtime не имеет ничего общего с latency прерывания.
Специально в самом начале написал, что realtime — это «удовлетворение многим критериям». Если брать готовое приложение — то это в трех словах «гарантия времени реакции». 2. Есть много систем, где задержка прерывания в 100 микросекунд допустима.
Но пост о железе E-линейки Атомов, поэтому я взял самую первую latency, которая, если может иногда быть больше некоторого предела, гарантирует бесполезность платформы, вне зависимости от ОС и приложения. Пост был о том, как это измерять, и немного коснулся того, как с этим бороться.
Насчет «interrupt latency — вовсе не всегда самый важный, параметр.»
Мы смотрим с разных сторон — для меня это часто самый важный параметр, т.к. если есть проблема, клиент может выбрать не Intel железо. Поэтому если вдруг кто-то жалуется, что на платформе, которую я поддерживаю, возможно в каких-то условиях непредсказуемое увеличение interrupt latency, то моя самая срочная задача — найти причину и фикс.
Мы смотрим с разных сторон — для меня это часто самый важный параметр, т.к. если есть проблема, клиент может выбрать не Intel железо. Поэтому если вдруг кто-то жалуется, что на платформе, которую я поддерживаю, возможно в каких-то условиях непредсказуемое увеличение interrupt latency, то моя самая срочная задача — найти причину и фикс.
а QNX — где?
Сорри, давно лично не сталкивался. Скорее всего, должна быть. Вписать?
Интересно бы было бы услушать слово Stellarton в этом контексте, а особенно комментарии к этому
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вопросы использования Intel Atom для embedded realtime задач