тут подешевле эти модули, но где взять распиновку для подключения программатора?
-
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
Обсуждение TLSR8269
- Автор темы nikolz
- Дата начала
pvvx
Активный участник сообщества
E180-Z6907A-
А есть ли у вас планы на счёт портирования под этот новый модуль E180 вашего же проекта EVK на e104-bt10 модуль? На данный момент нигде толком модули старого образца e104 не найти, даже на aliexpress. Взял этот e180 просто из мысли что в них одинаковый чип TLSR8269. Прошил его через BDT утилитку на 3.5 power bin прошивку, после чего этот модуль закирпичился, и дальнейшие попытки стирания или записи дают SWS Error. Потом уже начал копаться в чём могло быть дело, скорее всего из-за того что в голубеньком модуле заявлен кварц на 16Мгц, а в e180 на 38.4. Уже сжёг 1 из предыдущих 2х изготовленных по вашим наработкам программатор. Остался последний, а хотелось на запас ещё смастерить.E180-Z6907A-
www.ebyte.com
pvvx,
Если не сложно, то скажите свое мнение о возможности реализовать MP3 плеер на чипах TLSR .
Потребление и возможности беспроводной связи роли большой не имеют,
важна лишь цена, размеры и наличие средств в SDK.
----------------------------
Просьба, по возможности, ответить по существу вопроса.
-------------
Спасибо
Если не сложно, то скажите свое мнение о возможности реализовать MP3 плеер на чипах TLSR .
Потребление и возможности беспроводной связи роли большой не имеют,
важна лишь цена, размеры и наличие средств в SDK.
----------------------------
Просьба, по возможности, ответить по существу вопроса.
-------------
Спасибо
pvvx
Активный участник сообщества
Никаких возможностей - CPU слишком тормозной из-за малого "кэш".
Можно попробовать. Думаю шансы есть. Но только при наличии желания глубоко разбираться в коде (в том числе и на уровне ассемблера).
В моём проекте сейчас работает 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-декодер для каких-то скоростей.
Всё-таки - между 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
Активный участник сообщества
M0 и нет никаких связей с NRF. Если брать так сочинять - то уж можно найти связи с TI.
pvvx
Активный участник сообщества
Всё досконально описано. Типовой отдельный кристалл SPI Flash. Область подгрузки кода в окно icdata Cache Data в SRAM до 2 килобайт, таблица ictag сache Table в SRAM - 256 байт
И много раз уже было сказано, что данный чип выигрывает за счет правильно слепленной периферии у CPU, а CPU сам тормоз ещё тот.
Самая тяжёлая функция 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 на команду...
И вы сравниваете STM32, у которого предельно разогнанная Flash с широкой шиной - чем они и тянут. Но даже в SRAM у STM-ок wait на команду...
Это не так. Такое может быть только при наличии прерываний высокой частоты или переключения задач с высокой частотой. Чего не может быть в нормально спроектированной системе. Кроме того - из исходного вопроса:
можно заключить, что речь не идёт о какой-то сложной системе, в которой MP3-проигрыватель - только одна из функций (как в моём проекте). А видимо MP3-декодер - главная функция устройства, и других тяжёлых функций у него не будет. А значит не будет высокочастотных ISR и т.п.
Для примера - самая тяжёлая функция MP3-декодера - полифазный стерео-фильтр:
mp3_PolyphaseStereo.zip
Как показывает отладчик, на CM4 одна итерация цикла loopPS занимает 349 тактов. Общее время выполнения функции = 5567 тактов. На частоте 48МГц это = ~116мкс. Значит для более-менее высокой вероятности попадания прерывания на время выполнения этой функции, нужно чтобы в системе были периодические прерывания с частотами от нескольких кГц и выше.
Но даже если такое прерывание есть, то не забываем, что указанная функция занимает менее половины кеша. А значит даже если за время её выполнения случился ISR, то он не вытеснит её из кеша (если конечно ISR не монстроидальный).
Другие функции MP3-декодера ещё легче. Так что - 2КБ кеша должно вполне хватить для них.
Так что - не будет "каждая итерация выполняться с подгрузки в кеш".
Про BLE или какие-то ещё задачи, в исходном вопросе ничего не было. А значит предполагаем, что нет никаких BLE или WiFi.
Я уже писал, что можно самые тяжёлые куски кода расположить в ОЗУ. Их объём не так уж велик.
pvvx
Активный участник сообщества
И кому такое надо, если чип декодера стоит ещё меньше? Спортивный интерес?
Для кого? Для TLSR8269?
Кто вас заставляет что-то выдумывать - взяли и написали в TLSR8269 MP3 декодер и измерили, да выложили, если всё ok
Это гораздо быстрее, чем писать тут небылицы.
Мне он не нужен. Спрашивал nikolz. Ему и карты в руки.