Перейти к содержанию

zhevak

Свой
  • Публикаций

    723
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о zhevak

  • Звание
    Знающий
  • День рождения 30.03.1962

Контакты

  • Сайт
    http://zhevak.wordpress.com/
  • ICQ
    47933803

Информация

  • Город
    Березовский
  1. Китайский аналог STM32F103C8T6

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

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

    Коллеги! Двумя комментариями выше я привёл код, который отправляет МК в спячку. В коде ошибка! Правильный код должен быть таким: 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 мкА. Буду польщён, если этот камент кому-то поможет избежать проблем.
  4. Библиотеки

    Вообще-то в мире есть лагерь Виндовс и есть лагерь 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. Пионист играет, как умеет.
  5. Грабли с энергосбережением STM32F0

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

    Цитата(KnightIgor @ May 7 2018, 23:40) Где копать дальше - не знаю. 1. Не отчаиваться! 2. Возможно я не прав, но я бы сначала сдул с платы всю (потребляющую или возможно потребляющую) периферию. Оставил бы МК "голым", в гордом одиночестве. И в такой конфигурации попытался бы получить нужное потребление. Потом бы шаг за шагом добавлял на плату периферийные микросхемы. 3. Когда я работал с MSP430, то в книжке (по моему вроде в книжке автора Фрузе) приводилась наглядная диаграмма сквозного тока у полевых структур, который возникает при входном напряжении, близком к половине питания. К сожалению, эту картинку я не смог найти, но нашел другую: Зрительные образы лучще запоминаются. 4. И ещё -- выдержка из книжки John H. Davies "MSP430 Microcontroller Basics" (она в инете выложена в pdf) Цитата[page 215] 7.2.1 Configuration of Unused Pins Not all of the input/output pins are used in most applications. Unused pins must never be left unconnected in their default state as inputs. This follows a general rule that inputs to CMOS must never be left unconnected or ”floating.” A surprising number of problems can be caused by floating inputs. The most trivial is that the input circuit draws an excessive current from the power supply. This is because the input is likely to float to the midpoint of V SS and V CC , turning on both MOSFETs and leading to the situation shown in Figure 7.2©. The shoot-through current may exceed 40 ␮A, a huge waste by the standards of the MSP430. Old CMOS circuits, such as the 74HC family, are amazingly sensitive to floating inputs. They may oscillate or refuse to work at all if an input is floating, even if the input belongs to an unused gate or flip-flop. I have seen this happen many times when students have not taken heed of the rule about floating inputs. Missing decoupling (bypass) capacitors can cause similar problems. Floating inputs are also susceptible to noise and to static electricity if the product is handled, which may lead to permanent damage. There are three ways of avoiding these problems: 1. Wire the unused pins externally to a well-defined voltage, either V SS or V CC , and configure them as inputs. The danger with this is that you might damage the MCU if the pins are accidentally configured as outputs. 2. Leave the pins unconnected externally but connect them internally to either V SS or V CC by using the pull-down or pull-up resistors. They are again configured as inputs. I prefer this approach but it is restricted to the MSP430F2xx family because the others lack internal pull resistors. 3. Leave the pins unconnected and configure them as outputs. The value in the output register does not matter. This is perhaps the most robust solution and is recommended for MSP430 devices that lack internal pull resistors. I am less keen on this approach for experimental systems because it is easy to short-circuit pins with a test probe. There is a helpful list of recommended connections for unused pins at the end of the chapter on System Resets, Interrupts, and Operating Modes in the family user’s guides. In some manufacturers’ devices the unconnected bits of a port may be present on the chip itself but are not bonded to pins. In this case it is important to configure all bits of the port correctly, including those that are not connected to the outside world. This issue arises when the same integrated circuit (the same ”silicon”) may be offered in packages with different numbers of pins. I believe that this does not apply to the MSP430. However, a few input/output registers contain bits without corresponding pins. For example, the F1121A has all 8 bits of P2IFG implemented on silicon but there are pins for only P2.0–P2.5. The bits for the missing pins 6 and 7 can be used for software interrupts. Собственно, об этом С.Борщ сказал уже. 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 мкА.
  7. Цитата(Zlumd @ Sep 4 2017, 11:59) На ассемблере что-ли пишете? На С пофигу в какой памяти константы лежат. А какая разница? Так то оно так, но при таком подходе к вопросам создания программного обеспечения, есть очень неприятный момент. Какая, собственно, разница -- на каком языке программирования была написана программа? Константы и инициализируемые данные всяко будут изначально находиться во флешь памяти. В начале работы (после включения, перезагрузки и т.п.) эти данные нужно перенести из флеша в оперативную память. Если прога пишется на асме, то сам программист прописывает этот код -- когда, куда и сколько перененести данных. Если прога пишется на Си, то эту работа выполняется до вызова main(). Конечно, Си-программисту не нужно заботиться о перемещении инициализированных данных и констант из флеша в оперативу, но когда таких данных становится много, то вполне может случиться так, что под них будет израсходована вся оператива. В этом случае остаётся только одно -- изменять код программы таким образом, чтобы эти данные копировались бы в оператуву только по мере надобности. Для этого существует библиотека pgmspace. Разумеется, что использование библиотеки привносит в исходный код программы больше отвлекающих (от основного назначения программы) действий, и увеличивает время работы. В каких-то приложениях с потерями времени и чехардой копирования (PGMspace) можно мириться, поэтому нельзя сказать, что программы, интенсивно и много использующие инициализированные переменные, принципиально наAVR-ках работать не могут. Могут! Особой проблемы с константами и инициализированными значениями нет, если их немного. Проблемы появляются, где используются текстовые строки -- всякие меню, подсказки и индикация помощи. Особенно неприятно, когда в устройстве не символьный, а графический дисплей -- тут, помимо текстовых строк, нужно ещё заморачиваться размещением таблиц растеризации символов. Ну либо соглашаться с потерей быстродействия. Когда, имеешь опыт работы с AVR-ками и с другими типами микроконтроллеров (MSP430, STM32), то отчётливо видишь, что AVR-ки хороши только при создании ногодыгалок и светодиодоморгалок. Для более серьезных применений лучше ориентироваться на другие МК. Это я еще не задел тему операционных систем и многопоточных приложений. Переключение контекста (переключение задач, переключение потоков исполнения) у AVR выглядит крайне расточительно на фоне её крошечного объема оперативы. И ещё раз -- я не говорю, что AVR-ки полохие. Я лишь утверждаю, что AVR-ки хорошо заточены для не очень сложных приложений.
  8. Цитата(AI7 @ Jul 12 2017, 00:38) Это не проблема для АВР, только надо использовать другой отладчик. Я извиняюсь! Пока писал "оду Царю", совсем забыл сказать про отладку. Недавно я прочухал вот какой прикол в отладке STM32. Я ещё раз извиняюсь -- я использую Линукс (Debian). И я уже совсем плохо ориентируюсь в Виндовсе. Поэтому то, что я скажу далее, всё это относится к Линуксу. Про Винду не скажу, наверняка там тоже есть подобные механизмы. Итак. У нас есть оттаживаемый микроконтроллер (target), есть отладочное оборудование (программатор, в частности STLink), есть запущенный gdb-сервер (OpenOCD) и есть запущенная программа отладчика (gdb-arm-none-eaby). Вот такая длинная цепочка. Казалось бы, сервер и отладчик можно было бы объединить в "один флакон". Я по началу так и думал. Я не понимал прелести такого решения. Понимание пришло намного позже. Так вот, для отладки запускам сначала gdb-сервер, а потом запускаме отладчик. Отладчик и сервер обащаются друг с другом через сокекты. Да к это -- Опа! Это же стевое разделение! Это значит отладчик и сервер можно разместить на разных компах. Есть о чём полдумать -- это раз. Два -- это то, что мы в отладчике ручками (ручками!) набираем команды для исполнения. Разумеется, есть команды для чтения данных по заданному адресу, есть команды записи данных по заданному адресу. Отладчик тупо передает набранные нами строки команд gdb-серверу, а тот через отладочное средство управляет микроконтроллером. Таким образом, обмен информацией между отладчиком и серваком осуществляется по сети (а если они оба запущены на одной машине, то через localhost) пакетам, внутри которых чисто -- текстовые строки. Тест можно можно сразу видеть. Это очень удобно. Три -- поскольку речь идет о STM32, у которых единое адресное пространство, то командами отладчика мы можем контролировать (читать/писать) не только ячейки оперативной памяти, но и управлять перифериными устройствами. Самый прстой пример -- смотреть, что делается на портах ввода GPIOx_IDR и устанавливать состояния портов вывода GPIOx_ODR. То есть мы контролируем всё адресное пространство -- то есть полностью весь микрококнтроллер! Идем дальше. Поскольку команды и ответы на них текстовые, то нам нико не нешает написать свою прогу на Питоне, которая будет через соект общаться с gdb-сервером, вместо отладчика. Грубо говоря, в питоновской программе мы описываем наши действия -- что мы хотим прочитать, что и куда хотим записать. В питоновской программе мы можем принимать решения, организовывать циклы, подпрограммы и так далее. То есть что получается. Мы в питоновской программе описываем действия, которые должны выполняться ядром cortex по отношению к периферии. Только вместо ядра работает питоновская прога. Другми словами -- программа, написанная на Питоне, рулит периферийными устройствами в микроконтроллере. Медленно, конечно, но ведь -- рулит! А на этапе ознакомления (освоения) -- какая разница -- быстро или медленно. На этом этапе главное понять -- как оно вообще должно работать. Более того -- если к микроконтроллеру подцеплено какое-то оборудование, ну, например, Bluetooth-модуль, драйвер RS485 или просто SD-карта, то мы можем очень легко овоить работу и с этим оборудованием. А когда поймём и разберёмся, то перенести алгоритм работы с Питона на Си для ядра -- это дело не такое уж и неподъёмное. Мне какжется, что я немного туманно объяснил. (Но наброс, кажись, таки удался. Ща будет, что обсудить и кого обсудить.)
  9. Цитата(AI7 @ Jul 12 2017, 00:38) Это не проблема для АВР, только надо использовать другой отладчик. Использую отладчик, где через пару ножек (тактовый сигнал и сигнал данных) программно выбрасывается байт в отладчик, вполне достаточно для отладки. Поскольку запись байта в отладчик производится по тактовому сигналу, под сигнал данных можно задействовать занятую ножку, лишь бы она была на выход. Так что нужна одна свободная ножка. У меня в отладчике есть некоторая защита, поэтому под тактовый сигнал также можно использовать занятую ножку, но с некоторыми ограничениями. (Упс! Оказывается собрание пайщиков гаражного кооператива стихийно продолжается...) Ну, это как бы теоретически -- да. Наверно можно дебажить камушки через dW. Но я с этим интерфейсом ни разу не работал. Да, у меня и оборудования-то такого нет. Есть куча всяких разных прошивальщиков. Проблема не в том, что есть или нет оборудование для отладки. Проблема в том, что я не считаю нужным вкладываться в AVR-платформу. Это проблема не уровня бухгалтерии, а проблема уровня идеологии. Улавливаете, о чём я толкую? Мир не стоит на месте. Технологии находятся к каком-то постоянном движении. Дело ведь не в одном программаторе-отладчике. У AVR-ок много родовых пролем. На вскидку назову только некоторые из них, которые мне особенно досталяют хлопот. Прежде всего это -- Гарвардская архитектура: три адресных пространства. Чтобы поработать с константами, которые находятся во флеш-памяти, константы нужно сначала скопировать в оператиную память, и только потом уже можно с ними производить какие-то действия. Вторая проблема -- до хрена и более регистров (РОН). С одной стороны -- это классно: теоретически повышается скорость выполнения программ, так как не надо вытеснять в оперативу длительно неиспользуемые значения. А с другой стороны -- когда задумываешься о вопросах примения РТОС на этой платформе, волосы дыбом встают. В том числе и на голове тоже. Уходим в прерываение -- нужно сохранить контекст текущей задачи. Отлично! Значит, нужно сохранить в оперативе весь банк РОН. Ну хорошо, не весь! Но все равно это расход оперативы и время реакции на возникшее прерывание. В общем, та ещё попаболь! А что говорить про "удачно" созданный регистр стека? Почему (это риторический вопрос) разработчики ядра AVR не сделали так, чтобы можно было обращаться к данным в стековом кадре с помощью SP? Почему для этого дела нужно привлекать ригистровую паруR28:R29,.. А потом люди удивляются -- зачем AVR-компиляторы создают два отдельных стека -- для адресов возвратов из подпрограмм и для данных. Третья проблема -- какой-то дурдом с фьюзами. Я прошу поднять руки тех, кто ни разу не окрпичивал AVR-ку. Я пониаю, всё то, что я назвал, это не такие уж и страшные проблемы. Они более-менее успешно решаются. И даже с помощью параллельного высоковольтного программатора можно обратно раскирпичить камень. Проблема AVR-ок в том, что на рынке есть более "вкусная" альтернатива в той же ценовой категории. Я не говорю, что AVR-ки в ближайшем будущем исчезнут как класс. Нет! Они ещё долго будут с нами. (Как минимум нужно поддерживать старые проекты!) Я лишь замечаю, что сектор AVR-ок на рынке значительно сократился. И я говорю за себя -- я всё чаще делаю выбор в пользу STM32 или MSP430F2xx, чем ATMEGA. Я не думаю, что я одинк в своих решениях. АВР-ка хороша в простых (и радиолюбительских) конструкциях, где нет многозадачности, где нужно создать прототип устройства как можно быстрее, где не нужно изучать работу периферийных устройств микроконтроллера по англоязычным pdf-кам. Ну, Вы понимаете? (И тут Остапа понесло...)
  10. Цитата(Огурцов @ May 30 2017, 13:50) Цитата А вот в о всех других МК генерация прекращается всместе с сигналом из UART мне тоже не понравилось, выглядит как нарушение стандарта Хотя нет! Соврал, соврал! Я забыл упомянуть таиких зверей, как AT91SAMxxx. У них UART тоже генерит меандр в паузах. Но ведь они ж ... вымылись из употребления. Но самый писк я обнаружил в STM32. Там даже в режиме SPI можно генерить меандр. Казалось бы -- класс! Но, кому-то в голову пришло что генерацию нужно выключать не только в паузах между передачами байтов, но и при выводе стартовых и стоповых битов. Ну, я даже не знаю, как это комментировать... И тем не менее, в большинстве проектов я всё равно предпочетаю использовать stm-ки, а не.AVR-ки. Риторический вопрос -- Вот интересно, а почему?
  11. Цитата(zombi @ May 30 2017, 02:25) трупик вздохнул...и умер ещё раз ... очень на то похоже ... Почему-то вспоминается анекдот: Доктор: -- Больной перед кончиной потел? Родственники (хором): -- Да-а! Доктор: -- Оч-ч-хорошо!!! На минутку. Я по инерции иногда продолжаю закладывать AVR-ки в некоторые свои простецкие проекты. Ну, например, я не смог найти замену Меге среди STM32 и MSP430. Был у меня такой проект, где требовалось передавать данные по длинному (5 км) коаксиальному кабелю. Делать это нужно было на фоне питающего напряжения, которое поступало с противоположного конца кабеляна. Было решено, что передача будет происходить по UART в коде Manchester-II в виде токовых посылок. То есть не напряжением, а модуляцией потребляемого тока. В паузах между пакетами байтов (чтобы сохранить средний уровень) нужно генерить чистый меандр (без сигнала). Думаю, понятно -- берём выход UART-а и синхронный с ним генератор и смешиваем эти сигналы на ИСКЛЮЧАЮЩЕМ-ИЛИ. Вроде всё просто! Но собака порылась в генераторе! Во всех МК, с которыми я имел дело (программаторы, компиляторы и т.д.), присутствует такой вывод генератора. Но толькое в AVR-ках этот вывод продолжает генерить, в паузах, А вот в о всех других МК генерация прекращается всместе с сигналом из UART. От-такой казус. И тем не менее, я болше предпочетаю юзать STM32? а не AVR-ки. Могу сказать пару слов, чем это объясняется. Дело в том, что чтобы прикрутить к AVR-ке отладчик по JTAG, нужно забрать у неё под это дело весьма дефицитные ножки. А с другой стороны, если я, допустим отлаживаю какую-то прогу на STM32, и у меня ещё очень много непонимания что-как должно работать, то в таких редких случаях я пишу не код для исполнения ядром МК, а некоторый скрипт, который исполняется программой на Питоне (на компе). То есть -- псевдо-код для управления, который исполняется Питоновской программой на компе. Такая вот, фигня! Питон, исполняя прогу, обращяется через отладчик к регистрам периферийных устройств, к ячейкам оперативной памяти МК -- то есть выполнение задуманного алгоритма происходит не в МК, а на компе, а с другой стороны -- алгоритм использует железо МК. Вы правы! Да, программа выполняется медленно. Да, иногда бывают косяки. Но! Согласитесь -- скорость разработки "трудных" участков возрастает, поскольку тупо нет таких операций как компиляци и заливка. Если обнаруживается, что в скрипте что-то не то или не так, то процесс останавливается, на лету правится текст скрипта и вновь запускается сеанс отладки.. Более того, я тут на форуме иногда читаю, что у людей возникают проблемы с IAR-ом -- что де то он не выдает в отладочное окно какой-то набор регистров, то не показывает ещё какие-то дела. При подхлде, который я озвучил, таких проблем в принципе не возникает. Но есть одна большая проблема, которую я не рашаюсь назвать дабы невызывать волну религиозныз баталий. В общем, моё мнение такое, что AVR-ки не умерли. И не умрут ещё очень долго. Но их ниша на рынке неизбежно сокращается. И будет продолжать сокращаться по мере выхода из активного творческого состояния AVR-разработчиков, (На пенсию, переквалификация в другие экономические сферы.) Чуть выше кто-то уже задевал вопрос о том, почему форумы электронщиков-разработчиков-программистов в последние года два резко поугасли. Да вот потому и поугасли, что на рынке поугас спрос на разработку нового оборудования. У всех всё есть -- а ты попробуй подать своё изделие! Точно такое же как у сотни других производителей, но чуть-чуть другое. Яркий пример тому как раз накручивание тумана вокруг обсуждаемой здесь технологии CIP. Не заманишь -- не продашь! (Извините за то, что много написал.)
  12. Цитата(Dr.Alex @ May 29 2017, 21:22) Микроконтроллерщики делятся на контингенты? Можно об этом поподробнее? :-))) Отчего ж нельзя? Можно! Тем более мне всё равно делать нечего. Специально для Вас: КОНТИНГЕНТ -- это совокупность людей, образующих однородную в каком-либо отношении группу. (хттпс://ru.wiktionary.org/wiki/контингент) Официального разделения разработчиков на группы не существует. По крайней мере я такого задела в инете не встречал, а с другой стороны -- и не искал специально. Потому это мне как нафиг не нужно. Ну поскольку Вы интересуетесь, то это меняет дело. Итак, у меня очень слабое представление о группах (контингентах) разработчиков. С болшим трудом я различаю начинающих, более-менее поднатаревших и реально профи, перед которыми принято снимать с головы всякие покровы. Интрига моего первого поста состоит в том, что начинающим разработчикам эта хрень (я имею ввиду CIP) не по зубам. Но я иногда замечаю за некоторыми из них, кто с азартом применяет незнакомые им термины. Эдакая бравада некоторых бабуинов перед другими такими же бабуинами. Для продвинутых разработчиков, которые уже изъездили МК вдоль и поперёк эта "завлекалочки" до лампочки. Кому из низ действительно это было нужно, тот уже использовал эти технологии (в других типах МК). Поэтому мне и не понятно -- кого хотели маркетологи охмурить этим грязным трюком. На что расчитывали? Ни и -- что в итоге получили? Интересно же! Ну, вот, как-то так. Извините, если что.
  13. Цитата(Obam @ May 29 2017, 16:43) Да класс… Забавно тут: 8-bit, high-performance Atmel AVR RISC CPU – 135 instructions Фу, какой грязный маркетинговый ход! Фу, какая низкопробная замануха-ха-ха-ха! Цитата... стали первыми микроконтроллерами tinyAVR с независимой от ядра периферией (Core Independent Peripherals – CIP) (хттп://www.rlocman.ru/news/new.html?di=250263) Интересно, на какой контингент разработчиков был расчитан этот червячок?
  14. Необходимо подобрать замену

    Цитата(Igont @ Oct 30 2015, 00:15) Так где тот Cortex который заменит AVR...... А он что, обязан что ли заменить AVR-ки во всех-во всех применениях? (Не отвечайте, а то опять разовьется дискуссия ни о чём.)
  15. Необходимо подобрать замену

    Цитата(smalcom @ Oct 29 2015, 22:41) читайте ещё раз и внимательно. у ТСа автомобильные компоненты. 1. Ну я как бы знаю, что офф-топ. И даже принес извинения. Какой смысл в смайлике? 2. Ну я как бы внимательно прочитал требования товарища. Не догадаться по требованиям температурного диапазона о назначении изделия очень сложно. Но дело в другом. Дело в том, что специалист сначала акцентирует внимание на наиболее существенных проблемах. Требования по температурному диапазону стоят аж на третьем месте. А на первом месте не радиационная стойкость, не агрессивная среда, ... Вы только не смейтесь! На первом месте стоит: ЦитатаНог у него 32 (важно, т. к. размер и монтажная простота) О чём это говорит? Вы понимаете, что для товарища особенно важно? Разве это не попадалово?