uriy

Снова возникла проблемка с этим шифрованием. Исходники, которые я уже несколько лет использую работают с байтовыми указателями на uint8_t*, используют memcpy, memset, sizeof. Это отлично работает на STM подобных контроллерах. Сейчас мне надо запустить в DSP процессоре. В моем DSP минимальный тип данных это uint16. И memcpy, memset, sizeof оперируют с 16 битными данными. Думал легко будет переделать, но пока не осилил. Может быть есть у кого готовая реализация под 16 битную или 32 битную платформу?

Uniflash говорит что не видит target. На линиях JTAG осцилом не вижу никакой активности. Разбираюсь дальше.

С вашей подачи на FTDI нашел еще такую конфигурацию. Правда VID/PID во всех одинаковый. xds100v2.xml

Вот это очень интересно! Да у меня есть платы на FT2232. С удовольствием попробую

Кто-нибудь пользуется XDS110, купленным у китайцев? У меня имеется Sauris SAU510-USB, но с ним есть некоторые неудобства. Например, Uniflash его не поддерживает. Хочется купить еще что-то дешевое что поддерживается софтом от TI из коробки. Может быть потом и на производство передать для программирования чипов. Вопрос. Есть ли с китайским вариантом какие-то сложности? Как залоченные номера на китайских JLink или окирпичивание при обновлении.

У меня нет опыта работы с TMS320. Не могу найти чем обычно программируют на производстве TMS320F28xx. Есть ли что-то подобное Segger J-Flash?

Тактирование для IOMUX не забываете включать? Хотя без этого наверно никакие варианты бы не работали. У artery появился аналог cube, попробуйте там выставить нужные вам функции, может что-то прояснится.

Включите configASSERT() и сделайте его вывод в UART или RTT. Думаю много полезного увидите.

Массово применяем AT32F415CCT7. BOOT0 у меня заведен на землю через резистор 4.7К и также выведен на разъем для программирования. На разъеме для программирования есть SWD и UART чтобы можно было залить bootloader через оба эти интерфейса. По факту производство заливает bootloader через китайские J-Link, купленные на али за 1000 рублей. Последующие обновления прошивки через другой интерфейс UART, который имеет выход во внешний мир. Что у вас означает фраза "виснет" при вызове прерывания?

Пару лет не использовал Tracealyzer сейчас решил попробовать и что-то идет не так. Freertos создал две задачи void StartTaskButton( void * pvParameters ) { vTracePrint(trcbut, "StartTaskButton"); while(1) { LED_LD4_On(); vTaskDelay(120); vTracePrint(trcbut, "120"); LED_LD4_Off(); vTaskDelay(1010); vTracePrint(trcbut, "1010"); } } void StartTaskLED( void * pvParameters ) { vTracePrint(trcled, "StartTaskLED"); while(1) { LED_LD3_On(); vTaskDelay(100); vTracePrint(trcled, "100"); LED_LD3_Off(); vTaskDelay(900); vTracePrint(trcled, "900"); } } Помнится раньше задачи сразу были видны в логах. Сейчас задач не вижу, вижу только строки, которые отправляю через vTracePrint() И загрузку проца показывает 100%. Что я сделал не так? Нашел проблему. В файл FreeRTOSConfig.h забыл вставить #if ( configUSE_TRACE_FACILITY == 1 ) #include "trcRecorder.h" #endif

Кто-нибудь знает где можно найти J-Link Device Support Kit (DSK) https://www.segger.com/products/debug-probes/j-link/tools/j-link-dsk/ ? Хочу добавить возможность программирования NAND памяти для своего проца через J-Flash. Судя по всему в DSK есть примеры как это сделать. Ранее уже пытался это сделать через Segger Open Flash Loader, но не осилил. Сейчас пишут: "The Open Flash Loader concept is not recommended due its limitations in performance and functionality. It has been succeeded by SEGGER Flash Loader" Который и является частью DSK.

Я только с китайскими клонами и работал, проблем не было. Но наверно у меня был V8.

А чёрт его знает! Мне было негде читать. Документации на встроенный в проц бут не было, но есть исходники вторичного бута. Стал сравнивать дамп существующей железки и то что у меня скомпилилось. Увидел что через каждые полкилобайта наверно подсунуто еще байт 16. Сейчас не помню размеры. Оказалось есть масса вариантов ECC для NAND. Гуглятся по nand ecc algorithm. Мне подошел рекомендованный самсунгом.

В другом китайском процессоре я сталкивался с тем что для бута в NAND флеш используются помехоустойчивые коды. Возможно для NAND всегда так, только однажды хранил там бут. Для меня это было неожиданно. Имеющиеся у меня инструменты записи на NAND не добавляли этот код. Пришлось его добавлять самостоятельно до записи. После этого мой вторичный бут заработал. Может быть тут с этим тоже придется поработать.

Спасибо! Заметил что заявлена поддержка BareMetal. Кто-нибудь так пробовал? Я не нашел примеров под такой вариант, использовал только под FreeRTOS.

Отечественные резисторы покупаем по 60 рублей за штуку в партии несколько тысяч и сроки поставки на них около полугода. При этом импортные есть в наличии в городе примерно в 200 раз дешевле. Отечественные приходится брать из-за требований некоторых заказчиков.

Насчет IP адреса изучите опыт реализации этого в роутерах. Там обновление происходит либо через веб интерфейс по текущему IP адресу, который был настроен пользователем. Либо через бут, в который вошли с помощью зажатой кнопки. В таком случае в роутере будет другой фиксированный адрес и на нем будет DHCP сервер. Раз кнопка была нажата, предполагается что человек рядом. Дальше надо соединятся к девайсу напрямую кабелем ethernet. На устройстве стартует TFTP сервер, команды подаются через telnet или консоль. Аутентификация проверкой пароля.

Да я ее использую. В самом начале я думал что protobuf и grpc это одно и то же, сделал на ней. Не получил ответ от сервера. Стал сравнивать дампы в сети мои и от готовых программ и ужаснулся сколько там еще мусора поверх protobuf. Нашел еще вот такое https://github.com/aergoio/aergo-iot-microcontrollers Там в функции send_grpc_request используется path что туда пихать в нашем случае не понятно. И почему для http2 заголовок в текстовом формате не понимаю. sprintf(path, "/types.AergoRPCService/%s", service); sprintf(len, "%d", size); const nghttp2_nv nva[] = { SH2LIB_MAKE_NV(":method", "POST"), SH2LIB_MAKE_NV(":scheme", "https"), SH2LIB_MAKE_NV(":authority", hd->hostname), SH2LIB_MAKE_NV(":path", path), //SH2LIB_MAKE_NV("te", "trailers"), SH2LIB_MAKE_NV("Content-Type", "application/grpc"), //SH2LIB_MAKE_NV("grpc-encoding", "identity") SH2LIB_MAKE_NV("content-length", len) }; Вот тут в описании http2 в репозитории grpc https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md также есть эти текстовые поля.

Изначальное серверное и клиентское приложение было сделано под писюки, там все работает. Видно те разработчики где-то услышали о модном grpc и пошло поехало. Клиентская часть по большому счету всего-лишь шлет логи на сервер. Потом клиентскую часть решили перенести на девайсы попроще, тогда стали думать об одноплатниках с линуксом. А потом решили что клиентская часть должна стоить не больше 5 баксов. И тут появился я и смог предложить только ESP32.

Я вас наверно удивлю. protobuf добавляет всего лишь два байта к полезным данным и да он хорошо описан. Затем protobuf запихивают в grpc и затем grpc запихивают в HTTP2.

И где там описано что за данные передаются в этом запросе? 00000000 00 00 34 01 04 00 00 00 09 86 04 aa 61 05 5d 1d ..4..... ....a.]. 00000010 7b af 5d 87 49 d7 21 e9 a4 f5 21 74 1a 6a 91 7c {.].I.!. ..!t.j.| 00000020 69 1a f7 8f 52 6c 3d 1a ec 3c d6 0e 96 37 24 76 i...Rl=. .<...7$v 00000030 27 58 cd 61 aa 9b 83 c3 c2 c1 c0 bf be 00 00 0d 'X.a.... ........ 00000040 00 00 00 00 00 09 00 00 00 00 08 0a 06 31 31 32 ........ .....112 00000050 32 33 35 00 00 00 00 01 00 00 00 09 235..... .... и в ответе 00000011 00 00 04 01 04 00 00 00 09 88 c4 c3 c2 ........ ..... 0000001E 00 00 10 00 00 00 00 00 09 00 00 00 00 0b 0a 09 ........ ........ 0000002E 53 54 41 54 55 53 5f 4f 4b 00 00 01 01 05 00 00 STATUS_O K....... 0000003E 00 09 c1 ...

Ну на пару тысяч было бы вполне приемлемо. mantech, у вас есть опыт его использования в embedded? Перед тем как за это взяться я прочитал пару статей про grpc, везде пишут что это легкий протокол был разработан для минимизации трафика и ускорения передачи данных. Как бы не так, чтобы передать 6 байт полезной информации добавляется еще 200-300 байт http2 заголовков. У меня волосы дыбом от того сколько мусора накидывают и как это продвигают в массы. Серверную часть ребята писали на Kotlin и они считают что это крутой протокол. При этом они абсолютно ничего не знают о том как он работает и что передает - работает и ладно. Потом мы удивляемся что программы весят гигабайты и все тормозит. Не могу даже найти описание полей этого grpc. У меня есть дампы рабочих запросов, сделанных из-под винды. Это два разных запроса, у одного есть заголовок PRI * HTTP/2.0 у другого нет. Но на оба запроса сервер корректно отвечает.

Ищу реализацию протокол GRPC для ESP32. Нужно подключаться к чужому серверу. Вот тут https://github.com/grpc/grpc есть реализация на C++, но она тянет за собой массу системных файлов от целевой операционной системы. У меня пока нет никакого желания разбираться с этим громадным вариантом и впихивать это в ESP32. Нужно бы что-то попроще.

Нет. AT1846 плюс усилитель на 5 ватт. Программная, жесткие решения. В DMR стандарте применяется много разных помехоустойчивых кодов. В том то и дело что никак, но конечное устройство работает лучше.

А это следствие получения на приемнике многократных переотражений с разной задержкой. Что свойственно городской застройке. Но на моей практике 4FSK с турбокодами в DMR стандарте работает лучше чем OFDM QPSK с 41 поднесущей как в городе так и за городом.