alexandermas

Работаю с сабжем через qmi интерфейс, напрямую без либ, имхо веселее чем через ат, хотя и на порядок сложнее. Так вот, хотел поделиться. Работаю под linux. Во-первых под сабж нет нормальных реализаций cdc-wdm в ядрах младше 5.0. Во-вторых, то что предлагают (gobi-driver) ну просто дико кривой. В-третьих хотел спросить. Никто не вкурсе есть ли мост между сабжем и linux-alsa (ну или хотябы внятного описания сабжегово usb-аудио). То что написано в его мурзилке (что выдает pcm) что то отдает, да. Но как это что то превратить в pcm или какой то формат непонятно.

Удастся, я же smb поднял, тоже увесистый протокол. Дерзайте.

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

Начну с конца.... Для юсб аудио, не спорю, заниматься действительно нечем, но вот когда распаковываешь .ape или многоканальный .flac то мегагерцы становятся совсем не лишними. полусофтварность заключается в том что приходится соотв. образом подготавливать буфера для вывода, лить их по дма без участия ядра тоже не выходит (приходится проверять опустошение) это про sgpio. что касается i2s лично мне для моего проекта 2 набортных i2s мало, да и заставить их синхронно работать я не представляю как. С дма (касается lpc43xx, у 17хх вроде все нормально) тоже аппаратный косяк - при работе со связанными списками наблюдается выпадение 1 семпла из каждых 2-3 блоков по 4090 семплов, (тоже не особо удобно, т.к. фреймы в lossless форматов обычно 4096 семплов или больше) при работе на набортный i2s. плюс ко всему если вы делаете действительно высококлассную аудио систему, напомню что сами порты вывода (те к которым посредством матриц подключается встроенная переферия) тактируются совсем не от того клока что сам i2s. поэтому имеем резкое увеличение джиттера как результат(проверено опытным путем). Далее в своих мытарствах решил уйти на плис, подумал что от вышеописаных трудностей уйду... Прицепил плис, на тот момент по spi, все вроде ничего, и играло лучше чем с набортного, но только на 2х каналах, для большего невытянул spi по скорости(максимум выжал 50м/бит). решил повесить плис на EMC а вот тут была действительно засада, изза встроенных неотключаемых буферов на шине emc (даже флаг гады сделали, но нерабочий) если писать по 1 адресу я еще как то мог, то вот последовательное чтение по 1 адресу стабатывало только 1 раз, на второй логика emc считала что данные не изменились и выдавала результат из буфера. сейчас в плис находится 8 однотипных контроллеров которые я могу по своему усмотрению конфигурировать и настраивать выводя некоторые каналы хоть по i2s в разных форматах, хоть по spdif. Обмен с камнем планирую сделать по qspi.

И правильно, ошибка синтаксиса. в кейле это должно быть так __IO uint16_t __attribute__((at(xхххххххх)));

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

sgpio в lpc полная порнография, хотя сами процы вполне ничего хоть и не без багов. что касается самого i2s я сам сейчас нахожусь в процессе спрыгивания с lpc4357 в пользу stm32f7xx. и только потому что несмог путью прикрутить плиску к 43хх, в которой как раз похожий многоканальный i2s и реализован. а вот в 32f7хх есть qspi с ddr обменом в обе стороны. sgpio в 43xx полусофтварный и если пользовать его то получается что часть мощности самого проца уходит на вывод данных

Добрый день. плата stm32f7 disco. Проблемка с usb хостом в режиме HS , все это крутится под freertos. При работе с классом MSC при считывании с накопителя большого обьема даных (просто чтение в буфер файл размером 1.7гб) периодически наблюдается зависание порта, при этом перестают сыпаться даже sof прерывания. Сбои происходят не регулярно, но часто. Все это происходит так же и в примерах от st (MSC_RTOS) если его переключить в режим HS. Но в ихней же демонстрашке(ту что крутят на всех презентациях) этого глюка нет. Пробовал играть с приоритетами прерываний, настраивал хост и ось так же как и в рабочем коде. Результата ноль. Если отключть lcd глюк проявляется реже, но все равно есть. Код библиотек самого хоста и оси используется один и тот же, т.е. получается что проблема скрыта где то в настройках или конфигурации самого камня. Если вдруг кто то еще вставал на эти грабли прошу помощи или хотябы совета куда можно еще покопать. Возможно есть еще конфигурация самой шины обмена между периферией(задание приоритетов) но как и где я не нашел.

Вопрос ребром: А зачем их вообще дружить. У этого камня с лихвой хватает мощи декодировать mp3. У меня например правда на lpcc4357 мп3 идет с загрузом камня 15-20% при этом еще оссь крутиться и сетевой стек.

погуглите на тему "BitFontCreator" дивная вещь, особенно если ее правильно приготовить.

Настроено-то как раз все именно так, как предложено. с той лишь разницей, что новые блоки добавляются не в прерывании, т.к. буферов много. В прерывании щелкает счетный семафор, который недает перезаписывать еще не отправленные блоки. Проблемы с шиной: да , может быть, но в этом камне я ненашел регистра приоритетов арбитража шины. Это СМ4. В СМ3 lpc17xx он есть, и сильно помогал, а сдесь нет, или не указан в UM. Но вряд ли засада в этом, т.к. я писал что пробовал грузить данные из флешь, (в этом камне их 2 на разных шинах) . так что вряд ли. По поводу скорости: поток достаточно быстрый (выводится звук в ф-те 24бита 192 кгц), запас по скорости работы декодера аудио где-то раз в 10, но дефект проявляется и на меньшей скорости вплоть до 16бит 44100гц. просто он не так ярко выражен, время задержки меньше. пробовал так-же циклическую ссылку (когда 2 элемента списка ссылаются друг на друга). дефект все равно есть.

Оптимизируйте декодер. У меня на 120 мгц мп3 декодируется при загрузке камня 10-15%, а flac при 7-10%, при условии что файл забирается с ftp. При 204мгц уже тянет flac 384кгц, и 70% загрузке камня. Загрузку считаю по времяни нахождения в idle ф-ции ртоса. так что пилите гирю, она золотая...

В общем тема такая: есть lpc4357 на нем крутится freertos, под ней несколько задач. Втом числе lwip с ftp клиентом под ним. Так же есть i2s драйвер в задачи которого входит выделялять память под аудиобуффер из пула буферов(память под пул выделена статически) и добавлять его (выделенный буффер) в цепочку связанных списков дма, которая потом по мере опустошения хардварного fifo вываливается в i2s. Теперь собственно проблема: в некоторые моменты дма как бы зависает. изза чего на i2s формируются провалы. но если сформировать и забить всю цепочку списков дма данными, и в процессе работы системы остановить отладчиком камень, то сигнал на i2s не рвется. Сначала грешил на прерывания ethernet. но потом попробовал забивать буффера стат. данными из флешь. т.е. без участия сети. ситуация не изменилась. Сейчас скллоняюсь к тому что все это происходит изза наличия в коде критических секций, во время которых отключаются преравания. Но практического решения придумать немогу. Поэтому прошу совета......

для телефонов давно придуманы и сделаны однокнопочные решения для восстановления по в boot области, например riff jtag. и делается это без разбора телефона в течении 5 минут. если топикстартер из Нижнего Новгорода могу помочь.

потому что кроме ipv4 ,бывает ipv6. а там не 4 байта на адрес, и при подключении другого хедера там будет совершенно другая тема.