account3847

В референсной схеме нет, они были у меня в блоке питания на другой плате, которая подключалась к этому DC-DC с керамикой на входе. Но почему микросхема выгорает при дребезге "ручного" подключения заряженных входных электролитов ко входу микросхемы - мне до сих пор не ясно... Греется, конечно - скажем, TPS5420 использовал при токе в 1А (и Uвых около 30В), а при большем токе (паспортный до 2А) нагрев был уже неприличным... С другой стороны, эта микросхема не имеет thermal pad, в отличие от старших товарищей (TPS5450).

Может быть, вам подойдут ПАИС (FPAA), такие как у Anadigm?

Прошу прощения, что не ответил сразу (уже не следил за темой). Что касается моего случая, то единственный нюанс, который мог бы дать подсказку, состоял в следующем. Основные электролиты-бочки по входу стояли на другой плате (конвертер AC->DC), а на плате с этой микросхемой по входу стояла только керамика. Если подробно рассмотреть происходящее при включении "нагорячую" (т.е. соединении контактов входа питания руками), то из-за дребезга контактов периодически происходил "отрыв" входных ёмкостей от микросхемы; напряжение на входе быстро проседало, а имеющиеся немаленькие ёмкости на выходе разряжались медленее (при отключенной нагрузке). В какой-то момент напряжение на выходе микросхемы становилось больше напряжения на входе (ток шёл через обратный диод встроенного MOSFET'а?). Затем вход снова подключался, напряжение на входе росло и становилось больше выходного, и т.д. Почему именно это приводило к выгоранию микросхемы, установить не удалось (возможно, глюк в схеме Slow Start?). Ну а при штатном включении/выключении суммарная ёмкость по входу всегда больше чем по выходу, и всегда выполнялось условие Uвх > Uвых - всё работало без проблем...

Проблему решил грубо: при малейшей ошибке в любом из драйверов высокоуровневая операция с файлом прерывается, карта переинициализируется, файловая система перемонтируется, файлы переоткрываются и операция с файлом повторяется. Вроде работает.

Спасибо всем, кто ответил! Можно ли увидеть кусочек _MSC_SPI_ReadBuffer()? Интересует, прежде всего, логика генерации ошибки таймаута. И как система восстанавливается после подобных ошибок? Попадает ли эта ошибка сразу на application level или всё исправляется ещё на уровне драйверов? (Filesystem? MMC? SPI?) В каких случаях делается полная переинициализация карты памяти?

Есть устройство с ARM7, которое общается с SD-картой по SPI. На карте - файловая система, и файлы пишутся/читаются. Код работы с SD/MMC взят "стандартный" (IAR'овский), в котором повсюду конструкции вида while(!SSPSR_bit.TNF) ; ... while(!SSPSR_bit.RNE) ; Т.е. они расчитаны на штатную работу, когда все нужные биты выставляются как надо. Однако стоит поднести к устройству с картой работающую электродрель :rolleyes:, как этот код перестаёт работать (спотыкается на этих ожиданиях и не может из них выйти). К сожалению, такое может произойти и от других внешних факторов. Интересует программное решение данного вопроса. Т.е. хотелось бы иметь более надёжный robust код, который мог бы восстанавливаться после любой ситуации на шине. Чтобы не изобретать велосипед, поделитесь, пожалуйста, ссылкой на надёжную реализацию MMC/SD или расскажите, как её сделать?

Имеется модуль SIM300D, РЧ-выход которого идёт на разъём SMA-JR (в 9 мм от модуля). С разъёма, по кабелю RG174 (5 м) идёт на антенну SA64-5M. Стал я мерять уровень сигнала (RSSI): с антенной = 20. Без антенны = 20. Т.е. антенна как бы "не работает" - сигнал с антенны не идёт. Пробовал поэкспериментировать: если антенну поместить в клетку Фарадея, то ничего не происходит. Похоже, сигнал "ловится" где-то в районе разъёма или модуля (если плату с модулем поместить в клетку, а антенну оставить снаружи, то уровень сигнала сразу падает до 7-9, т.е. как если бы антенны не было вовсе). Если, к примеру, вместо антенны в разъём вставить обычную иголку, то уровень сигнала повышается до 23-х (если простенький самодельный диполь - до 25-ти). С самой антенной и разъёмом всё в порядке (замена антенны не помогла). Прошу уважаемых форумчан помочь мне понять и исправить ситуацию.

Проектирую простое устройство с микроконтроллером (LM3S102) и CPLD (EPM3032). Выводы МК, отвечающие за JTAG, также задействованы как выходы GPIO (для управления CPLD) - т.е. планируется, что прошивка сначала подождёт некоторое время после резета (для возможности доступа по JTAG), а затем поменяет назначение пинов на GPIO и начнёт работу. Теперь о проблеме. Нужно предусмотреть возможность многократного доступа к обоим устройствам по JTAG. Я подозреваю, что просто связать устройства по JTAG chain будет проблемно (поскольку при работе данные с GPIO-пинов полезут в JTAG CPLD и могут спровоцировать у нее ISP-режим). Как красивее решить эту проблему (при условии, что свободных пинов на МК не осталось)? Пока что я думаю посадить на линию TCK у CPLD джампер (а сам пин, конечно, пулл-даунить, чтоб случайно не дёрнулся) для отключения её JTAGа, благо JTAG-пины у CPLD задействованы только для JTAG. Пройдёт ли это, и есть ли решение получше? Может, тогда лучше отказаться от chain и провести им JTAG параллельно - выбирать, кому будет идти TCK с помощью джампера?

Пока что отвечу сам себе. :) На данный момент думаю использовать обычный ГУН типа MAX2607. Доступный, простой, дешевый. Правда, стабильности по частоте ожидать не приходится, но в моём случае это и не так важно (ШИМ). Не очень нравится также, что нужно согласовывать его по выходу с ПЛИСой (обвязочка L,C). Тюнинг думаю делать обычным делителем с подстроечником, никаких ФАПЧ. В целом пойдёт, как думаете?

Нужен генератор клока для крошечной CPLD (EPM3032), частота = 200 МГц. Главные критерии - доступность (в Киеве, в кол-ве 2-3 шт), простота (в идеале - 4 ноги) и цена (<$4), параметры джиттера и т.п. - не важно. Осцилляторы - в этой ветке советуют какую-то страшную экзотику (Golledga, Jito-2, CTS) - как я понимаю, только под заказ в промышленных количествах? А более известные (типа Geyer KXO-V99) на такие частоты, по-моему, никто в Киеве не продаёт. Смотрел также варианты с PLL, но они либо монстровидные/хитросделанные (как у ADI, TI или Cypress), либо нельзя достать в Киеве (как, например, Pericom PI6C4511). Подскажите, что и где я пропустил? Вроде бы, очень многие должны сталкиваться с задачей получить дешёвый и простой клок на нужную частоту порядка 200 МГц.

Ситуация такая. Есть плата БП на TPS5420, схема почти стандартная (разве что вместо R1 делителя стоит цифровой потенциометр), напряжение на входе 30-33В, токи до 1А. Были 2 случая, когда эти микросхемы выгорели. В обоих случаях питание на вход подавалось "нагорячую", т.е. вручную подключалась к плате вилка с напряжением 30В на нёй. При этом нагрузка БП была минимальна (<1мА). Когда же включается общее питание при уже соединённой плате БП с выпрямителем, то всё работает нормально, многократные включения/выключения не мешают. Если включать нагорячую, но через токоограничительный резистор (порядка 2кОм), то микросхема не выгорает, если напрямую - мгновенно выгорает, даже с 200мА предохранителем. По входу БП стоят 4 конденсатора 2.2uF, на выходе подключавшегося выпрямителя - 4700uF. Дроссель 100мкГн, на выходе 4 конденсатора 22uF. Вопрос в том, почему выгорели микросхемы? Какие-то хитрые переходные процессы при включении с дребезгом?

Есть также целое семейство чипов от Sigma Designs (EM8xxx), на базе ARM-ядра, всё необходимое уже есть на кристалле.

Постараюсь быть кратким. Действительно, я подробно всё не описал. По той причине, что, как я полагал, с вашей стороны был только праздный интерес к моей уже реализованной задаче, и никакие серьёзные обсуждения именно моего случая не планировал. По идее, можно ещё запустить стробо-клок на выходах MATx.y таймера, со двигом пару тактов. Но это так, досужие размышления... С этим полностью согласен. Я лишь "протестовал" против этого: а) ..."дерганье" ножками GPIO быстрее 0,9 us (микросекунд) не получается. б) ...Да ничего не зависит [от типа контроллера и конкретной задачи], при наличии аппаратного SPI - без вариантов.

Увы, нельзя совместить основные данные с данными SPI, т.к. у них разный период повторения. Данные SPI выводятся по 8 бит, а затем делается большая пауза (порядка 1 мс, поэтому мне скорость вывода через SPI не так важна), а вывод основных данных продолжается всё время (и период повторения может быть любым, с точностью до сэмпла). Кроме того, при наиболее экстремальном способе основного вывода каждые 5 тактов можно успевать доставать только 16 бит за раз, а ведь MOSI1 лежит в верхнем полуслове. Поэтому и получалось у меня 60 бит: ldr ; загружаем данные очередного бита для нашего SPI FIOBUF_5; 17 тактов str ; пишем данные этого бита в MOSI1 nop FIOBUF_5; 17 тактов str ; устанавливаем CLK1 в 1 - наш бит идёт во внешний девайс (позже MOSI1). nop FIOBUF_5; 17 тактов -- здесь CLK1 автоматически сбрасывается в 0 Конечно, если подумать, то можно сделать и поменьше - за счёт битовых сдвигов и т.п. Хм, возможно... Если же можно было основной вывод делать, например, за 8 тактов, то тут уже другая картина. FIOBUF_8 будет занимать всего 5 тактов вместо 17-ти, и скорость вывода в SPI будет уже 24 такта/бит. Ну а если за 9 тактов, то можно спокойно уже через аппаратный SSP выводить. P.S. Пардон, что немного сумбурно излагаю...

Что ж, давайте ещё раз напомню, в чём заключалась моя задача. Нужно было делать одновременно 2 вещи: 1) Выводить в порт FIO 16 бит информации; 2) Выводить в SPI по 8 бит данных. Причём, выводить в порт FIO как можно быстрее (это приоритетная задача). Дык вот, если использовать аппаратный SSP, то пока мы кидаем в него данные, проходит 7 тактов, следовательно, мы не можем слать в порт FIO чаще, чем за 7+2 такта (2 идёт на сам вывод в порт), т.е. за 9 тактов. Если же мы используем программный SPI, то шлём эти биты вручную, да, менее эффективно, чем по SSP, но зато у нас появляется возможность выводить в FIO каждые 3+2 такта, т.е. за 5 тактов. Жертвуем при этом скоростью вывода в SPI (примерно 60 тактов за бит, что в моём случае полностью устраивает). Но куда важнее мне было получить максимальную скорость вывода в FIO, что я и сделал. Именно поэтому я и писал, что существуют те редкие случаи, когда целесообразнее использовать программный SPI, и в этом нет ничего страшного. Если говорить о скорости передачи по SPI, то, например, программный параллельный 4-битный вывод за 5 тактов вполне окажется быстрее последовательного (и размер буфера можно уж поболее SSP-шного сделать). Нужно ли это автору этой темы - другой вопрос...