cnc-club.ru

Кулибин1437 писал(а):+-DATA к (Плате YL-128 RS422)-BA

Надо наоборот.

В описании указаны тайминги и т.п. - их надо выдерживать.

Нашёл тут
http://arduino.ru/forum/programmirovanie/ssi-interfeis
монитор в ардуинке стал что то писать. И при вращении энкодера цифры меняются.
Но как то не системно.
По крайней мере светодиод чтения на плате согласования RS422 стал вспыхивать слабенько.
Похоже действительно энкодер стал какую то инфу выдавать.
Но надо наверное разрядность менять энкодера в программе.?
И почему то временные задержки в програмке совершенно другие чем рекомендованно производителем, их наверная надо менять?

UAVpilot писал(а):

Кулибин1437 писал(а):+-DATA к (Плате YL-128 RS422)-BA

Надо наоборот.

В описании указаны тайминги и т.п. - их надо выдерживать.

Пардон. Не увидел ответ. На форуме чипмейкер както глазу было привычнее, а тут ещё не привык, извините.
В сысле +-помнеять или YZ-BA.
То есть в скетче там где все задержки, тайминги прописаны, менять всё по инструкции?

Только АВ.
Устройства с SSI часто чуствительны к частотам, и задержкам перед началом передачи.

Вот сам что то состряпал по таймингам, пока что .
Посмотрите пожалуйста, правильно ли создаётся сигнал CLOCK.
Пока мозгов только на это хватило(( (.
Но осцилограф мой с1-72, который лет 15 не доставал, кажет какие то тайминги совершенно отличающиеся в глобально большую сторону.
Или возможно он уже не справляется с внутренними утечками кондёров и т. д. и т.п.
Вот скетч.

void setup()
{
pinMode(6, INPUT); //DATA+
pinMode(5, OUTPUT); //CLOCK+
digitalWrite(5,HIGH);
Serial.begin(115200);
}

void loop()
{
digitalWrite(5,LOW); //на 5 пине (CLOCK+) низкий
delayMicroseconds(5); //задержка t1
//цикл 24 периода для 24 бит энкодера
for (int i=0; i <= 24; i++){
digitalWrite(5,HIGH); //на 5 пине (CLOCK+) высокий начало периода Т
delayMicroseconds(4); //задержка на 5 пине
digitalWrite(5,LOW); //на 5 пине (CLOCK+) низкий
delayMicroseconds(4); //задержка на 5 пине низкого-конец периода Т
// Serial.println(i); //попытка вывести на монитор, но время удлинняет дико(((
// и так 24 раза
}
delayMicroseconds(10); // задержка t3 для успевания выдачи инфы из DATA+
}

А по считыванию DATA и формированию цифры со сдвигами бит, для меня вообще тёмный лес

delayMicroseconds не самый удачный вариант для задержек. Собственно как и DigitalWrite. Они слишком медленно работают. Лучше по прерываниям и с прямым обращением к пинам. У вас ардуина на какой частоте работает?

UNO на 16 мгц.
Как это?
Пример какой нибудь, можете предложить, но или что читать.
Пока я с Ардуино к сожалениюна ВЫ(((.

P/S/ чтото вроде нашЁл

Такой скетч набросал, сильно не пинайте. Художник вояет как может))

void setup() {
}
void loop() {

PORTD=0;
for (int i=0; i <= 24; i++){
DDRD = B10111111; // назначает выводы Arduino 5 выходными, - входным

PORTD = B00000000; // устанавливает 0 на цифровых выводах 5
PORTD = B00100000; // устанавливает 1 на цифровых выводах 5
}
}


период между мелкими импульсами стал 0,4мкСек, а полный период 12мкСек-горраздо шустрее.
Только как задержки тогда делать.
Не набирать же ноликами и единичками весь тайминг?
Или всё же так и набирать?

Похоже вы описание протокола невнимательно читали...
Энкодер начинает слать данные после того, как на CLOCK будет выдержан высокий уровень в течении 20uS или более.

UAVpilot писал(а):Энкодер начинает слать данные после того, как на CLOCK будет выдержан высокий уровень в течении 20uS или более.

Пардон, но я ещё раз пересмотрел инструкцию, но не нашёл про 20мкС.
Вот ещё раз прилагаю инструкцию. Также перерисовал из неё тайменг и вырезал куски текста. Может конечно не нужно читать инструкции производителя, или китаёзи внесли какуюто загадку, или из за трудностей перевода может быть
Я если правильно перевёл.
То тайменг сигнала CLOCK таков, для рекомендованной ими частоты 125кГц;
1) “1”
2) “0”-t1-4mks
3) “1”-T-8/2=4 mks начало периода
4) “0”-T-8/2=4 mks конец периода
5) Повторяем 3) и 4)-ещё 23раза(для24 бит(8 mks*24=192 mks)-n*T)
6) “1”-15mks-4mks(полпериода)=11 mks
7) Возвращаемся к 1)
Таким образом общий цикл составляет 4+192+11=207mks
Если я правильно понял, между пачками импульсов может быть и большее время!???
Где я не правильно что понял, подскажите пожалйста

P.S. Кстати непосредственная адресация в разы быстрее чем стандартные команды , Спасибо большое, Вам nevkon
Циклами сделал каждую задержку и чтото рядом уже, похожее. Правда не могу понять как количество циклов завязывается с временем, приходиться методом подбора только.

В синхронных интерфейсах без сигнала выбора устройства (это который CS и т.п.) действительно на клоке должна быть пауза. Это нужно для того, чтобы не получилось рассинхронизации клока с данными. Т.е. ведомый должен иметь возможность понять, что сейчас вот пауза, значит активных транзакций нет и можно привести регистр приемника к исходному состоянию. Благодаря этому если, к примеру, принимающий из-за помех пропустит один тактовый импульс, или получит ложный то только одна посылка будет испорчена. По таймауту все будет по новой нормально работать. А если данные идут без видимых пауз, то тактовая и данные из-за помех могут разъехаться. На твоей диаграмме я вот тоже не вижу требований по этой паузе. Возможна она указана в другом месте... UAVpilot говорил видимо именно о ней.

N1X писал(а):На твоей диаграмме я вот тоже не вижу требований по этой паузе.

t3, скорее всего.

Похоже

Сергей Саныч писал(а):t3, скорее всего.

'njn cfvsq а этот t3 можно сколь угодный делать в большую сторону?
Я так понимаю, никак нельзя в меньшую сторону, чтоб энкодер видел данное время и сбрасывался или чтото делал(мне не понятное )

Кулибин1437 писал(а): этот t3 можно сколь угодный делать в большую сторону?

Да. Но только его. Остальная времянка должна быть выдержана в пределах допусков.

Сергей Саныч писал(а):Да. Но только его.

Спасибо. Досоздаю клок и потом будем изучать чтение)))

слушайте.
Если я создам аппаратное прерывание, то оно не будет удлиннять те самый тайменговые параметры созданный для сигнала CLOCK?

Кулибин1437 писал(а):Если я создам аппаратное прерывание, то оно не будет удлиннять те самый тайменговые параметры созданный для сигнала CLOCK?

Будет. В этом один из недостатков программного способа формирования задержек.
По хорошему надо организовать прерывание по таймеру и в нем уже работать с SSI.
Но, насколько мне известно, тут придется выходить за пределы типовых решений для Ардуино. Хотя сам МК на это способен.

N1X писал(а):Возможна она указана в другом месте... UAVpilot говорил видимо именно о ней.

Да, именно о ней (tp, tm):



расписано в спеках на протокол SSI.

Сергей Саныч писал(а):По хорошему надо организовать прерывание по таймеру и в нем уже работать с SSI.

В некоторых МК можно аппаратный SPI на это "подрядить", если разрядность данных позволяет.

Про tp, у китайцев ни слова...

Сергей Саныч писал(а):Будет. В этом один из недостатков программного способа формирования задержек.
По хорошему надо организовать прерывание по таймеру и в нем уже работать с SSI.
Но, насколько мне известно, тут придется выходить за пределы типовых решений для Ардуино. Хотя сам МК на это способен.

А если одна ардуинка тупо формирует CLOCK, а вторая считывает DATA по прерыванию, возможно идея в качестве бреда.
Или применить более шуструю(ИМХО) ардуинку типа http://arduino.ru/Hardware/ArduinoDue (32разрядный с тактовой 84мГц) , возможно он справиться с временными требованиями и не выйдет за заданные рамки.
Хотя любая команда тут же тормозит все тайминги и постоянно надо будет контролировать их, пока закончишь проект.
Не хватает к сожаленю современного осцилографа, мой С1-72 трудно ловит и синхронизируется, чтоб чётко промерять все задержки((

P.S. или заказать решение задачи, заплатив деньги, и в следующий раз залить скетч и готово, если конечно второй раз понадобиться