Dmitri Vladimirovich писал(а):А если несколько программых И2Ц взять?
Фишка в том, что i2c это открытый коллектор, это надо железо городить, а не только программно пинами дергать.
roboforum.ru
Технический форум по робототехнике.
RGB Color Light Sensor и Arduino
Re: RGB Color Light Sensor и Arduino
Фишка в том, что i2c это открытый коллектор, это надо железо городить, а не только программно пинами дергать.
Re: RGB Color Light Sensor и Arduino
но ведь в аврлибе есть программная реализациия?
или я чего то непонимаю
или я чего то непонимаю
Re: RGB Color Light Sensor и Arduino
Только не ОК а ОС.
И много где это можно эмулировать.
У авра PORTxy = 0, DDRxy = 0 | 1;
Некоторые другие так вообще имеют режим OD.
И много где это можно эмулировать.
У авра PORTxy = 0, DDRxy = 0 | 1;
Некоторые другие так вообще имеют режим OD.
Re: RGB Color Light Sensor и Arduino
Vooon писал(а):У авра PORTxy = 0, DDRxy = 0 | 1;
Вот блин
и правда ведь!Re: RGB Color Light Sensor и Arduino
=DeaD= писал(а):Dmitri Vladimirovich писал(а):А если несколько программых И2Ц взять?
Фишка в том, что i2c это открытый коллектор, это надо железо городить, а не только программно пинами дергать.
Можно и пинами эмулировать ОК. Это как раз не большая проблема.
Основная проблема в том, что если делать правильно (по спецификации I2C),
то необходимо отслеживать готовность слейва на каждом бите. По спецификации слейв может зажать клоки в любой момент, и мастер должен ждать, пока слейв их не отпустит.
Часто (но не всегда) этим можно пренебречь, но тогда говорить об I2C несколько некорректно.
То есть стандартный I2C, вообще говоря, не может гарантировать стабильное время обмена. И для реалтайм систем это плохо.
И еще неудобно то, что в I2C веревки двунаправленные. Это сразу превращается в геморрой, как только встают задачи согласования уровней, гальваноразвязки и т.п.
Программно делать слейв крайне неудобно (хотя тоже можно).
Re: RGB Color Light Sensor и Arduino
А зачем уровни конвертить? Часто можно просто pull-up к 3.3В сделать вместо 5.0В и всё.
Re: RGB Color Light Sensor и Arduino
Это как повезет. Например, у LSM303 уровни 1.8 вольт.
Я обычно делаю I2C программно, НО... я не мог бы гарантировать, что оно работоспособно с любым I2C девайсом.
Вот, например, стоят у меня на плате проц и два LSM303 - все работает (совершенно не по спецификации, но работает). И я могу это проверить!!!
Но если бы я делал девайс, типа, "вот вам I2C, подключайте что хотите", то я не смог бы проверить работоспособность с каждым конкретным датчиком.
Я был бы обязан строго следовать спецификации.
Как-то так.
Я обычно делаю I2C программно, НО... я не мог бы гарантировать, что оно работоспособно с любым I2C девайсом.
Вот, например, стоят у меня на плате проц и два LSM303 - все работает (совершенно не по спецификации, но работает). И я могу это проверить!!!
Но если бы я делал девайс, типа, "вот вам I2C, подключайте что хотите", то я не смог бы проверить работоспособность с каждым конкретным датчиком.
Я был бы обязан строго следовать спецификации.
Как-то так.
Re: RGB Color Light Sensor и Arduino
Michael_K писал(а):Основная проблема в том, что если делать правильно (по спецификации I2C),
то необходимо отслеживать готовность слейва на каждом бите. По спецификации слейв может зажать клоки в любой момент, и мастер должен ждать, пока слейв их не отпустит.
Ну понятно что это можно не делать, а в чем серьезная проблема это сделать?
Re: RGB Color Light Sensor и Arduino
В непредсказуемости.
Обычно есть прерывания, какие-то временнЫе константы и т.п.
Обычно есть прерывания, какие-то временнЫе константы и т.п.
Re: RGB Color Light Sensor и Arduino
1. Если делать по спецификации, то примерно половина даташита на любой пик занимает вопрос разруливания коллизий ХАРДОВЫМ модулем i2c - да ну его к черту, по спецификации
2. Согласовать уровни элементарно - по полевому транзистору с низким порогом открывания на линию. Главное, чтобы они были.
3. Главная проблема - ограниченное адресное пространство, пересекающиеся адреса и т.д. Т.е. чем более распространено i2c, тем шире проблема.
4. А вообще штука удобная. Вот например, я сейчас делаю драйвер двигателей, совместимый с OR. Но вчера почти что решил делать с управлением не по RoboMD2, а по i2c. МК с i2c и нужным количеством портов (да, а мне надо много -я делаю на Н-мостах, которые просят 8 пинов на управление каждым, т.е. 2 совершенно свободных порта.) МК стоит 50-70 рублей. Если все-таки не выводить всевозможные дисейблы и енейблы и оставить регистры управления только ШИМ, Направление, Фейл-статус и обратка по току, то МК обойдется в 45 рублей в тритоне. Один МК, два моста, коннектор на подключение двигателей, питания двигателей, питания МК (можно запитать от движков же, кстати, так и надо сделать), а дальше выводи куда хошь - УАРТ, i2C, SPI...
Поленился что-то за МК бегать (опять надо Анатолия просить закупку делать, ехать ему, ехать мне и все из-за 100 руб), да прошивку писать - но, черт побери, пока эти буквы написал, опять захотелось. Кинул два байтика на движки - поехали. Кинул еще два - встали. Первый байт - номер движка, направления вращения, младшие биты ПВМ, второй байт - старшие биты ПВМ. Если нужны статусы - один байт прочитал. Старший байт - статус, младшие - ток.
ВСЕ!!!!!
2. Согласовать уровни элементарно - по полевому транзистору с низким порогом открывания на линию. Главное, чтобы они были.
3. Главная проблема - ограниченное адресное пространство, пересекающиеся адреса и т.д. Т.е. чем более распространено i2c, тем шире проблема.
4. А вообще штука удобная. Вот например, я сейчас делаю драйвер двигателей, совместимый с OR. Но вчера почти что решил делать с управлением не по RoboMD2, а по i2c. МК с i2c и нужным количеством портов (да, а мне надо много -я делаю на Н-мостах, которые просят 8 пинов на управление каждым, т.е. 2 совершенно свободных порта.) МК стоит 50-70 рублей. Если все-таки не выводить всевозможные дисейблы и енейблы и оставить регистры управления только ШИМ, Направление, Фейл-статус и обратка по току, то МК обойдется в 45 рублей в тритоне. Один МК, два моста, коннектор на подключение двигателей, питания двигателей, питания МК (можно запитать от движков же, кстати, так и надо сделать), а дальше выводи куда хошь - УАРТ, i2C, SPI...
Поленился что-то за МК бегать (опять надо Анатолия просить закупку делать, ехать ему, ехать мне и все из-за 100 руб), да прошивку писать - но, черт побери, пока эти буквы написал, опять захотелось. Кинул два байтика на движки - поехали. Кинул еще два - встали. Первый байт - номер движка, направления вращения, младшие биты ПВМ, второй байт - старшие биты ПВМ. Если нужны статусы - один байт прочитал. Старший байт - статус, младшие - ток.
ВСЕ!!!!!
Re: RGB Color Light Sensor и Arduino
dccharacter писал(а):Вот например, я сейчас делаю драйвер двигателей, совместимый с OR. Но вчера почти что решил делать с управлением не по RoboMD2, а по i2c.
Тогда вешайте туда еще и 2 разъема энкодеров сдвоенных в распиновке GND,VCC,SIG1,SIG2.
Re: RGB Color Light Sensor и Arduino
=DeaD= писал(а):dccharacter писал(а):Вот например, я сейчас делаю драйвер двигателей, совместимый с OR. Но вчера почти что решил делать с управлением не по RoboMD2, а по i2c.
Тогда вешайте туда еще и 2 разъема энкодеров сдвоенных в распиновке GND,VCC,SIG1,SIG2.
Кстати да, забыл вот... А если делать все-таки с i2c, как опрашивать энкодеры? Как аксель? Т.е. делать пин прерывания, регистр прерывания и отдельные регистры на каждый энкодер со значением скорости???
П.С. мне можно тыкать
Re: RGB Color Light Sensor и Arduino
На каждом энкодере SIG1 (или на каждом - SIG2) надо завести на прерывание по изменению уровня.
Re: RGB Color Light Sensor и Arduino
=DeaD= писал(а):На каждом энкодере SIG1 (или на каждом - SIG2) надо завести на прерывание по изменению уровня.
Не, ты не понял. Я про то, как вовне отдавать. Это же все еще можно отдавать по i2c, но чтобы постоянно не оправшивать, делается пятый пин INT. Вообще i2c очень много разъемов. Вон вы на ОР пишете, что у вас совместимо с какими-то устройствами. Часть устройств имеют SDA и SDL по краям. Часть - шестипиновая (даже читал где-то что это "стандарт"), там еще INT и AUX
Re: RGB Color Light Sensor и Arduino
Какой еще пятый пин I2C, не надо этого, концепция I2C - мастер-слейв, вот и не надо её рушить.
Надо на самом ДД делать ПИД-регулятор, если уж делаешь его на I2C.
У тебя же на ДД контроллер стоит - нафига сурово дергать по прерыванию вышестоящий контроллер из-за энкодеров? Это же не катастрофа какая-то случилась непредвиденная
Надо на самом ДД делать ПИД-регулятор, если уж делаешь его на I2C.
У тебя же на ДД контроллер стоит - нафига сурово дергать по прерыванию вышестоящий контроллер из-за энкодеров? Это же не катастрофа какая-то случилась непредвиденная