uriy

Да я никогда не имел дел с помехоустойчивым кодированием. Я передаю данные через радиоканал. Факт обнаружения ошибки для меня бесполезен, нужно уметь восстанавливать как можно больше бит. Работаю в частной шараге.

Посоветуйте помехоустойчивый код. Имеется блок данных длиной 132 бита, его можно дополнить до 216 бит.

Хоть фотки покажите этих трех станков.

Начали заниматься реализацией по ссылке. Просят скачать исходники из репозиториев git clone git://gitorious.org/pru/pru-recipes.git arago git clone git://arago-project.org/git/arago-oe-dev.git git clone git://arago-project.org/git/arago-bitbake.git Первый репозиторий мертвый. И не можем найти следы в интернете. Может у вас идеи где найти? Альтернативу не нашли, похоже они просто забили на это

Вот что-то интересное нашлось https://processors.wiki.ti.com/index.php/Soft-UART_Implementation_on_OMAPL_PRU_-_Software_Users_Guide

ок, спасибо.

Так сложилось что мы раньше не работали с техасовскими процами, только блэкфины и микроконтроллеры. Пока мало что знаю про OMAP. Это пины: VP_DOUT[5] / LCD_D[5] / UPP_XD[13] / GP7[13] / PRU1_R31[13] VP_DOUT[4] / LCD_D[4] / UPP_XD[12] / GP7[12] / PRU1_R31[12] VP_DOUT[3] / LCD_D[3] / UPP_XD[11] / GP7[11] / PRU1_R31[11] VP_DOUT[2] / LCD_D[2] / UPP_XD[10] / GP7[10] / PRU1_R31[10] VP_DOUT[1] / LCD_D[1] / UPP_XD[9] / GP7[9] / PRU1_R31[9] VP_DOUT[0] / LCD_D[0] / UPP_XD[8] / GP7[8] / PRU1_R31[8] MMCSD1_DAT[5] / LCD_HSYNC / PRU1_R30[5] / GP8[9] / PRU1_R31[6] MMCSD1_DAT[4] / LCD_VSYNC / PRU1_R30[4] / GP8[8] / PRU1_R31[5] С платы OMAP во внешний мир также выходят UART, SPI, I2C. Сейчас они уже используются другими устройствами и приложениями в линуксе. Тут мне кажется со стороны линукса будет проблема использовать эти интерфейсы, потому что они уже заняты другими процессами.

Имеется чужое серийное изделие на OMAP-L138 с линуксом на борту. Появилась необходимость во взаимодействии этой платы с еще одной платой. Без переделки платы сейчас на стороне OMAP-L138 есть только 8 GPIO. Обмен данными нужен двунаправленный. OMAP->STM32 нужна скорость десятки килобит/сек, Обратно STM32->OMAP достаточно сотни бит/сек. В голову приходит только сделать софтовый SPI. Но пугает что это создаст большую нагрузку на проц. Какие еще есть идеи? Может быть в L138 есть DMA на GPIO и можно на этом ускорить софтовый SPI?

Класс! Спасибо, получилось!

Jlink V9 на STM32F205 всегда ругался что он defective, но вроде работал без проблем. Сейчас стал отваливаться из режима отладки через несколько минут. Залил прошивку из этого поста, поменяв серийный номер https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=59841&do=findComment&comment=1547889 Все равно ругается, удалил лицензию RDDI и теперь не ругается на defective. Но теперь при каждом старте дебага просит обновится, но прошивка эта не поддерживает обновление. Можно как-то избавиться от этого постоянного предложения обновиться?

Вот еще полезная статья https://habr.com/ru/post/425071/

Вот это я пробовал делать в осцилле. Мне в тыщу раз удобней на компьютере логическим анализатором Saleae или DSLogic

У меня сейчас на столе Atten ADS1062CML. Кажется я его перешивал под Siglent. Сейчас он не показывает заставку при включении.

попробуйте убрать русские буквы в папках и названиях файлов

Что можно купить за эти деньги? Достаточно 2 канала, полоса не менее 300 МГц. Пока присматриваемся к R&S®RTB2002 + RTB-B223 До сих пользовались только китайцами ATTEN, RIGOL. Мне не очень нравятся их интерфейсы управления, к тому же они подтормаживают, особенно ATTEN. Но и в брендах не пробовал, может там тоже самое?