типовой оптический DSP энкодер, делает несколько тысяч снимков поверхности диска (обычная матовая поверхность) в секунду и если поверхность движется (изображение фотоснимков смещается) (в данном случае диск вращается) то рассчитывает длину перемещения (в данном случае угол поворота диска, 2500 имп./об.), ну а дальше периодически МК получает пачки данных о длине перемещения и интерпретирует как импульсы энкодера. Это делал около 10 лет тому назад, так что сейчас эта тема давно морально устарела и надо уже делать что-то новое.
нет, can намного сложнее, там во первых два провода идет can-hi can-low, и сообщения могут отправлять все устройства одновременно НО получится отправить только у того у кого приоритет сообщения самый высокий
OWON - нормальный осциллограф или так себе? Что будет лучше OWON или Siglend ? Как зарекомендовал себя настольный мультиметр OWON? Хотелось бы посмотреть Ваш честный видос с обзором имеющегося у вас оборудования.
не занимаюсь обзорами. Берите что подороже, думаю так меньше будет причин для разочарования. Но помните, что для того чтоб получить технику всего-лишь с двукратно лучшими характеристиками и свойствами потребуется заплатить приблизительно в десять раз дороже.
14:28 Наверное не совсем так, что контроллер высвобождается во время посылки чего либо в шину i2c. После любой посылки в коде МК ждет ведомое устройство ему что ответит, выставив соответствующий бит в регистре. while(!(TWCR&(1
У меня строится по принципу, появилось свободное процессорное время, из под обработчика протокола обратились к логическому модулю обслуживающему линию, посмотрели что нового на линии, если есть изменения, дали из под обработчика новую команду и быстро освободили процессорное время для выполнения других программ. до следующих изменений на линии. при работе со внешней периферией процессор МК никогда ничего не ждет, периодически как доходит очередь из всего стека отдельных программных модулей выполнить модуль обработчик периферии, он только читает флаги о состоянии линии связи и состоянии периферийного устройства, раздает команды и принимает-получает новые данные из соответствующих регистров (не из линии связи). максимально быстро освобождает процессор чтоб тот мог выполнять другие задачи. Всеми низкоуровневыми операциями, тактирование, чтение и проверка данных линии связи занимается специальный логический модуль МК. процессор этим не занимается. За исключением каких-то редких устройств не поддерживающих стандартные протоколы.
Не занимаюсь обзорами. Просто в достаточной мере соответствует свойствам заявленным на странице продавца и все... При выборе товаров просто покупайте подороже и с известным именем продукты, тем в меньшей степени будете разочарованы покупкой.
Во внутрисхемной электронике такая шина данных не используется. По крайней мере не встречал. Насколько понимаю это старая шина данных для связи меж блоками автотранспорта которая постепенно уходит в историю из-за низкой надежности и малых скоростей передачи.
Возможно когда-то запишу как обрабатывать шину 1-wire в многозадачной системе когда МК аппаратно не поддерживает этот протокол. Сейчас пока что показать нечего, так как в основном работаю с 1-wire, во время работы с данной шиной, задерживая работу других процессорных задач.
@@Slesar.lin наооборот набирает большую популярность в автомобилях для не особо важных блоков(стеклоподьемники, климат, сигнализация и тд) популярна она потому что дешевая как на програмном уровне так и физическом(проводка, реализация протокола в железе). для ответственных узлов используют CAN на разных скоростях
@@xKUMAxMU , в автомобилях как минимум 10 лет набирают популярность оптические линии обмена данными, все проводные линии достаточно стары чтоб набирать популярность. В известных мне автомобилях уже более 15 лет только CAN шины. Уже не могу вспомнить на какой машине встречал LIN.
Ну кому надо разжевывать протокол I2C? Он же прост и описан подробнейшем образом в куче документов, книг и сайтов. Можно было в пару минут уместить. Ну полезней же было! )
Это мне нужно. если вам не нужно просто не смотрите. Потому как почитать описание это одно, а написать качественный обработчик протокола в контексте конкретной системы, это совсем другое...
@@ukr-pig, чем посложнее? Ждем когда на линия будет занята и выставлен байт адреса, сравниваем со своим адресом, если совпало, либо принимает указание и данные, либо принимаем указание и отправляем на линию данные.
Применительно к PIC микроконтроллеру в качестве подчиненного, старт бит, адресация, подтверждение приема, все делает контроллер шины, остается только правильно сконфигурировать...
@@Slesar. это всё теория.Когда доходит до дела уже не так смешно.Я люблю эмулировать тачскрины от телефонов при помощи stm32 микроконтроллера.И не всегда получается.То есть например у телефона разбился тачскрин а тапать по экрану нужно.Выкидываю разбитый тач и вместо него припаиваю stm32
Не использовал I2C совместно с ОСРВ, но в простой программе просто снабдил его индикатором состояний, типа "Свободен", "Принял данные", "Отправил данные" и "Ошибка". Этого достаточно, чтобы разрулить доступ к нему с нескольких конечных автоматов.
Ну так а ваш обработчик с этой шиной данных как взаимодействовал? Линию тактировал? Ждал ответа от подчиненного устройства на этот промежуток времени задерживал выполнение других программ?
@@Slesar. Интерфейс аппаратный. Сам процесс передачи и приёма происходит на прерываниях. Конечный автомат (а-ля драйвер какого-нибудь чипа на этой шине) перед использованием сначала проверяет, занят ли интерфейс или нет. Если занят, то КА возвращает управление обратно главному циклу. Если свободен, то начинает с ним работу. Соответственно, начав с ним работу, состояние интерфейса становится отличным от состояния "Свободен" и другие КА, которым он нужен, не смогут его занять. По окончанию работы, КА выставляет интерфейсу состояние "Свободен". В моих проектах главный цикл никогда и нигде не стопорится.
@@kardanium , у меня процессор не работает с линией связи. Он только проверяет контрольные биты аппаратного интерфейса, дает команды, записывает или вычитывает данные хранящиеся в регистрах аппаратного интерфейса. В общем, на разовую работу с таким интерфейсом расходуется всего несколько тактов процессора. Прерывания в данном случае не используются, так как нет необходимости в моментальной реакции на изменения на линии связи. В общем, тут ничего нового, я просто показал как это выглядит на линии связи. неравномерность посылки данных на линии связи наблюдается, так как процессор обрабатывает данный протокол в непредсказуемые моменты времени, в зависимости от того как выполняются все другие условно параллельные процессы.
@@Slesar. Ну, использовать прерывания не обязательно. Иногда даже вредит. Но в интерфейсах я их использую довольно часто. В основном для того, чтобы забрать принятый байт и записать его в буфер приема или отправить очередной байт из буфера передачи. Так меньше вероятности словить ошибку переполнения, если основная программа всетаки где-то задержится.
@@kardanium , для всех участвующих программных модулей стараются придерживаться идеологии, чтоб как можно быстрее освобождали процессор и передавали на выполнение другим задачам. В данном случае для шины I2C когда мастер на шине объявит стартовую последовательность, все устройства на шине будут мирно ждать поступления команд и данных на шину, то есть никакого переполнения или отваливания по истечению времени произойти не может, по этому мастер может слать новые байты информации через не равные и даже продолжительные промежутки времени. Прерывания использую только там, где требуется скорая реакция на событие или устройство должно просыпаться по событию, или где требуется делать отсчеты или раздавать указания через равные промежутки времени по таймеру. Во всех других случаях выполнение происходит по мере освобождения процессора от выполнения других задач.
Вы хоть что-то делали с использованием этих шин данных? Это вообще разные шины. I2C чипы адресуются кодом, а SPI чипы выбираются дополнительной линией CS к каждому чипу. I2C прием и передача данных осуществляется по одной и той же линии, а SPI данные передаются по одной линии, а принимаются данные по другой линии, причем параллельно, в одни и те же тактовые импульсы.
@@Slesar. а я вам что написал? В I2C нет дуплекса, по одной лини передаются и принимаются данные и в ней нет линии En (или CS как вы написали) Это точно такая же синхронная шина. Я смотрю ваш уровень ЧСВ зашкаливает.
@@AVK130174 мастер ставить на низкий уровень cs с кем хочется общаться. А i2c работает одновремено с разными адресами синхронизируяс по клок. Разные время для линии даных
@@AVK130174 , не все равно что вы там смотрите, у меня свое собственное понимание что и как там работает. У меня десятки самодельных устройств использующих эти шины данных, нет проблем с этим.
@@Magomed86 I2C не может работать одновременно с несколькими адресами, только послать сообщение на все устройства, что по факту не используется. SPI точно так же синхронизируется по clk это точно такая же синхронная шина, если вы понимаете что это такое.
Не смог посмотреть. Укачало.
Спасибо! Успеха в работе.
Могли бы Вы снять видео про дифиринциальный пробник. Для чего нужен и как им пользоваться ?
лучше расскажите про ваш уникальный энкодер
типовой оптический DSP энкодер, делает несколько тысяч снимков поверхности диска (обычная матовая поверхность) в секунду и если поверхность движется (изображение фотоснимков смещается) (в данном случае диск вращается) то рассчитывает длину перемещения (в данном случае угол поворота диска, 2500 имп./об.), ну а дальше периодически МК получает пачки данных о длине перемещения и интерпретирует как импульсы энкодера.
Это делал около 10 лет тому назад, так что сейчас эта тема давно морально устарела и надо уже делать что-то новое.
@@Slesar. Вы использовали сенсор от оптической мышки?
@@АнонимАнаномный , да. только старого типа. сейчас наверное такие уже не делают.
@@Slesar. сейчас можно с принтера аналогичную вытянуть. только диск там побольше будет
Спасибо было интересно, can линия примерно так же работает?
нет, can намного сложнее, там во первых два провода идет can-hi can-low, и сообщения могут отправлять все устройства одновременно НО получится отправить только у того у кого приоритет сообщения самый высокий
OWON - нормальный осциллограф или так себе? Что будет лучше OWON или Siglend ? Как зарекомендовал себя настольный мультиметр OWON? Хотелось бы посмотреть Ваш честный видос с обзором имеющегося у вас оборудования.
не занимаюсь обзорами. Берите что подороже, думаю так меньше будет причин для разочарования. Но помните, что для того чтоб получить технику всего-лишь с двукратно лучшими характеристиками и свойствами потребуется заплатить приблизительно в десять раз дороже.
Тоже хотел такой мультиметр Owon, но оттолкнул тот факт, что слишком узкая полоса при измерении переменного напряжения. Хотелось хотя бы до 20 кГц...
А камеру поставить на штатив не думали? А то подташнивает слегка
нет. не думал. если вас подташнивает идите смотреть другое кино.
14:28 Наверное не совсем так, что контроллер высвобождается во время посылки чего либо в шину i2c. После любой посылки в коде МК ждет ведомое устройство ему что ответит, выставив соответствующий бит в регистре. while(!(TWCR&(1
У меня строится по принципу, появилось свободное процессорное время, из под обработчика протокола обратились к логическому модулю обслуживающему линию, посмотрели что нового на линии, если есть изменения, дали из под обработчика новую команду и быстро освободили процессорное время для выполнения других программ. до следующих изменений на линии.
при работе со внешней периферией процессор МК никогда ничего не ждет, периодически как доходит очередь из всего стека отдельных программных модулей выполнить модуль обработчик периферии, он только читает флаги о состоянии линии связи и состоянии периферийного устройства, раздает команды и принимает-получает новые данные из соответствующих регистров (не из линии связи). максимально быстро освобождает процессор чтоб тот мог выполнять другие задачи. Всеми низкоуровневыми операциями, тактирование, чтение и проверка данных линии связи занимается специальный логический модуль МК. процессор этим не занимается.
За исключением каких-то редких устройств не поддерживающих стандартные протоколы.
while( используется наверное только один раз, в главном цикле всего ПО системы.
@@Slesar.В главной функции while (1) {} даёт бесконечный цикл. Тут же с условием по состоянию бита.
"Слесарь", сделай плиз обзор источника питания (справа в стойке приборов) . Хотел бы узнать мнение пользователя о приборе .
Не занимаюсь обзорами. Просто в достаточной мере соответствует свойствам заявленным на странице продавца и все...
При выборе товаров просто покупайте подороже и с известным именем продукты, тем в меньшей степени будете разочарованы покупкой.
Спасибо!
здравствуйте! спасибо было интересно. а про LIN будет? давайте сделаем!
Во внутрисхемной электронике такая шина данных не используется. По крайней мере не встречал. Насколько понимаю это старая шина данных для связи меж блоками автотранспорта которая постепенно уходит в историю из-за низкой надежности и малых скоростей передачи.
Возможно когда-то запишу как обрабатывать шину 1-wire в многозадачной системе когда МК аппаратно не поддерживает этот протокол. Сейчас пока что показать нечего, так как в основном работаю с 1-wire, во время работы с данной шиной, задерживая работу других процессорных задач.
@@Slesar.lin наооборот набирает большую популярность в автомобилях для не особо важных блоков(стеклоподьемники, климат, сигнализация и тд) популярна она потому что дешевая как на програмном уровне так и физическом(проводка, реализация протокола в железе).
для ответственных узлов используют CAN на разных скоростях
lin по своей работе похожа с oneWire, а вот oneWire уже часто используеться в среде микроконтролеров
@@xKUMAxMU , в автомобилях как минимум 10 лет набирают популярность оптические линии обмена данными, все проводные линии достаточно стары чтоб набирать популярность.
В известных мне автомобилях уже более 15 лет только CAN шины. Уже не могу вспомнить на какой машине встречал LIN.
Ну кому надо разжевывать протокол I2C? Он же прост и описан подробнейшем образом в куче документов, книг и сайтов. Можно было в пару минут уместить. Ну полезней же было! )
Это мне нужно. если вам не нужно просто не смотрите.
Потому как почитать описание это одно, а написать качественный обработчик протокола в контексте конкретной системы, это совсем другое...
я бы глянул про i2c в режиме slave это уже посложнее чем master
@@ukr-pig, чем посложнее? Ждем когда на линия будет занята и выставлен байт адреса, сравниваем со своим адресом, если совпало, либо принимает указание и данные, либо принимаем указание и отправляем на линию данные.
Применительно к PIC микроконтроллеру в качестве подчиненного, старт бит, адресация, подтверждение приема, все делает контроллер шины, остается только правильно сконфигурировать...
@@Slesar. это всё теория.Когда доходит до дела уже не так смешно.Я люблю эмулировать тачскрины от телефонов при помощи stm32 микроконтроллера.И не всегда получается.То есть например у телефона разбился тачскрин а тапать по экрану нужно.Выкидываю разбитый тач и вместо него припаиваю stm32
Не использовал I2C совместно с ОСРВ, но в простой программе просто снабдил его индикатором состояний, типа "Свободен", "Принял данные", "Отправил данные" и "Ошибка". Этого достаточно, чтобы разрулить доступ к нему с нескольких конечных автоматов.
Ну так а ваш обработчик с этой шиной данных как взаимодействовал? Линию тактировал? Ждал ответа от подчиненного устройства на этот промежуток времени задерживал выполнение других программ?
@@Slesar. Интерфейс аппаратный. Сам процесс передачи и приёма происходит на прерываниях. Конечный автомат (а-ля драйвер какого-нибудь чипа на этой шине) перед использованием сначала проверяет, занят ли интерфейс или нет. Если занят, то КА возвращает управление обратно главному циклу. Если свободен, то начинает с ним работу. Соответственно, начав с ним работу, состояние интерфейса становится отличным от состояния "Свободен" и другие КА, которым он нужен, не смогут его занять. По окончанию работы, КА выставляет интерфейсу состояние "Свободен". В моих проектах главный цикл никогда и нигде не стопорится.
@@kardanium , у меня процессор не работает с линией связи. Он только проверяет контрольные биты аппаратного интерфейса, дает команды, записывает или вычитывает данные хранящиеся в регистрах аппаратного интерфейса.
В общем, на разовую работу с таким интерфейсом расходуется всего несколько тактов процессора.
Прерывания в данном случае не используются, так как нет необходимости в моментальной реакции на изменения на линии связи.
В общем, тут ничего нового, я просто показал как это выглядит на линии связи. неравномерность посылки данных на линии связи наблюдается, так как процессор обрабатывает данный протокол в непредсказуемые моменты времени, в зависимости от того как выполняются все другие условно параллельные процессы.
@@Slesar. Ну, использовать прерывания не обязательно. Иногда даже вредит. Но в интерфейсах я их использую довольно часто. В основном для того, чтобы забрать принятый байт и записать его в буфер приема или отправить очередной байт из буфера передачи. Так меньше вероятности словить ошибку переполнения, если основная программа всетаки где-то задержится.
@@kardanium , для всех участвующих программных модулей стараются придерживаться идеологии, чтоб как можно быстрее освобождали процессор и передавали на выполнение другим задачам.
В данном случае для шины I2C когда мастер на шине объявит стартовую последовательность, все устройства на шине будут мирно ждать поступления команд и данных на шину, то есть никакого переполнения или отваливания по истечению времени произойти не может, по этому мастер может слать новые байты информации через не равные и даже продолжительные промежутки времени.
Прерывания использую только там, где требуется скорая реакция на событие или устройство должно просыпаться по событию, или где требуется делать отсчеты или раздавать указания через равные промежутки времени по таймеру. Во всех других случаях выполнение происходит по мере освобождения процессора от выполнения других задач.
I2C ровно также работает как SPI только не в дуплексе и вместо En у него адреса ))))))
Вы хоть что-то делали с использованием этих шин данных? Это вообще разные шины.
I2C чипы адресуются кодом, а SPI чипы выбираются дополнительной линией CS к каждому чипу.
I2C прием и передача данных осуществляется по одной и той же линии, а SPI данные передаются по одной линии, а принимаются данные по другой линии, причем параллельно, в одни и те же тактовые импульсы.
@@Slesar. а я вам что написал? В I2C нет дуплекса, по одной лини передаются и принимаются данные и в ней нет линии En (или CS как вы написали) Это точно такая же синхронная шина. Я смотрю ваш уровень ЧСВ зашкаливает.
@@AVK130174 мастер ставить на низкий уровень cs с кем хочется общаться. А i2c работает одновремено с разными адресами синхронизируяс по клок. Разные время для линии даных
@@AVK130174 , не все равно что вы там смотрите, у меня свое собственное понимание что и как там работает. У меня десятки самодельных устройств использующих эти шины данных, нет проблем с этим.
@@Magomed86 I2C не может работать одновременно с несколькими адресами, только послать сообщение на все устройства, что по факту не используется. SPI точно так же синхронизируется по clk это точно такая же синхронная шина, если вы понимаете что это такое.
что за Карлсон снимает на камеру? Надо бы его закрепить на штатив для начала..
смотрите другие ролики. крепление камеры на штатив не увеличивает монетизацию канала
Колхоз... 🤣🤣🤣
У LM75 к примеру 8 адресов можна поставить, восемь параллельно.