Quasar

Это понятно, естественно я так и делаю, но я говорю не о сигналах синхронизации на шине, которые генерит мастер, а о клоке ядра кодека и I2S модуля процессора в режиме CPU-MASTER <-> CODEC-SLAVE. В том случае, когда процессор мастер, он забирает данные по такту от своей I2SPll. И даже если настроить Fs=8ksps на процессоре и на кодеке, все равно между ними будет незначительный разбег из-за того, что у каждого свой кварц. Ну то есть, АЦП будет семплировать со скоростью 7999 Гц, а процессор забирать по шине, на которой он мастер, ровно 8000 Гц. Поэтому я и решил запустить это все в режиме CPU-SLAVE<->CODEC-MASTER. В таком режиме, I2SPLL не используется, и процессору пофиг на то, с какой скоростью в него поступают данные, он их просто в буфер скаладывает. Но, видимо в режиме slave у STM32 все очень плохо, мало того, что errata есть, так еще и он видимо не может работать в режиме когда bclk > FS x nof_bits x nof_channels.

Нет, делать надо было washer.pcb, а если у вас в базе оказалось два washer.pcb то надо было уточнить, чего за хрень, позвонив или написав. Просто кому-то было лень. Я например, не могу знать, чего коллеги мои отправляли от нашей фирмы. Они тоже могли назвать файл washer.pcb. Мне нужна двухсторонняя с нестандартной маской. И стоить это будет в два раза дороже (или во сколько там). С учетом того, что за эти 100 плат я уже заплатил несколько десятков тысяч рублей.

Есть STM32F407, есть WM8731 со своим кварцем (то есть мастерклок приходит не от процессора). Хочу наладить обмен по I2S в режиме 8000 Гц 16 бит, но получается какая-то ерунда. Если сделать процессор мастером, то звук ходит в обе стороны, но периодически появляются артефакты, так как у каждого своя синхра. Если сделать кодек мастером, то работать вообще перестает, точнее прерывания от DMA начинают приходить в 12 раз чаще. Данный кодек, генерит BCLK равный 64x(base frequency, в данном случае 64x48000), то есть 3.072 МГц при любой частоте выдачи семплов. То есть, при переключении частоты семплирования, у него меняется только частота на L/RCK линии, и STM такое не переваривает, так как ждет 8000 * 16 * 2 = 256000 Гц; Получается L/RCK у меня переключается как надо, с частотой 8000 Гц, а BCLK - 3.072 МГц (замерил осциллом). Собственно у меня вопрос, для slave I2S'а в STM'е, приходящий битклок должен быть строго Fs x nof_bits x nof_channels или нет?

А у меня вот тоже облом случился. Заказал сотню платок, делали месяц. Как привезли, оказалось не те. Делалось как повторное производство и оказалось, что есть на нашей фирме еще одна плата с таким же названием (прототип). Этот прототип и сделали, даже не спросив ничего. Хотя я при заказе дублировал герберы. Не понимаю, ну если несколько одинаковых названий у вас в базе, ну позвоните и уточните чего делать-то. Теперь вот и не ясно что делать, изделия до НГ надо было сдать.

Есть мнение, что его просто надо уметь готовить ;-)

Спасибо! Вроде кто-то откликнулся, попробую поработать с ними.

Всем добрый день. Нужно на радиаторах насверлить отверстий и нарезать резьбу М3. Всего 12 отверстий на каждом. Радиаторов - 100 штук, вопрос, где это сделать в Москве или области?

Вроде как: http://supp.iar.com/FilesPublic/UPDINFO/00...r/ewarm.ENU.htm

Я вот тоже к этому склоняюсь. То есть как-то так: 1) Создаем проект в IAR с этой библиотекой; 2) Адреса всех нужных функций складываем в таблицу; 3) Таблицу кладем по известному адресу (собственно, как и весь скомпилированный бинарник); 4) В проекте Keil вытаскиваем из этой таблицы адреса функций и используем их. Вроде все должно получиться?

Всех приветствую. Есть сторонняя библиотека, собранная в IAR - ".a" файл. Её надо подключить к проекту в Keil с RealView. Библиотеки и в IAR, и в Keil - просто архивы с объектными файлами, но формат объектных файлов у компиляторов свой, и один к другому не подходит. Есть ли какой-либо вариант от конвертировать IAR'овский ".a"-файл в Keil'овский .lib? Дело все происходит на Cortex-M4, STM32

А по DMR и APCO у вас все ограничилось декодером? Какое железо вы использовали для этих протоколов? (Если не секрет конечно)

На фотке чипсет явно не CML, непонятно к чему вы это? А цель по-моему очевидна, нужна конфигурация заливаемая в baseband при старте. [off] Круто. А что вы еще можете? :santa2: [/off]

Я правильно понял, что атан2 вы имеет ввиду обычный ЧМ демодулятор с последующей демодуляцией получившейся PAM?

Свитч (если он конечно не L3) вообще не знает ничего про IP. Он оперирует MAC адресами.

А вы покупали или используете GPL версию? Интересен порядок цен, я запрос отправил, но пока еще нет ответа.

Приветствую. Решил поизучать, что сейчас интересного есть на ниве коммерческих TCP/IP стеков. С бесплатными и открытыми вроде все ясно, а вот с платными коммерческими никогда не работал. Гугл навел на CycloneTCP, он открытый под GPLv2, но есть и коммерческие лицензии. Код организован и написан на мой взгляд хорошо, есть и драйвера на интересующий меня камень (STM32F4) и phy, но я не нашел информации, хотя бы примерной по требованию к ОЗУ и объему флеши. Кто-нибудь это чудо пробовал в своих проектах, если да, то как оно? http://www.oryx-embedded.com/#&panel1-2

Вам выше smalcom показал задержку в 30,027 ms, я сейчас в Москве и мои железки в Новосибе имеют пинг порядка 60 мс, но это же все нестабильно. Сегодня 60 мс, а завтра 600 мс. Короче, как у радиолюбителей, все будет зависеть от текущего прохождения, что бы иметь гарантированные параметры идите в Ростелеком и арендуйте канал с гарантированными параметрами предоставления услуг связи.

У меня тоже все работает и ничего не вылетает, проблема была в префтече на ревизии А, собственно выше я так и написал.

Еще топикстартеру надо сверить ревизии, а то мало ли, как в моем случае окажется... http://electronix.ru/forum/index.php?showt...=121871&hl=

Какая-то обезьянская статья, ошибками называются вполне валидные примеры кода, а почему надо именно так? Ну потому что гладиолус. Особенно понравился пример с массивом переменной длины, вот уже точно, как лучше "не делать".

Честно говоря, я не совсем понял, чего они делают. Пишут, что считывают защищенные МК и тут же предлагают какую-то свою защиту, которая по сути, состоит из стандартного решения: В данном случае перед установкой нашей дополнительной защиты можно прошить только бутлоадер без основной программы. После того, как мы установим дополнительную защиту, вы уже сможете запрограммировать основную память. Причем бутлоадер для загрузки основной программы должен использовать любой другой интерфейс отличный от основного, использующегося для стандартного программирования, так как основной интерфейс будет отключен после установки нашей дополнительной защиты. Обычно сам бутлоадер не представляет никакого интереса для копирования. В качестве бутлоадера можно использовать свой, либо модифицированный из примеров от производителя микроконтроллера. Я так понимаю, они каким-то образом исправляют биты защиты, разблокировав тем самым МК, а потом уже читают обычным программатором, но как их способ защиты не допускает такого же метода вскрытия, я не понял.

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

Ну это ВЫ так используете, но в массе своей, практика показывает, что высоконагруженное I2C это экзотика, так же как и I2C в слейве со стороны МК. Никто же не спорит, что это не нужно или нереально, просто речь идет о том, что I2C в 99% случаев, для эмбеддера это мастер с небольшим объемом данных, и все эти мегагерцы на SCL и аппаратный I2C - просто не нужны.

I2C не сильно-то нагруженный интерфейс, чаще всего, пару байт переслать раз в минуту/час. Это не SPI/I2S/Ethernet/CAN, которые чаще всего загружены "по полной".

Как тут уже писалось, аппаратные I2C модули во многих популярных МК настолько убоги, что проще использовать свою софтовую реализацию этого простого протокола. Ну правда, чтение документации, изучние erratы, написание кода - займет больше времени, чем написание кода софтового I2C (у бывалых людей он уже давно написан и кочует из поекта в проект, плюс он не привязан к ножкам) :-)