[HHIMERA 0]

Тщательнее надо придумывать аргументы.

Вы о чём вообще сейчас??? Мне аргументы не нужны... у меня всё работает... и работает так как надо... без всех ваших свободноубегающих микросекунд...

Посмотрел в интернете и нигде не нашел хорошего описания триггеров. Пришлось обратиться к первоисточнику.

Здесь все изложено подробно. Ищите output compare.

http://www.nxp.com/files/microcontrollers/...anual/GPTRM.pdf

Это прикол??? При чём здесь NXP к STM??? Я что... референс на STM8 не видел... и не знаю как и что там работает???

Пишите тут что хотите... мне это не интересно... и пользы от этого никакой...

 

[Tarbal 4]

Вы о чём вообще сейчас??? Мне аргументы не нужны... у меня всё работает... и работает так как надо... без всех ваших свободноубегающих микросекунд...

 

Ну а зачем тогда спорите? Человек спросил как сделать достоверную задержку, я ответил, а вы начали нам рассказывать, что вам это не подходит.

 

 

Это прикол??? При чём здесь NXP к STM??? Я что... референс на STM8 не видел... и не знаю как и что там работает???

Пишите тут что хотите... мне это не интересно... и пользы от этого никакой...

 

Это не прикол.

В этом документе красиво описана концепция input capture и output compare. Это первоисточник.

 

Если вас убеждают только документы по конкретному процессору, то вот вам

http://www.st.com/st-web-ui/static/active/.../DM00072019.pdf

в нем вскользь тоже упоминается о свободнобегущем 16 битном таймере: "TIM1 is a 16-bit timer which is allowed to free run." в начале 3-ей страницы. Я полагал вас интересует объяснение почему это так и дал вам хороший документ, но если вас интересуют только конкретные комбинации процессоров и решений, то я не буду настаивать.

[HHIMERA 0]

Ну а зачем тогда спорите?

Где??? Это вы что-то там пытаетесь доказать... не владея предметом спора... кстати...

Человек спросил как сделать достоверную задержку, я ответил

На что вам и заметили... что фигня всё это... что это костыли перевязанные скотчем...

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

То что предлагаете вы... подразумевает запрет прерываний... следовательно на универсальность никак претендовать не может... и по сути... ничем от обычного цикла не отличается... потому что в цикле и находится... это хоть понятно???

Это не прикол.

В этом документе красиво описана концепция input capture и output compare. Это первоисточник.

А красиво никому не нужно... это не художественная галерея... всем нужно чтобы правильно... как есть...

вскользь тоже упоминается о свободнобегущем 16 битном таймере

Что вы ещё за уши притянете??? Это не просто конкретные решения... это правильные решения...

 

===================

Чтобы было понятно о чём речь... нефиг юзать старые замшелые решения прошловековых МК на современных МК... где более развитая периферия и более широкие возможности... Сейчас многие производители тяготеют к хардварным решениям... достаточно глянуть на новые PIC16F16xx от Микрочип... чего там только нет... и это правильно...

Изменено 18 января, 2016 пользователем HHIMERA

[Tarbal 4]

Чтобы было понятно о чём речь... нефиг юзать старые замшелые решения прошловековых МК на современных МК... где более развитая периферия и более широкие возможности... Сейчас многие производители тяготеют к хардварным решениям... достаточно глянуть на новые PIC16F16xx от Микрочип... чего там только нет... и это правильно...

 

Ну это вы не ко мне, а к производителям МК обращайтесь с указаниями что им юзать.

 

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

У меня есть сильное подозрение, что вы не использовали в своих разработках компаратор. Я прав? И что-то мне подсказывает, что это не замшелые решения виноваты.

[HHIMERA 0]

предложил читать время из хардвера.

Ваша чушь пошла по пятому кругу... Придумайте что нибудь другое... если сможете...

 

[Tarbal 4]

Верно. Я напрасно теряю время.

[Eddy_Em 1]

Да всё там нормально... На STM8L тем более...

У l-ки, да, есть DMA и аппаратный 1-wire элементарно пилится. А вот у s-ок приходится софтварно пихать параметры таймера, т.е. по сути пока передаешь-принимаешь, ничего полезного сделать не получится. А это означает, что если, скажем, нужно LCD использовать, то на КА его индикацию не выйдет сделать — нужно будет по прерыванию еще какого-нибудь таймера, что некошерно!

 

Вопрос был как сделать короткую микросекундную задержку, чтобы она была стабильной.

Это невозможно. Придется отключать все прерывания, кроме заданного таймера (ну или пока будешь нопы считать). Да и вообще бесполезно это: кому нахрен нужна стабильная микросекундная пауза? Это — верный признак того, что автор лезет не в те дебри!

[HHIMERA 0]

У l-ки, да, есть DMA и аппаратный 1-wire элементарно пилится. А вот у s-ок приходится софтварно пихать параметры таймера, т.е. по сути пока передаешь-принимаешь, ничего полезного сделать не получится.

Эдди... Эдди... притормози... ты ли ещё картинок не насмотрелся??? Что... и здесь их ещё выкладывать???

Майн крутится сам по себе... делай чо хош... По прерыванию с прелоадом грузишь времянку следующего слота... по окончанию преобразования выставляешь флаг... Дальше в майне разруливаешь...

Там просечки в майне что-то около 7%...

А это означает, что если, скажем, нужно LCD использовать, то на КА его индикацию не выйдет сделать — нужно будет по прерыванию еще какого-нибудь таймера, что некошерно!

LCD на другой таймер... даже если это мелкий TFT... пусть молотит...

Это невозможно. Придется отключать все прерывания, кроме заданного таймера (ну или пока будешь нопы считать). Да и вообще бесполезно это: кому нахрен нужна стабильная микросекундная пауза? Это — верный признак того, что автор лезет не в те дебри!

Можно заюзать OPM свободного таймера... если он есть... ну уж точно не вылавливать что-то там в цикле...

Изменено 18 января, 2016 пользователем HHIMERA

[Eddy_Em 1]

LCD на другой таймер... даже если это мелкий TFT... пусть молотит...

И в итоге упрешься в недостачу таймеров, потому что все будешь вешать на них.

Уж опрос кнопок и всякие экранчики — штука настолько медленная, что лучше ее через КА в while(1) main'а забульбенить.

[HHIMERA 0]

И в итоге упрешься в недостачу таймеров, потому что все будешь вешать на них.

А ну и что??? Их что... солить??? Не хватит... буду выкручиваться... или тихо переползу на STM32F030... там таймеров поболее... а по цене они примерно как старшие STM8...

Да и вообще... смысл STM8 в совсем мелких и копеечных проектах на уровне STM8S003... дальше только STM32...

Уж опрос кнопок и всякие экранчики — штука настолько медленная, что лучше ее через КА в while(1) main'а забульбенить.

Кнопки можно и к LED дисплею привязать... если он есть... Короче... "Это не есть проблем!"(С)...

[Eddy_Em 1]

Да и вообще... смысл STM8 в совсем мелких и копеечных проектах на уровне STM8S003... дальше только STM32...

Ты это селеву (который еще и "ветерок") объясни ☺

[jcxz 181]

И в итоге упрешься в недостачу таймеров, потому что все будешь вешать на них.

Уж опрос кнопок и всякие экранчики — штука настолько медленная, что лучше ее через КА в while(1) main'а забульбенить.

при опросе кнопок, желательно избавляться от дребезга (ну если только он аппаратно не подавлен), а значит опрашивать их надо с частотой порядка 50Гц. Да и обновление экранчиков, если там есть динамическая картинка - движение этой картинки будет зависеть от равномерности работы этого вашего while - тоже не должно быть больших задержек в нём.

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

[Tarbal 4]

при опросе кнопок, желательно избавляться от дребезга (ну если только он аппаратно не подавлен), а значит опрашивать их надо с частотой порядка 50Гц. Да и обновление экранчиков, если там есть динамическая картинка - движение этой картинки будет зависеть от равномерности работы этого вашего while - тоже не должно быть больших задержек в нём.

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

 

Не знаю. Я всегда вешал в 10 миллисекундный цикл обработчик клавиатуры и выжидал 50 миллисекунд для успокоения дребезга. Никогда не было с этим проблем. Выжидал не в цикле, а пропуская 5 обращений к обработчику.

[Eddy_Em 1]

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

Ничего подобного! Отлично все работает. Целых три варианта: раз — проверка в теле КА (но там антидребезг обеспечивается немалым временем отработки затвора); два — опрос не чаще 1 раза в 50мс (это — эмулятор "нормальной" клавиатуры на основе матричной); три — обработка сигнала от кнопки в прерывании (там антидребезг подавляется тем, что пока обработчик не сбросит флаг, заново не устанавливается, а на это уходит не меньше 100мс).

 

На STM8 я тоже всякие разные методики реализовал. Но самое простое — реализовать аппаратно, т.е. повесить на кнопку кондер и резистор на сотню Ом.

[jcxz 181]

Не знаю. Я всегда вешал в 10 миллисекундный цикл обработчик клавиатуры и выжидал 50 миллисекунд для успокоения дребезга. Никогда не было с этим проблем. Выжидал не в цикле, а пропуская 5 обращений к обработчику.

Вы не поняли. Я не говорю, что это нельзя делать. Я говорю, что в этот цикл (в котором опрашивается кнопка) лучше не включать вызовы других процедур, которые могут длительно выполняться (десятки мсек) и блокировать процесс скана кнопок на десятки мсек ибо будет некомфортно работать с такими кнопками из-за задержек их реакции.

 

На STM8 я тоже всякие разные методики реализовал. Но самое простое — реализовать аппаратно, т.е. повесить на кнопку кондер и резистор на сотню Ом.

RC-цепочка никак не поможет в борьбе с дребезгом сама по себе. Она поможет только если сигнал после неё поступает на вход, имеющий гистерезис (триггер Шмидта).

А самая надёжная аппаратная защита от дребезга - парафазный вход set/reset (RS-триггер).