-
- Скрипт лишь выделяет секцию. Eddy_Em(124 знак., 27.05.2023 11:48)
- Мне иногда кажется, что ты бредишь... В чем проблема выделения
секции? Зачем скорость при поиске записи? Ты отдаешь себе отчет в
скорости самой записи (времени работы хардварного автомата этой
записи)? Открой даташит на МК и убей себя апстену. ))))) - my504(27.05.2023 19:55)
- При линейном поиске МК грузится две-три секунды, пока сотню кБ
флеша перелопатит с шагом в 32..64Б. Eddy_Em(72 знак., 27.05.2023 21:12)
- Линейном поиске ЧЕГО? Ты сначала напридумываешь всяких глупостей, а
потом решаешь странные проблемы... 100КБ флеша - это 25К шагов
поиска. Делим обозначенные тобой две-три секунды на 25000 и
получаем 80...120 мкс на одно слово. Эдик, ты и впрямь такой идиот
или прикидываешься? У тебя цикл чтения ОДНОГО слова флеша
составляет 5...10 тыс. машинных циклов? - my504(27.05.2023 21:39)
- А с какого перепоя операция чтения из флеша стала бесплатной, как
из ОЗУ? - Eddy_Em(27.05.2023 22:27)
- Минимальное время доступа к флешу составляет примерно 30 нс. Прежде
чем писать очередную свою ахинею, ты бы хоть попробовал посмотреть
осциллографом реальное время перебора флеша при чтении. Обычным
ногодрыгом. Поднял ногу на входе в перебор, опустил на выходе. my504(1 знак., 28.05.2023 04:47, картинка)
- Wait states - это задержка первоначального доступа. При линейном
чтении, за счёт ширины шины доступа к флеш, все последующие адреса
читаются на полной скорости. У вас табличка - latency а не clock
rate. - Nikolay_Po(28.05.2023 10:41)
- Опыт подсказывает, что нет. По крайней мере для кода это не так.
Поэтому при 3WS при реализации функции задержки нопами скорость
падает примерно в 2,3...2,5 раза. Приходится это учитывать
множителем аргумента, чтобы откалибровать 1 мкс. my504(480 знак., 28.05.2023 12:54 - 13:01)
- Вопрос возник в контексте именно линейного чтения. Это в коде с ветвлениями не угадаешь. А при линейном чтении, у STM32 будет полная скорость доступа, по крайней мере до STM32F4 (хотя специально не изучал, лучше перепроверить). У dsPIC да, встречал. Делал фильтры на 33EP. - Nikolay_Po(29.05.2023 09:26)
- Функция задержки нопами? Ужос. Такой грех будет трудно смыть... - SciFi(28.05.2023 12:58)
- Это у вас - троеперстных - грех, а у нас - старообрядцев -
богоугодное деяние. - Kpoк(28.05.2023 13:21)
- +1. Но будем иметь ввиду особенности современных чипов. - Nikolay_Po(29.05.2023 09:27)
- Я реализую на нопах МИКРОсекундные задержки. Например для
формирования строба CS для SPI или подобных вещей. Блокировка кода
практически незаметна. - my504(28.05.2023 13:04)
- Для этого DWT->CYCCNT весьма хорош. - SciFi(28.05.2023 14:57)
- Спасибо! - Nikolay_Po(29.05.2023 09:27)
- Хорош то он хорош, но является фичей STM. По нынешним временам
неактуально. Поэтому альтернативы простому циклу с калибровкой под
архитектуру/проект не видно. - my504(28.05.2023 15:25)
- Любой таймер в непрерывном режиме. Дополнительно ещё и прерывания
можно использовать под свои задачи, просто каждый раз пересчитывать
временную точку. - Dingo(29.05.2023 05:34)
- Когда нужна задержка на, тактов, 6, таймером будет не эффективно. - Nikolay_Po(29.05.2023 09:29)
- Согласен, на единицы тактов nop-ами лучше. Но следует пересчитывать
под конкретную частоту. - Dingo(29.05.2023 09:58)
- может
иконамибарьерами? - Vit(29.05.2023 14:32) - В Матлабе. - Kpoк(29.05.2023 14:07)
- может
- Как правило, при формировании строба требования к задержке "не
менее N микросекунд". Если получится N+1..2, нет повода горевать.
Экстремальная эффективность нужна крайне редко, вот и не надо
заморачиваться заранее, а то не останется времени на отдых... SciFi(1 знак., 29.05.2023 09:37, картинка)
- Такое я вообще машиной состояний делаю, пусть себе в фоне крутится, производительности не мешает... - Nikolay_Po(29.05.2023 09:41)
- Согласен, на единицы тактов nop-ами лучше. Но следует пересчитывать
под конкретную частоту. - Dingo(29.05.2023 09:58)
- Когда нужна задержка на, тактов, 6, таймером будет не эффективно. - Nikolay_Po(29.05.2023 09:29)
- Вроде как он фича кортексов M3 и выше. Емнип, на luminary я его
тоже юзал. А вот что на M0 его нет - то я щетаю косяк арма (вместе
с VTOR и BASEPRI) - LightElf(28.05.2023 16:49)
- на M23 тоже нет - Vit(28.05.2023 23:58)
- Тута пишут что есть (страница 7-9) LightElf(33 знак., 29.05.2023 12:36, ссылка)
- Только для членов профсоюза. - SciFi(29.05.2023 12:40)
- Тута пишут что есть (страница 7-9) LightElf(33 знак., 29.05.2023 12:36, ссылка)
- на M23 тоже нет - Vit(28.05.2023 23:58)
- Ну это уже совсем от безысходности. Когда и таймеры кончились, и
вообще вариантов не осталось. Не дай бог так оголодать... - SciFi(28.05.2023 15:43)
- У меня таймеры заканчиваются в каждом втором проекте. Делать из них
микросекундные задержки совсем некуртуазно. Я даже не понимаю какой
с этого профит. Другое дело - таймер больших задержек. Под это я
стандартно выделяю отдельный простой таймер (иногда SysTick) и он
генерирует прерывания с нужным мне дискретом (обычно 10 мс). - my504(28.05.2023 15:54)
- Я давно обнаружил, что большинство вопросов времени решаются в
стиле "start = current_time(); while (current_time() - start <
BLAH_BLAH) { /* wait */ }". То есть один таймер (обычно
DWT->CYCCNT) решает почти все такие вопросы. Никаких
регулярных прерываний. - SciFi(28.05.2023 16:52)
- Либо задержка блокирующая, либо работает через прерывания. Делать
блокирующие задержки значительной длительности - плохая идея. А
маленькие можно и традиционным способом через программный счетчик
циклов. По любому для них особой точности не получить и она не
требуется. - my504(28.05.2023 17:15)
- Да, по приведённому коду - блокирующая. Если без ОС - то автор, предположительно, понимает что делает: нет чего-то, что надо отслеживать на интервале такого замера; если ОС - то на крайний случай вытеснится задача. К тому же прерывания тоже имеют время реакции, сохранения на стек, загрузки из стека; так что для микросекундных - вполне вариант при определённых условиях. - Dingo(29.05.2023 04:52)
- Неблокирующая. Main Loop + protothreads. Удивительно, но решает
почти все мои вопросы. В редких случаях, когда нужна точная
времянка, есть аппаратные таймеры и прерывания. - SciFi(28.05.2023 17:32)
- Тогда у вас скорее не while(), a PT_WAIT_WHILE() :о) - Dingo(29.05.2023 04:55)
- Строго говоря, можно и while (...) { PT_YIELD(...); } :-) - SciFi(29.05.2023 09:40)
- Это частности; существенно то, что вы умолчали об используемом
вызове ОС, но утверждали, что неблокирующий и оно так работает. - Dingo(29.05.2023 09:57)
- Арестуйте меня :-) - SciFi(29.05.2023 09:58)
- Не дождётесь. ;-) - Dingo(29.05.2023 10:02)
- Арестуйте меня :-) - SciFi(29.05.2023 09:58)
- Это частности; существенно то, что вы умолчали об используемом
вызове ОС, но утверждали, что неблокирующий и оно так работает. - Dingo(29.05.2023 09:57)
- Строго говоря, можно и while (...) { PT_YIELD(...); } :-) - SciFi(29.05.2023 09:40)
- Тогда у вас скорее не while(), a PT_WAIT_WHILE() :о) - Dingo(29.05.2023 04:55)
- Либо задержка блокирующая, либо работает через прерывания. Делать
блокирующие задержки значительной длительности - плохая идея. А
маленькие можно и традиционным способом через программный счетчик
циклов. По любому для них особой точности не получить и она не
требуется. - my504(28.05.2023 17:15)
- Я давно обнаружил, что большинство вопросов времени решаются в
стиле "start = current_time(); while (current_time() - start <
BLAH_BLAH) { /* wait */ }". То есть один таймер (обычно
DWT->CYCCNT) решает почти все такие вопросы. Никаких
регулярных прерываний. - SciFi(28.05.2023 16:52)
- У меня таймеры заканчиваются в каждом втором проекте. Делать из них
микросекундные задержки совсем некуртуазно. Я даже не понимаю какой
с этого профит. Другое дело - таймер больших задержек. Под это я
стандартно выделяю отдельный простой таймер (иногда SysTick) и он
генерирует прерывания с нужным мне дискретом (обычно 10 мс). - my504(28.05.2023 15:54)
- Любой таймер в непрерывном режиме. Дополнительно ещё и прерывания
можно использовать под свои задачи, просто каждый раз пересчитывать
временную точку. - Dingo(29.05.2023 05:34)
- CS в тех же STM32 аппаратно реализуется. Другое дело, что эту ногу
зачастую приходится под более нужный интерфейс мспользовать и
реально щёлкать ногодрыгом... - Eddy_Em(28.05.2023 14:04)
- она аппаратно дергается на каждый байт? Нафиг тогда. Мне надо чтобы
после 16 байт (к примеру) или 9, или 29 - Лaгyнoв(28.05.2023 14:27)
- Такой CS в SPI есть у Микрочипа в относительно новых МК. Там и длина слова выбирается с шагом 1 бит и длина CS независимо контролируется с таким же шагом. Причем запуск CS отдельный. Поэтому можно установить нужное опережение. - my504(28.05.2023 15:10)
- У, ну, ясен пень, так оно не работает. Так - только ногодрыгом... Eddy_Em(304 знак., 28.05.2023 14:31)
- А ты сам лично использовал эту самую CS/SS или просто потрындеть
решил? )))) - my504(28.05.2023 14:15)
- Неа. Мне она только один раз нужна была - для работы с TFT. Но на
стадии трассировки платы я не знал, что протокол жёстко требует
стробирования CS, т.к. в даташите ничего такого не было. В итоге
пришлось ногой, которую я на программный резет хотел использовать,
дрыгать. Eddy_Em(84 знак., 28.05.2023 14:26)
- Вот когда сделаешь - расскажешь... - my504(28.05.2023 14:48)
- Неа. Мне она только один раз нужна была - для работы с TFT. Но на
стадии трассировки платы я не знал, что протокол жёстко требует
стробирования CS, т.к. в даташите ничего такого не было. В итоге
пришлось ногой, которую я на программный резет хотел использовать,
дрыгать. Eddy_Em(84 знак., 28.05.2023 14:26)
- она аппаратно дергается на каждый байт? Нафиг тогда. Мне надо чтобы
после 16 байт (к примеру) или 9, или 29 - Лaгyнoв(28.05.2023 14:27)
- +1, так делаю 5 мкс для LATCH в 595 - Лaгyнoв(28.05.2023 13:41)
- Для этого DWT->CYCCNT весьма хорош. - SciFi(28.05.2023 14:57)
- Только пост и молитва! - LightElf(28.05.2023 13:03)
- Это у вас - троеперстных - грех, а у нас - старообрядцев -
богоугодное деяние. - Kpoк(28.05.2023 13:21)
- Опыт подсказывает, что нет. По крайней мере для кода это не так.
Поэтому при 3WS при реализации функции задержки нопами скорость
падает примерно в 2,3...2,5 раза. Приходится это учитывать
множителем аргумента, чтобы откалибровать 1 мкс. my504(480 знак., 28.05.2023 12:54 - 13:01)
- Wait states - это задержка первоначального доступа. При линейном
чтении, за счёт ширины шины доступа к флеш, все последующие адреса
читаются на полной скорости. У вас табличка - latency а не clock
rate. - Nikolay_Po(28.05.2023 10:41)
- С того момента как были придуманы кэши, акселераторы и увеличенные разрядности шины. - VladislavS.(27.05.2023 22:51)
- Минимальное время доступа к флешу составляет примерно 30 нс. Прежде
чем писать очередную свою ахинею, ты бы хоть попробовал посмотреть
осциллографом реальное время перебора флеша при чтении. Обычным
ногодрыгом. Поднял ногу на входе в перебор, опустил на выходе. my504(1 знак., 28.05.2023 04:47, картинка)
- А с какого перепоя операция чтения из флеша стала бесплатной, как
из ОЗУ? - Eddy_Em(27.05.2023 22:27)
- Линейном поиске ЧЕГО? Ты сначала напридумываешь всяких глупостей, а
потом решаешь странные проблемы... 100КБ флеша - это 25К шагов
поиска. Делим обозначенные тобой две-три секунды на 25000 и
получаем 80...120 мкс на одно слово. Эдик, ты и впрямь такой идиот
или прикидываешься? У тебя цикл чтения ОДНОГО слова флеша
составляет 5...10 тыс. машинных циклов? - my504(27.05.2023 21:39)
- При линейном поиске МК грузится две-три секунды, пока сотню кБ
флеша перелопатит с шагом в 32..64Б. Eddy_Em(72 знак., 27.05.2023 21:12)
- Мне иногда кажется, что ты бредишь... В чем проблема выделения
секции? Зачем скорость при поиске записи? Ты отдаешь себе отчет в
скорости самой записи (времени работы хардварного автомата этой
записи)? Открой даташит на МК и убей себя апстену. ))))) - my504(27.05.2023 19:55)
- Скрипт лишь выделяет секцию. Eddy_Em(124 знак., 27.05.2023 11:48)