roboforum.ru

Dmitri Vladimirovich писал(а):А если несколько программых И2Ц взять?

Фишка в том, что i2c это открытый коллектор, это надо железо городить, а не только программно пинами дергать.

но ведь в аврлибе есть программная реализациия?

или я чего то непонимаю

Только не ОК а ОС.
И много где это можно эмулировать.
У авра PORTxy = 0, DDRxy = 0 | 1;
Некоторые другие так вообще имеют режим OD.

Vooon писал(а):У авра PORTxy = 0, DDRxy = 0 | 1;

Вот блин и правда ведь!

=DeaD= писал(а):

Dmitri Vladimirovich писал(а):А если несколько программых И2Ц взять?

Фишка в том, что i2c это открытый коллектор, это надо железо городить, а не только программно пинами дергать.

Можно и пинами эмулировать ОК. Это как раз не большая проблема.

Основная проблема в том, что если делать правильно (по спецификации I2C),
то необходимо отслеживать готовность слейва на каждом бите. По спецификации слейв может зажать клоки в любой момент, и мастер должен ждать, пока слейв их не отпустит.

Часто (но не всегда) этим можно пренебречь, но тогда говорить об I2C несколько некорректно.
То есть стандартный I2C, вообще говоря, не может гарантировать стабильное время обмена. И для реалтайм систем это плохо.

И еще неудобно то, что в I2C веревки двунаправленные. Это сразу превращается в геморрой, как только встают задачи согласования уровней, гальваноразвязки и т.п.

Программно делать слейв крайне неудобно (хотя тоже можно).

А зачем уровни конвертить? Часто можно просто pull-up к 3.3В сделать вместо 5.0В и всё.

Это как повезет. Например, у LSM303 уровни 1.8 вольт.
Я обычно делаю I2C программно, НО... я не мог бы гарантировать, что оно работоспособно с любым I2C девайсом.

Вот, например, стоят у меня на плате проц и два LSM303 - все работает (совершенно не по спецификации, но работает). И я могу это проверить!!!

Но если бы я делал девайс, типа, "вот вам I2C, подключайте что хотите", то я не смог бы проверить работоспособность с каждым конкретным датчиком.
Я был бы обязан строго следовать спецификации.

Как-то так.

Michael_K писал(а):Основная проблема в том, что если делать правильно (по спецификации I2C),
то необходимо отслеживать готовность слейва на каждом бите. По спецификации слейв может зажать клоки в любой момент, и мастер должен ждать, пока слейв их не отпустит.

Ну понятно что это можно не делать, а в чем серьезная проблема это сделать?

В непредсказуемости.
Обычно есть прерывания, какие-то временнЫе константы и т.п.

1. Если делать по спецификации, то примерно половина даташита на любой пик занимает вопрос разруливания коллизий ХАРДОВЫМ модулем i2c - да ну его к черту, по спецификации
2. Согласовать уровни элементарно - по полевому транзистору с низким порогом открывания на линию. Главное, чтобы они были.
3. Главная проблема - ограниченное адресное пространство, пересекающиеся адреса и т.д. Т.е. чем более распространено i2c, тем шире проблема.
4. А вообще штука удобная. Вот например, я сейчас делаю драйвер двигателей, совместимый с OR. Но вчера почти что решил делать с управлением не по RoboMD2, а по i2c. МК с i2c и нужным количеством портов (да, а мне надо много -я делаю на Н-мостах, которые просят 8 пинов на управление каждым, т.е. 2 совершенно свободных порта.) МК стоит 50-70 рублей. Если все-таки не выводить всевозможные дисейблы и енейблы и оставить регистры управления только ШИМ, Направление, Фейл-статус и обратка по току, то МК обойдется в 45 рублей в тритоне. Один МК, два моста, коннектор на подключение двигателей, питания двигателей, питания МК (можно запитать от движков же, кстати, так и надо сделать), а дальше выводи куда хошь - УАРТ, i2C, SPI...

Поленился что-то за МК бегать (опять надо Анатолия просить закупку делать, ехать ему, ехать мне и все из-за 100 руб), да прошивку писать - но, черт побери, пока эти буквы написал, опять захотелось. Кинул два байтика на движки - поехали. Кинул еще два - встали. Первый байт - номер движка, направления вращения, младшие биты ПВМ, второй байт - старшие биты ПВМ. Если нужны статусы - один байт прочитал. Старший байт - статус, младшие - ток.

ВСЕ!!!!!

dccharacter писал(а):Вот например, я сейчас делаю драйвер двигателей, совместимый с OR. Но вчера почти что решил делать с управлением не по RoboMD2, а по i2c.

Тогда вешайте туда еще и 2 разъема энкодеров сдвоенных в распиновке GND,VCC,SIG1,SIG2.

=DeaD= писал(а):

dccharacter писал(а):Вот например, я сейчас делаю драйвер двигателей, совместимый с OR. Но вчера почти что решил делать с управлением не по RoboMD2, а по i2c.

Тогда вешайте туда еще и 2 разъема энкодеров сдвоенных в распиновке GND,VCC,SIG1,SIG2.

Кстати да, забыл вот... А если делать все-таки с i2c, как опрашивать энкодеры? Как аксель? Т.е. делать пин прерывания, регистр прерывания и отдельные регистры на каждый энкодер со значением скорости???

П.С. мне можно тыкать

На каждом энкодере SIG1 (или на каждом - SIG2) надо завести на прерывание по изменению уровня.

=DeaD= писал(а):На каждом энкодере SIG1 (или на каждом - SIG2) надо завести на прерывание по изменению уровня.

Не, ты не понял. Я про то, как вовне отдавать. Это же все еще можно отдавать по i2c, но чтобы постоянно не оправшивать, делается пятый пин INT. Вообще i2c очень много разъемов. Вон вы на ОР пишете, что у вас совместимо с какими-то устройствами. Часть устройств имеют SDA и SDL по краям. Часть - шестипиновая (даже читал где-то что это "стандарт"), там еще INT и AUX

Какой еще пятый пин I2C, не надо этого, концепция I2C - мастер-слейв, вот и не надо её рушить.
Надо на самом ДД делать ПИД-регулятор, если уж делаешь его на I2C.

У тебя же на ДД контроллер стоит - нафига сурово дергать по прерыванию вышестоящий контроллер из-за энкодеров? Это же не катастрофа какая-то случилась непредвиденная