Сообщение Re[29]: Эльбрус - 8 ядер от 07.06.2017 16:10
Изменено 07.06.2017 19:48 vdimas
Re[29]: Эльбрус - 8 ядер
Здравствуйте, netch80, Вы писали:
V>>Просто в цикле крутишь несколько счетчиков параллельно, при обнулении счетчика выдаёшь сигнал.
N>А некоторые не крутишь, ибо закончились. А код, по твоему варианту, крутит их всех.
Верно, просто где-то слагаемое будет равно 0-лю или соотв. бит будет нулевой, если несколько счетчиков упакованы в одном слове.
V>>Причем, в одном слове можно располагать несколько счетчиков обычно.
N>>>на каждой итерации — неважно)? А как же пункт 1?
V>>Это ты слишком сложные для себя вопросы пока задаешь. ))
N>Это ты не можешь простейший алгоритм в голове уложить, чтобы не ляпнуть по-тупому такое, что смеются не только лишь все (tm).
Тут наоборот — похоже, что я не могу простейший алгоритм объяснить.
V>>>>2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).
N>>>Это же какой контроллер надо подобрать, чтобы он на прерывание реагировал дольше, чем длится 2-3 команды?
V>>Любой, с длиной конвейера больше 2-х, вестимо.
N>Воистину фейспалм — писали контроллеры такие же "спецы", если у них прерывание не может врезаться в конвейер, когда это действительно нужно.
Ага, но ты же коммунист, Петька! — и пулемёт застрочил вновь.
Удивляют порой коллеги верой в мифы и вообще вот этот подход — "оно там как-то само всё образуется".
Да никогда еще ни разу "само собой" ничего не образовалось. Всегда надо включать моск.
N>Хотя им это не нужно — они же поллят и получают ту же проблему с конвейером и без прерываний
Не получают. Фронт может немного "дрожать", но не более, чем получили бы такое дрожание при реакции на самое первое аппаратное прерывание.
Главное, что ошибка такого дрожания задержки затем не накапливается от слова совсем. А если еще задействовать механизм фазовой автоподстройки для этого цикла, так вообще сколь угодно точно можно импульсы выдавать — с точностью фазы до одного nop, т.е. одного такта.
V>>В любом случае, для сценари использования таймера "выдай мне прерывание через столько-то времени" (а там именно такой сценарий) — это будет накопление ошибки, бо обычно у тебя нет никакой информации о том, сколько действительно времени потребовалось на реакцию на таймер. А когда таймеров более одного, ты находишься в обработке прерывания одного из них, прерывания от других запрещены... Дальше продолжать или уже догадался?
N>Двойной фейспалм — вместо таймеров использовать туалетную бумагу, которая не в состоянии показать даже текущее время.
Увы, именно так. Зря ты отказался хотя бы одним глазом взглянуть на даташиты.
Чтобы "показать текущее время" при наличии только 16-тиразрядных таймеров в той же архитектуре STM32 — это надо еще прилично кода вокруг такого таймера городить на ровном месте. И так будешь всё глубже и глубже закапываться в преодоление на каждом шаге очередных граблей, которые сам же решил и разложить перед собой. А ведь можно взять самый простой чип и обойтись программкой в пол-сотни строчек на асме основного цикла (не берем строчки на инициализацию режимов контроллера).
N>Ну и "спец", который рассказал про событие от одного таймера во время прерывания другого, но точно так же забыл про событие от одного таймера во время поллинга группы таймеров, по рецепту этого же "спеца".
Это ты забыл, что циклы у нас имеют фиксированную длительность, т.е. сработал некий софтовый таймер или нет — ничего не изменится, по-сути.
N>Твой образ на RSDN никакого ликбеза провести не в состоянии — ему самому в школу идти надо, с нуля.
Вот поэтому и скучно, что объяснять совсем уж с 0-ля — это надо в школе, а не на этом сайте.
В принципе, тут достаточно было включить воображение или накатать несколько строчек, чтобы прикинуть — как такие циклы могут выглядеть.
Мне вообще странен подобный игнор некоторыми коллегами того факта, что на один современный центральный проц приходится чуть ли не десяток вспомогательных процов в остальных подсистемах их компов. На них программы по-твоему боги пишут? ))
Такие программисты и пишут. Ну разве что у них обязательно наблюдается такая особенность как внимательность к мелочам, в отличие от разработчиков цепочек if-ов для обслуживания протокола SIP, например.
V>>Просто в цикле крутишь несколько счетчиков параллельно, при обнулении счетчика выдаёшь сигнал.
N>А некоторые не крутишь, ибо закончились. А код, по твоему варианту, крутит их всех.
Верно, просто где-то слагаемое будет равно 0-лю или соотв. бит будет нулевой, если несколько счетчиков упакованы в одном слове.
V>>Причем, в одном слове можно располагать несколько счетчиков обычно.
N>>>на каждой итерации — неважно)? А как же пункт 1?
V>>Это ты слишком сложные для себя вопросы пока задаешь. ))
N>Это ты не можешь простейший алгоритм в голове уложить, чтобы не ляпнуть по-тупому такое, что смеются не только лишь все (tm).
Тут наоборот — похоже, что я не могу простейший алгоритм объяснить.
V>>>>2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).
N>>>Это же какой контроллер надо подобрать, чтобы он на прерывание реагировал дольше, чем длится 2-3 команды?
V>>Любой, с длиной конвейера больше 2-х, вестимо.
N>Воистину фейспалм — писали контроллеры такие же "спецы", если у них прерывание не может врезаться в конвейер, когда это действительно нужно.
Ага, но ты же коммунист, Петька! — и пулемёт застрочил вновь.
Удивляют порой коллеги верой в мифы и вообще вот этот подход — "оно там как-то само всё образуется".
Да никогда еще ни разу "само собой" ничего не образовалось. Всегда надо включать моск.
N>Хотя им это не нужно — они же поллят и получают ту же проблему с конвейером и без прерываний
Не получают. Фронт может немного "дрожать", но не более, чем получили бы такое дрожание при реакции на самое первое аппаратное прерывание.
Главное, что ошибка такого дрожания задержки затем не накапливается от слова совсем. А если еще задействовать механизм фазовой автоподстройки для этого цикла, так вообще сколь угодно точно можно импульсы выдавать — с точностью фазы до одного nop, т.е. одного такта.
V>>В любом случае, для сценари использования таймера "выдай мне прерывание через столько-то времени" (а там именно такой сценарий) — это будет накопление ошибки, бо обычно у тебя нет никакой информации о том, сколько действительно времени потребовалось на реакцию на таймер. А когда таймеров более одного, ты находишься в обработке прерывания одного из них, прерывания от других запрещены... Дальше продолжать или уже догадался?
N>Двойной фейспалм — вместо таймеров использовать туалетную бумагу, которая не в состоянии показать даже текущее время.
Увы, именно так. Зря ты отказался хотя бы одним глазом взглянуть на даташиты.
Чтобы "показать текущее время" при наличии только 16-тиразрядных таймеров в той же архитектуре STM32 — это надо еще прилично кода вокруг такого таймера городить на ровном месте. И так будешь всё глубже и глубже закапываться в преодоление на каждом шаге очередных граблей, которые сам же решил и разложить перед собой. А ведь можно взять самый простой чип и обойтись программкой в пол-сотни строчек на асме основного цикла (не берем строчки на инициализацию режимов контроллера).
N>Ну и "спец", который рассказал про событие от одного таймера во время прерывания другого, но точно так же забыл про событие от одного таймера во время поллинга группы таймеров, по рецепту этого же "спеца".
Это ты забыл, что циклы у нас имеют фиксированную длительность, т.е. сработал некий софтовый таймер или нет — ничего не изменится, по-сути.
N>Твой образ на RSDN никакого ликбеза провести не в состоянии — ему самому в школу идти надо, с нуля.
Вот поэтому и скучно, что объяснять совсем уж с 0-ля — это надо в школе, а не на этом сайте.
В принципе, тут достаточно было включить воображение или накатать несколько строчек, чтобы прикинуть — как такие циклы могут выглядеть.
Мне вообще странен подобный игнор некоторыми коллегами того факта, что на один современный центральный проц приходится чуть ли не десяток вспомогательных процов в остальных подсистемах их компов. На них программы по-твоему боги пишут? ))
Такие программисты и пишут. Ну разве что у них обязательно наблюдается такая особенность как внимательность к мелочам, в отличие от разработчиков цепочек if-ов для обслуживания протокола SIP, например.
Re[29]: Эльбрус - 8 ядер
Здравствуйте, netch80, Вы писали:
V>>Просто в цикле крутишь несколько счетчиков параллельно, при обнулении счетчика выдаёшь сигнал.
N>А некоторые не крутишь, ибо закончились. А код, по твоему варианту, крутит их всех.
Верно, просто где-то слагаемое будет равно 0-лю или соотв. бит будет нулевой, если несколько счетчиков упакованы в одном слове.
V>>Причем, в одном слове можно располагать несколько счетчиков обычно.
N>>>на каждой итерации — неважно)? А как же пункт 1?
V>>Это ты слишком сложные для себя вопросы пока задаешь. ))
N>Это ты не можешь простейший алгоритм в голове уложить, чтобы не ляпнуть по-тупому такое, что смеются не только лишь все (tm).
Тут наоборот — похоже, что я не могу простейший алгоритм объяснить.
V>>>>2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).
N>>>Это же какой контроллер надо подобрать, чтобы он на прерывание реагировал дольше, чем длится 2-3 команды?
V>>Любой, с длиной конвейера больше 2-х, вестимо.
N>Воистину фейспалм — писали контроллеры такие же "спецы", если у них прерывание не может врезаться в конвейер, когда это действительно нужно.
Ага, но ты же коммунист, Петька! — и пулемёт застрочил вновь.
Удивляют порой коллеги верой в мифы и вообще вот этот подход — "оно там как-то само всё образуется".
Да никогда еще ни разу "само собой" ничего не образовалось. Всегда надо включать моск.
N>Хотя им это не нужно — они же поллят и получают ту же проблему с конвейером и без прерываний
Не получают. Фронт может немного "дрожать", но не более, чем получили бы такое дрожание при реакции на самое первое аппаратное прерывание.
Главное, что ошибка такого дрожания задержки затем не накапливается от слова совсем. А если еще задействовать механизм фазовой автоподстройки для этого цикла, так вообще сколь угодно точно можно импульсы выдавать — с точностью фазы до одного nop, т.е. одного такта.
V>>В любом случае, для сценари использования таймера "выдай мне прерывание через столько-то времени" (а там именно такой сценарий) — это будет накопление ошибки, бо обычно у тебя нет никакой информации о том, сколько действительно времени потребовалось на реакцию на таймер. А когда таймеров более одного, ты находишься в обработке прерывания одного из них, прерывания от других запрещены... Дальше продолжать или уже догадался?
N>Двойной фейспалм — вместо таймеров использовать туалетную бумагу, которая не в состоянии показать даже текущее время.
Увы, именно так. Зря ты отказался хотя бы одним глазом взглянуть на даташиты.
Чтобы "показать текущее время" при наличии только 16-тиразрядных таймеров в той же архитектуре STM32 — это надо еще прилично кода вокруг такого таймера городить на ровном месте. И так будешь всё глубже и глубже закапываться в преодоление на каждом шаге очередных граблей, которые сам же решил и разложить перед собой. А ведь можно взять самый простой чип и обойтись программкой в пол-сотни строчек на асме основного цикла (не берем строчки на инициализацию режимов контроллера).
N>Ну и "спец", который рассказал про событие от одного таймера во время прерывания другого, но точно так же забыл про событие от одного таймера во время поллинга группы таймеров, по рецепту этого же "спеца".
Это ты забыл, что циклы у нас имеют фиксированную длительность, т.е. сработал некий софтовый таймер или нет — ничего не изменится, по-сути.
N>Твой образ на RSDN никакого ликбеза провести не в состоянии — ему самому в школу идти надо, с нуля.
Вот поэтому и скучно, что объяснять совсем уж с 0-ля — это надо в школе, а не на этом сайте.
В принципе, тут достаточно было включить воображение или накатать несколько строчек, чтобы прикинуть — как такие циклы могут выглядеть.
Мне вообще странен подобный игнор некоторыми коллегами того факта, что на один современный центральный проц приходится чуть ли не десяток вспомогательных процов в остальных подсистемах их компов. На них программы по-твоему боги пишут? ))
Такие же программисты и пишут. Ну разве что у них обязательно наблюдается такая особенность как внимательность к мелочам, в отличие от разработчиков цепочек if-ов для обслуживания протокола SIP, например.
V>>Просто в цикле крутишь несколько счетчиков параллельно, при обнулении счетчика выдаёшь сигнал.
N>А некоторые не крутишь, ибо закончились. А код, по твоему варианту, крутит их всех.
Верно, просто где-то слагаемое будет равно 0-лю или соотв. бит будет нулевой, если несколько счетчиков упакованы в одном слове.
V>>Причем, в одном слове можно располагать несколько счетчиков обычно.
N>>>на каждой итерации — неважно)? А как же пункт 1?
V>>Это ты слишком сложные для себя вопросы пока задаешь. ))
N>Это ты не можешь простейший алгоритм в голове уложить, чтобы не ляпнуть по-тупому такое, что смеются не только лишь все (tm).
Тут наоборот — похоже, что я не могу простейший алгоритм объяснить.
V>>>>2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).
N>>>Это же какой контроллер надо подобрать, чтобы он на прерывание реагировал дольше, чем длится 2-3 команды?
V>>Любой, с длиной конвейера больше 2-х, вестимо.
N>Воистину фейспалм — писали контроллеры такие же "спецы", если у них прерывание не может врезаться в конвейер, когда это действительно нужно.
Ага, но ты же коммунист, Петька! — и пулемёт застрочил вновь.
Удивляют порой коллеги верой в мифы и вообще вот этот подход — "оно там как-то само всё образуется".
Да никогда еще ни разу "само собой" ничего не образовалось. Всегда надо включать моск.
N>Хотя им это не нужно — они же поллят и получают ту же проблему с конвейером и без прерываний
Не получают. Фронт может немного "дрожать", но не более, чем получили бы такое дрожание при реакции на самое первое аппаратное прерывание.
Главное, что ошибка такого дрожания задержки затем не накапливается от слова совсем. А если еще задействовать механизм фазовой автоподстройки для этого цикла, так вообще сколь угодно точно можно импульсы выдавать — с точностью фазы до одного nop, т.е. одного такта.
V>>В любом случае, для сценари использования таймера "выдай мне прерывание через столько-то времени" (а там именно такой сценарий) — это будет накопление ошибки, бо обычно у тебя нет никакой информации о том, сколько действительно времени потребовалось на реакцию на таймер. А когда таймеров более одного, ты находишься в обработке прерывания одного из них, прерывания от других запрещены... Дальше продолжать или уже догадался?
N>Двойной фейспалм — вместо таймеров использовать туалетную бумагу, которая не в состоянии показать даже текущее время.
Увы, именно так. Зря ты отказался хотя бы одним глазом взглянуть на даташиты.
Чтобы "показать текущее время" при наличии только 16-тиразрядных таймеров в той же архитектуре STM32 — это надо еще прилично кода вокруг такого таймера городить на ровном месте. И так будешь всё глубже и глубже закапываться в преодоление на каждом шаге очередных граблей, которые сам же решил и разложить перед собой. А ведь можно взять самый простой чип и обойтись программкой в пол-сотни строчек на асме основного цикла (не берем строчки на инициализацию режимов контроллера).
N>Ну и "спец", который рассказал про событие от одного таймера во время прерывания другого, но точно так же забыл про событие от одного таймера во время поллинга группы таймеров, по рецепту этого же "спеца".
Это ты забыл, что циклы у нас имеют фиксированную длительность, т.е. сработал некий софтовый таймер или нет — ничего не изменится, по-сути.
N>Твой образ на RSDN никакого ликбеза провести не в состоянии — ему самому в школу идти надо, с нуля.
Вот поэтому и скучно, что объяснять совсем уж с 0-ля — это надо в школе, а не на этом сайте.
В принципе, тут достаточно было включить воображение или накатать несколько строчек, чтобы прикинуть — как такие циклы могут выглядеть.
Мне вообще странен подобный игнор некоторыми коллегами того факта, что на один современный центральный проц приходится чуть ли не десяток вспомогательных процов в остальных подсистемах их компов. На них программы по-твоему боги пишут? ))
Такие же программисты и пишут. Ну разве что у них обязательно наблюдается такая особенность как внимательность к мелочам, в отличие от разработчиков цепочек if-ов для обслуживания протокола SIP, например.