Обсуждение MT7688AN HLK-7688A

pvvx

Активный участник сообщества
Даже описанное в Onion сделать не смогли - не правильно выставляется CS :) не ждет полного завершения передачи.
Не удивительно - так и выходит у повторяшек: то работает/ то нет
[inline]spi-config -d /dev/spidev0.1 -s 100000 | echo 0123456789abcdef0123456789abcdef | spi-pipe -d /dev/spidev0.1 -b 32[/inline]:
upload_2019-9-19_22-55-57.png
 

pvvx

Активный участник сообщества
Победил эти "дрова" на SPI.
Full Duplex. Для теста стоит резистор 8к с SDO на SDI... От этого и скорость не разогнать, а замыкать незя - spi-flash...
Код:
root@OpenWrt:/# spi-config -d /dev/spidev0.1 -s 500000 | cat /etc/banner | spi-p
ipe -d /dev/spidev0.1 -b 396
  _______                     ________        __
|       |.-----.-----.-----.|  |  |  |.----.|  |_
|   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
|_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
-----------------------------------------------------
OpenWrt 18.06.4, r7808-ef686b7292
-----------------------------------------------------
root@OpenWrt:/#
upload_2019-9-20_11-27-58.png
Блоки на 1 байт - 4 кило тоже гоняет... Пробовал и больше, но лень сверять.
Остаточные дела по /dev/spidev0.1 :
  1. Шина используется для доступа к SPI-Flash, а семафора нет. Сбивает установки spidev0.1.
  2. Не подключил DMA. Оставлено на потом.
  3. Есть неясный аппаратный глюк с текущими установками SPI - если первый байт блока имеет какое-то хитрое значение (диапазон типа символов "abcdef"), то наблюдается фронт к "1" на весь первый CLK, что можно считать как передачу ложного "1" (старшего бита), но сам приемник MT7688 его не фиксирует - хороший глюк. Для обхода этого глюка требуется оборудование и комп помощьнее, чем у меня тут на даче :) Т.е. исправлю когда буду в городе.
 

pvvx

Активный участник сообщества
Для теста исходник во вложении. Дописывайте/переписывайте сами, т.к. следующая версия будет закрытая.
 

Вложения

pvvx

Активный участник сообщества
От вас нужны PR в upstream. Иначе это труд в помойку.
Он не нужен, т.к. у MT7688A баг.
Она сжирает первый бит блока данных буфера на передачу. Хотите передать 0x80 - передаст 0x00 (на осциллограмме вообще не будет даже импульсa).
И если выставляется первый бит передачи из блока данных буфера (например передаем 0xFF) то это происходит одновременно с активным стробом фронта CLK.
И это не полное описание бага - там первый бит пересекается со вторым. И пофигу какие установки от старшего к младшему или наоборот, режимы 0..3, имеющиеся задержки....

На самой низкой скорости:
root@OpenWrt:/# spidev_test -D /dev/spidev0.1 -s 50000 -p "\xCA" -v
spi mode: 0x0
bits per word: 8
max speed: 50000 Hz (50 KHz)
TX | CA __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ | К
RX | 4A __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ | J
upload_2019-9-20_15-30-24.png
root@OpenWrt:/# spidev_test -D /dev/spidev0.1 -s 50000 -p "\xFF" -v
spi mode: 0x0
bits per word: 8
max speed: 50000 Hz (50 KHz)
TX | FF __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ | .
RX | 7F __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ |
upload_2019-9-20_15-38-12.png

root@OpenWrt:/# spidev_test -D /dev/spidev0.1 -s 50000 -p "\x80123456789abcdef\x80" -v
spi mode: 0x0
bits per word: 8
max speed: 50000 Hz (50 KHz)
TX | 80 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66 80 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ | Ђ123456789abcdefЂ
RX | 00 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ | .123456789abcdef.
upload_2019-9-20_15-39-45.png upload_2019-9-20_15-40-19.png

Но чтение работает.
Т.е. если в дровах выбираем длину передающего буфера в 16 байт, то каждый 16-й не должен иметь активный старший бит... Так жить можно.

Закрытая - нарушение GPL!
Ни в коем разе. Если кто получит устройство и по его особой просьбе будут выданы исходники - сразу все, кучей в Гега-Террабайты, без разбору и уточнений - пусть всю жизнь ищет зависимости и прочее :)
 

pvvx

Активный участник сообщества
Короче выбираете что вам лучше -
  • пропускать каждый первый передающийся бит в 1..16-ом байте (длина буфера задается до битов) и использовать Full Duplex (до 40..80 Mpbs)
  • передавать отдельно (HalfDuplex) без бага, принимать тоже отдельно.
  • передавать стартуя из адресного буфера (HalfDuplex) и эти первые биты не иметь возможности принять пока идет буфер адреса и команды. Тогда длина всего буфера 36 байт, а далее повтор.
 

Алексей.

Active member
Он (uboot) успешно стартовал в 4-х байтной адресации, выполнил загрузку прошивки в ram, успешно от эрейсил флешку от 0x50000 до 0x2000000, скопировал из рама во флеш, а на ресете завис. После дерганья за PORST_N он оживает и стартует загруженную прошивку.
 

pvvx

Активный участник сообщества
Я ныне тестирую что можно сделать с этим: 695.76 руб. 21% СКИДКА|300 м беспроводной сигнальный повторитель wifi беспроводной усилитель сигнала мини беспроводное реле двойной сетевой порт-in Беспроводные маршрутизаторы from Компьютер и офис on Aliexpress.com | Alibaba Group

Чип немного отличается - MT7628KN со встроенной RAM. Для работы нужна только внешняя SPI-Flash...
Для многих поделок - достаточный чип и стоит (Роутер WR02M) в готовой коробке с разъемами и БП всего до 700 руб, если поштучно...
Как супер замена ESP32 пойдет.
 

Алексей.

Active member
Нужен был опенссл версии 1.1.x, в релизах v18.06.x только 1.0.x.
Взял транк openwrt-19.07, опенссл подходящий оказался, а с драйвером spi-mt7621 сюрприз.
В mt7621_spi_probe инициализируют struct spi_controller *master в полудуплекс
master->flags = SPI_CONTROLLER_HALF_DUPLEX;
Прежнего mt7621_spi_transfer_full_duplex просто нет.
Из за этого при использовании фулдуплекса, когда указываю в struct spi_ioc_transfer и tx_buf и rx_buf для одного сообщения, получаю -EINVAL
При выполнении транзакции из двух сообщений, в первом только tx_buf а во втором только rx_buf, ошибок -EINVAL нет.
 

pvvx

Активный участник сообщества
а с драйвером spi-mt7621 сюрприз.
В mt7621_spi_probe инициализируют struct spi_controller *master в полудуплекс
master->flags = SPI_CONTROLLER_HALF_DUPLEX;
Прежнего mt7621_spi_transfer_full_duplex просто нет.
В релизах нет и не будет, т.к. аппаратный баг.
Несколько страниц описывали что и с чем там в SPI ...
Кратко, если не прочитали:
Т.е. если внутри самих дров выбираем длину передающего буфера у SPI в 16 байт (а больше и не сделать), то каждый 16-й не должен иметь активный старший бит...
Или так, если ещё короче: При передаче в full_duplex на SPI будет выбит первый бит FIFO и нарушен CLK.
В режиме full_duplex бага с CLK на защелке на выдачу первого бита из буфера SPI.
 

Алексей.

Active member
Если отказаться от фулдуплекс, использовать только халфдуплекс, то бага с первым выбитым битом не будет?
Типа работаем с периферийным устройством как с флешкой, сначала передаем инструкцию, после принимаем или передаем данные.
 

pvvx

Активный участник сообщества
Если отказаться от фулдуплекс, использовать только халфдуплекс, то бага с первым выбитым битом не будет?
Не будет. Баг только в режиме full_duplex. когда буфер SPI разбит на два - приемный и передающий и они работают синхронно.
Типа работаем с периферийным устройством как с флешкой, сначала передаем инструкцию, после принимаем или передаем данные.
Да.
 

pvvx

Активный участник сообщества
Типа работаем с периферийным устройством как с флешкой, сначала передаем инструкцию, после принимаем или передаем данные.
Если работаете как с Flash - у данного контроллера есть такой аппаратный режим и он Half-Dupleх, но транзакция ограничена аппаратным буфером на передачу команды и адреса и 32 приемных байта. По этому с Flash глюка нет.
 

pvvx

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

Алексей.

Active member
Проверил на стм-ке, она как слейв работает.
Отправляю ей в первом сообщении 4 байта, а в следующим сообщении ожидаю 4к байта, как ни странно работает.
Стм-ка в обработчике прерывания dma который на прием, получаю те самые 4 байта от мастера и отправляю мастеру 4к байта.
Пока не проверил передачу от мастера больших блоков на слейв.
 

pvvx

Активный участник сообщества
Пока не проверил передачу от мастера больших блоков на слейв.
Вся работа ведется CPU с буфером SPI. Предельный прием 32 байта = размер аппаратного буфера SPI.
На передачу - больше на 4 байта, т.к. используют и буфер команды-адреса.
 

Алексей.

Active member
Вся работа ведется CPU с буфером SPI. Предельный прием 32 байта = размер аппаратного буфера SPI.
В драйвере я это видел, я из юзер-спейса через драйвер работаю.
Сначала сбило с толку в openwrt-19.07 пример работающий в фулдуплекс на v18.06 перестал работать. Пока не обложил трассировкой вызовы в драйвере, не мог понять откуда -EINVAL взялся.
 

pvvx

Активный участник сообщества
Короче - при большой скорости SPI и большой загрузке CPU разрыв при приеме или передаче больших блоков гарантирован.
В режиме Slave использовать при более 32-х байтах на блок - незя.
Т.к. нет DMA - Считаем что нет SPI контроллера.
 
Сверху Снизу