Пришел байт, в прерывании добавляем его в очередь, потом хоть в твоем любимом суперлупе данные потихоньку обрабатываем не боясь оттуда вызывать относительно ресурсоемкие задачи, главное чтобы буфер не переполнился. А какой толк от добавления в очередь(регистрации события) при поллинге, если это делается чтобы не терялись данные во время поллинга?
STM32 новичку в ARM что к чему
Re: STM32 новичку в ARM что к чему
[uquote="a5021",url="/forum/viewtopic.php?p=3448173#p3448173"]Еще раз медленно и печально -- независимо от того, как регистрируются события, через поллинг ли или через прерывания, последующая обработка этих событий все равно потребует очередей, семафоров, планировщика и прочих атрибутов многозадачности. Не уйти от этого.[/uquote]
Пришел байт, в прерывании добавляем его в очередь, потом хоть в твоем любимом суперлупе данные потихоньку обрабатываем не боясь оттуда вызывать относительно ресурсоемкие задачи, главное чтобы буфер не переполнился. А какой толк от добавления в очередь(регистрации события) при поллинге, если это делается чтобы не терялись данные во время поллинга?
Пришел байт, в прерывании добавляем его в очередь, потом хоть в твоем любимом суперлупе данные потихоньку обрабатываем не боясь оттуда вызывать относительно ресурсоемкие задачи, главное чтобы буфер не переполнился. А какой толк от добавления в очередь(регистрации события) при поллинге, если это делается чтобы не терялись данные во время поллинга?
- Реклама
Re: STM32 новичку в ARM что к чему
[uquote="Reflector",url="/forum/viewtopic.php?p=3448181#p3448181"]Пришел байт, в прерывании добавляем его в очередь, потом хоть в твоем любимом суперлупе данные потихоньку обрабатываем[/uquote]
Не "хоть в твоем любимом", а только в нем и получится. Оставшийся вариант -- это 1мс в обработчике сидеть. Вижу, что вы готовы и такой подход рассматривать.
А вообще, конечно, отрадно, что хотя бь после троекратных разжовываний по буквам и только на вторые сутки, но и до вас таки дошло, что вариант может работать.
Не "хоть в твоем любимом", а только в нем и получится. Оставшийся вариант -- это 1мс в обработчике сидеть. Вижу, что вы готовы и такой подход рассматривать.
А вообще, конечно, отрадно, что хотя бь после троекратных разжовываний по буквам и только на вторые сутки, но и до вас таки дошло, что вариант может работать.
Вы либо глобально что-то не догоняете, либо с русским у вас все-таки проблемы. То, что вы только что изрекли, по правилам русского языка законченной мыслью являться не может.А какой толк от добавления в очередь(регистрации события) при поллинге, если это делается чтобы не терялись данные во время поллинга?
Последний раз редактировалось a5021 Сб сен 01, 2018 15:19:12, всего редактировалось 1 раз.
Re: Re:
[uquote="a5021",url="/forum/viewtopic.php?p=3448147#p3448147"]В десяти строках вы так и не смогли увидеть, что верхние обработчики имеют более низкую латентность, чем нижние.[/uquote]
Вобщем с вами всё ясно - это не лечится.
Вобщем с вами всё ясно - это не лечится.
Re: STM32 новичку в ARM что к чему
Понты и тухляк ваше жизненное кредо?
Re: STM32 новичку в ARM что к чему
[uquote="a5021",url="/forum/viewtopic.php?p=3448192#p3448192"]Не "хоть в твоем любимом", а только в нем и получится. Оставшийся вариант -- это 1мс в обработчике сидеть. Вижу, что вы готовы и такой подход рассматривать.[/uquote]
Конечно готов, я же не фанатик утверждающий, что прерывания вообще не нужны кроме, как в немногочисленных случаях специально сконструированных программ.
Конечно готов, я же не фанатик утверждающий, что прерывания вообще не нужны кроме, как в немногочисленных случаях специально сконструированных программ.
Данные добавляются в очередь в прерывании чтобы они не терялись при полинге, это понятно? А если добавлять их в очередь при поллинге, который сам является причиной того, что данные теряются, то они будут теряться при добавлении, что делает саму затею достаточно бессмысленной. Это был комментарий к твоим словам о том, что независимо от того регистрируются ли события через поллинг или прерывания, последующая обработка этих событий все равно потребует очередей и т.д.... И где тут "независимость"? Очередь с прерываниям позволяет легко решить мою задачу, с которой все началось, хотя очередь там совсем не обязательна, можно большую часть байт обработать прямо в прерывании, все равно есть приоритеты, а в случае необходимости выполнения тяжелой задачи выставить флаг. А очередь с поллингом - это усложнение не несущее особой выгоды.Вы либо глобально что-то не догоняете, либо с русским у вас все-таки проблемы. То, что вы только что изрекли, по правилам русского языка законченной мыслью являться не может.
- Реклама
- Аlex
- Модератор
- Сообщения: 4614
- Зарегистрирован: Чт мар 18, 2010 23:09:57
- Откуда: Планета Земля
- Контактная информация:
Re: STM32 новичку в ARM что к чему
[uquote="pvit",url="/forum/viewtopic.php?p=3448178#p3448178"]У меня на проекте программисты менялись без проблем. Это нормально, если человек через 2-4 года хочет сменить работу и заняться чем-то новым.[/uquote] Это далеко не нормально. Если для Вас нормально, что на вашем предприятии меняются специалисты раз в 2 года без всяких проблем - грош цена вашему предприятию, вместе с Вами...
[uquote="pvit",url="/forum/viewtopic.php?p=3448178#p3448178"]А вы можете продолжать гордиться, что у вас на предприятии есть "незаменимые специалисты", без которых все встанет раком.[/uquote] Отвечу взаимностью. Продолжайте гордиться тем, что у вас по 3 "программиста" быдлокодят поллингом в суперлупе программу для одного проца лишь для того, чтобы потом отдать на просмотр другим трём долбаёбам, отсеивающие программы по "мне не нравится этот кусок кода"...

[uquote="pvit",url="/forum/viewtopic.php?p=3448178#p3448178"]А вы можете продолжать гордиться, что у вас на предприятии есть "незаменимые специалисты", без которых все встанет раком.[/uquote] Отвечу взаимностью. Продолжайте гордиться тем, что у вас по 3 "программиста" быдлокодят поллингом в суперлупе программу для одного проца лишь для того, чтобы потом отдать на просмотр другим трём долбаёбам, отсеивающие программы по "мне не нравится этот кусок кода"...
Re: STM32 новичку в ARM что к чему
[uquote="Reflector",url="/forum/viewtopic.php?p=3448226#p3448226"]Конечно готов, я же не фанатик утверждающий, что прерывания вообще не нужны кроме, как в немногочисленных случаях специально сконструированных программ.[/uquote]
Ну это, я думаю, поправимо. Раз через сутки вы все-таки разглядели в полинге признаки рационального содержания, то и из группы "слесари и сварщики изучают ардуино" вас так же можно попробовать вытащить.
Ну это, я думаю, поправимо. Раз через сутки вы все-таки разглядели в полинге признаки рационального содержания, то и из группы "слесари и сварщики изучают ардуино" вас так же можно попробовать вытащить.
Ошеломительный в своей первобытной естественности бред. Получается, что вы просто не читаете, что я вам пишу, а только толкаете тут порожняк каждый раз одинаковым образом. Расклады про прием с двух последовательных портов (по 921600 бод каждый) двумя самыми "латентными" обработчиками (9-м и 10м) я уже давал. Там ничего не теряется и времени вагон в запасе. Не теряется, понимаете? Сколько раз вам еще это объяснить?Данные добавляются в очередь в прерывании чтобы они не терялись при полинге, это понятно? А если добавлять их в очередь при поллинге, который сам является причиной того, что данные теряются, то они будут теряться при добавлении, что делает саму затею достаточно бессмысленной.
Для сварщика, решившего заняться изучением ардуины? Несомненно. Но начинайте все-таки двигаться дальше.А очередь с поллингом - это усложнение не несущее особой выгоды.
Re: STM32 новичку в ARM что к чему
[uquote="Аlex",url="/forum/viewtopic.php?p=3448235#p3448235"]Это далеко не нормально. Если для Вас нормально, что на вашем предприятии меняются специалисты раз в 2 года без всяких проблем - грош цена вашему предприятию, вместе с Вами...[/uquote]
Прям день открытий, оказывается стабильный процесс разработки это не нормально. И, очень аргументированно, да.
[uquote="Аlex",url="/forum/viewtopic.php?p=3448235#p3448235"]Отвечу взаимностью. Продолжайте гордиться тем, что у вас по 3 "программиста" быдлокодят поллингом в суперлупе программу для одного проца лишь для того, чтобы потом отдать на просмотр другим трём долбаёбам, отсеивающие программы по "мне не нравится этот кусок кода"...
[/uquote]
Ну я понимаю, что современная разработка для вас пустой звук, но зачем врать-то и приписывать мне суперлупы? Примите разупорин уже.
Прям день открытий, оказывается стабильный процесс разработки это не нормально. И, очень аргументированно, да.
[uquote="Аlex",url="/forum/viewtopic.php?p=3448235#p3448235"]Отвечу взаимностью. Продолжайте гордиться тем, что у вас по 3 "программиста" быдлокодят поллингом в суперлупе программу для одного проца лишь для того, чтобы потом отдать на просмотр другим трём долбаёбам, отсеивающие программы по "мне не нравится этот кусок кода"...
Ну я понимаю, что современная разработка для вас пустой звук, но зачем врать-то и приписывать мне суперлупы? Примите разупорин уже.
Re: STM32 новичку в ARM что к чему
[uquote="pvit",url="/forum/viewtopic.php?p=3448256#p3448256"]Ну я понимаю, что современная разработка для вас пустой звук[/uquote]
А для вас это какой звук? Я понимаю, если бы вы про скрам и эжайл тут загибали. Это хотя бы в тренде. Так вы же про то, что качество кода не должно с квалификацией соотноситься, задвигаете. Вот, в чем дикость.
А для вас это какой звук? Я понимаю, если бы вы про скрам и эжайл тут загибали. Это хотя бы в тренде. Так вы же про то, что качество кода не должно с квалификацией соотноситься, задвигаете. Вот, в чем дикость.
Re: STM32 новичку в ARM что к чему
[uquote="a5021",url="/forum/viewtopic.php?p=3448265#p3448265"]А для вас это какой звук? Я понимаю, если бы вы про скрам и эжайл тут загибали. Это хотя бы в тренде. Так вы же про то, что качество кода не должно с квалификацией соотноситься, задвигаете. Вот, в чем дикость.[/uquote]
А смысл баззводдами кидаться? Я давал ссылки на гиттхаб. Если есть желание проверить, вместо того чтобы голой харизмой давить - никто не мешает полазать по репам в организациях, которые видны на моем аккаунте. Коммиты идут каждый день (без толстых задач), все ревьючится, травис прикручен почти везде. Ну называйте агилем, если вам так ближе, не вопрос.
Про качество я говорил, что код не стоит писать так, чтобы его мог понять только профессор. Таки да, это один из показателей качества, когда речь о совместной разработке. Если пилить код в одно жало и никому не показывать - можно на многое спокойно забить. Потом, если с вами что-то случиться, это все равно уже будет не ваша проблема
А смысл баззводдами кидаться? Я давал ссылки на гиттхаб. Если есть желание проверить, вместо того чтобы голой харизмой давить - никто не мешает полазать по репам в организациях, которые видны на моем аккаунте. Коммиты идут каждый день (без толстых задач), все ревьючится, травис прикручен почти везде. Ну называйте агилем, если вам так ближе, не вопрос.
Про качество я говорил, что код не стоит писать так, чтобы его мог понять только профессор. Таки да, это один из показателей качества, когда речь о совместной разработке. Если пилить код в одно жало и никому не показывать - можно на многое спокойно забить. Потом, если с вами что-то случиться, это все равно уже будет не ваша проблема
Re: STM32 новичку в ARM что к чему
[uquote="pvit",url="/forum/viewtopic.php?p=3448274#p3448274"]Про качество я говорил, что код не стоит писать так, чтобы его мог понять только профессор.[/uquote]
Нет такого показателя, как профессорочитабельность. Вы опять выдумываете какую-то чепуху на ходу. Квалификация, от которой по вашим представлениям не должен зависеть код, как раз больше всего и располагает к тому, чтобы код был простым, понятным и эффективным. Квалификация выше -- код качественнее. Прямая зависимость. Вы же говорите, что никакой зависимости от квалификации не должно быть. Зачепушились окончательно.
Нет такого показателя, как профессорочитабельность. Вы опять выдумываете какую-то чепуху на ходу. Квалификация, от которой по вашим представлениям не должен зависеть код, как раз больше всего и располагает к тому, чтобы код был простым, понятным и эффективным. Квалификация выше -- код качественнее. Прямая зависимость. Вы же говорите, что никакой зависимости от квалификации не должно быть. Зачепушились окончательно.
Re: STM32 новичку в ARM что к чему
Сорри, перепутал, мне показалось что Alex спрашивал. А вам я уже объяснял тут https://radiokot.ru/forum/viewtopic.php ... 6#p3447926. В очередной раз тратить вагон времени на метание бисера ради пары плевков в ответ мне не интересно. Пишите свои суперлупы и будьте счастливы. Это ваш уровень, и больше вам ничего не надо, вы очень убедительно это объяснили.
Re: STM32 новичку в ARM что к чему
И опять тупейший наезд без единого аргумента. Остается вас только поздравить с очередным обсёром.
Re: STM32 новичку в ARM что к чему
[uquote="a5021",url="/forum/viewtopic.php?p=3448349#p3448349"]И опять тупейший наезд без единого аргумента. Остается вас только поздравить с очередным обсёром.[/uquote]
Вы уже сумели наконец-то подсчитать латентность обработки событий в Вашем же шедевре? (позволю напомнить его ниже):
Или до сих пор затрудняетесь?
Может попросите помощи у зала? Кто из здесь присутствующих как думает - какова максимальная латентность обслуживания скажем - события со строчки /* 1 */?
Поможем всем миром сирым и убогим адептам суперлупа!
Я вот считаю, что максимальная латентность обслуживания любого события в этом шедевре - одинакова для всех событий (если для простоты пренебречь содержимым строчек начинающихся с //...) и равна (примерно) времени выполнения всего этого цикла. Хоть для события /* 1 */, хоть для события /* 10 */ - один фиг.
Но адепты секты Пресвятого Суперлупа уже предали меня анафеме за еретические мысли!
Вы уже сумели наконец-то подсчитать латентность обработки событий в Вашем же шедевре? (позволю напомнить его ниже):
Спойлер
Код: Выделить всё
for (;;) {
while (DEFAULT_ISPR_STATE == NVIC->ISPR[0]) {
//
}
/* 1 */ if (NVIC_GetPendingIRQ(DMA1_Channel2_3_IRQn)) {
// SPI1 data arrived
NVIC_ClearPendingIRQ(DMA1_Channel2_3_IRQn);
// ...
continue;
/* 2 */ } else if (NVIC_GetPendingIRQ(DMA1_Channel4_5_IRQn)) {
// USART1 data arrived
NVIC_ClearPendingIRQ(DMA1_Channel4_5_IRQn);
// ...
continue;
/* 3 */ } else if (NVIC_GetPendingIRQ(DMA1_Channel1_IRQn)) {
NVIC_ClearPendingIRQ(DMA1_Channel1_IRQn);
// ...
continue;
/* 4 */ } else if (NVIC_GetPendingIRQ(I2C2_IRQn)) {
NVIC_ClearPendingIRQ(I2C2_IRQn);
// ...
continue;
/* 5 */ } else if (NVIC_GetPendingIRQ(I2C1_IRQn)) {
NVIC_ClearPendingIRQ(I2C1_IRQn);
// ...
continue;
/* 6 */ } else if (NVIC_GetPendingIRQ(TIM16_IRQn)) {
NVIC_ClearPendingIRQ(TIM16_IRQn);
// ...
continue;
/* 7 */ } else if (NVIC_GetPendingIRQ(ADC1_IRQn)) {
NVIC_ClearPendingIRQ(ADC1_IRQn);
// ...
continue;
/* 8 */ } else if (NVIC_GetPendingIRQ(EXTI0_1_IRQn)) {
NVIC_ClearPendingIRQ(EXTI0_1_IRQn);
// ...
continue;
/* 9 */ } else if (NVIC_GetPendingIRQ(TIM1_BRK_UP_TRG_COM_IRQn )) {
NVIC_ClearPendingIRQ(TIM1_BRK_UP_TRG_COM_IRQn );
// ...
continue;
/* 10 */ } else if (NVIC_GetPendingIRQ(RTC_IRQn)) {
NVIC_ClearPendingIRQ(RTC_IRQn);
// ...
}
}Может попросите помощи у зала? Кто из здесь присутствующих как думает - какова максимальная латентность обслуживания скажем - события со строчки /* 1 */?
Поможем всем миром сирым и убогим адептам суперлупа!
Я вот считаю, что максимальная латентность обслуживания любого события в этом шедевре - одинакова для всех событий (если для простоты пренебречь содержимым строчек начинающихся с //...) и равна (примерно) времени выполнения всего этого цикла. Хоть для события /* 1 */, хоть для события /* 10 */ - один фиг.
Но адепты секты Пресвятого Суперлупа уже предали меня анафеме за еретические мысли!
Re: STM32 новичку в ARM что к чему
Когда я просил вас показать мне ваш мега-обработчик, вы мне что ответили? Вот и вам туда же.
Если кому-то вопрос латентности тоже покажется интересным, то говорить надо не о максимальном времени, а скорее о лучшем и худшем случае. В лучшем случае латентность поллинга будет всего несколько тактов, против примерно 24 тактов у обработчика прерывания и бесконечность для обоих в результате наступления худшего случая.
Говоря про 24 такта нужно сделать оговороку, что здесь и дальше их число может отличаться в зависимости от ядра. Цифра означает некую близкую величину, не претендующую на абсолют.
Горе-счетовод, высчитавший "максимальную латентность", неизвестно с какого перепугу просто посчитал частный случай. Причем, можно взять другой частный случай и это время получится даже больше. Больше максимального в системе мер счетовода. Но счетоводу не в первой обсираться, т.ч. наверное даже и внимания не стоит заострять.
Кстати сказать, счетоводческих мозгов видимо не хватило на то, чтобы прикинуть столь же неблагоприятный частный случай для прерываний. Речь идет о возвращении из обработчика прерывания, которому "посчастливилось" случиться на пол-такта позже, чем прерыванию с более высоким приоритетом. Тогда более приоритетное прерывание вернет управление через 24 такта и еще столько же уйдет на обслуживание того, латентность которого замеряется. Итого 48 тактов, без учета времени выполнения кода в обработчиках. Дофига, надо заметить. Поллинг при дуплете двух самых приоритетных событий отработает за чуть больше десятка тактов. Выводы очевидны.
Если кому-то вопрос латентности тоже покажется интересным, то говорить надо не о максимальном времени, а скорее о лучшем и худшем случае. В лучшем случае латентность поллинга будет всего несколько тактов, против примерно 24 тактов у обработчика прерывания и бесконечность для обоих в результате наступления худшего случая.
Говоря про 24 такта нужно сделать оговороку, что здесь и дальше их число может отличаться в зависимости от ядра. Цифра означает некую близкую величину, не претендующую на абсолют.
Горе-счетовод, высчитавший "максимальную латентность", неизвестно с какого перепугу просто посчитал частный случай. Причем, можно взять другой частный случай и это время получится даже больше. Больше максимального в системе мер счетовода. Но счетоводу не в первой обсираться, т.ч. наверное даже и внимания не стоит заострять.
Кстати сказать, счетоводческих мозгов видимо не хватило на то, чтобы прикинуть столь же неблагоприятный частный случай для прерываний. Речь идет о возвращении из обработчика прерывания, которому "посчастливилось" случиться на пол-такта позже, чем прерыванию с более высоким приоритетом. Тогда более приоритетное прерывание вернет управление через 24 такта и еще столько же уйдет на обслуживание того, латентность которого замеряется. Итого 48 тактов, без учета времени выполнения кода в обработчиках. Дофига, надо заметить. Поллинг при дуплете двух самых приоритетных событий отработает за чуть больше десятка тактов. Выводы очевидны.
- Ярослав555
- Поставщик валерьянки для Кота
- Сообщения: 2081
- Зарегистрирован: Пт май 31, 2013 17:14:38
- Откуда: Украина, Винница
Re: STM32 новичку в ARM что к чему
[uquote="Reflector",url="/forum/viewtopic.php?p=3448226#p3448226"][uquote="a5021",url="/forum/viewtopic.php?p=3448192#p3448192"]Не "хоть в твоем любимом", а только в нем и получится. Оставшийся вариант -- это 1мс в обработчике сидеть. Вижу, что вы готовы и такой подход рассматривать.[/uquote]
Конечно готов, я же не фанатик утверждающий, что прерывания вообще не нужны кроме, как в немногочисленных случаях специально сконструированных программ.[/uquote]
У меня пром устройства крутятся на прерываниях и системном таймере, а главный цикл пустой вообще.
Добавлено after 4 minutes 1 second:
Есть критичные задачи - их вешаю на таймер с высоким приоритетом, который тикает каждые несколько мС. Остальное не критичное к времени раскидываю на разные софтверные системные таймеры, которые крутятся от одного железного с более низким приоритетом. А потом на тестах смотрю успевают ли все задачи.
Конечно готов, я же не фанатик утверждающий, что прерывания вообще не нужны кроме, как в немногочисленных случаях специально сконструированных программ.[/uquote]
У меня пром устройства крутятся на прерываниях и системном таймере, а главный цикл пустой вообще.
Добавлено after 4 minutes 1 second:
Есть критичные задачи - их вешаю на таймер с высоким приоритетом, который тикает каждые несколько мС. Остальное не критичное к времени раскидываю на разные софтверные системные таймеры, которые крутятся от одного железного с более низким приоритетом. А потом на тестах смотрю успевают ли все задачи.
Re: STM32 новичку в ARM что к чему
[uquote="a5021",url="/forum/viewtopic.php?p=3448383#p3448383"]Кстати сказать, счетоводческих мозгов видимо не хватило на то, чтобы прикинуть столь же неблагоприятный частный случай для прерываний. Речь идет о возвращении из обработчика прерывания, которому "посчастливилось" случиться на пол-такта позже, чем прерыванию с более высоким приоритетом. Тогда более приоритетное прерывание вернет управление через 24 такта и еще столько же уйдет на обслуживание того, латентность которого замеряется. Итого 48 тактов, без учета времени выполнения кода в обработчиках. Дофига, надо заметить. Поллинг при дуплете двух самых приоритетных событий отработает за чуть больше десятка тактов. Выводы очевидны.[/uquote]
Никаких 48 тактов тут не будет. После выхода из первого прерывания из стека не будут удаляться сохраненные регистры, соответственно они не будут и заново сохранятся для второго прерывания, итого от 24 тактов останется 6, суммарно 30.

Касательно твоих замечательно работающих комов на скорости 921600 бод... А чему там тормозить? На такой скорости байты приходят каждые 8.7 us, добавь туда задачу длительностью 1ms и посчитай на сколько частей ее придется разделить, чтобы не терялись данные. Наверно сотни на две, а это и дополнительные расходы на само дробление, и после каждого из заходов будут опрашиваться флаги, возможно все, возможно суммарное число лишних проверяемых флагов достигнет нескольких тысяч. А еще попробуй любую задачу разбить на нужное количество частей... Вот создал я массив на 20 значений отсортированных в обратном порядке, вызвал стандартный sort, он отрабовал за 16 us, это больше 8.7 us, нужно сортировку выполнить захода за 3, как это сделать?
Никаких 48 тактов тут не будет. После выхода из первого прерывания из стека не будут удаляться сохраненные регистры, соответственно они не будут и заново сохранятся для второго прерывания, итого от 24 тактов останется 6, суммарно 30.

Касательно твоих замечательно работающих комов на скорости 921600 бод... А чему там тормозить? На такой скорости байты приходят каждые 8.7 us, добавь туда задачу длительностью 1ms и посчитай на сколько частей ее придется разделить, чтобы не терялись данные. Наверно сотни на две, а это и дополнительные расходы на само дробление, и после каждого из заходов будут опрашиваться флаги, возможно все, возможно суммарное число лишних проверяемых флагов достигнет нескольких тысяч. А еще попробуй любую задачу разбить на нужное количество частей... Вот создал я массив на 20 значений отсортированных в обратном порядке, вызвал стандартный sort, он отрабовал за 16 us, это больше 8.7 us, нужно сортировку выполнить захода за 3, как это сделать?
Re: STM32 новичку в ARM что к чему
[uquote="a5021",url="/forum/viewtopic.php?p=3448383#p3448383"]Если кому-то вопрос латентности тоже покажется интересным, то говорить надо не о максимальном времени, а скорее о лучшем и худшем случае.[/uquote]
Очередной бред. Ну да - в лучшем случае - 4 такта, а в худшем - 400 тактов. В лучшем случае - устройство будет работать, а в худшем - будет терять данные. Сейчас - работает, через миллисекунду - глючит, ну что-ж - так звёзды сложились.
Важнейшее значение имеет максимальная латентность, так как от неё зависит - успеет ли программа выгрести и обработать данные из периферии или потеряет их. То что она будет терять их не всегда, а только иногда - не спасёт такой девайс от выброса в помойку, а его автора - от закономерного увольнения.
[uquote="a5021",url="/forum/viewtopic.php?p=3448383#p3448383"]Горе-счетовод, высчитавший "максимальную латентность", неизвестно с какого перепугу просто посчитал частный случай.[/uquote]
тут похоже до фанатичного адепта суперлупа наконец то стала доходить одна из проблем его обожаемого метода.
[uquote="a5021",url="/forum/viewtopic.php?p=3448383#p3448383"]Кстати сказать, счетоводческих мозгов видимо не хватило на то, чтобы прикинуть столь же неблагоприятный частный случай для прерываний.[/uquote]
Если б у Вас были хотя бы зачатки мозга, вы смогли бы осилить понятие "Tail-chaining" из мануала на Cortex-M в который Вы всех тут неоднократно посылали.
И не несли бы очередной вздор.
Очередной бред. Ну да - в лучшем случае - 4 такта, а в худшем - 400 тактов. В лучшем случае - устройство будет работать, а в худшем - будет терять данные. Сейчас - работает, через миллисекунду - глючит, ну что-ж - так звёзды сложились.
Важнейшее значение имеет максимальная латентность, так как от неё зависит - успеет ли программа выгрести и обработать данные из периферии или потеряет их. То что она будет терять их не всегда, а только иногда - не спасёт такой девайс от выброса в помойку, а его автора - от закономерного увольнения.
[uquote="a5021",url="/forum/viewtopic.php?p=3448383#p3448383"]Горе-счетовод, высчитавший "максимальную латентность", неизвестно с какого перепугу просто посчитал частный случай.[/uquote]
тут похоже до фанатичного адепта суперлупа наконец то стала доходить одна из проблем его обожаемого метода.
[uquote="a5021",url="/forum/viewtopic.php?p=3448383#p3448383"]Кстати сказать, счетоводческих мозгов видимо не хватило на то, чтобы прикинуть столь же неблагоприятный частный случай для прерываний.[/uquote]
Если б у Вас были хотя бы зачатки мозга, вы смогли бы осилить понятие "Tail-chaining" из мануала на Cortex-M в который Вы всех тут неоднократно посылали.
И не несли бы очередной вздор.
Re: STM32 новичку в ARM что к чему
[uquote="Reflector",url="/forum/viewtopic.php?p=3448620#p3448620"]Никаких 48 тактов тут не будет. После выхода из первого прерывания из стека не будут удаляться сохраненные регистры, соответственно они не будут и заново сохранятся для второго прерывания, итого от 24 тактов останется 6, суммарно 30.[/uquote]
Может и 30, может и 64. Cortex-m0, напомню, не умеет Tail-Chaining и вход/выход у него по 16 тактов. Я ж специально в тексте приписку сделал, что число тактов примерное, т.к. имеются варианты.
Добавлено after 9 minutes 48 seconds:
[uquote="jcxz",url="/forum/viewtopic.php?p=3448656#p3448656"]Очередной бред.
[...]
И не несли бы очередной вздор.[/uquote]
Я не увидел в вашем "крике души" возражений по технической части, как и какой-либо конкретики вообще. Свои личные духовные ценности, в любимом вами стиле "визжащие бабы на базаре", обсуждайте без меня.
[uquote="Ярослав555",url="/forum/viewtopic.php?p=3448532#p3448532"]У меня пром устройства крутятся на прерываниях и системном таймере, а главный цикл пустой вообще.[/uquote]
О примерно таком подходе я и говорил, когда упоминал "специально сконструированные". У слушателей курсов "Ардуино для слесарей и сварщиков", однако, упоминание об этом ведет к деструктивным процессам в головном мозге и когнитивным расстройствам. Истерики на этом форуме тому подтверждения.
Interrupt-driven интересен в энергосберегающих режимах, когда прерывания могут вызываться без переключения контекста.
Может и 30, может и 64. Cortex-m0, напомню, не умеет Tail-Chaining и вход/выход у него по 16 тактов. Я ж специально в тексте приписку сделал, что число тактов примерное, т.к. имеются варианты.
У вас замечательно-гибкая позиция. В одно и то же время вы стращаете, что при поллинге события будут теряться, намекая на перегруз, то вдруг наивно спрашиваете, "а чему там тормозить". Примите уже какую-нибудь одну сторону.Касательно твоих замечательно работающих комов на скорости 921600 бод... А чему там тормозить?
Мне нравится, как мои оппоненты старательно выбирают примеры, чтобы на прерываниях оно еще могло как-то работать, а с поллингом уже пришлось бы заморачиваться с планированием подзадач. Я же уже приводил пример с задачами "А", "Б" и "В", где та же самая проблема встает во весь рост и с использованием прерываний. Если с поллингом к такому приходится быть готовым всегда, то вы со своим ардуино-сварщецким подходом, чего делать будете? Плакать и мамку звать?Вот создал я массив на 20 значений отсортированных в обратном порядке, вызвал стандартный sort, он отрабовал за 16 us, это больше 8.7 us, нужно сортировку выполнить захода за 3, как это сделать?
Добавлено after 9 minutes 48 seconds:
[uquote="jcxz",url="/forum/viewtopic.php?p=3448656#p3448656"]Очередной бред.
[...]
И не несли бы очередной вздор.[/uquote]
Я не увидел в вашем "крике души" возражений по технической части, как и какой-либо конкретики вообще. Свои личные духовные ценности, в любимом вами стиле "визжащие бабы на базаре", обсуждайте без меня.
[uquote="Ярослав555",url="/forum/viewtopic.php?p=3448532#p3448532"]У меня пром устройства крутятся на прерываниях и системном таймере, а главный цикл пустой вообще.[/uquote]
О примерно таком подходе я и говорил, когда упоминал "специально сконструированные". У слушателей курсов "Ардуино для слесарей и сварщиков", однако, упоминание об этом ведет к деструктивным процессам в головном мозге и когнитивным расстройствам. Истерики на этом форуме тому подтверждения.
Interrupt-driven интересен в энергосберегающих режимах, когда прерывания могут вызываться без переключения контекста.
Re: STM32 новичку в ARM что к чему
[uquote="a5021",url="/forum/viewtopic.php?p=3448772#p3448772"]Может и 30, может и 64. Cortex-m0, напомню, не умеет Tail-Chaining и вход/выход у него по 16 тактов. Я ж специально в тексте приписку сделал, что число тактов примерное, т.к. имеются варианты.[/uquote]
Отмазка так себе, особенно на фоне того, что конечно M0 умеет Tail-Chaining. Гораздо проще все объясняется тем, что у тебя очень смутные представления об архитектуре используемых мк.
При этом нужно учесть, что к достаточно долго длящейся задаче не предъявляется требований к скорости реакции на прерывания, а именно это самая слабая сторона твоего подхода. А о трех задачах еще и с приоритетами даже говорить странно, конечно это усложнит дело в любом случае, но в самом невыгодном положении окажется тот, у кого проблемы начинаются уже с одной задачей без приоритетов...
Отмазка так себе, особенно на фоне того, что конечно M0 умеет Tail-Chaining. Гораздо проще все объясняется тем, что у тебя очень смутные представления об архитектуре используемых мк.
Я ничего старательно не выбирал, самый первый мой пример был с задачей выполняющейся 1 ms и ты сначала убеждал, что никаких проблем с этим нет, потом оказалось, что задачу нужно выполнять частями, но и с этим никаких проблем, а когда я добавил задачу длящуюся всего 16 us, то оказалось я все примеры старательно подбираю под себяМне нравится, как мои оппоненты старательно выбирают примеры, чтобы на прерываниях оно еще могло как-то работать, а с поллингом уже пришлось бы заморачиваться с планированием подзадач. Я же уже приводил пример с задачами "А", "Б" и "В", где та же самая проблема встает во весь рост и с использованием прерываний. Если с поллингом к такому приходится быть готовым всегда, то вы со своим ардуино-сварщецким подходом, чего делать будете? Плакать и мамку звать?


