CS это простой GPIO, нет необходимости их выделять в командах SPI.
SPI обмен преобразовать в I2C-подобный достаточно просто, достаточно писать рез-т обмена в буфер.
Вообще самый простой протокол:
< S 20 01 S 21 01 P
> 70
< S 60 FF 01 02 03 S 61 03 P
> 01 02 03
Максимально близок к I2C, минимум заморочек
roboforum.ru
Технический форум по робототехнике.
Обсуждение протокола шлюз-контроллера
Правила форума
Правила раздела OpenRobotics
Правила раздела OpenRobotics
Re: Обсуждение протокола шлюз-контроллера
Можно CS сделать не GPIO, а просто 3 разными SPI-адресами.
Re: Обсуждение протокола шлюз-контроллера
Dead, ну что? На чем-то остановились?
Re: Обсуждение протокола шлюз-контроллера
Пока ни на чем 
ща чуть разгребусь, тут в офисе за моё отсутствие какой-то бардак устроили 
ща чуть разгребусь, тут в офисе за моё отсутствие какой-то бардак устроили Re: Обсуждение протокола шлюз-контроллера
А может все-таки признать, что внутренние устройства МК, устройства поключенные к SPI и I2C-устройства - разные вещи, управляются по-разному, и не стоит все их пихать в одну кучу?
Re: Обсуждение протокола шлюз-контроллера
Не надо так признавать это рушит универсальность и заставляет писать сложные драйверы на стороне ПК...
это рушит универсальность и заставляет писать сложные драйверы на стороне ПК...Re: Обсуждение протокола шлюз-контроллера
Ну пока что рушить нечего - ничего действительно универсального предложено не было.
Re: Обсуждение протокола шлюз-контроллера
Дописал парcер команд.
Основывался на userial, но выкинул все лишнее
Комманды:
S<aa><data>[S<aa><data>]P — I2C
R<aa><rr>[<ll>] — register read
W<aa><rr><data> — register write
C<freq> — set I2C speed
X — clear
V — get version
#<any-data> — comment
Основывался на userial, но выкинул все лишнее
Комманды:
S<aa><data>[S<aa><data>]P — I2C
R<aa><rr>[<ll>] — register read
W<aa><rr><data> — register write
C<freq> — set I2C speed
X — clear
V — get version
#<any-data> — comment
- Код: Выделить всё • Развернуть
vovan@vovan-laptop:~/src/i2c-gate$ ./i2c-gate.elf
s 20 01 s 21 01 p
# I2C write address: 0x20
# I2C write byte: 0x01
# I2C read address: 0x21
# I2C read byte 1: 0xFF
SAASAFFP
r2001
# I2C write address: 0x20
# I2C write byte: 0x01
# I2C read address: 0x21
# I2C read byte 1: 0xFF
SAASAFFP
w200102
# I2C write address: 0x20
# I2C write byte: 0x01
# I2C write byte: 0x02
SAAAP
s20 80 \f\i\l\e\n\a\m\e \. \w\a\v p
# I2C write address: 0x20
# I2C write byte: 0x80
# I2C write byte: 0x66
# I2C write byte: 0x69
# I2C write byte: 0x6C
# I2C write byte: 0x65
# I2C write byte: 0x6E
# I2C write byte: 0x61
# I2C write byte: 0x6D
# I2C write byte: 0x65
# I2C write byte: 0x2E
# I2C write byte: 0x77
# I2C write byte: 0x61
# I2C write byte: 0x76
SAAAAAAAAAAAAAAP
s20 \
p
# I2C write address: 0x20
# I2C write byte: 0x0A
SAAP
Re: Обсуждение протокола шлюз-контроллера
А интерфейсы можно объявить по которым этот парсер будет работать с i2c реальным или с локальными устройствами?
И еще - есть команда задающая адрес локального устройства?
И еще - есть команда задающая адрес локального устройства?
Re: Обсуждение протокола шлюз-контроллера
Пока такой команды нет, но добавить не сложно.
Выбор канала тоже можно сделать, там сейчас заглушки вместо реальной работы с I2C, чтоб отлаживать на пк.
Добавлено спустя 5 минут 50 секунд:
Я только сомневаюсь в выводе i2c запростов.
сейчас используется вариант из userial (только без I в начале)
но из него нельзя определить какая операция проводилась (чтение/запись)
Думаю заменить Ack адреса на R/W в ответе.
Выбор канала тоже можно сделать, там сейчас заглушки вместо реальной работы с I2C, чтоб отлаживать на пк.
Добавлено спустя 5 минут 50 секунд:
Я только сомневаюсь в выводе i2c запростов.
сейчас используется вариант из userial (только без I в начале)
но из него нельзя определить какая операция проводилась (чтение/запись)
Думаю заменить Ack адреса на R/W в ответе.
Re: Обсуждение протокола шлюз-контроллера
А интерфейс программный пока не прописывал которому должен удовлетворять как модуль работы с реальным i2c из под этого протокола, так и модуль контроллера? Чтобы удовлетворяющий этому интерфейсу программный функционал можно было быстро и просто скомпилировать как в i2c-SLAVE-контроллер, так и в Шлюз-контроллер.
Re: Обсуждение протокола шлюз-контроллера
Этот модуль реализует только шлюз usart-to-i2c.
Обработка локальных запросов — задача другого модуля, и поскольку вызов его аналогичен запросу и2с то и изменять для слейва не потребуется.
Вот как я себе представляю структуру:
Добавлено спустя 3 часа 1 минуту 7 секунд:
Обработка локальных запросов — задача другого модуля, и поскольку вызов его аналогичен запросу и2с то и изменять для слейва не потребуется.
Вот как я себе представляю структуру:
Добавлено спустя 3 часа 1 минуту 7 секунд:
- Код: Выделить всё • Развернуть
vovan@vovan-laptop:~/src/i2c-gate$ ./i2c-gate.elf
laa
# i2c_set_localhost(0xaa)
LAA
raa0102
# i2c_master_start(0xaa, 0) -> localhost
# i2c_master_txc(0x01) -> localhost
# i2c_master_start(0xab, 1) -> localhost
# i2c_master_rxc(0xff, 1) -> localhost
# i2c_master_rxc(0xff, 0) -> localhost
SWASRFFFFP
l20
# i2c_set_localhost(0x20)
L20
waa0102
# i2c_master_start(0xaa, 0) -> real
# i2c_master_txc(0x01) -> real
# i2c_master_txc(0x02) -> real
SWAAP
s200102s2101saa01p
# i2c_master_start(0x20, 0) -> localhost
# i2c_master_txc(0x01) -> localhost
# i2c_master_txc(0x02) -> localhost
# i2c_master_start(0x21, 1) -> localhost
# i2c_master_rxc(0xff, 0) -> localhost
# i2c_master_start(0xaa, 0) -> real
# i2c_master_txc(0x01) -> real
SWAASRFFSWAP
- Вложения
-
structure.uxf.gz- http://www.umlet.com
- (953 байт) Скачиваний: 13
Re: Обсуждение протокола шлюз-контроллера
А можно исходник или еще чего? А то непонятно вообще куда потом цеплять свой контроллер локальный
Re: Обсуждение протокола шлюз-контроллера
Исходники конечно же доступны:
(можно сделать клон, а не качать архив)
(можно сделать клон, а не качать архив)
Re: Обсуждение протокола шлюз-контроллера
Если я всё правильно понял, то там нечестный КА - например если читаем "С", то не выходим из обработки пока не получим еще 2 символа - так? А это завешивает основную программу или нет?