esaulenka

Мне кажется, вполне осуществимы оба варианта (хотя ни одного не делал :) ). 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-й год).

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

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

В своё оправдание могу сказать только, что у LP падение напряжения меньше - мне это актуально, т.к. питание батарейное и может заметно просаживаться. Но на самом деле майкрочип в тот момент просто не смотрел, спасибо за подсказку. PS а MCP этот куда лучше ложиться на задачу "запитать RTC (макс. 3.3 вольта) от свинцового аккумулятора (6 вольт)" - я туда цепочку из резистора и стабилитрона ставил. Проект помер, но надо будет запомнить...

5->3.3 это совсем не low drop по нынешним временам :-) Я для low drop поставил LP2981. Когда, наконец, доберётся до серии, в требование "меньше 10 руб" влезет со свистом.

Во-первых, обнулять глобальные (не локальные!) переменные компилятор Си должен согласно спецификации. А во-вторых, если переменная прямо такая важная, её изначально привести в нужное состояние можно и руками.

LEXIS, не мучайте технологов, поставьте везде зазоры 0.2, у Вас места - вагон. И поясок на центральном отверстии ф7 маловат, на мой взгляд. Его можно сделать типа mounting hole и убрать галку plated, если вам не нужна там металлизация. PS У Вас ошибка: у LM1117 корпус надо бы подключать к средней ноге.