roboforum.ru

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

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

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

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

Обновил таблицу 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$

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

Я не помню что это за микросхема. Вот пример микрухи попроще, но то же самое - можно читать из памяти, потом прочитать статус, потом возобновить чтение памяти.


Добавлено спустя 1 минуту 41 секунду:
Короче, я утверждаю, что все, что доступно на шине I2C, в наших драйверах можно реализовать, только если к драйверам будет побайтовый доступ.

Чем побайтовый доступ от по 10-байтового принципиально отличается, кроме размера пакета возвращаемого драйвером ядру?

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

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

А что если когда шлюз оаботает как I2C slave, ему передавать запросы в том же формате, в каком передаются по уарту? Записали запрос, сразу прочитали ответ.

Тогда только побайтовую версию делать.
К тому же буфферизация при мультимастере не канает, т.к. запрос устройству может прийти от кого угодно. И не надо, Dead, говорить, что надо быть проще и2с позволяет мультимастер? Значит потенциально ваши модули могут попасть в мультимастер-среду!

2blindman:

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

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

Добавлено спустя 2 минуты 10 секунд:

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

Наши модули много куда могут попасть, но сначала доделываем базовые вещи, потом хватаемся за космические технологии.

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

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

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

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

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

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

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

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

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

Не-не-не не надо нам этой уличной магии

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

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

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

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

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

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

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

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

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

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

Добавлено спустя 53 секунды:
Либо явно объявляем - обращение в какой регистр - продолжение чтения, а в какой - перезапуск запроса. Но тогда это действительно всё на уровне драйвера.

С чего это оно сбрасывает? Драйвер то отдал уже данные - может они еще валидны, откуда ядро-то об этом знает?

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

Или тогда надо, как я уже и предлагал, разделить обращение к каким регистрам - продолжить чтение ответа, а к каким - инициировать помещение в буфер нового ответа.