zhevak

Когда элемент питания будет садится и его напряжение будет опускаться к 1.2 В и ниже, Микроконтроллер сможет работать при таком напряжении? Я не знаю, что за устройство Вы проектируете, но на мой взгляд самое оптимальное решение -- это использовать литиевый элемент типа CR2030. (Может быть я не прав, я ведь не знаю какую задачу Вы решаете.)

Обратите внимание, что сначала нужно читать ADCL и только потом ADCH. (Даташит на ATMEGA48_88_168, стр.258) А Вы подключили include-файл ? .includepath "/usr/share/avra/" ; Путь к инклюдам .include "m168def.inc" ; Инклюд для ATMEGA186 Ну или опубликуйте свой код. Так людям будет легче помочь Вам. (Не стесняйтесь того, что ваш код может оказаться далёким от совершенства. Все мы когда чего-то не знали и делали очень глупые ошибки. Стыдиться надо не незнания, а того, что не хочешь знать.)

Ну вот как бы LED лампы могут и не дать такого ярко-выраженного эффекта. Вот, с. 8 написано И там где-то по тексту рядом сказано, что наибольший эффект имеют галогенные ламы, обычные лампочки Ильича и солнышко, ибо пик в спектре их излучения и чувствительность чипа совпадают где-то на этих длинах волн. А у ЛЭД-лампочек спектр совсем другой. В документе даже рекомендации даны -- типа проверять свою продукцию галогенками перед тем как. Но ради спортивного интереса я бы с ЛЭД-лампочками тоже поигрался. Практика -- это много значит.

ну или вообще не будет работать -- ...in a WLCSP package maystop operating whenexposed to direct sunlight. This effect can be reproduced by holding a 42 W halogen lamp at a distance of approximately40 cm:the BLE WLCSPdevice stops advertising immediately (Выделено мною -- сразу перестаёт работать.)

https://www.dialog-semiconductor.com/sites/default/files/an-b-021_-_da1458x_wlcsp_light_sensitivity_v1.3.pdf -- Application note DA1458x WLCSP package light sensitivity alex_zhuravlyov -- успел чуть быстрее, пока я занимался копипастами :)

Мдя... Дела. :(

Александр, спасибо за то, что взбодрили унылую серую жизнь! А Вы не пробовали затенять те или иные микросхемы? Хорошо бы вычислить того, кто "гадит в общий котел". Ещё вопрос -- Вы когда пробовали светить с разных направлений, Вы поворачивали плату или же плата была зафиксирована, а Вы светили фонариком с разных позиций? Хотелось бы исключить влияние пространственного положения IMU-шек. (Извините, за возможную некорректность. Просто очень интересный эффект и очень хочется найти причину. Я ни чуть не сомневаюсь в Вашем уровне знаний. Просто для чистоты эксперимента.

диоды типа 4148 от света могут "подтекать". Замечено было ещё на стадии ознакомления с диодами Д9 и Д7 (если светить ему в... ну, выражаясь культурно -- со стороны анода, у него там стеклянный изолятор был).

Вообще ожидается, что должно быть как раз наоборот. Может какие-то наводки от руки? Подносить руку с телефоном, но с выключенным фонариком не пробовали? Попробуйте вместо телефона обычный фонарик. С какого расстояния светили телефоном? А фонариком? А включать-включать фонарик на расстоянии (скажем -- один метр) -- как оно, потребление так же будет реагировать? Недавно в интернете вплывала тема, что давным-давно было замечено, что КТ315 реагируют на свет через свой корпус.

Вряд ли поможет, но может быть подскажет правильное направление -- Недавняя статья на Хабре "Считывание защищённой прошивки из флеш-памяти STM32F1xx с использованием ChipWhisperer" (Яндекс находит)

Не знаю в какие двери постучать... Задача следующая: Имеется некий девайс на базе STM32F4xx, к нему прикручена "физика" DP83848, пара светодиодов и пара кнопок. Простецкий тестовый проект сгенерён под CubeMX. Созданный проект позволяет удалённо по UDP (по TCP/IP) управлять светиками и опрашивать кнопки. Всё красиво работает, проблем нет. Теперь нужно это же самое сделать под технологией OPC UA. В частности, я сориентировался на её конкретную реализацию -- open62541. Проблема в том, что я пока никак не могу поставить open62541 на FreeRTOS. Одних только моих мозгов не хватает. Хотелось бы найти тех, кто озаботился темой. Авторы упорно молчат. Я пробовал прикрутить амальгамный вариант open62541, июль, 2019. (Сейчас этой амальгамы нет, авторы open62541 более не рекомендуют пользоваться амальгамой.) Я пробовал создавать свою амальгаму. Пробовал поиграться с мульти-файловым решением. В общем, ничего пока толком не компилится/не собирается. Для справки, в проекте использую BSD-сокеты (не netcom), это чисто для удобства прикручивания open62541. Прошу отозваться, кто озабочен темой.

На прошлой неделе я тоже словил нечто подобное. Я тоже использовал прерывания от внешнего устройства по EXTI. По невнимательности я забыл в main() перед главным циклом разрешить прерывания (__enable_interrupt()). Более того, я эту ошибку не сразу просёк! Девайс работал но как-то странно. Прерывания возникали и обработчик прерывания их даже отрабатывал. Но отрабатывал не каждое, а примерно одно из ста. Я тупил над кодом несколько минут. Копал, но не в том месте. Надо было сразу пойти в main(). Как только я прописал эту строку, девайс сразу начал функционировать как и ожидалось. Но для себя я отметил, что с прерываниями EXTI у STM32F0xx что-то не в порядке. Почему-то они умудряются каким-то образом "просачиваться". Я не знаю, с чем это связано. Понятно, что надо бы по хорошему покопаться поглубже, но пока руки не доходят (как обычно -- всяких дел выше крыши). Боюсь, что придётся отложить это интереснейшее исследование до Новогодних каникул. Параметры для повторения: проц STM32F030F4, питание 3.3 В, тактовая частота ядра 48 МГц. Прерывание от внешнего (цифрового, не аналогового!) устройства возникает каждые 60 мс. Фронт -- спадающий (из "1" в "0"). Внешнее устройство висит на SPI1, тактовая частота SPI -- 3 или 6 МГц (не помню!) Всё чрезвычайно просто -- устройство ставит прерывание на ногу процу, проц обслуживает устройство по SPI. В девайсе задействован ещё USART1, работает только на передачу (TX). Передача байтов происходит тоже по прерываниям (не через DMA.)

Вот тут -- https://smdprutser.nl/blog/ товарищ проводит сравнение. Но, как я понял, он ничего, чтобы отличало один от другого, не нарыл. Ну, если, конечно, не считать, что китайский вариант может работать на более высокой частоте.

Если камень ничего больше не делает, кроме как из своей памяти извлекает байты и отправляет их в Манчестеровском коде, то наверно можно. По сути, МК должен через каждые 5 мкс изменять состояние одного какого-то бита в порте. МК -- достаточно быстрый, способен работать на 48 МГц. Мне кажется, что такого времени -- 5 мкс -- вполне достаточно для программного управления ногой. Но вообще задача решается куда проще на МК фирмы Atmel (бывш.) -- на AVR и на AT91Sxxx. Они умеют генерировать меандр синхронный с выходом UART. Сигнал называется XCK. Причём генерируют даже в паузах между передачами байт. На приёмном конце это весьма актуально. А вот, STM32, к сожалению, выдают меандр только для информационных битов USART. Во время вывода стартового и стопового битов меандр не вырабатывается. Я так думаю, что такое немного странное функционирование USART-ов в STM32 продиктовано не тем, что ST хотела предоставить разработчикам работать с Манчестером (как это было у Atmel), а возможностью перевести USART в режим, совместимый с SPI. Странное решение. Но, какое уж есть. У меня вот тут https://wp.me/p1H7g0-1Qm кое-что есть на эту тему.

Коллеги! Двумя комментариями выше я привёл код, который отправляет МК в спячку. В коде ошибка! Правильный код должен быть таким: while (true) { SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk; // Задаём режим STOP PWR->CR |= PWR_CR_LPDS; // Регулятор (1.8 В) в энергосберегающий режим __WFI(); // Спать!!! } Вместо команды __WFI() я написал __WFE(). Написал и даже как-то не обратил на это внимание. Видимо, был сосредоточен на чём-то другом. Хуже того -- код с опиской (ошибкой) благополучно заработал. На присутствие в коде ошибки я обратил внимание только тогда, когда моё устройство стало вести себя мягко говоря странно. Моё устройство -- это телефонная трубка. При пятисекундном нажатии на клавишу "повесть трубу" (красная кнопка) устройство должно было засыпать или наоборот -- просыпаться. На деле устройство меняло режим работы не через 5 секунд, а через 2-3. Хорошо! Я увеличил порог до 10 секунд. Теперь устройство стало издевательски засыпать и просыпаться через 5 секунд. "Стрелка осциллографа" показала, что устройство засыпало не стразу, а только когда главный цикл (в main()) совершит ещё один оборот и команда __WFE будет выполнена повторно. Всё правильно! Команда WFI переводит МК в спячку не взирая на. А вот команда WFE работает немного по другому. Если флаг однобитового регистра события сброшен, то команда отработает как и положено -- отправит МК в спячку. Но если этот бит взведён, то команда WFE не сможет усыпить МК. Вместо этого она просто сбросит этот бит. Поэтому повторное выполнение команды WFE уже будет происходить со сброшенным флагом, поэтому только оно (то есть, повторная команда) и загонит МК в сон. Programming manual PM0215 так об этом и говорит (страница 29, в средине): Для таких как я это положение повторено в руководстве дважы. :) К стати, обратите внимание на последнее предложение -- однобитный регистр события программно не доступен. Ну, и что в итоге? После разумного подхода всё встало на свои места -- трубка засыпает и просыпается после 5-секундного нажатия, и энергопотребление в режиме STOP снизилось еще примерно на 10 мкА и составило примерно 9 мкА. Такие токи достаточно сложно измерять традиционными (китайскими) тестерами типа 828-го. На работе тестер показывает 9 мкА, мой домашний -- 14 мкА. Буду польщён, если этот камент кому-то поможет избежать проблем.

Вообще-то в мире есть лагерь Виндовс и есть лагерь UNIX/Linux. В каждом лагере приняты свои гласные и негласные правила. В том числе и правила именования файлов. Вот небольшая табличка соответствия суффикосов имён файлов в Линуксе расширениям имен в Виндовсе. UNIX/Linux Windows ---------- -------- Объектный модуль: File.o FILE.OBJ Статическая библиотека (архив): statLib.a LIBA.LIB Динамическая библиотека: dynLib.so DYNLIB.DLL Программа: Proga PROGA.EXE Мне думакется, что в компании IAR тупо взяли за основу gcc (который произростает из UNIX/Linux) и не захотели переделывать его на платформу Виндовса. Кроме того, в Линуксе принято к началу имени статической библиотеки добавлять три буквы -- "lib". Например, математическая библиотека имеет имя "libm.a". В Линуксе вообще понятие "расширение имени файла" ничем не поддерживается. Всё, что есть, -- это всё есть имя файла. И никаких расширений. Любовь придумали мужчины, чтобы не платить... Расширения придуманы в Виндовсе. Поэтому, в именах программ нет никаких дополнительных элементов, а символ точка (".") в имени файла -- это точно такой же символ как и другие Вас же не удивляет, что родительский каталог имеет имя состоящее из двух точек (".."). К стати, имя текущиго каталога -- это одна точка ("."). Более того, в Линуксе файлы, чьи имена начинаются с точки, считаются скрытыми. Поэтому текущий и родительский дириктории -- сходу являются скрытыми. С точки зрения пользователя Виндовса это всё необычно и кажется уродливым. Но с точки зрения пользователя UNIX/Linux -- это вполне нормальные комфортные правила. Каждому своё. В мире много языков (русский, китайский, английский). У каждого языка свои достоинства и свои проблемы. Просто, это -- разные миры. Но в каждом мире свои правила. Как то так. Не надо "катить" на IAR. Пионист играет, как умеет.

Ой! Это описка. Я сейчас работаю с STM32F030. Сегодня, если сподоблюсь попробую внутренний стабилизатор (1.8 В) переводить в экономичный режим. По результатам отпишусь здесь же. Добавлено. А вот хрен там! -- Не удержался, дописал-таки строку перевода внутреннего регулятора в режим энергосбережения. PWR->CR |= PWR_CR_LPDS; // Регулятор (1.8 В) в энергосберегающий режим В результате получил снижени потребляемого тока ещё на 10 мкА (как и описано в ДШ). Перед зпливкой проги тестер показывал 31-32 мкА (вчера почему-то показывл 27 мкА, наверно проц был холодный, только принёс с улицы). После заливки показывает 19-20 мкА.

1. Не отчаиваться! 2. Возможно я не прав, но я бы сначала сдул с платы всю (потребляющую или возможно потребляющую) периферию. Оставил бы МК "голым", в гордом одиночестве. И в такой конфигурации попытался бы получить нужное потребление. Потом бы шаг за шагом добавлял на плату периферийные микросхемы. 3. Когда я работал с MSP430, то в книжке (по моему вроде в книжке автора Фрузе) приводилась наглядная диаграмма сквозного тока у полевых структур, который возникает при входном напряжении, близком к половине питания. К сожалению, эту картинку я не смог найти, но нашел другую: Зрительные образы лучще запоминаются. 4. И ещё -- выдержка из книжки John H. Davies "MSP430 Microcontroller Basics" (она в инете выложена в pdf) Собственно, об этом С.Борщ сказал уже. 5. А Вы, случаем, не забываете отключить от платы программатор, когда измеряете потребление? У меня при подключении st-link (по SWD) потребление сразу возрастает. 6. Мне тоже нужно загнать свой девайс в спячку. Проц MSP430F030C8. Питание проца 3.3 В. Режим "спчки" -- STOP. Внутренний стабилизатор LDO на 1.8 В, я НЕ перевожу в малопотребляющий режим. Все биты портов проинициализированы и развёрнуты на выход. В том числе биты, которые предназначены для подключения кварцевых резонаторов. Вся внутренняя периферия (за исключенимем PWR и RTC) отключена. Главный цикл программы пустой: while (true) { SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk; __WFE(); } Просыпаюсь раз в секунду (от Alarm), зажигаю сетодиод на 5 мкс и тут же гашу -- потребление 33 мкА, Если просыпаюсь 128 раз в секунду (тоже по событию от AlarmA), то потребление возрастает до 40 мкА. Следует заметить, что разные тестеры (типа традиционного 838-го) показывают разное потребление. Показания колеблются от 27 мкА до 40 мкА.

А какая разница? Так то оно так, но при таком подходе к вопросам создания программного обеспечения, есть очень неприятный момент. Какая, собственно, разница -- на каком языке программирования была написана программа? Константы и инициализируемые данные всяко будут изначально находиться во флешь памяти. В начале работы (после включения, перезагрузки и т.п.) эти данные нужно перенести из флеша в оперативную память. Если прога пишется на асме, то сам программист прописывает этот код -- когда, куда и сколько перененести данных. Если прога пишется на Си, то эту работа выполняется до вызова main(). Конечно, Си-программисту не нужно заботиться о перемещении инициализированных данных и констант из флеша в оперативу, но когда таких данных становится много, то вполне может случиться так, что под них будет израсходована вся оператива. В этом случае остаётся только одно -- изменять код программы таким образом, чтобы эти данные копировались бы в оператуву только по мере надобности. Для этого существует библиотека pgmspace. Разумеется, что использование библиотеки привносит в исходный код программы больше отвлекающих (от основного назначения программы) действий, и увеличивает время работы. В каких-то приложениях с потерями времени и чехардой копирования (PGMspace) можно мириться, поэтому нельзя сказать, что программы, интенсивно и много использующие инициализированные переменные, принципиально наAVR-ках работать не могут. Могут! Особой проблемы с константами и инициализированными значениями нет, если их немного. Проблемы появляются, где используются текстовые строки -- всякие меню, подсказки и индикация помощи. Особенно неприятно, когда в устройстве не символьный, а графический дисплей -- тут, помимо текстовых строк, нужно ещё заморачиваться размещением таблиц растеризации символов. Ну либо соглашаться с потерей быстродействия. Когда, имеешь опыт работы с AVR-ками и с другими типами микроконтроллеров (MSP430, STM32), то отчётливо видишь, что AVR-ки хороши только при создании ногодыгалок и светодиодоморгалок. Для более серьезных применений лучше ориентироваться на другие МК. Это я еще не задел тему операционных систем и многопоточных приложений. Переключение контекста (переключение задач, переключение потоков исполнения) у AVR выглядит крайне расточительно на фоне её крошечного объема оперативы. И ещё раз -- я не говорю, что AVR-ки полохие. Я лишь утверждаю, что AVR-ки хорошо заточены для не очень сложных приложений.

Я извиняюсь! Пока писал "оду Царю", совсем забыл сказать про отладку. Недавно я прочухал вот какой прикол в отладке STM32. Я ещё раз извиняюсь -- я использую Линукс (Debian). И я уже совсем плохо ориентируюсь в Виндовсе. Поэтому то, что я скажу далее, всё это относится к Линуксу. Про Винду не скажу, наверняка там тоже есть подобные механизмы. Итак. У нас есть оттаживаемый микроконтроллер (target), есть отладочное оборудование (программатор, в частности STLink), есть запущенный gdb-сервер (OpenOCD) и есть запущенная программа отладчика (gdb-arm-none-eaby). Вот такая длинная цепочка. Казалось бы, сервер и отладчик можно было бы объединить в "один флакон". Я по началу так и думал. Я не понимал прелести такого решения. Понимание пришло намного позже. Так вот, для отладки запускам сначала gdb-сервер, а потом запускаме отладчик. Отладчик и сервер обащаются друг с другом через сокекты. Да к это -- Опа! Это же стевое разделение! Это значит отладчик и сервер можно разместить на разных компах. Есть о чём полдумать -- это раз. Два -- это то, что мы в отладчике ручками (ручками!) набираем команды для исполнения. Разумеется, есть команды для чтения данных по заданному адресу, есть команды записи данных по заданному адресу. Отладчик тупо передает набранные нами строки команд gdb-серверу, а тот через отладочное средство управляет микроконтроллером. Таким образом, обмен информацией между отладчиком и серваком осуществляется по сети (а если они оба запущены на одной машине, то через localhost) пакетам, внутри которых чисто -- текстовые строки. Тест можно можно сразу видеть. Это очень удобно. Три -- поскольку речь идет о STM32, у которых единое адресное пространство, то командами отладчика мы можем контролировать (читать/писать) не только ячейки оперативной памяти, но и управлять перифериными устройствами. Самый прстой пример -- смотреть, что делается на портах ввода GPIOx_IDR и устанавливать состояния портов вывода GPIOx_ODR. То есть мы контролируем всё адресное пространство -- то есть полностью весь микрококнтроллер! Идем дальше. Поскольку команды и ответы на них текстовые, то нам нико не нешает написать свою прогу на Питоне, которая будет через соект общаться с gdb-сервером, вместо отладчика. Грубо говоря, в питоновской программе мы описываем наши действия -- что мы хотим прочитать, что и куда хотим записать. В питоновской программе мы можем принимать решения, организовывать циклы, подпрограммы и так далее. То есть что получается. Мы в питоновской программе описываем действия, которые должны выполняться ядром cortex по отношению к периферии. Только вместо ядра работает питоновская прога. Другми словами -- программа, написанная на Питоне, рулит периферийными устройствами в микроконтроллере. Медленно, конечно, но ведь -- рулит! А на этапе ознакомления (освоения) -- какая разница -- быстро или медленно. На этом этапе главное понять -- как оно вообще должно работать. Более того -- если к микроконтроллеру подцеплено какое-то оборудование, ну, например, Bluetooth-модуль, драйвер RS485 или просто SD-карта, то мы можем очень легко овоить работу и с этим оборудованием. А когда поймём и разберёмся, то перенести алгоритм работы с Питона на Си для ядра -- это дело не такое уж и неподъёмное. Мне какжется, что я немного туманно объяснил. (Но наброс, кажись, таки удался. Ща будет, что обсудить и кого обсудить.)

(Упс! Оказывается собрание пайщиков гаражного кооператива стихийно продолжается...) Ну, это как бы теоретически -- да. Наверно можно дебажить камушки через dW. Но я с этим интерфейсом ни разу не работал. Да, у меня и оборудования-то такого нет. Есть куча всяких разных прошивальщиков. Проблема не в том, что есть или нет оборудование для отладки. Проблема в том, что я не считаю нужным вкладываться в AVR-платформу. Это проблема не уровня бухгалтерии, а проблема уровня идеологии. Улавливаете, о чём я толкую? Мир не стоит на месте. Технологии находятся к каком-то постоянном движении. Дело ведь не в одном программаторе-отладчике. У AVR-ок много родовых пролем. На вскидку назову только некоторые из них, которые мне особенно досталяют хлопот. Прежде всего это -- Гарвардская архитектура: три адресных пространства. Чтобы поработать с константами, которые находятся во флеш-памяти, константы нужно сначала скопировать в оператиную память, и только потом уже можно с ними производить какие-то действия. Вторая проблема -- до хрена и более регистров (РОН). С одной стороны -- это классно: теоретически повышается скорость выполнения программ, так как не надо вытеснять в оперативу длительно неиспользуемые значения. А с другой стороны -- когда задумываешься о вопросах примения РТОС на этой платформе, волосы дыбом встают. В том числе и на голове тоже. Уходим в прерываение -- нужно сохранить контекст текущей задачи. Отлично! Значит, нужно сохранить в оперативе весь банк РОН. Ну хорошо, не весь! Но все равно это расход оперативы и время реакции на возникшее прерывание. В общем, та ещё попаболь! А что говорить про "удачно" созданный регистр стека? Почему (это риторический вопрос) разработчики ядра AVR не сделали так, чтобы можно было обращаться к данным в стековом кадре с помощью SP? Почему для этого дела нужно привлекать ригистровую паруR28:R29,.. А потом люди удивляются -- зачем AVR-компиляторы создают два отдельных стека -- для адресов возвратов из подпрограмм и для данных. Третья проблема -- какой-то дурдом с фьюзами. Я прошу поднять руки тех, кто ни разу не окрпичивал AVR-ку. Я пониаю, всё то, что я назвал, это не такие уж и страшные проблемы. Они более-менее успешно решаются. И даже с помощью параллельного высоковольтного программатора можно обратно раскирпичить камень. Проблема AVR-ок в том, что на рынке есть более "вкусная" альтернатива в той же ценовой категории. Я не говорю, что AVR-ки в ближайшем будущем исчезнут как класс. Нет! Они ещё долго будут с нами. (Как минимум нужно поддерживать старые проекты!) Я лишь замечаю, что сектор AVR-ок на рынке значительно сократился. И я говорю за себя -- я всё чаще делаю выбор в пользу STM32 или MSP430F2xx, чем ATMEGA. Я не думаю, что я одинк в своих решениях. АВР-ка хороша в простых (и радиолюбительских) конструкциях, где нет многозадачности, где нужно создать прототип устройства как можно быстрее, где не нужно изучать работу периферийных устройств микроконтроллера по англоязычным pdf-кам. Ну, Вы понимаете? (И тут Остапа понесло...)

мне тоже не понравилось, выглядит как нарушение стандарта Хотя нет! Соврал, соврал! Я забыл упомянуть таиких зверей, как AT91SAMxxx. У них UART тоже генерит меандр в паузах. Но ведь они ж ... вымылись из употребления. :( Но самый писк я обнаружил в STM32. Там даже в режиме SPI можно генерить меандр. Казалось бы -- класс! Но, кому-то в голову пришло что генерацию нужно выключать не только в паузах между передачами байтов, но и при выводе стартовых и стоповых битов. Ну, я даже не знаю, как это комментировать... И тем не менее, в большинстве проектов я всё равно предпочетаю использовать stm-ки, а не.AVR-ки. Риторический вопрос -- Вот интересно, а почему?

Почему-то вспоминается анекдот: Доктор: -- Больной перед кончиной потел? Родственники (хором): -- Да-а! Доктор: -- Оч-ч-хорошо!!! На минутку. Я по инерции иногда продолжаю закладывать AVR-ки в некоторые свои простецкие проекты. Ну, например, я не смог найти замену Меге среди STM32 и MSP430. Был у меня такой проект, где требовалось передавать данные по длинному (5 км) коаксиальному кабелю. Делать это нужно было на фоне питающего напряжения, которое поступало с противоположного конца кабеляна. Было решено, что передача будет происходить по UART в коде Manchester-II в виде токовых посылок. То есть не напряжением, а модуляцией потребляемого тока. В паузах между пакетами байтов (чтобы сохранить средний уровень) нужно генерить чистый меандр (без сигнала). Думаю, понятно -- берём выход UART-а и синхронный с ним генератор и смешиваем эти сигналы на ИСКЛЮЧАЮЩЕМ-ИЛИ. Вроде всё просто! Но собака порылась в генераторе! Во всех МК, с которыми я имел дело (программаторы, компиляторы и т.д.), присутствует такой вывод генератора. Но толькое в AVR-ках этот вывод продолжает генерить, в паузах, А вот в о всех других МК генерация прекращается всместе с сигналом из UART. От-такой казус. И тем не менее, я болше предпочетаю юзать STM32? а не AVR-ки. Могу сказать пару слов, чем это объясняется. Дело в том, что чтобы прикрутить к AVR-ке отладчик по JTAG, нужно забрать у неё под это дело весьма дефицитные ножки. А с другой стороны, если я, допустим отлаживаю какую-то прогу на STM32, и у меня ещё очень много непонимания что-как должно работать, то в таких редких случаях я пишу не код для исполнения ядром МК, а некоторый скрипт, который исполняется программой на Питоне (на компе). То есть -- псевдо-код для управления, который исполняется Питоновской программой на компе. Такая вот, фигня! Питон, исполняя прогу, обращяется через отладчик к регистрам периферийных устройств, к ячейкам оперативной памяти МК -- то есть выполнение задуманного алгоритма происходит не в МК, а на компе, а с другой стороны -- алгоритм использует железо МК. Вы правы! Да, программа выполняется медленно. Да, иногда бывают косяки. Но! Согласитесь -- скорость разработки "трудных" участков возрастает, поскольку тупо нет таких операций как компиляци и заливка. Если обнаруживается, что в скрипте что-то не то или не так, то процесс останавливается, на лету правится текст скрипта и вновь запускается сеанс отладки.. Более того, я тут на форуме иногда читаю, что у людей возникают проблемы с IAR-ом -- что де то он не выдает в отладочное окно какой-то набор регистров, то не показывает ещё какие-то дела. При подхлде, который я озвучил, таких проблем в принципе не возникает. Но есть одна большая проблема, которую я не рашаюсь назвать дабы невызывать волну религиозныз баталий. В общем, моё мнение такое, что AVR-ки не умерли. И не умрут ещё очень долго. Но их ниша на рынке неизбежно сокращается. И будет продолжать сокращаться по мере выхода из активного творческого состояния AVR-разработчиков, (На пенсию, переквалификация в другие экономические сферы.) Чуть выше кто-то уже задевал вопрос о том, почему форумы электронщиков-разработчиков-программистов в последние года два резко поугасли. Да вот потому и поугасли, что на рынке поугас спрос на разработку нового оборудования. У всех всё есть -- а ты попробуй подать своё изделие! Точно такое же как у сотни других производителей, но чуть-чуть другое. Яркий пример тому как раз накручивание тумана вокруг обсуждаемой здесь технологии CIP. Не заманишь -- не продашь! (Извините за то, что много написал.)

Отчего ж нельзя? Можно! Тем более мне всё равно делать нечего. Специально для Вас: КОНТИНГЕНТ -- это совокупность людей, образующих однородную в каком-либо отношении группу. (хттпс://ru.wiktionary.org/wiki/контингент) Официального разделения разработчиков на группы не существует. По крайней мере я такого задела в инете не встречал, а с другой стороны -- и не искал специально. Потому это мне как нафиг не нужно. Ну поскольку Вы интересуетесь, то это меняет дело. Итак, у меня очень слабое представление о группах (контингентах) разработчиков. С болшим трудом я различаю начинающих, более-менее поднатаревших и реально профи, перед которыми принято снимать с головы всякие покровы. Интрига моего первого поста состоит в том, что начинающим разработчикам эта хрень (я имею ввиду CIP) не по зубам. Но я иногда замечаю за некоторыми из них, кто с азартом применяет незнакомые им термины. Эдакая бравада некоторых бабуинов перед другими такими же бабуинами. Для продвинутых разработчиков, которые уже изъездили МК вдоль и поперёк эта "завлекалочки" до лампочки. Кому из низ действительно это было нужно, тот уже использовал эти технологии (в других типах МК). Поэтому мне и не понятно -- кого хотели маркетологи охмурить этим грязным трюком. На что расчитывали? Ни и -- что в итоге получили? Интересно же! Ну, вот, как-то так. Извините, если что.

Фу, какой грязный маркетинговый ход! Фу, какая низкопробная замануха-ха-ха-ха! (хттп://www.rlocman.ru/news/new.html?di=250263) Интересно, на какой контингент разработчиков был расчитан этот червячок?