Огромное спасибо за Ваши ролики и разбор полетов, собрал эл гитару, но пришло время переходить на новый уровень, привязка оптических линеек это супер, по шаговикам почерпнул очень многое!!!!!
1. Кольцевой буфер, в данной реализации, не позволяет управлять одновременно и независимо несколькими двигателями. Я могу с помощью одного таймера управлять одновременно несколькими шаговиками с разными режимами работы. 2. По поводу одновременной записи в одну переменную из разных мест: Если имеется ввиду запись из основного цикла программы и из обработчика, то в этом случае необходимо запрещать тот самый обработчик в момент записи в переменную из основного цикла при условии, что размер переменной больше 8 бит для восьмибитного контроллера. Иначе делать ничего не нужно - запись всегда будет строго последовательной и корректной. 3. Обработчик прерывания никогда не прерывает запись битов в ячейку памяти! Сначала завершается текущая операция ввода/вывода с памятью, а затем происходит вызов обработчика. Для STM8 сей факт отражён в документации RM0016 на стр. 25
1. и это правильно - ибо это не 3D принтер. В абсолютном большинстве 3D станков (не принтеров) двигатели включаются последовательно и это правильно ибо: - снижение вибрации ибо одновременно стартующие двигатели создают очень сильную нагрузку на станок. Именно поэтому по мосту нельзя ходить шагая синхронно - иначе мост разрушится. - экономия мощности блока питания ибо мощность БП должна превышать мощность только одного двигателя, а не всех 2. уже ответил 3. тоже ответил - смотрите volatile и обратите внимание на код от STM - они этот атрибут используют очень часто. И одно дело это описание МК, а другое дело как компилятор С интерпретирует свой код в машинный код - я пишу на c++, а не напрямую в машинных кодах - поэтому и выводы делаю только того компилятора что использую я. А в других компиляторах ситуация возможно иная и такое поведение зависит от разработчика компилятора, а вовсе не от описания МК в его даташите.
@@LACNC 1. Я не разработчик электронных гитар и мне не известны все нюансы. Поэтому ваше утверждение по данному пункту полностью принимается. 2. Ответил в другом посте _обратите внимание на код от STM - они этот атрибут используют очень часто_ - это говорит, лишь, об уровне программиста и его понимании происходящих процессов _И одно дело это описание МК, а другое дело как компилятор С интерпретирует свой код в машинный код_ - одно другого не касается. _я пишу на c++, а не напрямую в машинных кодах_ - я тоже пишу не в машинных кодах :) _поэтому и выводы делаю только того компилятора что использую я_ - разные компиляторы с разных языков могут генерировать код в одни и те, же, машинные инструкции для похожих синтаксических конструкций. Что C, что C++ компиляторы скорее всего сгенерируют один и тот же код для присваивания значения переменной. Но важно понимание сути процессов на низком уровне! Если вы не хотите разбираться в мелочах, то у вас всегда будут возникать утверждения, которые противоречат реальности и даташиту, как в данном случае! :) И дальнейшая ваша деятельность будет уже основана на этих неверных выводах, что, скорее всего, приведёт к лишним затратам при проектировании железа и разработки ПО. В чём суть "проблемы" с якобы неполной записью в память я пояснил в другом посте.
Огромное спасибо за Ваши ролики и разбор полетов, собрал эл гитару, но пришло время переходить на новый уровень, привязка оптических линеек это супер, по шаговикам почерпнул очень многое!!!!!
1. Кольцевой буфер, в данной реализации, не позволяет управлять одновременно и независимо несколькими двигателями. Я могу с помощью одного таймера управлять одновременно несколькими шаговиками с разными режимами работы.
2. По поводу одновременной записи в одну переменную из разных мест: Если имеется ввиду запись из основного цикла программы и из обработчика, то в этом случае необходимо запрещать тот самый обработчик в момент записи в переменную из основного цикла при условии, что размер переменной больше 8 бит для восьмибитного контроллера. Иначе делать ничего не нужно - запись всегда будет строго последовательной и корректной.
3. Обработчик прерывания никогда не прерывает запись битов в ячейку памяти! Сначала завершается текущая операция ввода/вывода с памятью, а затем происходит вызов обработчика. Для STM8 сей факт отражён в документации RM0016 на стр. 25
1. и это правильно - ибо это не 3D принтер. В абсолютном большинстве 3D станков (не принтеров) двигатели включаются последовательно и это правильно ибо:
- снижение вибрации ибо одновременно стартующие двигатели создают очень сильную нагрузку на станок. Именно поэтому по мосту нельзя ходить шагая синхронно - иначе мост разрушится.
- экономия мощности блока питания ибо мощность БП должна превышать мощность только одного двигателя, а не всех
2. уже ответил
3. тоже ответил - смотрите volatile и обратите внимание на код от STM - они этот атрибут используют очень часто. И одно дело это описание МК, а другое дело как компилятор С интерпретирует свой код в машинный код - я пишу на c++, а не напрямую в машинных кодах - поэтому и выводы делаю только того компилятора что использую я. А в других компиляторах ситуация возможно иная и такое поведение зависит от разработчика компилятора, а вовсе не от описания МК в его даташите.
@@LACNC
1. Я не разработчик электронных гитар и мне не известны все нюансы. Поэтому ваше утверждение по данному пункту полностью принимается.
2. Ответил в другом посте
_обратите внимание на код от STM - они этот атрибут используют очень часто_ - это говорит, лишь, об уровне программиста и его понимании происходящих процессов
_И одно дело это описание МК, а другое дело как компилятор С интерпретирует свой код в машинный код_ - одно другого не касается.
_я пишу на c++, а не напрямую в машинных кодах_ - я тоже пишу не в машинных кодах :)
_поэтому и выводы делаю только того компилятора что использую я_ - разные компиляторы с разных языков могут генерировать код в одни и те, же, машинные инструкции для похожих синтаксических конструкций. Что C, что C++ компиляторы скорее всего сгенерируют один и тот же код для присваивания значения переменной. Но важно понимание сути процессов на низком уровне! Если вы не хотите разбираться в мелочах, то у вас всегда будут возникать утверждения, которые противоречат реальности и даташиту, как в данном случае! :) И дальнейшая ваша деятельность будет уже основана на этих неверных выводах, что, скорее всего, приведёт к лишним затратам при проектировании железа и разработки ПО. В чём суть "проблемы" с якобы неполной записью в память я пояснил в другом посте.