Hyper Transport

[alexandermas]

... в общем то это продолжение темы opensource usb transport, но ввиду того что в той теме
так нафлудили что решил завести новую. Да простят меня модераторы. во-первых: проект потерял
статус opensource так как на мое предложение поработать сообща отозвалось очень немногие,
а из этих немногих отпочковались почти все. Почему почти, потому что в конце останется
только один . И он остался и им оказался AAL. С ним мы и продолжили разработку....
И собственно вот что мы имеем на данный момент:

• работа с usb/ftp/smb(сеть windows)*
• управление сенсор/сеть по udp (собственное ПО под WIN пока BETA планируются версии android\macos) планируется api для создания собственных(пользовательских) программ воспроизведения/управления
• дисплей 480х272 TFT
• flac 16/24bit 44100-384000hz
• alac 16/24bit 44100-384000hz
• ape 16/24bit пока только 44100-48000hz
• wv 16/24 44100-192000hz
• wav 16/24bit 44100-768000гц
• mp3 до 320 kbps
• ac3 до 320 kbps
• интернет радио
• обучаемый ик пульт*
• выходы i2s (rj/lj48, rj/lj64 ,i2s48/64),spdif
• входы spdif*, usb(stream audio)*,i2s*
• поддержка cue, m3u, встроенных cue, логотипов альбомов
• база данных медиа библиотеки лдя комфортного выбора контента*
• создание/редактирование собственных плейлистов, добавление трека в режиме воспроизведения к теневому плейлисту, удаленная загрузка плейлистов*
• урпавление цф цап, рг.громкости*, коммутатором входов*
• usb мультиплексор и возможность внутреннего usb накопителя (это когда в плеере стоит встроенный usb-hdd,

но можно подключить внешний и посмотреть на него через usb до ПК или через сеть)

• автообновление ПО через интернет*
• тактирование бОльшего числа компонентов от мастерклока(дисплейный модуль, все настраиваемые выходы управления).
• автоопределение заведенного мастерклока*

знаком *** помечены сырые или недоделаные опции. Это значит что они точно будут включены в проект,
проработаны с точки зрения hardware, включены в первую ревизию плат но не включены в прошивку или неотлажены.

hardware arm(CM4)+fpga+sdram)

Небольшая ремарка по поводу freertos и вообще ос в подобных проектах собственное мнение: по
большому счету минималистичная ос реального времени, а freertos по сути как
не такая уж помеха для высококачественного вывода звука если ее правильно приготовить. Она лишь упрщает
жизнь программиста. Потому как для одновременного проигрования музыки, отображения чего либо на экране,
работы системы управления и чего то еще все равно требуется многозадачность. Иначе нельзя было бы
переключить трек или выключить ус-во во время проигрования музыки. Не спорю, можно добиться того же
результата и без ос, но в основной программе все равно приходится находить время и обслуживать так
называемые неосновные процессы. Но мы теряем еще один плюс - гибкость и масштабируемость системы в
целом. Например добавление дополнительного модуля может привести к полной неработоспособности системы
ввиду слета всех таймингов. Что касается систем с ОС там этим занимается сама ОС. И если правильно ее
настроить и доработать можно добиться вполне достойных результатов....

[Alex]

Т.е. у него есть свой МК с генератором и видеопамятью? Imho, такое решение облегчает подключение, но имеет кучу минусов.

А в твоем плеере что ТФТ это чисто стекляшка без контроллера? Я таких и не припомню уже, они давно все с чипом-контроллером, в котором видеопамять внутри.

---------- Сообщение добавлено 16.06 ---------- Предыдущее сообщение было 16.04 ----------

У вас например много такого контента в фонотеке?

Даже если его 2-3%, так что, не слушать его совсем?
Я так для этого специально держу многоканальных усилитель и Ямаху-2700, хотя ДВД-Аудио дисков у меня 2-3 десятка всего.

[alexandermas]

А не проще из SDRAM читать 32-бит слово во внутреннюю SRAM, и там изгаляться как угодно?

Ну оптимально не слово а банк сдрама (его нужно соотв. образом там разместить сначала). А использовать придется, потому что посекторное чтение с карты слишком затормозит работу. Время на чтение 1 куска 512 байт никак не равно десятой части чтения от 512*10 байт. А памяти в камне(сунулся в даташит) мало.

Вам видится, а мне ещё и не слышится: ни провалов звука, ни проблем с экраном...Может, я чего не так делаю?
Спасибо за подсказку, но всё и так отлично работает, зачем менять? Когда напишу декодеры, возможно, ещё понижу такт проца и SDRAM.
Битовый буфер не нужен, память и так 32-бит, чуть больше трети пропускной способности SDRAM тратится на экран, из оставшихся 2/3 маленький кусочек на ввод-вывод 192000*24, остальное - резерв. О каком ограничении SDRAM вообще тут говорить?

Это прошу прощения как? если декодер не написан еще. Упс, а как это вы распаковываете формат с битовым уплотнением без битового буффера? Как можно вообще читать из потока по 1, 2, 3 ... 20бит без соотв. софтовой прослойки. А вот когда допишите декодеры вспомните мои советы.... Видимо вы еще в самом начале разработки. А вот когда дойдете до декомпрессии fixed и lpc фреймов будете крайне недовольны количеством итераций на семпл, а еще бывают фреймы по 64к и у них надо считать crc, причем до процесса распаковки , а у вас всего 32к оперативы. Конечно можно и без crc но это уже отхождение от стандарта и при битом фрейме будет шум или вообще зависание декодера. Так что я все ж рекомендую не отступать от стандарта. тем более что в некоторых форматах семплы идут фрейм левого, фрейм правого, фрейм левого.... И приходится в итоге склеивать в конце, но и это не проблема, проблема в том что у вас скорее всего нет в компиляторе атомарного типа 24бита и пользовать он будет 32, а размер типового блока на выходе 4096(бывает еще 1052 и 4608, реже,но не сильно), а 4096*32бита*2канала = 32768байт. итак нужен входной буфер, ну пусть 8к + выходной буфер 32к + еще один выходной буфер 32к для пинг-понга + локальные переменные +++ итого не менее 72-128 кб. так что без сдрам вряд ли что выйдет.

Т.е. у него есть свой МК с генератором и видеопамятью? Imho, такое решение облегчает подключение, но имеет кучу минусов.

Например?

---------- Сообщение добавлено 18.19 ---------- Предыдущее сообщение было 18.09 ----------

Даже если его 2-3%, так что, не слушать его совсем?

Ну в последствии может быть сделаю, если будет достаточное количество желающих. На ПП все равно с плисы пинов с запасом выводим. Но после вылизывания осн. функционала. Декодеры тянут а в плисе только вывод закопипастить да пару триггеров добавить

---------- Сообщение добавлено 18.34 ---------- Предыдущее сообщение было 18.19 ----------

они давно все с чипом-контроллером, в котором видеопамять внутри

Это только мелкие, и пара моделей 4.3 все что больше имеют 20 - 28 проводной интерфейс или lvds но там нет памяти даже на строку. Видимо бессмысленно делать т.к. многие мк имеют свой видео контроллер. Но он сцуко жрет шину немеряно Поэтому собственно мы и отказались от встроенного. И как оказалось не зря. На фото не видно, но смеху ради за основным изображением иногда летает шарик размытый раз в несколько секунд. Типа как в арканоиде только улетает за пределы экрана... И все это по spi при трафике 120-130кб!!! в секунду.

[forever_student]

А в твоем плеере что ТФТ это чисто стекляшка без контроллера?...

Не чисто стекляшка. Есть 2 регистра и элементы, формирующие напряжения для стекла, а также светодиоды подсветки. Контроллера нет.

...А памяти в камне(сунулся в даташит) мало...

Мне хватает, с большим запасом.

...Упс, а как это вы распаковываете формат с битовым уплотнением без битового буффера? Как можно вообще читать из потока по 1, 2, 3 ... 20бит без соотв. софтовой прослойки...

А я много чего делаю не по стандарту. В том числе и декодирую "формат с битовым уплотнением без битового буффера". Потому и скорости такие.

...Видимо вы еще в самом начале разработки...

И снова смелый прогноз!

...а еще бывают фреймы по 64к и у них надо считать crc, причем до процесса распаковки , а у вас всего 32к оперативы...

Мне хватило 24 байта.

...итак нужен входной буфер, ну пусть 8к + выходной буфер 32к + еще один выходной буфер 32к для пинг-понга + локальные переменные +++ итого не менее 72-128 кб... .

Это Вам столько нужно. Мне - сильно меньше.

...Например?...

Присутствие ещё одного МК с генератором и с памятью, платы, разведённой без учёта EMI/EMC.
Наличие сильно более высокочастотного clk для SPI (чем pclk для параллельной шины, как у меня), при этом мЕньшая скорость обновления экрана.
Невозможность использования N страниц для видеобуфера. Хватит?

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

У меня почему-то не жрёт .

[alexandermas]

Присутствие ещё одного МК с генератором и с памятью, платы, разведённой без учёта EMI/EMC.
Наличие сильно более высокочастотного clk для SPI (чем pclk для параллельной шины, как у меня), при этом мЕньшая скорость обновления экрана.
Невозможность использования N страниц для видеобуфера. Хватит?

Генератора нет, памяти как отдельного чипа тоже нет, видеобуффера в его класическом вариане тоже нет, да он мне и не нужен, тактируется мастерклоком. По поводу шины spi: клок шины кратен мастерклоу, соотв соотв. все 3 использующиеся сигнала когерентны тому же мастерклоку. Причем при желании его можно держать на уровне около мегагерца неболее. Так что по поводу параллельной шины тоже вроде как не аргумент, да и экранировать 3 провода проще хотя этого и не требуется.

А я много чего делаю не по стандарту. В том числе и декодирую "формат с битовым уплотнением без битового буффера". Потому и скорости такие.

Не рекомендую. Ато потом для декодера "не по стандарту" придется писать кодер, причем по тому же "не стандарту". И злится на меня не надо, я не для того время тратил и писал пост чтоб глумиться.

Ладно, оставим полемику. Доделаете декодер, сравним результаты. И этого думаю хватит.

[forever_student]

Генератора нет, памяти как отдельного чипа тоже нет, видеобуффера в его класическом вариане тоже нет, да он мне и не нужен, тактируется мастерклоком...

А МК на плате дисплея от кого работает? То, что Вы не видите на плате отдельный чип памяти - ничего не значит. Память есть, как то управлять ею МК должен, clk-SPI для этого не хватит.

...Причем при желании его можно держать на уровне около мегагерца неболее. Так что по поводу параллельной шины тоже вроде как не аргумент...

1. Угу, и бегущую строку полчаса обновлять
2. МК на плате дисплея всё равно должен сколько-то раз в секунду обновить дисплей (т.е. как минимум, считать память) - это лишнее подтверждение тому, что он работает от своего генератора

...Ато потом для декодера "не по стандарту" придется писать кодер, причем по тому же "не стандарту"...

Обьясняю: "я много чего делаю не по стандарту" - это значит "пользуюсь нестандартными методами", а не "нарушаю стандарт декодера/кодера/протокола и т.д.".

...И злится на меня не надо...

Даже и не думал

[alexandermas]

А МК на плате дисплея от кого работает? То, что Вы не видите на плате отдельный чип памяти - ничего не значит. Память есть, как то управлять ею МК должен, clk-SPI для этого не хватит.

еще раз повторяю клок видео это мастерклок. Я не говорил что памяти нет, я говорил что нет фреймбуфера. Бегущяя строка(ее данные), так же как и ее шрифт грузятся в контроллер единожды или по необходимости ,а передаются только координаты начала вывода это всего 8 байт. При смене текста я гружу только коды букв, это 1байт на букву. так что для бегущей строки с нормальной скоростью достаточно очень маленькой частоты. Этот контроллер работает по другому принципу. Он строит изображение "на лету" из своих примитивов, из предварительно загруженных шрифтов и картинок и кучи всего еще. и ему не нужен буффер для того чтоб сначала сгенерить там картинку, а потом ее выводить.

[forever_student]

Если контроллер строит изображение на лету каждый раз при обновлении экрана - там должен стоять ну очень нехилый МК, с соответствующим быстродействием, потреблением и EMI. В противном случае Вы передаёте по SPI имена/адреса нужных примитивов, контроллер рисует их один раз в памяти(буфере), а потом читает её и выводит на стекло каждый раз при обновлении экрана. Вот это чтение и вывод - аналог параллельной шины у меня. И эти операции МК будет проводить независимо от частоты мастерклока (я правильно понимаю, что это clk SPI?). Опять же в противном случае д.б. ещё отдельный провод mclk, не имеющий никакого отношения к SPI.
P.S. Все эти примитивы точно также можно задавать во встроенном LCD-контроллере, только это делается проще.

[alexandermas]

P.S. Все эти примитивы точно также можно задавать во встроенном LCD-контроллере, только это делается проще.

В вашем камне да. Но большинство МК имеют куда более примитивную графику, без поддержки примитивов.

[forever_student]

???
О какой графике речь? Примитивы - это самописные функции, которые работают непосредственно с видеопямятью. В любом другом МК со встроенным LCD-контроллером они будут работать точно также (если позволит разрешение/глубина цвета).

[alexandermas]

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

[aal]

Саш, это уже несколько офтопик: нам желательней по функционалу поговорить..... Может ещё раз подумать и сформулировать понятней описание. Упомянуть, что пока IR RC5 реализован, а другие пока нет , да и не известно надо ли.

[Wired]

Упомянуть, что пока IR RC5 реализован, а другие пока нет , да и не известно надо ли.

вообще возможность управлять устройство с пульта, штука полезная.
особенно если при єтом нет необходимости использовать екран.

[Alex]

Упомянуть, что пока IR RC5 реализован, а другие пока нет

Так возьмите мой на 5 стандартов, он же открыт.
И если уж для него 4мгц pic16 хватает...

[alexandermas]

Так возьмите мой на 5 стандартов, он же открыт.
И если уж для него 4мгц pic16 хватает...

У меня есть реализация rc5 на верилоге (делал кода то) просто еще не заморачивался приклеиванием к проекту. там надо rs открутить и сделать другой интерфейс

[Alex]

У меня есть реализация rc5 на верилоге

Обучаемого?

RC5 уже давно не самый популярный, и пульты на него не на каждом шагу валяются, в отличие
от NEC, а у меня все вместе - RC5, SIRC, JAP, NEC, Samsung.

[alexandermas]

Обучаемого?

Нет не обучаемого. Но можно сделать и такой. Ессно не полностью в плисе. Хотя честно сказать я не сильно пока этим вопросом занимался, про остальные форматы нужно вникать что да как. И твой декодер будет кстати.

[Alex]

про остальные форматы нужно вникать что да как

http://altor1.narod.ru/Articles/IRC.pdf