esaulenka

Исходя из того, что он в разделе power supply, это ток через ногу GND этого ключа. Попал в таблицу как повод для гордости инженеров Maxim, что у них получилось сделать такой малопотребляющий ключ :-) UPD. Странно, для dual supply цифры потребления сходятся, а для single supply - нет (макс. ток gnd на порядок больше, чем токи питаний + утечек). PS дропбокс - это не хостинг для картинок, т.к. они по ссылке выдают не сам файл, а html'ку, в которую файл с картинкой вставлен. Форумы такое понять не могут.

От компилятора и линкера подобные вещи всё-таки зависят. Как вариант, можно просто написать const int CRP __attribute__ ((at(0x1FC))) = ...; без редактирования скаттер-файла.

Есть. Аж два килобайта "battery RAM". Читайте даташит внимательнее. У NXP есть appnote "как сделать эмуляцию EEPROM на LPC111x". Различий особых быть не должно. Только с записью по отключению питания возможны проблемы - она довольно долгая, насколько я понимаю.

Не бойтесь, он не кусается :-) И вообще, шину I2C можно одновременно "садить на землю" хоть с 10 одновременно подключенных устройств. Схема "открытый коллектор" этому не препятствует. Работает что-то явно не так. Если с этого барометра тоже снимали питание, то сразу после старта он шину не займёт - он просто не помнит, что "в прошлой жизни" что-то передавал. Перечитал первый пост. Очень странно, что лог.анализатор на что-то влияет. Осциллограмму обмена есть возможность посмотреть? И номиналы подтягивающих резисторов интересуют. У нас была железяка на LPC2138, которая регулярно опрашивала I2C EEPROM. Особенность LPC213x - вход в загрузчик по ноге, на которую выведен I2C. И дотошные тестировщики научились так щелкать выключателем питания, что контроллер перезагружался, а eeprom продолжала передавать. В итоге контроллер попадал в загрузчик. Но я так ничего и не сделал - тут или алгоритмы работы полностью переделывать, или схемотехнику менять (с потерей совместимости).

Стандартное решение: дать ему "выговориться" :-) Выдать на SCL 9 импульсов (до 8 данных и 1 ack), но не подтверждать приём. После этого NAK'а слейв должен отпустить шину. Одна проблема - я не знаю контроллеров, которые могут сделать подобный манёвр без передачи START.

Мне кажется, вполне осуществимы оба варианта (хотя ни одного не делал :) ). 1) это сделать проще - примеров "как работать с EEPROM" в сети много. Грабли - если оба мастера полезут к слейву одновременно, возможны проблемы - такую ситуацию надо специально обрабатывать, и скорее всего, авторы рации над этим не думали. Обходной манёвр - подсмотреть осциллографом, когда идёт обмен, и в эти моменты память не трогать. 2) чуть сложнее, но тоже вполне реально. Общие грабли - структура данных в EEPROM может "сама собой" измениться в новых прошивках рации.

Нужно разобраться, как это можно сделать. Написать техзадание (да-да, самому себе). А только потом - "пример кода на си".

Помирает она, если уже не померла. Нагрев кортексов-М "на палец" обнаружить тяжело - они потребляют сильно меньше одного ватта. Для начала посоветовал бы проверить напряжение питания самого контроллера.

Коллега тут озадачил. По его мнению, в природе существуют трёхслойные ПП. Пообщались с производством - они пообещали нам это сделать, стравив с четырёхслойки лишний слой. Заодно предупредили, что при больших габаритах платы желательно обеспечивать симметрию распределения меди по слоям. Собственно, вопрос: кто-нибудь такое делает, или ему это приснилось? Остальные параметры не выдающиеся - FR4, 0.2 дорожка/зазор, обычные переходные, общая толщина 1.5 мм +/- пол-лаптя.

Ну и в чём проблема? добавить копеечный сдвиговый регистр, будет SPI. Да, статус считать так просто не получится, но кому он нужен, статус этот? :) Есть вот такое, например. Правда, буковки придётся самому растеризовывать...

Какой там код... Собственно, нога MATn.x будет полностью повторять состояние бита EMx регистра TnEMR. Надо сконфигурировать таймер, чтоб считал, и выставить в TnEMR условие, по которому изменяется EMx. Этот бит также можно изменять вручную, в прерывании. 50% - просто toggle bit, все остальные значения - в прерывании сбрасываем, автоматом устанавливаем (или наоборот, как удобнее).

User Manual даёт ДОСТАТОЧНО информации. Стандартные таймеры довольно "тупые", без прерываний можно сгенерировать только ШИМ 50%. Или с любым коэф. заполнения, но с прерыванием в каждом цикле.

Очевидно, что отладчик не может прочитать содержимое памяти, и показывает 0xFF. Лично у меня сложились весьма сложные отношения с J-Link (точнее, MT-Link), кейлом и LPC2138 / LPC2368. Приходилось подбирать набор галочек и версии софта (отладка работала через Segger RDI). После переезда проектов на LPC1768 и SWD полегчало... Ну и +1 к принтф - часто оно куда лучше джитагов.

Первое - приоритет для вложенных прерываний. Если будет запрос на прерывание, у которого preemption будет выше, чем у текущего исполняющегося прерывания, будет вызвано высокоприоритетное. Второе - порядок выполнения прерываний, если вдруг два запроса поступили одновременно.

А как оно работает? Почитал отзывы, народ без особого восторга говорит о прилагающемся софте... А ещё оно продаётся в Китае, т.е. едет долго и начальством не оплачивается... У нас аналогичная задачка есть, только перехватывать I2C надо. Проблема в том, что почти всё работает нормально, но иногда данные теряются: надо собирать мегабайты логов. Осциллограф, увы, не справляется. Имеющийся USB-анализатор (АКТАКОМ-что-то-там) умеет писать в свою куцую память, а потом выгонять на компьютер - это вообще не вариант. На коленке собрали анализатор на LPC1111, там есть monitor mode. Вероятно, в контроллере баг, который NXP признавать не хочет - монитор этот работает только наполовину. Никак не сподоблюсь написать программный I2C слейв - на 400 кГц без других задач должно успевать...

А почему он не должен этого делать? Вон, мои устройства потребляют доли мА по линии VBUS (т.к. там питание - из розетки). И что-то мне кажется, что я не одинок :-) По этим долям достоверно и не определишь ничего... Определение подключения производится по уровню на D+ (или D-), там для этого специальные подтяжки должны быть.

Честно говоря, разделю опасения гуру - вероятность, что с первого раза всё заработает, довольно низкая. Если чуть-чуть полистать теорию, выяснится, что выходное напряжение у buck'а впрямую зависит от duty cycle. Второй ключ вместо диода (т.е. синхронная топология) заметно повышает КПД, но на напряжение сильно не влияет. Почитайте теорию всё ж. Мартин Браун, например, "Источники питания. Расчёт и конструирование". Или app note практически любого производителя.

Да какая-то странная тема вышла. Пришёл человек с проблемой "не умею проектировать dc/dc, а надо". Нашёл в меру своих возможностей какие-то предложения от китайцев. А гуру источнико-строительства ему прямым текстом "не лезь со своим свиным рылом". Да, это сложно - построить нормальный преобразователь. Но не невозможно же! Лучше б советы давали по делу. Или ТЗ стрясли, наконец. Вот лично мне кажется, что пункт в ТЗ "5 вольт, и ни граммом меньше" несколько надуман. 4 аккумулятора NiMH в эту железку можно вставлять? Работает? Значит, можно и меньше 5 вольт на вход подавать, производитель не запрещает. А значит, можно и меньше. А значит, можно и не геморроиться с SEPIC'ами (я совсем не гуру, но у меня сложилось впечатление, что это несколько сложнее обычного buck'а).

Я наблюдал похожие грабли: void TIMER0_IRQHandler (void) __irq { // что-то полезное T0IR = 0x01; // Clear match 0 interrupt } Влетал в прерывание два раза - до контроллера прерывания не доходило, что флаг прерывания сброшен. Нашёл рекомендации использовать инструкции для синхронизации (ISB, кажется), но сделал проще - перенёс сброс флага в начало. Конкретное место, в котором есть проблема, раскапывать поленился.

Артём, можно вопрос по коду в сообщении #8? Что-то до меня не доходит необходимость флажка и while'а. Или это задел под несколько прерываний, по которым работу продолжать не надо (проснулись - отработали - сразу уснули) ?

Блин, вот вместо ожидания контроллера "с ножками" взяли б демо-платку (LPCXpresso или STM-как-её-там), подпаялись, и было б щщастье радиолюбителя. И выбор куда больше, и возможности, и... Ну да ладно, это мне вздумалось побухтеть... Правда, LPCXpresso стоит под 1000 рублей (около 30$, если кому привычнее). Но с отладчиком. Но тыщщу... Можно найти вдвое дешевле, но без отладчика (Олимекс, например). Можно, в конце концов, найти ЛУТ-умельца, который умеет травить пады с шагом 0.5 (по рассказам, таких много :) ). Лично мне кажется, что "проблема" освоения ARM - в том, что это не AVR ;-) Хотя, если на время забыть, что такое ассемблер, мигалка лампочкой запускается за одинаковое время на обоих платформах.

Раз тут пошли "страшные истории"... pragma pack(n) надо обязательно закрывать pragma pack() При включении заголовка с незакрытой прагмой такие интересные косяки проявляются - все структуры в одном модуле сами собой "упаковываются", а в другом - остаются неупакованными, в зависимости от последовательности #include. Пример для наглядности: a.h: #pragma pack (1) b.h typedef struct .... b_struct; a.c #include "a.h" #include "b.h" b_struct A; b.h #include "b.h" b_struct B; Так вот, A и B получились РАЗНЫЕ, хотя этого вряд-ли кто-то добивался :-) Короче, плохая это прагма, не ленитесь писать атрибуты для каждой структуры.

Да, у меня тоже довольно давно RDI не работает. В какой-то версии даже пункта меню такого не было :-) Если что, могу поделиться DLL'кой из какого-то старого дистрибутива (дата файла - 9-й год).

Это как, простите? Явно ж не схемы зарядки, а схемы защиты. Зарядка на такой ток должна обладать катушкой индуктивности или, на крайний случай, здоровым радиатором.