repstosw

Вот тут ещё один умелец приделал tinyusb к Allwinner H3. https://github.com/uli/allwinner-bare-metal usb.h и usb.c у названного выше проекта. Для H3. Надеюсь, что host HID Kbd там нормально заработает

Что такое LS клавиатура? Есть обычная клавиатура от ПК с USB радио-выходом. Там кстати, в tinyusb-master\examples\host\hid_controller есть пример, но в файле only.txt заявлена поддержка только таких чипов: И ещё вот пример как читать клавиши: https://github.com/dquadros/RPTerm/blob/main/keybd.cpp

https://github.com/hathach/tinyusb Насколько сильно отличается USB у T113-s3 и F1C*00s ? Регистры совпадают? Понятно дело, что клоки и гейты, делители частоты и база регистров будут другими.

Требуется подключить USB-клавиатуру от ПК к USB T113-s3. Нужна кросс-платформенная библиотека с ядром USB и классом USB HID Keyboard, на которую нужно натянуть базовый адрес регистров USB хоста у T113-s3, включение клоков и гейтов и обработчик прерывания для USB. Есть ли такая библиотека? С готовым дескриптором клавиатуры. Типа как FatFs, который кроссплатформенный - туда только чтение-запись сектора вставить и всё!

Как включить L2 кэш у T113-s3 ? Какой регистр (название) и номер бита? Ничего не могу найти про L2: ни документации, ни примеров.

В последней версии исправили: https://github.com/xboot/xfel/releases/tag/v1.2.9

Использую SPI NOR mx25l12835fm, подключенную к SPI T113-s3. При попытке сделать стирание размером 64 KB от начала командой: xfel spinor erase 0x00000000 0x00010000 Стирается 0x12000 байт (72 кБ вместо 64 кБ). Проверяю следующей командой: xfel spinor read 0x00000000 0x01000000 dump.bin При просмотре дампа dump.bin символы 0xFF до адреса 0x12000: Наткнулся на это случайно, когда записывал SPL загрузчик размером 64 кБ. Ниже шёл диск FAT, который впоследствии разрушается стиранием.

Пока проблему решил следующим образом: размер сектора принимается за 512 байт. В функциях чтения и записи секторов проделываются необходимые вычисления и пересчёт на то что и сколько нужно прочесть-стереть-записать. Размер сектора = 512 байт (Винда) Максимальный размер блока записи = 256 байт Размер блока для стирания = 4096 байт Размер блока чтения - произвольный Чтение секторов делается просто: void NOR_ReadSector(u32 sector,u8 *buf,u32 count) { NOR_read(sector*512,buf,count*512); } С записью секторов - сложно + стирание: void NOR_EraseWriteSector(u32 sector,u8 *buf,u32 count) { u32 LBA=sector*512; u32 Bytes=count*512; u32 LBAs=(LBA/4096)*4096; u32 Add=LBA-LBAs; u32 Bytess=Bytes+Add; u32 Count=Bytess/4096; if(Bytess%4096)Count++; u32 Count4=Count*4096; u8 *save=malloc(Count4); NOR_read(LBAs,save,Count4); for(int i=0;i<Count;i++)NOR_erase(LBAs+(i*4096)); memcpy(&save[LBA-LBAs],buf,Bytes); for(int i=0;i<Count4/256;i++)NOR_write(LBAs+(i*256),&save[i*256],256); free(save); } Всё работает: форматирование, метка диска, чтение и запись файлов: как на стороне МК, так и на стороне ПК через USB Mass Storage. Из минусов: приходится тереть 8 виндовых секторов вперёд.

Сделал FatFs с размером сектора 4096 байт: диск форматируется, файловая система монтирруется, задаётся метка диска, создаётся файл для записи, файл записывается и закрывается. Работает в микроконтроллере и в Линуксе на ПК (через USB). Но винда неправильно видит этот диск и требует его отформатировать. В DiskImager показываются только первые 512 байт каждого сектора SPI NOR (из 4096 байт). Есть ли способ заставить винду работать с сектором 4096 байт?

Есть SPI NOR, которая подключена через SPI к Allwinner T113-s3. Функционал записи, чтения, стирания работает. Запись - блок до 256 байт Стирание - блок 4096 байт Необходимо прикрутить FatFs к SPI NOR и отобразить диск через USB для ПК. ПК тоже должен уметь читать и писать файлы в SPI NOR. Есть проблема: ПК видит только съёмные диски с размером сектора 512 байт. Если записать такой кусок я ещё смогу - 2 раза по 256 байт для SPI NOR. То как быть со стиранием? Стираются сразу 4096 байт. В идеале, заставить FatFs работать с размером сектора 4096 байт, но Windows в ПК такой диск не распознаёт и требует форматирования. Что можно сделать? Как избежать лишнего стирания? (копировать все 8 блоков по 512 байт каждый, менять один и записывать все 8 - это сильно уменьшит ресурс по стиранию SPI NOR).

Когда-то я ковырялся со вторым TCON (который для TV-OUT) в T113-s3. Тоже не запускался, пока не проинициализировал TOP-регистры. Возможно, с включением LVDS аналогично. Тоесть мало установить и проинициализировать то, что очевидно. Ещё надо разрешить тактирование TOP-регистров и проинициализировать их. О существовании этих регистров рассказал сорец Tina-Linux для T113-s3. Как раз - тот случай, когда делаешь всё правильно, а оно не работает. Потому что не всё разрешено.

В доке на DE2.0 есть информация про ROT ("поворачиватель"), причём очень подробная. Но у T113-s3 нет глобального ROT: я опрашивал регистр контроля, после запуска бит должен обнуляться, но не обнуляется. Плюс та портянка, что для фрейм-буфера T113-s3 в линуксе используется, не содержит определений адресов этого узла. Всё работает и очень быстро. Делал так: вначале поворот (с одинаковыми форматами входных и выходных данных), затем конверсия. Минус этого способа в том, что надо промежуточный буфер заводить, при этом с учётом поворота, он должен быть квадратным со значением максимальной стороны прямоугольника. И напрячь голову, чтобы правильно расчитать параметры для G2D. В линуксовой портянке на G2D кстати, есть printf который говорит что поворот и блендер(включая конвертор) не могут использоваться одновременно. Вопрос закрыт, решение найдено.

Уже давно найден: #define DE2_FORMAT_YUV420_V1U1V0U0 0x08 Только этого недостаточно. Оно влияет только на распределение байт в видеопамяти. Без включенного CSC цвета будут неправильными. В CSC задаются 12 коэффициентов матрицы преобразования YUV в RGB (для правильного отображения в TCON. Дисплей же RGB, а не YUV.) К сожалению с CSC - не этот случай. Так и делал. Но теперь нужна портретная ориентация дисплея - приходится всё разворачивать на 90 градусов. А G2D не может одновременно поворачивать и конвертить из YUV в RGB - изображение расслаивается на три фрагмента. Поэтому за 1 раз G2D: либо конвертит, либо поворачивает. Радикальное решение: повернуть всю видеопамять на 90 градусов, чтобы считывание точек из памяти было вдоль меньшей стороны (портретная ориентация дисплея). Интересно, DE может такое? Если удастся всё глобально развернуть, то можно G2D вызвать с конверсией и отказаться от YUV/CSC (т.е. оба слоя сделать ARGB и не париться). Он и так этим занимается - поворот на 90 градусов. Только это всё оформленно в обработчик прерывания, и никто ничего не ждёт в основном цикле программы.

так и сделано: слой 0 - YUV420 слой 1 - ARGB8888 При попытке нарисовать на слое 1 цвета конвертятся из ARGB в AYUV. Тоесть полупрозрачность сохраняется, а RGB превращаются в YUV соответственно. Если выключить CSC, то отрисовка в слой 1 идёт корректно, но видео в слое 0 выглядит неправильно (в других цветах) Можно отказаться от CSC и обоим плоскостям задать ARGB8888 и помощью G2D отконвертить видео из YUV в RGB - работает. Но одновременно с поворотом видео на 90 градусов не получается: приходится вначале поворачивать, потом конвертировать (два вызова G2D_BLT вместо одного)

Вернулся на какое-то время к T113-s3. Обнаружил такую вещь, что включенный CSC (Color Space Converter) влияет на обе плоскости: на видео-плоскость(layer0, YUV420) и на графическую плоскость (layer1, ARGB8888): изображение зеленеет. Кто знает, как задать работу CSC только на одну плоскость(layer0) без влияния на вторую? Надо в одном слое выводить видео в YUV420, а в другом слое рисовать G2D картинки в формате ARGB888

По карте дистанция 700 метров. Дальше идти возможности не было (из-за сложности рельефа). Максимальный потенциал в дальности не раскрыт. Антенны - четвертьволновый штырь с одним противовесом под углом 135 градусов. Слишком сложный рельеф в городе, приём в точках, где есть прямая оптическая видимость антенн. Если где здание загораживает - прием пропадает.

Испытал RF4463F30 на дальность в черте города. Результат лучше, чем с CMT2300A (E-49). Хотя и битрейт в 3 раза больше и 4FSK вместо 2FSK. Возможно коды Рида-Соломона с перемежением внесли свой вклад.

Схемы не даются производителем (nice-RF). Есть фото платы со снятой крышкой. Выходной транзистор - 2SK3756

Вам очень сильно повезло, что китаец обладал возможностями сделать плату

Выходное сопротивление модуля заявлено производителем 50 Ом. Кабель - от того же производителя: был в комплекте с этими модулями. Логично утверждать, что волновое сопротивление кабеля тоже 50 Ом. Нагрузка - резистор 50 Ом. Значит - при любой длине этого кабеля будет согласование с КСВ в идеале =1.0. Вопрос был не в том почему кабель даёт прибавку мощности на индикаторе. А в том, почему разъём-SMA (тоже 50 Ом), подпаянный на коротких(1,5 см) проводах вносит такую расстройку - с понижением мощности до 0,25 Вт (КСВ 4:1) ? Частота 433 МГц.

Пришла более мощная версия RF4463F30. Если полключить выход платы к КСВ-метру через штатный кабель длиной 11 см, то выходная мощность до 1,2 Вт. Если же подключить выход к КСВ-метру двумя короткими(до 1,5 см) проводами к SMA-разъёму и на вход КСВ-метра, то мощность будет 0,25 Вт. Почему так? Неужели 1,5 см провода в воздухе вносят сильное рассогласование и полезная(прямая) мощность снижается? Антенный выход КСВ метра нагружен на резистор 50 Ом (углеродный, плёночный) Фото кабеля ниже:

Тоже смотрел на них, но не понравились внешним видом: Вышеупомянутые мной ATB2012-50011 выглядят более аккуратнее ИМХО:

А значение импеданса ножек AT86RF215 RFP09/RFN09 на 430-470 МГц неизвестен, как расчитать? Честно говоря, эти балуны напрягают. Вначале хочу поиграться с OFDM модуляцией и проверить трансивер на передаче-приеме данных в помещении. А потом использовать вместе с усилителем мощности SKY65116. Надо бы глянуть его OIP3 и P1dB на предмет совместимости с трансивером. А то вдруг линейность у SKY65116 просто никакая, и OFDM на 1200 кбит/c загнётся. Хотя пишут, что для GSM и хорошая линейность, и вход-выход уже 50-омные:

нету там балуна на нужные характеристики В том же TinySDR стоит балун на 896 МГц. https://github.com/uw-x/tinysdr Непонятно, нсколько плохо будет с таким балуном на 433 МГц. Я бы поставил тот что по крайней мере подходит по диапазону частот, коэф. трансформации и сопротивлению 50 Ом: ATB2012-50011

Разбираюсь с AT86RF215, у неё дифференциальный порт(RFP09/RFN09) - один: как для приёмника, так и для передатчика. Глядел референсные дизайны (схема платы ATREB215-XPRO), там используется балун на 896 МГц: 0896BM15E0025E. Глянул даташит на этот балун и понял, что он спроектирован именно для AT86RF215 (не указан входной импеданс для балансного входа). Для диапазона 470-510 МГц такой балун не заявлен. Встал вопрос - ЧТО ДЕЛАТЬ? В даташите на AT86RF215 вскользь упомянуты эти выводы, но процитированное ниже - не вселяет у меня надежды, что импеданс портов(интересуют только RFP09/RFN09) ровно 50 Ом и без реактивностей: Нашёл широкополосный(40 - 860 МГц) балун: ATB2012-50011, у которого сопротивления балансного/небалансного входов 50 Ом, коэфф. трансформации 1:1 Вопрос - можно ли его использовать совсестно с AT86RF215 ? Модуляция OFDM, скорости 600 -2400 кбит/c, частоты: 430-510 МГц, нагрузка - несимметричная 50 Ом (между выходом и GND). И ещё, как я понял, обмотки балуна нужно развязать гальванически, через конденсаторы, чтобы постоянный ток не протекал через выводы микросхемы(RFP09/RFN09) ?