• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Обсуждение TLSR8269

DOMOB

New member
А есть ли у вас планы на счёт портирования под этот новый модуль E180 вашего же проекта EVK на e104-bt10 модуль? На данный момент нигде толком модули старого образца e104 не найти, даже на aliexpress. Взял этот e180 просто из мысли что в них одинаковый чип TLSR8269. Прошил его через BDT утилитку на 3.5 power bin прошивку, после чего этот модуль закирпичился, и дальнейшие попытки стирания или записи дают SWS Error. Потом уже начал копаться в чём могло быть дело, скорее всего из-за того что в голубеньком модуле заявлен кварц на 16Мгц, а в e180 на 38.4. Уже сжёг 1 из предыдущих 2х изготовленных по вашим наработкам программатор. Остался последний, а хотелось на запас ещё смастерить.
 

nikolz

Well-known member
pvvx,
Если не сложно, то скажите свое мнение о возможности реализовать MP3 плеер на чипах TLSR .
Потребление и возможности беспроводной связи роли большой не имеют,
важна лишь цена, размеры и наличие средств в SDK.
----------------------------
Просьба, по возможности, ответить по существу вопроса.
-------------
Спасибо
 

rst

Member
Если не сложно, то скажите свое мнение о возможности реализовать MP3 плеер на чипах TLSR .
Можно попробовать. Думаю шансы есть. Но только при наличии желания глубоко разбираться в коде (в том числе и на уровне ассемблера).
В моём проекте сейчас работает STM32F429 на тактовой 96МГц декодируя и проигрывая MP3-stereo 128kbps онлайн-поток с загрузкой CPU= ~25%.
Из них думаю примерно ~20% - собственно само декодирование и проигрывание (за минусом работы драйвера WiFi, графики, драйвера LCD и пр.).
Т.е.: 96*.2 = ~19.2 МГц.
Конечно STM32F429 - это CM4 и кеш там хороший.
Из даташита TLSR8269 не понятно - какое там ядро? Написано, что "32-битное", но какое именно - не понятно. Возможно - что-то из младших Cortex. У меня в коде MP3-декодера широко используются MAC-команды, команды CLZ, USAT, SSAT. Без них (или аналогов) тоже будет сложно.
Также из даташита не ясен ни размер кеша ни его наличие. Также неизвестно - какова ширина шины чтения FLASH? А всё это сильно влияет на скорость выполнения кода.
В MP3-декодере наибольшее время тратится всего в нескольких функциях. Я их все перевёл на ассемблер. Если отдать часть ОЗУ TLSR8269 для этих функций и оптимизировать их на асме для ядра TLSR8269, то это уменьшит влияние недостатка кеша. И думаю - даст шанс запустить MP3-декодер для каких-то скоростей.
 

nikolz

Well-known member
Можно попробовать. Думаю шансы есть. Но только при наличии желания глубоко разбираться в коде (в том числе и на уровне ассемблера).
В моём проекте сейчас работает STM32F429 на тактовой 96МГц декодируя и проигрывая MP3-stereo 128kbps онлайн-поток с загрузкой CPU= ~25%.
Из них думаю примерно ~20% - собственно само декодирование и проигрывание (за минусом работы драйвера WiFi, графики, драйвера LCD и пр.).
Т.е.: 96*.2 = ~19.2 МГц.
Конечно STM32F429 - это CM4 и кеш там хороший.
Из даташита TLSR8269 не понятно - какое там ядро? Написано, что "32-битное", но какое именно - не понятно. Возможно - что-то из младших Cortex. У меня в коде MP3-декодера широко используются MAC-команды, команды CLZ, USAT, SSAT. Без них (или аналогов) тоже будет сложно.
Также из даташита не ясен ни размер кеша ни его наличие. Также неизвестно - какова ширина шины чтения FLASH? А всё это сильно влияет на скорость выполнения кода.
В MP3-декодере наибольшее время тратится всего в нескольких функциях. Я их все перевёл на ассемблер. Если отдать часть ОЗУ TLSR8269 для этих функций и оптимизировать их на асме для ядра TLSR8269, то это уменьшит влияние недостатка кеша. И думаю - даст шанс запустить MP3-декодер для каких-то скоростей.
спасибо.
Ядро там Cortex- от M0 до M3
изначально это стянутые чипы NRF
 

rst

Member
Ядро там Cortex- от M0 до M3
Всё-таки - между M0 и MP3 - значительная разница. Изначально этот проект у меня работал на LPC1778 (Cortex-M3), так что - на Cortex-M3 код можно использовать без переделок. Большинство используемых команд в CM3 имеются (в декодере широко используются: SMLAL, CLZ, SSAT, USAT, REV). Правда после перехода на CM4 я оптимизировал код с использованием SMMUL, SMMLA, SMMLS, которых нет в CM3. Но это можно откатить назад.
Полностью на ассемблере у меня оптимизированы всего 2 функции: полифазные фильтры для моно и стерео. По моим прикидкам - в них тратится наибольшее время CPU. Их суммарный размер = ~1.5КБ. Т.е. - вполне влезут в ОЗУ TLSR8269. Думаю - можно и ещё какие-то тяжёлые функции тоже впихнуть в ОЗУ.
Думаю: если ядро - CM3, то почти гарантированно должно хватить скорости.

PS: Да и в принципе - глубокой оптимизации MP3-декодера по скорости я в своём проекте не проводил. Только указанные асм-функции. Остальной код оптимизировал только по размеру. Так как у меня проекте есть ещё AAC-декодер, а он даёт значительно бОльшую загрузку CPU. И нет смысла оптимизировать MP3-декодер, если AAC-декодер требует большей загрузки CPU (так как они не работают одновременно). Поэтому (думаю) есть возможность ещё увеличить скорость MP3-декодера.

PPS: Сейчас посмотрел - увеличение скорости потока до 320kbps, увеличивает загрузку CPU ещё на +1% (относительно 128kbps).
 

pvvx

Активный участник сообщества
Также из даташита не ясен ни размер кеша ни его наличие. Также неизвестно - какова ширина шины чтения FLASH?
Всё досконально описано. Типовой отдельный кристалл SPI Flash. Область подгрузки кода в окно icdata Cache Data в SRAM до 2 килобайт, таблица ictag сache Table в SRAM - 256 байт
И много раз уже было сказано, что данный чип выигрывает за счет правильно слепленной периферии у CPU, а CPU сам тормоз ещё тот.
 

pvvx

Активный участник сообщества
Только за счет правильной организации внутренних fifio отображаемых в RAM вместо dma, он запросто побеждает STM32F1xxx с USB, I2C, ADC,... Но не в MIPS-ах CPU.
 

rst

Member
Область подгрузки кода в окно icdata Cache Data в SRAM до 2 килобайт, таблица ictag сache Table в SRAM - 256 байт
Самая тяжёлая функция MP3-декодера имеет размер чуть меньше килобайта. Т.е. - вполне влазит в кеш. Внутри - цикл на 15 итераций. Первая итерация - из флеша, остальные - из кеша. Другие тяжёлые функции - тоже все как правило менее 2КБ. Значит - подавляющая часть кода будет выполняться из кеша. Можно даже не помещать эти функции в ОЗУ.
Ядро M0 - тут конечно хуже. Надо смотреть, мерять и аккуратно портировать. Возможно и получится.
 

pvvx

Активный участник сообщества
Вы сильно просчитываетесь. Тот-же ESP8266, при большей частоте CPU, уже не в состоянии обрабатывать MP3 одновременно с другими задачами. В итоге у вас будет каждая итерация выполняться с подгрузки в “кеш”, а это итог до десятка MIPS при очень хорошей оптимизации и жестком алгоритме действий всего приложения с оборудованием. А это выльется в не рентабельные временные затраты специалистов, чтобы выйти на такой уровень оптимизации. И достигните какие-то 60kbps, не более.
 

pvvx

Активный участник сообщества
Никаких RTOS в TLSR не применяется, т.к. тик BLE – 1 мкс, и время работы вашего кода должно быть ограничено до периодов связи BLE, т.е. желательно отдавать время стеку BLE каждые 4..7 us при соединении, который каждый раз перезапишет весь “кэш”, а кодер в 2 кило будет только заливаться из Flash в “кэш” более 200 мкс (такой длительности Ready/Wait будет на шине CPU во время его исполнения - никакого "предсказания" там нет).
И вы сравниваете STM32, у которого предельно разогнанная Flash с широкой шиной - чем они и тянут. Но даже в SRAM у STM-ок wait на команду...
 

pvvx

Активный участник сообщества
Обшибся - каждые 4..7 мкс при соединении. Это предел - иначе сбой связи... И это при том, что просто держим соединение, а не принимаем и передаем с максимальным RTU. Там блоки пойдут с ~0.5ms только в одну сторону (зависит от BT4/5)..
 

rst

Member
Вы сильно просчитываетесь. Тот-же ESP8266, при большей частоте CPU, уже не в состоянии обрабатывать MP3 одновременно с другими задачами. В итоге у вас будет каждая итерация выполняться с подгрузки в “кеш”
Это не так. Такое может быть только при наличии прерываний высокой частоты или переключения задач с высокой частотой. Чего не может быть в нормально спроектированной системе. Кроме того - из исходного вопроса:
Если не сложно, то скажите свое мнение о возможности реализовать MP3 плеер на чипах TLSR .
можно заключить, что речь не идёт о какой-то сложной системе, в которой MP3-проигрыватель - только одна из функций (как в моём проекте). А видимо MP3-декодер - главная функция устройства, и других тяжёлых функций у него не будет. А значит не будет высокочастотных ISR и т.п.
Для примера - самая тяжёлая функция MP3-декодера - полифазный стерео-фильтр:
mp3_PolyphaseStereo.zip
Как показывает отладчик, на CM4 одна итерация цикла loopPS занимает 349 тактов. Общее время выполнения функции = 5567 тактов. На частоте 48МГц это = ~116мкс. Значит для более-менее высокой вероятности попадания прерывания на время выполнения этой функции, нужно чтобы в системе были периодические прерывания с частотами от нескольких кГц и выше.
Но даже если такое прерывание есть, то не забываем, что указанная функция занимает менее половины кеша. А значит даже если за время её выполнения случился ISR, то он не вытеснит её из кеша (если конечно ISR не монстроидальный).

Другие функции MP3-декодера ещё легче. Так что - 2КБ кеша должно вполне хватить для них.
Так что - не будет "каждая итерация выполняться с подгрузки в кеш".
 

Вложения

rst

Member
Никаких RTOS в TLSR не применяется, т.к. тик BLE – 1 мкс
Про BLE или какие-то ещё задачи, в исходном вопросе ничего не было. А значит предполагаем, что нет никаких BLE или WiFi.

И вы сравниваете STM32, у которого предельно разогнанная Flash с широкой шиной - чем они и тянут. Но даже в SRAM у STM-ок wait на команду...
Я уже писал, что можно самые тяжёлые куски кода расположить в ОЗУ. Их объём не так уж велик.
 

rst

Member
Длительность выполнения функции фильтра, которую приводил выше (5567 тактов), это я измерил при выполнении кода из внутреннего ОЗУ STM32F429. Сейчас измерил время выполнения её из флеши (кешированной), получилось = 3529 тактов. На 48МГц это будет = ~74мкс.
Ещё значительно быстрее.
 

pvvx

Активный участник сообщества
Про BLE или какие-то ещё задачи, в исходном вопросе ничего не было. А значит предполагаем, что нет никаких BLE или WiFi.
И кому такое надо, если чип декодера стоит ещё меньше? Спортивный интерес?
Я уже писал, что можно самые тяжёлые куски кода расположить в ОЗУ. Их объём не так уж велик.
Для кого? Для TLSR8269? :)
Кто вас заставляет что-то выдумывать - взяли и написали в TLSR8269 MP3 декодер и измерили, да выложили, если всё ok :)
Это гораздо быстрее, чем писать тут небылицы.
 
Сверху Снизу