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

[pvvx]

Вот такое оно:

жёлтый - работа SWS/SWM, голубой - передача по UART в CH430C...
Т.е. UART жрет всё время...
Большие паузы - идет расчет CRC для передачи через UART. Оно-же ужасное...

 

[pvvx]

Ндас... Быстрее будет по BLE передать... По прошлым ковыряниям с TLSR чипами выходило более 10 килобайт в сек если все умерли давно, т.е. старые чипы приемники в телефонах/usb-bt-брелках/ноутах и прочее старьё не новее BT 4.2.
А из расчета, что SPI-Flash обычно пишется с посекторным стиранием где-то в пределах от 180 килобайт в сек и менее, то BLE с BT5.0 пойдет в самый раз.

 

[pvvx]

По SWM/SWS скорость чтения или передачи блока записи в Flash с использованием fifo в контроллере Swire определяется примерно так:

Необходимо сделать – передать/принять такое кол-во транзакций по Swire:

1. Send команду контроллеру spi “Установить SPI CS Flash в ‘0’” (reg[0x0d]=0 set csn low) (reg spi ctrl)
2. Send flash cmd <чтениe> 0x03 (reg[0x0c]=0x03)(reg spi data)
3. Send flash 16..23 bits addr (reg[0x0c]=addrh) (reg spi data)
4. Send flash 8..15 bits addr (reg[0x0c]=addrm) (reg spi data)
5. Send flash 0..7 bits addr (reg[0x0c]=addrl) (reg spi data)
6. Send reg [0x0c]=0 - launch first read, reg [0x0d]=0x0a - set auto read mode (тут передача сразу 2-х байт одной транзакции) (reg spi data) + (reg spi ctrl)
7. Далее переключаемся на режим fifo: [0xb3]=0x80 - fifo mode (reg spi mode)
8. Читаем сколько надо байт одной транзакцией: *bytes++ = reg[0x0c] (reg spi data)
9. Отключаем режим fifo: : [0xb3]=0 - normal mode (reg spi mode)
10. Send команду контроллеру spi “Установить SPI CS Flash в ‘1’” (reg[0x0d]=0 set csn hi) (reg spi ctrl)

Т.к. одна транзакция Swire имеет формат побайтно: start, addrh, addrm, addrl, id, data1,... dataN, stop

Т.е. для передачи одного байта по адресу надо передать 7 байт по 10 бит + мелкие паузы, следовательно для N байт (6+N)*10.

Описанная последовательность чтения Flash через fifo включает 10 транзакций -> 10*7+N байт Swire. Если читаем по 1024 байту, то N=1024 и выходит 10*7+1024 = 1094 байт или 10940 бит. Нужно добавить ещё джиттер и паузы межбайтных пауз, т.к. их вставляют чипы TLSR из-за внутренних тормозов CPU (опроса флагов передачи), хотя шина Swire работает и без них при своем контроллера Swire…

Битовая скорость передачи на Swire* в чипах TLSR определяется регистром делителя и равна Fclk/5/(значение делителя). По сбросу чипа он равен 5-ти и в TLSR825x Fclk кварц или RC на 24 МГц, то это 24000000/5/5 = 960000 bit/s или 1.04 us.
(*Синхронизация приема Swire допускает отклонение битвой скорости в низ в сотни раз и малое превышение вверх – протокол Swire имеет авто-синхронизацию. Но вывод на шину от котроллера всегда идет с фиксированной частотой.)

А 10940 бит по 1.04 us = 11377.6 us. Добавив неравномерное распределение (джиттер) межсимвольных пауз при чтении (SWM задает стартовый бит, а SWS отвечает 9-тью битами), плюс неточность RC генератора и получим то, что кажет осел - 11.319 ms на 1024 байта:



Ну а теперь главный вопрос - почему BDT через свой фирменный EVK читает Flash или что угодно по тем-же алгоритмам аж полчаса?

 

[nikolz]

а Вы по UART через SWS пишите flash или напрямую?

 

[pvvx]

Главное, что их EVK пихается в пром. применение....
Походу вопрос с китайcким EVK от Telink ясен - у них человеко-часы умножаются на их поголовье!!

 

[pvvx]

а Вы по UART через SWS пишите flash или напрямую?

А мне давно всё равно через что и как читать/писать в чипы TLSR.
Про UART всё описано ранее - читайте и вникайте, а не задавайте глупых вопросов...
В последних примерах (сообщениях в этой теме) описано чтение через аппаратный SWM/SWS другого чипа чипом TLSR8253 и соединенным с компом через UART на USB-COM чипах. Описано различие USB-COM чипов.
Так-же в github (ранее указано где) описано, что FTDI USB-COM контроллеры не могут читать SWire. Годится только Prolific PL-2303HX - пашет до 12 Мбит/сек, но на такой скорости он превышает скорости Swire если 1 bit Swire = 1 байту UART .
CH430C ужасен - у него большое время меж-транзакций по шине USB (дрова и сам чип) - байтовый полинг равен 3 ms! и у него беда с буферами, т.е. предельная скорость 230400 baud.

 

[pvvx]

Т.к. лепил текст сообщения кое как мышиной-копи-пастой, то поправки и уточнения:
...Далее переключаемся на режим fifo: [0xb3]=0x80 - fifo mode (reg swire mode)...
...Отключаем режим fifo: : [0xb3]=0 - normal mode (reg swire mode)...
...и получим то, что кажет осел - 11.319 ms на 1024 байта прочитанных из Flash другого чипа по SWM/SWS

И ещё уточнение - через эмуляцию Swire на Prolific PL-2303HX чипы TLSR читаются/пишутся быстрее чем это делает фирменный EVK с BDT.

 

[pvvx]

а Вы по UART через SWS пишите flash или напрямую?

А вы хотите на халяву получить контроллер для серийного производства (записи прошивок в TLSRxxxx с их проверкой)?
Подождете когда у меня будет настроение, время и желание это дело приводить в порядок для кидания в паблик... Та вообще это не моё забота - кто хотел уже написал и запись через UART - https://github.com/atc1441/ATC_MiThermometer/blob/master/ATCtelink.py

 

[nikolz]

Т.к. лепил текст сообщения кое как мышиной-копи-пастой, то поправки и уточнения:
...Далее переключаемся на режим fifo: [0xb3]=0x80 - fifo mode (reg swire mode)...
...Отключаем режим fifo: : [0xb3]=0 - normal mode (reg swire mode)...
...и получим то, что кажет осел - 11.319 ms на 1024 байта прочитанных из Flash другого чипа по SWM/SWS

И ещё уточнение - через эмуляцию Swire на Prolific PL-2303HX чипы TLSR читаются/пишутся быстрее чем это делает фирменный EVK с BDT.

Я когда баловался с программированием через UART-SWS то максимальная частота получилась 500000 baud для CH340. на 2000 000 тоже работало но импульсы были не одинаковые.
Я делал так: по SWS заливал драйвер UART, а потом общался через UART. По UART можно и 3M использовать, а учитывая, что эквивалент по SWS будет раза в 3 выше, то все должно быть быстро.

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

 

[pvvx]

Я когда баловался с программированием через UART-SWS то максимальная частота получилась 500000 baud для CH340. на 2000 000 тоже работало но импульсы были не одинаковые.

На 500 kbit/s CH340 уже сбоит для применения к Swire. Возможно и на такой скорости, но следует учитывать длину блока передачи по USB.
Т.е. у вас должна быть организована кратность 10 битам Swire в блоках передачи до 64 байт. Иначе возникает разрыв передачи 10-ти битного символа Swire на поблочную коммуникацию по USB, следующую каждые 1 ms для древнего USB1.1, что и есть всего в CH430.
Как пример - если биты Swire организуются как одно слово UART, то необходимо разбивать передачу на кратность по 10 байт -> следовательно передаете блоками по 60 байт.

 

[pvvx]

Разбивка на блоки это первое для возможности поднять скорость USB-UART-SWIRE.

TlsrComSwireWriter/ComSwireReader825x.py at master · pvvx/TlsrComSwireWriter

TLSR826x/825x COM port Swire Writer. Contribute to pvvx/TlsrComSwireWriter development by creating an account on GitHub.

github.com

Второе - необходимо задействовать режим FIFO в контроллере Swire, путем включения когда это возможно. Тогда на передачу байта к Flash или от Flash (работа с SPI регистром данных) требуется не 7 слов swire, а одно!
Т.е. выигрыш по скорости от 7 раз!

 

[pvvx]

USB, как и BLE, и WiFi, и GSM, и ... имеет тайм-слот - интервал типа connection time в BLE, в начале которого происходит опрос устройства мастером и если есть что для приема-передачи то и передается. Следующий опрос мастера шины USB1.0..2.0 будет только через 1 ms! Старьё (USB1.1) имеет MTU всего 64 байта. Более новые, с нормальной поддержкой USB2.0 - размер MTU более 1.5 килобайта (требования для USB3.0). Для этого у контроллеров USB должен быть свой буфер или они должны успевать перезаряжать DMA на прем каждого блока по 64 байта и успевать передать ACK на после-блочный опрос шины мастером. Больший MTU и набирается блоками до 64 байта, и после каждого идет опрос мастера о приеме. Если device сожрал блок, и вовремя выставил ACK на опрос мастера, то мастер гонит новый блок до 64 байта. И так пока у мастера не закончится буфер (типа максимум MTU для данного контроллера) или не подойдет к концу интервал тайм-слота выделенный для опроса этого устройства... А т.к. в компах и прочем современном дерьме давно USB3.0, то и буфера там килобайтные...
Но это не относится к CH430C - у неё трафик ограничен до(!) 64 байт на 1 ms. До 64-х, т.к. по протоколу для USB-COM портов передача/прием блока в ровно 64 байта говорит о том, что будет ещё один блок, хоть 0 байт, говорящий о конце данного фрейма. На это уйдет ещё один тайм слот или более(!)... В итоге лучше передать 63 + 1 байт

 

[pvvx]

Нюансов реализации дровами USB очень много. К примеру тот-же Microsoft в своих драйверах USB2.0 для типа USB-UART обслуживает/опрашивает возможность устройства на работу до 4-х блоков по 64 байта на одну транзакцию в тайм-слоте в 1 ms... И это ещё зависит от аппаратной реализации USB контроллера мастера. Если ваше устройство не успевает готовить ответы ACK мастеру после приема блоков, то скорость у него будет ужасная - 64*1000 байт в сек.

Никогда не пересчитывал это для USB-UART baud... Но вроде всё просто 64000*кол-во бит в слове (зависит от кол-ва бит данных + кол-ва стоп бит и наличия бита четности). Для 8N1 - 10 бит.
Т.е. теор. предел для USB1.1 640000 UART Baud. Но надо учитывать и доп. тайм-ауты для кратных 64-х байтам транзакциям, пропуски опроса мастером (занятость другими устройствами на этом хаб), хабы и тормознутость самого компа (он не всегда может готовить новую транзакцию через каждые 1 ms - он не реал-тайм система)... В итого и выходит, что реальная предельная непрерывная скорость потока на UART для CH430 и типа - 230400 Baud.

Более чем на 230400 Baud с USB-UART без RTS/CTS работать незя! Будут пропуски приема и прочие бяки.

 

[pvvx]

Поэтому лишь наблюдаю с интересом за Вашими решениями.

И выводы такие:

UART давно умер, ограничившись скоростью 115200 bit/s, когда в бажном контроллере 8250 UART от National Semiconductor исправили баги и ввели FIFO, переименовав в 16450 и далее в 16550... Тогда разогнанный i386 или i486 сумел достигнуть скорости в 115200 baud!

На этом всё и застряло для некромансеров (Ардуинщиков скупающих всякие устаревшие чипы с китайских складов…).

А для нормальных людей UART давно заменена USB…

 

[pvvx]

Вот он - основной закон для Ардуино-поклонников при работе с UART (в вики):
Замена установленной производителем микросхемы 8250 UART стала обыденной процедурой по усовершенствованию для владельцев IBM PC, XT и совместимых компьютеров, после того, как на рынке стали появляться высокоскоростные модемы. Владельцы этих компьютеров обнаружили, что при обмене данными на скоростях выше 9600 бод по последовательному порту, компьютер не мог обрабатывать непрерывный поток данных без потери символов. Замена микросхемы 8250, имевшей всего 1 байт входного буфера, на 16550 с перенастройкой ПО на работу с новым чипом с поддержкой FIFO решали эту проблему: повышалась стабильность и надёжность соединения.
FIFO
Главным недостатком более ранних микросхем 8250 и 16450 было то, что прерывания требовалось генерировать на каждый принятый байт. Это сильно увеличивало частоту генерируемых прерываний. Также была велика вероятность переполнения буфера — когда новый байт приходит раньше считывания старого. Для решения проблем в микросхемы серии 16550 был встроен 16-байтный FIFO-буфер с установкой прерывания после приёма 1, 4, 8 или 14 байт.

К сожалению, в первоначальном варианте микросхемы 16550 была допущена аппаратная ошибка, из-за которой невозможно было получить доступ к этому буферу. В следующей реализации 16550A эта ошибка была исправлена. Многие производители не стали использовать новое название, кодируя обновлённый чип прежним названием 16550.

При аппаратном контроле потока FIFO-буфер также используется, однако это не столь критично: в случае отсутствия этого буфера данные не теряются, а лишь происходит задержка в их передаче, то есть снижается фактическая скорость передачи.

И коротко - На начало 2020-х выше 9600 бод по последовательному порту Arduino не работает - низкая стабильность и надёжность соединения.

 

[pvvx]

И что интересно - STMicroelectronics так и не усвоил данную фичу и продолжает выпускать новые серии STM32 c UART без нормального FIFO... А с USB они застряли так-же на уровне USB1.1 - не могут впихнуть в чип PHY для полноценной USB2.0 hi-speed. Лет через 50 наверно и до них дойдет... Но будет ли тогда кто-то знать что такое UART?
И вот так пытаются это обойти https://diymcblog.blogspot.com/2019/01/uart-dma-stm32.html

 

[pvvx]

 

[nikolz]

На 500 kbit/s CH340 уже сбоит для применения к Swire. Возможно и на такой скорости, но следует учитывать длину блока передачи по USB.
Т.е. у вас должна быть организована кратность 10 битам Swire в блоках передачи до 64 байт. Иначе возникает разрыв передачи 10-ти битного символа Swire на поблочную коммуникацию по USB, следующую каждые 1 ms для древнего USB1.1, что и есть всего в CH430.
Как пример - если биты Swire организуются как одно слово UART, то необходимо разбивать передачу на кратность по 10 байт -> следовательно передаете блоками по 60 байт.

Фокус в том, что я иначе, чем Вы описали, передаю данные на SWS через UART.
Поэтому при загрузке не наблюдал никаких сбоев ни при 500 000 ни при 2000 000.
Но при 2000 000 старт импульс перестает уменьшаться для CH340.
При частотах до 500 000 включительно все работает красиво.
Но спорить с Вами не буду.

 

[pvvx]

Фокус в том, что я иначе, чем Вы описали, передаю данные на SWS через UART.
Поэтому при загрузке не наблюдал никаких сбоев ни при 500 000 ни при 2000 000.
Но при 2000 000 старт импульс перестает уменьшаться для CH340.
При частотах до 500 000 включительно все работает красиво.

Т.е. вы описать не можете как "иначе" ?
TLSR82xx не нравится когда ей рвут 10 бит слова по SWire. При этом 10 бит Swire не укладывается в одно слово-байт UART.
Варианты передачи у UART могут быть такими:
a) 1 бит SWire = 1 символ UART
б) 2 бита SWire = 1 символ UART
При варианте:
а) кратности к USB буферу 64 байта нет, т.к. слово SWire = 10 байт UART.
б) кратности к USB буферу 64 байта нет, т.к. слово SWire = 5 байт UART.
А пока происходит пауза обслуживания мастером USB в 1 ms уходит 200 байт из UART на 2 мегабита. Где возьмет 200 байт каждую ms CH430 со своими тупыми дровами?

 

[pvvx]

Счас другая тема - надо разгрести что такое Flash UID в TLSR825x.
Вот инфа с чипа TLSR8253 из модуля TB-04:

=======================================================
TLSR825x TlsrPgm version 25.11.20
-------------------------------------------------------
Open COM10, 230400 bit/s... ok
PGM: ChipID: 0x5562 (TLSR825x), ver: 0.0.0.1
swdiv 5, addrlen 3, swbuf [5a 00 06 02 00 05], pwr On
SWire bit rate: 0.9600 Mbits/s
-------------------------------------------------------
Hard reset Ext.MCU 5 ms... ok
Activate 100 ms... ok
CPU PC=0x000000
Chip ID: 0x5562, rev: 0x02
CPU PC=0x000000 ([0x0602] = 0x05)
Flash JEDEC ID: 0xC86013, Size: 512 kbytes
-------------------------------------------------------

REGISTERS:
000060: 7c ff c7 83 00 30 06 00 02 00 02 00 01 02 1f 00 
000070: 00 04 00 04 00 00 00 00 00 00 00 64 00 02 62 55 
-------------------------------------------------------

FLASH:
000000: 26 80 00 00 00 00 5d 02 4b 4e 4c 54 30 04 88 00 
000010: ae 80 00 00 00 00 00 00 a4 4f 01 00 00 00 00 00 
-------------------------------------------------------
Flash UID: b'AP21693\x01'
000000: 41 50 32 31 36 39 33 01 00 40 00 f1 fe e5 ff ff 
000010: c8 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
000020: 41 50 32 31 36 39 33 01 00 40 00 f1 fe e5 ff ff 
000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
000080: 10 d0 c0 c4 c4 dd 09 21 1d 31 10 d0 c1 0d 08 d9 
000090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0000a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0000b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0000c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0000d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0000e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0000f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

А это инфа с чипа TLSR8251 из термометра Xiaomi:

=======================================================
TLSR825x TlsrPgm version 25.11.20
-------------------------------------------------------
Open COM10, 230400 bit/s... ok
PGM: ChipID: 0x5562 (TLSR825x), ver: 0.0.0.1
swdiv 5, addrlen 3, swbuf [5a 00 06 02 00 05], pwr On
SWire bit rate: 0.9600 Mbits/s
-------------------------------------------------------
Hard reset Ext.MCU 5000 ms... ok
Activate 1000 ms... ok
CPU PC=0x000000
Chip ID: 0x5562, rev: 0x02
CPU PC=0x000000 ([0x0602] = 0x05)
Flash JEDEC ID: 0xC86013, Size: 512 kbytes
-------------------------------------------------------

REGISTERS:
000060: 7c ff c7 83 00 30 06 00 02 00 02 00 01 02 1f 00 
000070: 00 04 00 04 00 00 00 00 00 00 00 64 00 02 62 55 
-------------------------------------------------------

FLASH:
000000: 26 80 00 00 00 00 5d 02 4b 4e 4c 54 30 04 88 00 
000010: ae 80 00 00 00 00 00 00 a4 4f 01 00 00 00 00 00 
-------------------------------------------------------
Flash UID: b'EAB398\x18\xff'
000000: 45 41 42 33 39 38 18 ff 01 11 00 6f 02 99 ff ff 
000010: c8 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
000020: 45 41 42 33 39 38 18 ff 01 11 00 6f 02 99 ff ff 
000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
000080: 50 d0 c0 e4 cc dd e5 0d 09 29 1d 30 d1 4d 10 d0 
000090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0000a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0000b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0000c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0000d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0000e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
0000f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Flash UID, получаемое по команде '0x4B', всегда отличается (у меня на всех потырканых чипах) и может служить идентификатором для отличия MAC и прочей фигни в BLE...
Но доки на сами чипы Flash и команды нет. Есть столько отговорки от kite:
Type of Internal Flash
Telink MCU usually embeds different flash based on customer's needs, which are listed as the following.

MCU Telink обычно встраивает различные флэш-память в зависимости от потребностей клиента, которые перечислены ниже.

И далее там таблица...