тут подешевле эти модули, но где взять распиновку для подключения программатора?
-
Уважаемые посетители сайта esp8266.ru!
Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru -
Система автоматизации с открытым исходным кодом на базе 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. Ему и карты в руки.