a_electronic

В HDMI кабеле не коаксиалы, а витые пары в экране ВНЕЗАПНО.

Вера - это немного ортогональное к электронике понятие. Очень рекомендую вам охмуриться и вступить в секту Практического Агностицызма святого Мерфи)))

USB4 40 Гбит даст. А потому что в USB2...4 витая пара. Удачи)

Проект в J-Flash или в IDE под этот камень? А не видеть может быть несколько причин. Например потому, что китайцы, клонируя J-Linк, иногда загоняют шару. Есть варианты, в которых Vdd (который в фирменном J-Linке и"правильных" китайских является входом и по нему отладчик определяет что питание на камень подано) сделан как выход. Т.е. там висит лоу-дроп, который выдает на лапку 3.3В вместо того, чтобы быть входом. Жестоко. Мне один такой пришлось как то хорошо дорабатывать напилильником, к счастью был в наличии правильный для образца. Еще надо почитать доку, какие в этом камне есть защиты. Вполне может быть, что JTAG в нем тупо отключен и J-Linк стучит в рельсу.

)))И тем самым херится вся прелесть дифференциальной пары. Китйцы жгут!. И не только))) Даже неэкранированная витая пара даст форы по скорости передачи по сравнению с коаксиалом. А идеально - это как в S/FTP CAT7 или в HDMI кабелях, т.е. витые пары каждая в своем экране. Даже плоский шлейф, в котором сигналы идут в последовательности GND/D+/D-/GND/D+/D-... , будет работать лучше, не говоря уже о шлейфе с нормированным волновым сопротивлением.

Коаксиалы - не лучшая, а всего лишь одна из возможных реализаций единой среды передачи. И коаксиальный кабель - несимметричный. Для симметричных сигналов применяются сбалансировнные линии, такие как витая пара либо компланарные линии. Чтобы перейти с балансного сигнала на коаксиал без ощутимых потерь, надо ставить трансформатор. CSI-2 имеет 6 балансных сигналов, т.е. передать его через "лучшую реализацию" нужно 12 транформаторов и 6 коаксиалов))). Для передачи таких скоростей по одному кабелю есть интерфейс SDI, но там злые-злые чипы и частоты совсем другие. 4К через него пропихнуть сложно, дорого, и недоступно. 3G SDI доступен, но это максимум 1080p.

Между линиями дифпары ничего пускать нельзя! Возможно это просто некорректно построенная фраза. А если смотреть "в сторону микрокоаксиала" это означает смотреть в сторону смены физической среды передачи, а значит в сторону смены всего интерфейса. MIPI CSI использует дифпары и коаксиалы для него неприменимы.

Юзал китайскую борду со входами CSI-2, к которой на шлейф цеплялась 4К камера. Шлейф от камеры похоже, обыкновенный (ибо есть шлейфы с гарантированным волновым сопротивлением за другие деньги), правда длиной всего сантиметра 3. На борде от разъема к чипу дорожки (длиной от 2 до 2.5 см) явно тоже не ровняли от слова совсем. Камера заявлено что на матрице Sony, но картинка - УГ, что аж сопли из носа начинают течь. Скорее всего вот так набирается по чуть чуть - там несогласовочка, там прижали спектр, там прогнали шарика - и в итоге вроде как работает, а вроде как и нет.

В папке, куда установлен JLink есть папка Doc\Manuals, в ней дока UM08001_JLink.pdf. Там подробно все расписано. Я так понимаю, данный кристалл дебажится через JTAG. Надо выбрать подходящую распиновку выходного разъема JLinkа и бубочка к бубочке.

Буфер с каким током? У чипа-источника выходы IO настраиваемые и настроены на максимум : +-12mA. На выходе висят резисторы 27 Ом.

Это лучше оформить как внешнюю либу по типу .dll, разместив ее в отдельных секторах флеша. Либу должна содержать таблицу экспортируемых функций, размещенную по определенному фиксированному адресу линкерным скриптом .my_lib_funcs 0x......: { . = ALIGN(4); KEEP(*(.my_lib_funcs)) . = ALIGN(4); } >FLASH В коде либы определить таблицу указателей на функции. #define _MY_LIB_FUNC __attribute__ ((section(".my_lib_funcs"))) const _MY_LIB_FUNC BOOT_FS MyLibFunc = {Func1, Func1, ....., NULL}; Скомпилированный код перегнать в бинарник objcopy с ключом -O binary. Полученный бинарник можно удаленно зашить куда угодно в пределах разумного. В основном софте ваяем раздел импорта. Хидер, в котором пототипы и фиксированные указатели. typedef void (*pFunc1)(......); typedef void (*pFunc2)(......); typedef void (*pFunc3)(......); .... #define _myFync1(x, y...) ((pFunc1)0xaddr_table)(x, y...) #define _myFync2(x, y...) ((pFunc2)0xaddr_table+4)(x, y...) #define _myFync3(x, y...) ((pFunc3)0xaddr_table+8)(x, y...)

Да. Всякие проведенные реверс-инжиниринговые тесты показали, что у .... кодера большие проблемы с синхронизацией если он работает в режиме слейва. Максимум удалось добиться мимимизации эффекта, чак что щелчки ужу не щелчки, а похрустывание. Хруст и щелчки пропадают, если: а)перевести источник с режима I2S в режим serial, когда данные начинаются сразу после LRCLK, а кодер оставить в I2S и проинвертировать MCLK. Но тогда он явно теряет старший бит( не знаковый) и начинает пердеть, если звук громче определенного уровня. Когда он мастер - все ок, ибо демо-борда, на которой стоит аналоговый АЦП, работает чисто. Трабл в том, что чип-источник может быть только мастером. Есть идея воткнуть между ними самлрэйт конвертер который настроить с двух сторон слейвом. Ну или связку ЦАП-АЦП))) Буду пробовать и то, и другое. Это спецуха от самураев.

Есть устройство, которое является источником, подается на кодер MP3(черный ящик) по I2S. Источник работает как мастер клоков MCLK/BCLK/LRCLK(по другому не умеет), кодер как слейв. Трабл в том, после кодера появляются щелчки. Непериодические и со случайной амплитудой. I2S-ный ЦАП, подключенный параллельно входу кодера, дает чистый звук. Настройки частот MCLK/BCLK/LRCLK идентичны. Источник и кодер каждый имеет свой кварц 27Мгц. Если затактировать их от одного кварца это проблему не решает. В чем может быть причина?

Не совсем понятно, а точнее совсем непонятно, что должен делать тред-приемник. Он должен проснуться по определенному флагу о пошуршать, после чего опять уснуть или он постоянно шуршит, иногда посматривая на флаг? В первом случай есть объект Event. В нем как раз есть пачка вожделенных флагов, которые тред-передатчик может установить, как надо, пробудив тред-приемник, который сможет на низ посмотреть и сделать что надо. Второй случай явно кривой и такого стоит избегать в вытесняющей многозадачке.

Не нужно так глубоко залазить в железо, если есть HAL и RTOS. Как было правильно замечено, задача перед работой должна захватить мутекс. Потом работа идет по событиям. Пример - фрагмент драйвера KSZ9897: void HAL_I2C_MemTxCpltCallback(I2C_HandleTypeDef *hi2c){ if(hi2c == &hi2c1){ osEventFlagsSet(I2C1EventHandle, 0x01U); return; } } void HAL_I2C_MemRxCpltCallback(I2C_HandleTypeDef *hi2c){ if(hi2c == &hi2c1){ osEventFlagsSet(I2C1EventHandle, 0x01U); return; } } void HAL_I2C_ErrorCallback(I2C_HandleTypeDef *hi2c){ if(hi2c == &hi2c1){ osEventFlagsSet(I2C1EventHandle, 0x02U); return; } } //-------------------------------------------------------------------------- uint16_t EthCtrlWrite8(uint16_t addr, uint8_t src){ uint16_t res; uint32_t ret; abyEthCtrlTmpBuf[0] = src; if((res = HAL_I2C_Mem_Write_IT(&hi2c1, KSZ_I2C_ADDR, addr, KSZ_ADDR_SIZE, abyEthCtrlTmpBuf, 1)) != HAL_OK) { return res; } ret = osEventFlagsWait(I2C1EventHandle, osFlagsWaitAll, osFlagsWaitAny, osWaitForever); // TO DO return HAL_OK; } Понятно, что Event нужно предварительно создать и проинициализировать. Если девайсы на шине могут ВНЕЗАПНО пропадать и появляться, то в ожидании события osWaitForever надо заменить на определенное вменяемое значение и после срабатывания события проанализировать, чего же IRL мы таки дождались: проанализировать возврат ожидания и посмотреть флаги - кто вызвал событие. Ну и ГЛАВНОЕ - не забыть отпустить мутекс))) Тут мутекс не использован, потому что у меня девайсом монопольно рулить один процесс.