roboforum.ru

Технический форум по робототехнике.

Обсуждение реализации шлюз-контроллера [ORFA]

Разработка стандартизированных модулей для домашнего робостроения.
Правила форума
Правила раздела OpenRobotics

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение =DeaD= » 29 май 2009, 13:37

blindman писал(а):Конечно я могу ошибаться. Но только не надо обвинять меня во лжи, а то так наш диалог может выйти за рамки конструктивного :friends:

Ну ничего себе :) тогда просьба все мои высказывания считать с припиской IMHO, я очень редко в даташиты гляжу, обычно из общих принципов утверждения выдвигаю, тем более что тут вопросы терминологии и нет однозначной привязки к даташитам :)

blindman писал(а):Пример навскидку - драйвер ЖКИ (имеется в виду реальная I2C микруха NXP). Можно последовательно читать данные из видеопамяти, потом считать показания датчика температуры, и вернуться к чтению памяти. Подобных примеров можно немало привести

А как у неё это сделано? Давай разберем, я думаю оттуда мы немедленно выйдем на то решение, которое я предлагаю - если хотим продолжать чтение - в таких драйверах перезапуск запроса отдельным регистром. И это именно фишка драйвера :) выложи даташит на неё - глянем?
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение Vooon » 29 май 2009, 13:41

Обновил таблицу UID'ов в вике и в pyor.
Сейчас интроспектор выдает слкдующее:
Код: Выделить всёРазвернуть
vovan@vovan-pc:~/dev/project/pyor$ orintro.py -d /dev/rfcomm0
< L00\n                                                     
> L00\r                                                     
> \n                                                         
< C0064\n                                                   
> C0066\r                                                   
> \n                                                         
< S000000                                                   
< S0101                                                     
< P\n                                                       
> SWAASR05P\r                                               
> \n                                                         
< S000001                                                   
< S0106                                                     
< P\n                                                       
> SWAASR004001001002P\r                                     
< S000002                                                   
< S0106                                                     
< P\n                                                       
> \n                                                         
> SWAASR006001000C04P\r                                     
> \n                                                         
< S000003                                                   
< S0106                                                     
< P\n                                                       
> SWAASR000101000A02P\r                                     
> \n                                                         
< S000004                                                   
< S0106                                                     
< P\n                                                       
> SWAASR002001000208P\r                                     
> \n                                                         
< S000005                                                   
< S0106                                                     
< P\n                                                       
> SWAASR000001000001P\r                                     
> \n                                                         
< V\n                                                       
> V1.0\r                                                     
> \n                                                         
PyOR version: 0.1.6                                         
UIDs database version: 1.0.2                                                                                                                                     
Serial Gate protocol version: 1.0                                                                                                                               
Selected device: 0x00                                                                                                                                           
                                                                                                                                                                 
Drivers:                                                                                                                                                         
#1 RoboGPIO ADC driver                                                                                                                                           
ADC driver                                                                                                                                                       
ADC_CONF — write 2 byte (WO):                                                                                                                                   
|  byte 1: adc mode & refrence mode                                                                                                                             
|    bit 2: 8 bit/10 bit                                                                                                                                         
|    bit 0-1:                                                                                                                                                   
|      00: External refrence                                                                                                                                     
|      01: AVCC refrence                                                                                                                                         
|      10, 11: Internal refrence                                                                                                                                 
|  byte 2: enabled channels mask                                                                                                                                 
ADC_DATA — write 1 byte start channel, output 1 or 2 bytes.                                                                                                     

UID: 0x0040
Version: 1.0                                                                                                                                                     
Registers: 0x10, 0x11                                                                                                                                           
ADC_CONF: 0x10                                                                                                                                                 
ADC_DATA: 0x11                                                                                                                                                 
                                                                                                                                                                 
#2 RoboMD2 motor driver                                                                                                                                         
Motor driver                                                                                                                                                     
PWMn — motor n speed register (R/W)                                                                                                                             
DIRn — motor n direction register (R/W)                                                                                                                         

UID: 0x0060
Version: 1.0                                                                                                                                                     
Registers: 0x0C, 0x0D, 0x0E, 0x0F                                                                                                                               
     DIR1: 0x0E                                                                                                                                                 
     DIR2: 0x0F
     PWM1: 0x0C
     PWM2: 0x0D

#3 RoboBus SPI driver
SPI driver
<need more information about this driver>

UID: 0x0001
Version: 1.0
Registers: 0x0A, 0x0B
SPI_CONF: 0x0B
SPI_DATA: 0x0A

#4 RoboGPIO digital driver
Digital I/O driver
PORTc — port register (R/W)
DDRc — port direction (WO)

UID: 0x0020
Version: 1.0
Registers: 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09
     DDRA: 0x06
     DDRB: 0x07
     DDRC: 0x08
     DDRD: 0x09
    PORTA: 0x02
    PORTB: 0x03
    PORTC: 0x04
    PORTD: 0x05

Meta information:
     rbgp: PORTB.4, PORTD.7, PORTD.6
     gpio: 0, 0xe3, 0x03, 0x33

#5 Introspection driver
ORFA Introspection driver
INTRO register always 0x00
00 00 — get driver count
00 nn — get driver nn info

UID: 0x0000
Version: 1.0
Registers: 0x00
    INTRO: 0x00

vovan@vovan-pc:~/dev/project/pyor$
Linux user | Firefox user
Аватара пользователя
Vooon
Site Admin
 
Сообщения: 3339
Зарегистрирован: 09 фев 2006, 15:36
Откуда: Москва
Skype: vooon341
прог. языки: Python, C, Bash, JavaScript, C++, PHP
ФИО: Владимир Ермаков

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение blindman » 29 май 2009, 14:33

=DeaD= писал(а):А как у неё это сделано? Давай разберем, я думаю оттуда мы немедленно выйдем на то решение, которое я предлагаю - если хотим продолжать чтение - в таких драйверах перезапуск запроса отдельным регистром. И это именно фишка драйвера :) выложи даташит на неё - глянем?


Я не помню что это за микросхема. Вот пример микрухи попроще, но то же самое - можно читать из памяти, потом прочитать статус, потом возобновить чтение памяти.
PCF2119X_4.pdf
(342.86 КиБ) Скачиваний: 9


Добавлено спустя 1 минуту 41 секунду:
Короче, я утверждаю, что все, что доступно на шине I2C, в наших драйверах можно реализовать, только если к драйверам будет побайтовый доступ.
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

Аватара пользователя
blindman
 
Сообщения: 4130
Зарегистрирован: 29 апр 2008, 21:15
Откуда: Хабаровск
прог. языки: C,C++,Assembler,PHP,Javascript,Ruby, SPIN,Java(?)
ФИО: Андрей Юрьевич

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение =DeaD= » 29 май 2009, 14:33

Чем побайтовый доступ от по 10-байтового принципиально отличается, кроме размера пакета возвращаемого драйвером ядру?
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение blindman » 29 май 2009, 14:56

Тем что если драйвер отдал 10 байт - он уверен, что отдал 10, и что половину из них просто не проигнорировали, потому что мастер прочел только 5.

Добавлено спустя 19 минут 13 секунд:
Мысль. Может и бредовая.

А что если когда шлюз оаботает как I2C slave, ему передавать запросы в том же формате, в каком передаются по уарту? Записали запрос, сразу прочитали ответ.
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

Аватара пользователя
blindman
 
Сообщения: 4130
Зарегистрирован: 29 апр 2008, 21:15
Откуда: Хабаровск
прог. языки: C,C++,Assembler,PHP,Javascript,Ruby, SPIN,Java(?)
ФИО: Андрей Юрьевич

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение Digit » 29 май 2009, 14:59

Тогда только побайтовую версию делать.
К тому же буфферизация при мультимастере не канает, т.к. запрос устройству может прийти от кого угодно. И не надо, Dead, говорить, что надо быть проще :) и2с позволяет мультимастер? Значит потенциально ваши модули могут попасть в мультимастер-среду! :)
злой полицейский
Аватара пользователя
Digit
 
Сообщения: 3339
Зарегистрирован: 27 ноя 2004, 00:42
Откуда: совсем Москва
ФИО: Григорий

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение =DeaD= » 29 май 2009, 15:04

2blindman:

А какая ему разница проигнорировали их или нет? Их и выше могут проигнорировать - это не дело драйвера. Другое дело что если ядро запросят продолжить чтение - оно должно сначала вернуть оставшиеся 5 байт, а только потом начать возвращать остальное. Хотя это конечно повлечет создание системы буферов под каждый регистр на уровне ядра - это я не обдумывал.

Про шлюз как и2с слейв не понял. Там нет возможности сразу сказать сколько длиной будет запрашиваемый ответ.

Добавлено спустя 2 минуты 10 секунд:
Digit писал(а):И не надо, Dead, говорить, что надо быть проще :) и2с позволяет мультимастер? Значит потенциально ваши модули могут попасть в мультимастер-среду! :)

Наши модули много куда могут попасть, но сначала доделываем базовые вещи, потом хватаемся за космические технологии.
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение blindman » 29 май 2009, 15:15

=DeaD= писал(а):А какая ему разница проигнорировали их или нет? Их и выше могут проигнорировать - это не дело драйвера.

Если тот кто запрашивает данные их игнорирует - это его проблема. А если они потерялись по пути - получаем рассинхронизацию мастера и слэйва, и неверный поток данных

=DeaD= писал(а):Другое дело что если ядро запросят продолжить чтение - оно должно сначала вернуть оставшиеся 5 байт, а только потом начать возвращать остальное. Хотя это конечно повлечет создание системы буферов под каждый регистр на уровне ядра - это я не обдумывал.

Да, множественные буфера. Но это во-вторых. А во-первых - между чтениями может быть запись, которая изменит режим работы драйвера, и остаток в буфере потеряет смысл. А может быть и не изменит - тогда остаток в буфере по-прежнему имеет смысл. Отследить это за пределами драйвера невозможно.

=DeaD= писал(а):Про шлюз как и2с слейв не понял. Там нет возможности сразу сказать сколько длиной будет запрашиваемый ответ.

Да это так пока, поток сознания :) С уартом мы как работаем - сначала пишем запрос, потом читает ответ. Ну вот я и подумал, I2C используем просто как транспорт, и по нему передаем запросы и ответы в таком же формате как и с уартом. Этакий I2C поверх I2C :D
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

Аватара пользователя
blindman
 
Сообщения: 4130
Зарегистрирован: 29 апр 2008, 21:15
Откуда: Хабаровск
прог. языки: C,C++,Assembler,PHP,Javascript,Ruby, SPIN,Java(?)
ФИО: Андрей Юрьевич

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение =DeaD= » 29 май 2009, 15:23

blindman писал(а):между чтениями может быть запись, которая изменит режим работы драйвера, и остаток в буфере потеряет смысл. А может быть и не изменит - тогда остаток в буфере по-прежнему имеет смысл. Отследить это за пределами драйвера невозможно.

Мне кажется это не проблема. Мы в любом случае на куче уровней будем работать с буферами - какая нам разница потерял остаток смысл находясь в буфере драйвера или в буфере ядра или в буфере приёмника на хосте или еще где?
А вот мультибуферы на каждый регистр - это действительно я не подумал.

blindman писал(а):Да это так пока, поток сознания :) С уартом мы как работаем - сначала пишем запрос, потом читает ответ. Ну вот я и подумал, I2C используем просто как транспорт, и по нему передаем запросы и ответы в таком же формате как и с уартом. Этакий I2C поверх I2C :D

Не-не-не :) не надо нам этой уличной магии :)
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение blindman » 29 май 2009, 15:31

=DeaD= писал(а):Мы в любом случае на куче уровней будем работать с буферами - какая нам разница потерял остаток смысл находясь в буфере драйвера или в буфере ядра или в буфере приёмника на хосте или еще где?

1. В буфере приемника на хосте не будет данных, потерявших смысл - ибо туда попадут только данные которые хост запрашивал. Как он их использует - его дело, шлюз свою работу выполнил корректно.
2. Если в буфере драйвера - он может это разрулить.
3. А вот в буфере ядра будут находиться данные, которые никто не просил - и режим работы драйвера уже изменился, и он те n байт что остались в буфере выдал бы уже по-другому.
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

Аватара пользователя
blindman
 
Сообщения: 4130
Зарегистрирован: 29 апр 2008, 21:15
Откуда: Хабаровск
прог. языки: C,C++,Assembler,PHP,Javascript,Ruby, SPIN,Java(?)
ФИО: Андрей Юрьевич

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение =DeaD= » 29 май 2009, 15:45

blindman писал(а):1. В буфере приемника на хосте не будет данных, потерявших смысл - ибо туда попадут только данные которые хост запрашивал. Как он их использует - его дело, шлюз свою работу выполнил корректно.

Почему это данные находясь в другом месте не могут потерять смысл? :)

blindman писал(а):2. Если в буфере драйвера - он может это разрулить.

Понятно теоретически, но вот как практически разруливать - каждый раз надо будет что-то новое выдумывать. ИМХО это какая-то непонятная борьба с самой концепцией буферизации - когда в буфере на любом уровне может находиться то, что уже никуда не нужно.

blindman писал(а):3. А вот в буфере ядра будут находиться данные, которые никто не просил - и режим работы драйвера уже изменился, и он те n байт что остались в буфере выдал бы уже по-другому.

Совершенно не ясно почему остаток запроса он выдал бы по другому это как раз мне кажется неочевидным вредным фактором, отлаживать который будет очень увлекательно - прочитал чуть позже хвост ответа на один и тот же запрос - и получил вместо книги фигу. Это всё равно что в банк отправляешь запрос и тебе в начале ответа говорят что сумма на твоём счете такая-то, потом в середине ответа в него вставляют транзакцию новую и в конце ответа сумма на твоём счете уже другая - писать программы с учетом таких фишек сложнее на порядок.
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение blindman » 29 май 2009, 15:51

Пример. Читаем АЦП в 16-битном режиме. Нужно прочитать 4 канала, от 0 до 3. Ядро запросило 10 байт, в результате драйвер выдал данные 5 каналов. Теперь надо прочитать каналы 4-7 в 8-битном режиме. Пишем значение в регистр конфигурации, начинаем читать 4 байта. В результате получаем лажу в первых 2 прочитанных байтах.
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

Аватара пользователя
blindman
 
Сообщения: 4130
Зарегистрирован: 29 апр 2008, 21:15
Откуда: Хабаровск
прог. языки: C,C++,Assembler,PHP,Javascript,Ruby, SPIN,Java(?)
ФИО: Андрей Юрьевич

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение =DeaD= » 29 май 2009, 15:54

Обращение к регистру сбрасывает все буферы. Продолжаем читать только если не было обращений к регистрам.

Добавлено спустя 53 секунды:
Либо явно объявляем - обращение в какой регистр - продолжение чтения, а в какой - перезапуск запроса. Но тогда это действительно всё на уровне драйвера.
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение blindman » 29 май 2009, 15:56

С чего это оно сбрасывает? Драйвер то отдал уже данные - может они еще валидны, откуда ядро-то об этом знает?
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

Аватара пользователя
blindman
 
Сообщения: 4130
Зарегистрирован: 29 апр 2008, 21:15
Откуда: Хабаровск
прог. языки: C,C++,Assembler,PHP,Javascript,Ruby, SPIN,Java(?)
ФИО: Андрей Юрьевич

Re: Обсуждение реализации шлюз-контроллера [ORFA]

Сообщение =DeaD= » 29 май 2009, 16:04

С того что мы прописали жестко - если обращаемся к этому же i2c устройству к другому регистру - считай что сказал что тебе по старому запросу данные больше ненужны :)

Или тогда надо, как я уже и предлагал, разделить обращение к каким регистрам - продолжить чтение ответа, а к каким - инициировать помещение в буфер нового ответа.
Проект [[Open Robotics]] - Универсальные модули для построения роботов
Аватара пользователя
=DeaD=
 
Сообщения: 24218
Зарегистрирован: 06 окт 2004, 18:01
Откуда: Ебург
прог. языки: C++ / PHP / 1C
ФИО: Антон Ботов

Пред.След.

Вернуться в Open Robotics

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0

cron