Обсуждение Программатор для TLSR

pvvx

Активный участник сообщества
Мой Расчет:
Время передачи по UART 512 KB на скорости 230400 бод составляет 512000/23040 (10 тактов на байт) =22 секунды
на скорости 3 Мбод составит 512000/300000 (10 тактов на байт) =2 секунды
Т е время исполнения программы составляет примерно 10 секунд
Таким образом, при скорости 3 Мбод 90% времени тратится на исполнение программы , а не на работу UART
ИНФОРМАЦИЯ К РАЗМЫШЛЕНИЮ:
Скорость в бодах не отражает кол-во переданных байт в чип. У протокола есть заголовки и много других команд для передачи одного байта в Flash.
Для передачи данных в Flash BDT использует скрипты (некоторые версии на LUA). Передача данных в Flash производится манипуляцией регистров SPI контроллера и на один байт переданный в чип Flash уходят десятки команд котроллеру SWire и SPI. В последних версиях, на новых адаптерах у Telink стали применять оптимизацию - в Telink вдруг вспомнили, что у SWire контроллера есть 'fifo mode'...

Ваши соединения по UART, т.е. более чем 1 сигнальным проводом = не удобно.
Для тех кто не хочет ничего паять и устанавливать какое-то ПО давно есть вариант запуска однопроводного TX-SWS программатора из эксплорера по ссылке:
1617488253111.png
 

pvvx

Активный участник сообщества
Но аппаратный программатор на USB в TLSR8269 отличается "умом и сообразительностью" (с) Тайна Третьей планеты
Ему не интересны никакие боды. Т.е. совсем пофиг, т.к. Telink SWire самосинхронизирующийся в широчайших пределах - более чем в 100 раз по бодовой скорости, в отличии от UART.
И аппаратный программатор не допускает ошибок, как это происходит в эмуляции протокола через UART.

PS: У Telink cуществует и вариант для openocd. Все ПО от него доступно. Но оно не дается "смертным".
 

pvvx

Активный участник сообщества
И писатель от Ai-Thinker уже давно отчитался о встраивании варианта с резисторами на RX-TX, вместо их программатора во Flash:
При этом взял за основу не лучший (немного проблемный и старый) вариант кода на Питоне...
 

pvvx

Активный участник сообщества
В их репозитории у Ai-Thinker, в переработанных вариантах SDK от Telink, ещё много несовместимостей с оригинальным ПО от Telink для чипов. В основном в во всех дописанных скриптах:
1. Распределение Flash для OTA
2. Подписи файлов для OTA. Не работают с другими версиями SDK от Telink, а имеющаяся в репозитории у Ai-Thinker SDK для BLE - устаревшая и в ОТА не проверяет подписи, что и прокатило отсебятину от Ai-Thinker.
 

nikolz

Well-known member
Но аппаратный программатор на USB в TLSR8269 отличается "умом и сообразительностью" (с) Тайна Третьей планеты
Ему не интересны никакие боды. Т.е. совсем пофиг, т.к. Telink SWire самосинхронизирующийся в широчайших пределах - более чем в 100 раз по бодовой скорости, в отличии от UART.
И аппаратный программатор не допускает ошибок, как это происходит в эмуляции протокола через UART.

PS: У Telink cуществует и вариант для openocd. Все ПО от него доступно. Но оно не дается "смертным".
Благодарю за подробную информацию.
---------------------
У меня все проще, но также быстро.
-------------------------
Использую CH340. (можно любой)
SWS TLSR соединяю лишь с Tx СH340 (можно без паяльника).
-------------------------
Обмен информацией двухсторонний.
---------------------------
Размер загрузчика для TLSR 2 КБ.(грузится 0.1сек)
TLSR8266 и CH340 работают на скорости 1 500 000 бод. Ничего не теряют.
-------------------------------
Время чтения всей флеш памяти (512КБ) составляет 9 (точнее 9.08) сек
----------------------
Прошивальщик написан на СИ может работать на любой винде в режиме командной строки.
Не надо заморачиваться с версиями питона и библиотеками для UART.
-------------------------
Для контроля сообщений открываю окно.
1617713511339.png
 

nikolz

Well-known member
Но аппаратный программатор на USB в TLSR8269 отличается "умом и сообразительностью" (с) Тайна Третьей планеты
Ему не интересны никакие боды. Т.е. совсем пофиг, т.к. Telink SWire самосинхронизирующийся в широчайших пределах - более чем в 100 раз по бодовой скорости, в отличии от UART.
И аппаратный программатор не допускает ошибок, как это происходит в эмуляции протокола через UART.
PS: У Telink cуществует и вариант для openocd. Все ПО от него доступно. Но оно не дается "смертным".
Я эмулирую протокол SW лишь для передачи 2КБ загрузчика.
После этого работаю по UART со всеми возможностями контроля ошибок.
-------------------
Если сможете, то подскажите, как уменьшить размер файла cstartup.s.
Что можно выкинуть, чтобы работать на "голом металле"?
 

A_D

Active member
Случайно наткнулся, иногда почитываю темы ради интереса...
SWS TLSR соединяю лишь с Tx СH340 (можно без паяльника).
-------------------------
Обмен информацией двухсторонний.
Отличная шутка! XD Нафига в UART Rx\Tx линии, когда можно подключить только Tx и будет двухсторонний обмен...
 

pvvx

Активный участник сообщества
Отличная шутка! XD Нафига в UART Rx\Tx линии, когда можно подключить только Tx и будет двухсторонний обмен...
Он наверно перепутал CH430 с некоторыми UART у MCU, у которых есть вариант переключения TX вывода в режим OK и переключения RX на тот-же пин. :)
Вот только не ясно каким образом производится синхронизация скорости ответа чипа по SWire с UART, да ещё на 1.5 мегабита, когда тактовый генератор у Swire в чипе тактируется от частоты CLK CPU. А частота CLK CPU может меняться в процессе и у 825x обычно имеет 4 варианта при стандартных делителях от RC генератора или кварца.
Но в итоге всё равно делитель тактирования у Swire на 1.5 мегабита очень редко совпадает, т.к. минимальное деление от CLK - число 5, а дискретность не позволяет попасть в синхронизацию бит у UART адаптера. Так-же диаграмма режима чтения слова по swire не имеет строгой дискретности - начальный бит (как строб) задает читающий, а ответные 9 бит выдает читаемый через асинхронное время паузы. Даже если в промежуток после строба переключить UART на прием, то у UART будут ошибки по синхронизации - побитный протокол отличается от диаграммы приема UART на 8 бит. По этой причине чипы FTDI не могут эмулировать Telink Swire - они строго соблюдают битовую последовательность с проверкой по 3-м точкам каждого бита и выводят ошибку фрейма без занесения "шума" в принятый буфер. Только урезанные до безобразия китайские чипы USB-COM могут как-то принять последовательность swire, т.к. не проверяют RX биты на шум и правильную последовательность - есть или нет старт/стоп бита и т.д. К примеру UART в ESP так-же не шарит что на линии - шум или передача. :)
 

pvvx

Активный участник сообщества
CH430 не может выдавать строгую последовательность бит на TX уже начиная со скорости порядка 230400 бит/c. Происходит разрыв посылок на размер внутреннего буфера - пока по USB придут новые байты для его заполнения. А USB устроена так, что это пауза происходит от частоты опроса флагов point мастером на шине... И она асинхронна с UART и зависит от драйверов на компе и наличия нагрузки на хаб, pci и прочие блоки в структуре компа.
Аналогично и прием - на скоростях более 230400 бит/c c USB Full-Speed (до 12 Мбит/с) без RTS/CTS на время передачи буфера по USB обязательно будут потери. Вероятность такого события превышает уже десятки процентов для Windows и подобных не real-time систем.

В итоге эмуляция Swire на UART - это работа с некой вероятностью наличия неисправимых ошибок, а не строгая эмуляция.
 

pvvx

Активный участник сообщества
Кратность кол-ва бит на слово Swire с размером буфера USB-COM чипа только снижет вероятность появления асинхронных пауз между байтами UART, но не исправляет ситуацию.
У nikolz нет на то средств проверить это, т.к. у него нет осциллографа, нескольких компов c разными USB, времени на проверку, знаний, предыдущих работ и отзывов по ним от пользователей, решений этих проблем с пользователями имеющими эти возможности и т.д...
По одиночному тесту, и то, когда это вдруг "проскочило" среди сотен опытов, он выдумывает, что это рабочий вариант :)

По отзывам и проверкам только запись в TLSR чипа загрузчика в пару килобайт с компа через USB-COM - это вариант с вероятностью ошибки к 10%.
 

pvvx

Активный участник сообщества
Такой вероятности ошибок достаточно для критических случаев восстановления сбитого ПО в чипе у пользователя, но не для работы с TLSR чипами.
 

pvvx

Активный участник сообщества
Время чтения всей флеш памяти (512КБ) составляет 9 (точнее 9.08) сек
Это очередной теоретически ошибочный подсчет от вас?
Предельная скорость Swire у разных чипов и разных CLK разная. Только это уже направляет ваши расчеты в помойку.
Прошивальщик написан на СИ может работать на любой винде в режиме командной строки.
Чтобы странслировать СИ пользователю необходимо загрузить от пол GB приложений и библиотек на компе и без наличия типовой инструкции :p :)
А на многих OC есть и другие заморочки несовместимые с знаниями пользователей...
Не надо заморачиваться с версиями питона и библиотеками для UART.
Т.е. вы ещё не осознали, что код для Питона написанный с синтаксисом к последней версии и учета старых работает на всех старых версиях? А причина подбора старых версий у пользователей - код написан до выхода новых версий Питона и типа...
 

Kabron

Member
Жалко, что мы так и не услышали начальника транспортного цеха
 

nikolz

Well-known member
Это очередной теоретически ошибочный подсчет от вас?
Предельная скорость Swire у разных чипов и разных CLK разная. Только это уже направляет ваши расчеты в помойку.
Чтобы странслировать СИ пользователю необходимо загрузить от пол GB приложений и библиотек на компе и без наличия типовой инструкции :p :)
А на многих OC есть и другие заморочки несовместимые с знаниями пользователей...
Т.е. вы ещё не осознали, что код для Питона написанный с синтаксисом к последней версии и учета старых работает на всех старых версиях? А причина подбора старых версий у пользователей - код написан до выхода новых версий Питона и типа...
Вы опять невнимательно читали.
Повторяю специально и медленно.
------------------------------
Все работает по UART а не по Swire. UART у всех чипов одинаковый.
Поэтому скорость чтения flash не изменится.
Я ее не рассчитывал, а измерил на TLSR8266 (JDY-10) и она ограничивается скоростью чтения из флеш внутри чипа.
-----------------------------
По Swire я загружаю лишь 1.8 Кбайт бинарного кода загрузчика .
---------------------------------
загрузчик сделан в виде exe файла и работает на любой вуинде. Его не надо собирать так как он уже собран, но можно и собрать так как никаких сторонних библиотек не требуется.
Исполняемый файл 44 Кбайта.
Это Ваш загрузчик требует питона версии 3 и выше и драйверов на UART т е. гигабайты софта и может работать лишь на win10.
----------------------------
 

nikolz

Well-known member
Случайно наткнулся, иногда почитываю темы ради интереса...

Отличная шутка! XD Нафига в UART Rx\Tx линии, когда можно подключить только Tx и будет двухсторонний обмен...
Видно что не в теме, Но хочется выпендриваться? Верно?
Объясняю для тех кто временами тявкает на караван.
Двухсторонний обмен я делаю по UART интерфейсу. Для него не нужен SW интерфейс.
Поэтому SWS подключается лишь для загрузки начального загрузчика (2 кб) в SRAM чипа т е для этого надо соединить SWS с Tx CH340.
----------------
схему можете нарисовать сами. Rx Tx TLSR соединяете с Tx Rx CH340. и дополнительно через диод шоттки,или тумблер, или кнопу соединяете SWS TLSR с Tx CH340 .
 

nikolz

Well-known member
Кратность кол-ва бит на слово Swire с размером буфера USB-COM чипа только снижет вероятность появления асинхронных пауз между байтами UART, но не исправляет ситуацию.
У nikolz нет на то средств проверить это, т.к. у него нет осциллографа, нескольких компов c разными USB, времени на проверку, знаний, предыдущих работ и отзывов по ним от пользователей, решений этих проблем с пользователями имеющими эти возможности и т.д...
По одиночному тесту, и то, когда это вдруг "проскочило" среди сотен опытов, он выдумывает, что это рабочий вариант :)

По отзывам и проверкам только запись в TLSR чипа загрузчика в пару килобайт с компа через USB-COM - это вариант с вероятностью ошибки к 10%.
я вам результаты работы реальной рассказываю, а вы мне общеизвестные учебники своими словами пересказываете.
Ну и зачем?
Если Вы не можете это сделать, но не факт, что у других не получится.
------------------
 

nikolz

Well-known member
Такой вероятности ошибок достаточно для критических случаев восстановления сбитого ПО в чипе у пользователя, но не для работы с TLSR чипами.
выше спросил Вас, но Вы промолчали. Возможно не заметили вопрос. Повторю:
--------------------------
Если сможете, то подскажите, как уменьшить размер файла cstartup.s.
Что можно выкинуть, чтобы работать на "голом металле"?
 

pvvx

Активный участник сообщества
я вам результаты работы реальной рассказываю, а вы мне общеизвестные учебники своими словами пересказываете.
Ну и зачем?
Чтобы вы осознали, что обречены по теоретическим и физическим факторам.
Если Вы не можете это сделать, но не факт, что у других не получится.
Новая математика получится? Или измените физические законы и все чипы CH430 совместно с компами и ОС у пользователей?
Тем более пока не видно что вы что-то нового сделали, кроме частичного повтора того, что уже выложено в паблик.
 
Сверху Снизу