Неожиданно. Зачем? Микрочиповцы решили поглумиться под занавес над AVR? )
http://www.microchip.com/wwwproducts/en/ATtiny817
http://www.rlocman.ru/news/new.html?di=250263

Да класс…
Забавно тут: 8-bit, high-performance Atmel AVR RISC CPU
– 135 instructions

Фу, какой грязный маркетинговый ход! Фу, какая низкопробная замануха-ха-ха-ха!

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

Это не глумление но признание архитектуры. Я думаю, что AVR под MICROCHIP получат второе дыхание.

Может и правда вдохнут жизнь)))
Онлайн приблуду сделали для инициализации : http://start.atmel.com/#

всё, что просили, всё, что atmel нужно было сделать - поднять тактовую в 10 раз (теперь уже в 100)
теперь st идёт по тем же граблям - нужно поднять тактовую в 10 раз, но они ни в какую
скоро мы увидим ту же самую картину
независимая переферия - было прикольно, но теперь это как мёртвому припарки



трупик вздохнул...и умер ещё раз

Микроконтроллерщики делятся на контингенты?
Можно об этом поподробнее? :-)))

Отчего ж нельзя? Можно! Тем более мне всё равно делать нечего.

Специально для Вас:

КОНТИНГЕНТ -- это совокупность людей, образующих однородную в каком-либо отношении группу.
(хттпс://ru.wiktionary.org/wiki/контингент)

Официального разделения разработчиков на группы не существует. По крайней мере я такого задела в инете не встречал, а с другой стороны -- и не искал специально. Потому это мне как нафиг не нужно. Ну поскольку Вы интересуетесь, то это меняет дело. Итак, у меня очень слабое представление о группах (контингентах) разработчиков. С болшим трудом я различаю начинающих, более-менее поднатаревших и реально профи, перед которыми принято снимать с головы всякие покровы.

Интрига моего первого поста состоит в том, что начинающим разработчикам эта хрень (я имею ввиду CIP) не по зубам. Но я иногда замечаю за некоторыми из них, кто с азартом применяет незнакомые им термины. Эдакая бравада некоторых бабуинов перед другими такими же бабуинами. Для продвинутых разработчиков, которые уже изъездили МК вдоль и поперёк эта "завлекалочки" до лампочки. Кому из низ действительно это было нужно, тот уже использовал эти технологии (в других типах МК).

Поэтому мне и не понятно -- кого хотели маркетологи охмурить этим грязным трюком. На что расчитывали? Ни и -- что в итоге получили? Интересно же!

Ну, вот, как-то так. Извините, если что.

Такие буквы (CIP) первый раз увидел, решил просвятиться: тут
Насчет Waveform генераторов большой новизны не нашел, а остальное неплохо.
Не припоминаю прежних маленьких МК с зачатками CPLD, блоками частотного выхода и встроенными контроллерами DC/DC преобразователей.

Так что какая разница на кого эта реклама рассчитана?
Они же не врут, действительно, в tinyAVR такие блоки периферии от Микрочип были засунуты впервые

Являясь приверженцем Atmel не могу не признать откровенного глумления микрочипа над оным!



100%, а еще лучше в 1000 раз клок поднять!
А они все какие-то CIPы-дрипы внутрь пихают, издеваются, не иначе...

Купили, сволочи, деньги вложили, периферию улучшают, выпускать продолжают, цены не поднимают!
Нет, чтобы, замочить одним ударом. Издеваются, не иначе...

Да ну нах не поднимают!!! брал иксмеги по $2.55 сейчас по $5.90 хер найдёшь
Тысячами покупаю

Облажались с E Series и решили в тини эту CIPу запихнуть


очень на то похоже

да, лучше
и у нормальных производителей это будет
пока тактовая у них ограничена единицами гигагерц
что для разных недочипов в 100 раз выше



прям неуловимый джо

Для утюгов нужны гигагерцы?
Подавляющее большинство приборов в жизни - утюги...

Почему-то вспоминается анекдот:

Доктор:
-- Больной перед кончиной потел?
Родственники (хором):
-- Да-а!
Доктор:
-- Оч-ч-хорошо!!!

На минутку. Я по инерции иногда продолжаю закладывать AVR-ки в некоторые свои простецкие проекты.

Ну, например, я не смог найти замену Меге среди STM32 и MSP430. Был у меня такой проект, где требовалось передавать данные по длинному (5 км) коаксиальному кабелю. Делать это нужно было на фоне питающего напряжения, которое поступало с противоположного конца кабеляна. Было решено, что передача будет происходить по UART в коде Manchester-II в виде токовых посылок. То есть не напряжением, а модуляцией потребляемого тока.

В паузах между пакетами байтов (чтобы сохранить средний уровень) нужно генерить чистый меандр (без сигнала). Думаю, понятно -- берём выход UART-а и синхронный с ним генератор и смешиваем эти сигналы на ИСКЛЮЧАЮЩЕМ-ИЛИ. Вроде всё просто! Но собака порылась в генераторе!

Во всех МК, с которыми я имел дело (программаторы, компиляторы и т.д.), присутствует такой вывод генератора. Но толькое в AVR-ках этот вывод продолжает генерить, в паузах, А вот в о всех других МК генерация прекращается всместе с сигналом из UART.

От-такой казус.

И тем не менее, я болше предпочетаю юзать STM32? а не AVR-ки. Могу сказать пару слов, чем это объясняется.

Дело в том, что чтобы прикрутить к AVR-ке отладчик по JTAG, нужно забрать у неё под это дело весьма дефицитные ножки. А с другой стороны, если я, допустим отлаживаю какую-то прогу на STM32, и у меня ещё очень много непонимания что-как должно работать, то в таких редких случаях я пишу не код для исполнения ядром МК, а некоторый скрипт, который исполняется программой на Питоне (на компе). То есть -- псевдо-код для управления, который исполняется Питоновской программой на компе. Такая вот, фигня!

Питон, исполняя прогу, обращяется через отладчик к регистрам периферийных устройств, к ячейкам оперативной памяти МК -- то есть выполнение задуманного алгоритма происходит не в МК, а на компе, а с другой стороны -- алгоритм использует железо МК.

Вы правы! Да, программа выполняется медленно. Да, иногда бывают косяки. Но! Согласитесь -- скорость разработки "трудных" участков возрастает, поскольку тупо нет таких операций как компиляци и заливка. Если обнаруживается, что в скрипте что-то не то или не так, то процесс останавливается, на лету правится текст скрипта и вновь запускается сеанс отладки..

Более того, я тут на форуме иногда читаю, что у людей возникают проблемы с IAR-ом -- что де то он не выдает в отладочное окно какой-то набор регистров, то не показывает ещё какие-то дела. При подхлде, который я озвучил, таких проблем в принципе не возникает. Но есть одна большая проблема, которую я не рашаюсь назвать дабы невызывать волну религиозныз баталий.

В общем, моё мнение такое, что AVR-ки не умерли. И не умрут ещё очень долго. Но их ниша на рынке неизбежно сокращается. И будет продолжать сокращаться по мере выхода из активного творческого состояния AVR-разработчиков, (На пенсию, переквалификация в другие экономические сферы.)

Чуть выше кто-то уже задевал вопрос о том, почему форумы электронщиков-разработчиков-программистов в последние года два резко поугасли. Да вот потому и поугасли, что на рынке поугас спрос на разработку нового оборудования. У всех всё есть -- а ты попробуй подать своё изделие! Точно такое же как у сотни других производителей, но чуть-чуть другое. Яркий пример тому как раз накручивание тумана вокруг обсуждаемой здесь технологии CIP. Не заманишь -- не продашь!

(Извините за то, что много написал.)

мне тоже не понравилось, выглядит как нарушение стандарта


хороша ложка к обеду
а обед был 15..20 лет назад

Хотя нет! Соврал, соврал! Я забыл упомянуть таиких зверей, как AT91SAMxxx. У них UART тоже генерит меандр в паузах. Но ведь они ж ... вымылись из употребления.

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

"трупик", кстати, в космосе летает уже года два.

так трупики тама толка и мохут лэтать! нармалныэ чыпы тыпа stm32 давно уже здохли бы...

http://www.microchip.com/wwwproducts/en/ATmega88
косячок, RAM Bytes = 1

в feedback отправить не смог, контрольная картинка не отображается. А потом вообще "An error has occurred on the page you were visiting. We apologize for the inconvenience. "
так что авр-патриоты, киньте им мессагу

это не ниша АВР, у них для таких мощностей другие семейства.
памяти у них нехватает катастрофически - вот это да, но это вроде сброшено в туже нишу где и тактовая в 10раз больше.
получается что неспешный контроллер со средним объемом программы найти сложно. техас с мпс430 рулит.

Среди STM32 можно найти микроконтроллер на любой вкус. Стоит только окунуться, и вылазить не захочется.

Да сейчас свои контроллеры только ленивый не клепает. Почти каждая полупроводниковая шарашка клепает свои MCU

Только STMicroelectronics - не шаражка. Лидер.

По какому критерию?

По маркетинговой политике в первую очередь: поддержка + цены. Что, впрочем, не мешает нам использовать в основном LPC. Но найти замену AVR среди STM действительно можно. Одна серия F0 чего стоит! И в прямом и в переносном смысле. Я имею в виду возможности, и низкие цены.

Даже с тремя UART в корпусе TSSOP-16?

AVR, да и другие 8-битники, широкий диапазон питания 1.8-5.5. Энергосбережение удобное - где заснул, там и проснулся при максимальном уровне энергосбережения.
Из минусов - малое кол-во UART, малая разрядность АЦП, мало ОЗУ. Зато многие из AVR имеет диф.усилитель.

а что не с тремя эзернетами сразу ? в TSSOP-20 есть, с одним, в tqfp 0.8 есть, в tqfp 48 есть ажно с шестью, f3 - с аналогом - чего не хватает-то, чтобы забыть уже avr ?

У STM32 хватит быстродействия на кучу программых USARTов.

А у (неявно) упомянутых LPC812M101 три аппаратных. Плюс драйвера в ROM. Плюс приличная термостабильность RC-генератора. И ценник - где-то на уровне STM32F030F4.
Впрочем, это несколько необычный случай. NXP выпустили LPC800 специально на замену 900-м восьмибитникам, даже распиновку постарались максимально приблизить.

Что??? AVR на 200 МГц? Не согласен, больше всего ненавидел в AVR (тьфу на мой ник, как поменять?) так это то, что там очень мало RAMы. Всё бы ничего, но рамы мало. А так ведь и USB был и Ethernet MAC, и даже SDRAM добавили интерфейс... А память как у золотой рыбки.

Т.е. то, что там по сути 0 периферии, никак не смущало?
А между тем, элементарный STM8 рвет самый наблатыканный 8-битный авр!

2000, что у вас с математикой ?


и нафига козе баян ?

Это не проблема для АВР, только надо использовать другой отладчик.
Использую отладчик, где через пару ножек (тактовый сигнал и сигнал данных) программно выбрасывается байт в отладчик, вполне достаточно для отладки.
Поскольку запись байта в отладчик производится по тактовому сигналу, под сигнал данных можно задействовать занятую ножку, лишь бы она была на выход. Так что нужна одна свободная ножка.
У меня в отладчике есть некоторая защита, поэтому под тактовый сигнал также можно использовать занятую ножку, но с некоторыми ограничениями.

(Упс! Оказывается собрание пайщиков гаражного кооператива стихийно продолжается...)

Ну, это как бы теоретически -- да. Наверно можно дебажить камушки через dW. Но я с этим интерфейсом ни разу не работал. Да, у меня и оборудования-то такого нет. Есть куча всяких разных прошивальщиков. Проблема не в том, что есть или нет оборудование для отладки. Проблема в том, что я не считаю нужным вкладываться в AVR-платформу. Это проблема не уровня бухгалтерии, а проблема уровня идеологии. Улавливаете, о чём я толкую?

Мир не стоит на месте. Технологии находятся к каком-то постоянном движении.

Дело ведь не в одном программаторе-отладчике. У AVR-ок много родовых пролем. На вскидку назову только некоторые из них, которые мне особенно досталяют хлопот. Прежде всего это -- Гарвардская архитектура: три адресных пространства. Чтобы поработать с константами, которые находятся во флеш-памяти, константы нужно сначала скопировать в оператиную память, и только потом уже можно с ними производить какие-то действия.

Вторая проблема -- до хрена и более регистров (РОН). С одной стороны -- это классно: теоретически повышается скорость выполнения программ, так как не надо вытеснять в оперативу длительно неиспользуемые значения. А с другой стороны -- когда задумываешься о вопросах примения РТОС на этой платформе, волосы дыбом встают. В том числе и на голове тоже. Уходим в прерываение -- нужно сохранить контекст текущей задачи. Отлично! Значит, нужно сохранить в оперативе весь банк РОН. Ну хорошо, не весь! Но все равно это расход оперативы и время реакции на возникшее прерывание. В общем, та ещё попаболь!

А что говорить про "удачно" созданный регистр стека? Почему (это риторический вопрос) разработчики ядра AVR не сделали так, чтобы можно было обращаться к данным в стековом кадре с помощью SP? Почему для этого дела нужно привлекать ригистровую паруR28:R29,.. А потом люди удивляются -- зачем AVR-компиляторы создают два отдельных стека -- для адресов возвратов из подпрограмм и для данных.

Третья проблема -- какой-то дурдом с фьюзами. Я прошу поднять руки тех, кто ни разу не окрпичивал AVR-ку.

Я пониаю, всё то, что я назвал, это не такие уж и страшные проблемы. Они более-менее успешно решаются. И даже с помощью параллельного высоковольтного программатора можно обратно раскирпичить камень. Проблема AVR-ок в том, что на рынке есть более "вкусная" альтернатива в той же ценовой категории.

Я не говорю, что AVR-ки в ближайшем будущем исчезнут как класс. Нет! Они ещё долго будут с нами. (Как минимум нужно поддерживать старые проекты!) Я лишь замечаю, что сектор AVR-ок на рынке значительно сократился. И я говорю за себя -- я всё чаще делаю выбор в пользу STM32 или MSP430F2xx, чем ATMEGA.

Я не думаю, что я одинк в своих решениях.

АВР-ка хороша в простых (и радиолюбительских) конструкциях, где нет многозадачности, где нужно создать прототип устройства как можно быстрее, где не нужно изучать работу периферийных устройств микроконтроллера по англоязычным pdf-кам. Ну, Вы понимаете?

(И тут Остапа понесло...)

Я извиняюсь! Пока писал "оду Царю", совсем забыл сказать про отладку.

Недавно я прочухал вот какой прикол в отладке STM32. Я ещё раз извиняюсь -- я использую Линукс (Debian). И я уже совсем плохо ориентируюсь в Виндовсе. Поэтому то, что я скажу далее, всё это относится к Линуксу. Про Винду не скажу, наверняка там тоже есть подобные механизмы.

Итак. У нас есть оттаживаемый микроконтроллер (target), есть отладочное оборудование (программатор, в частности STLink), есть запущенный gdb-сервер (OpenOCD) и есть запущенная программа отладчика (gdb-arm-none-eaby). Вот такая длинная цепочка. Казалось бы, сервер и отладчик можно было бы объединить в "один флакон". Я по началу так и думал. Я не понимал прелести такого решения. Понимание пришло намного позже.

Так вот, для отладки запускам сначала gdb-сервер, а потом запускаме отладчик. Отладчик и сервер обащаются друг с другом через сокекты. Да к это -- Опа! Это же стевое разделение! Это значит отладчик и сервер можно разместить на разных компах. Есть о чём полдумать -- это раз.

Два -- это то, что мы в отладчике ручками (ручками!) набираем команды для исполнения. Разумеется, есть команды для чтения данных по заданному адресу, есть команды записи данных по заданному адресу. Отладчик тупо передает набранные нами строки команд gdb-серверу, а тот через отладочное средство управляет микроконтроллером. Таким образом, обмен информацией между отладчиком и серваком осуществляется по сети (а если они оба запущены на одной машине, то через localhost) пакетам, внутри которых чисто -- текстовые строки. Тест можно можно сразу видеть. Это очень удобно.

Три -- поскольку речь идет о STM32, у которых единое адресное пространство, то командами отладчика мы можем контролировать (читать/писать) не только ячейки оперативной памяти, но и управлять перифериными устройствами. Самый прстой пример -- смотреть, что делается на портах ввода GPIOx_IDR и устанавливать состояния портов вывода GPIOx_ODR. То есть мы контролируем всё адресное пространство -- то есть полностью весь микрококнтроллер!

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

То есть что получается. Мы в питоновской программе описываем действия, которые должны выполняться ядром cortex по отношению к периферии. Только вместо ядра работает питоновская прога. Другми словами -- программа, написанная на Питоне, рулит периферийными устройствами в микроконтроллере. Медленно, конечно, но ведь -- рулит! А на этапе ознакомления (освоения) -- какая разница -- быстро или медленно. На этом этапе главное понять -- как оно вообще должно работать.

Более того -- если к микроконтроллеру подцеплено какое-то оборудование, ну, например, Bluetooth-модуль, драйвер RS485 или просто SD-карта, то мы можем очень легко овоить работу и с этим оборудованием. А когда поймём и разберёмся, то перенести алгоритм работы с Питона на Си для ядра -- это дело не такое уж и неподъёмное.

Мне какжется, что я немного туманно объяснил.

(Но наброс, кажись, таки удался. Ща будет, что обсудить и кого обсудить.)

Самое интересное начинается тогда, когда с отладчиком прошивка работает, а без него - не всегда.

А это зачем? Всегда использовал константы из флеш памяти напрямую, есть же библиотека pgmspace.h ... Или я вас просто не правильно понял?

Будет сокращаться не по мере выхода из активного творческого состояния AVR-разработчиков, а по мере.... в конкурентной борьбе.

Есть задача, которую изночально смакетировали на абдурино ардуино. Потом подняли на стм32 (вышло с халом 30 кб коду). Наши российские поставщики предлагают стм32 от 100-150 р. Пошла оптимизация цены. вроде есть атмега по 50-100 р. Подняли на атмеге328, портировал код с стм32, влез в 16 кб атмеги. Полез на али.... нашел камни стм32 по 27 р с 16 кб флеша и по 32 рубля с 32 кб флеша. Есть по такой цене авр-ы? (желательно 16 кб флеша).
полазил на али... нашел стм8 по 12 р за процессор, правда с 8 кб флеша. Буду пробовать упихнуть код в 8 кБ. Если получится - в серию пойдет стм.
И ни при чем тут творческое состояние АВР-разработчиков. Сделают камень микрочип на архитектуре арв по цене $0,1 за шт с достаточной периферией - будет вам армия активно творческих АВР-разработчиков.

ps кстати, на ардуино авр прижился, причем очень даже не плохо.

У National есть примочка, которую можно зашить в ардуину и превратить её в слейв для LabView.
Рисуешь аццкую "программу" из кубиков и стрелочек и опа - серва крутится синхронно с контролом на мониторе компьютера, светодиодики мигают, дисплей отображает что ему положено.
Битики в портах и регистрах нынче любят колупать не только лишь все..

На ассемблере что-ли пишете? На С пофигу в какой памяти константы лежат.
На мой взгляд самое в хмегах - аппаратное шифрование. Редко у каких армов оно есть. У 8-битников тем более.
Многим тербуется обновление прошивки в контроллере. В отрытом виде отдавать прошивку плохо.
А программное шифрование работает в 100-1000 раз медленнее.

А какая разница?

Так то оно так, но при таком подходе к вопросам создания программного обеспечения, есть очень неприятный момент.

Какая, собственно, разница -- на каком языке программирования была написана программа? Константы и инициализируемые данные всяко будут изначально находиться во флешь памяти. В начале работы (после включения, перезагрузки и т.п.) эти данные нужно перенести из флеша в оперативную память. Если прога пишется на асме, то сам программист прописывает этот код -- когда, куда и сколько перененести данных. Если прога пишется на Си, то эту работа выполняется до вызова main().

Конечно, Си-программисту не нужно заботиться о перемещении инициализированных данных и констант из флеша в оперативу, но когда таких данных становится много, то вполне может случиться так, что под них будет израсходована вся оператива. В этом случае остаётся только одно -- изменять код программы таким образом, чтобы эти данные копировались бы в оператуву только по мере надобности. Для этого существует библиотека pgmspace.

Разумеется, что использование библиотеки привносит в исходный код программы больше отвлекающих (от основного назначения программы) действий, и увеличивает время работы. В каких-то приложениях с потерями времени и чехардой копирования (PGMspace) можно мириться, поэтому нельзя сказать, что программы, интенсивно и много использующие инициализированные переменные, принципиально наAVR-ках работать не могут. Могут!

Особой проблемы с константами и инициализированными значениями нет, если их немного. Проблемы появляются, где используются текстовые строки -- всякие меню, подсказки и индикация помощи. Особенно неприятно, когда в устройстве не символьный, а графический дисплей -- тут, помимо текстовых строк, нужно ещё заморачиваться размещением таблиц растеризации символов. Ну либо соглашаться с потерей быстродействия. Когда, имеешь опыт работы с AVR-ками и с другими типами микроконтроллеров (MSP430, STM32), то отчётливо видишь, что AVR-ки хороши только при создании ногодыгалок и светодиодоморгалок. Для более серьезных применений лучше ориентироваться на другие МК.

Это я еще не задел тему операционных систем и многопоточных приложений. Переключение контекста (переключение задач, переключение потоков исполнения) у AVR выглядит крайне расточительно на фоне её крошечного объема оперативы.

И ещё раз -- я не говорю, что AVR-ки полохие. Я лишь утверждаю, что AVR-ки хорошо заточены для не очень сложных приложений.

Если говорить об xmega'х, то там необязательно копировать все данные в оперативку, т.к. EEPROM имеет режим с отображением на адресное пространство оперативки. Я там оставляю настроечные, редко меняющиеся данные (например, номера рабочих каналов в радиомодемах).
Да, пишу на ассемблере.
Да, отлаживаю на всех Авр'овских интерфейсах (JTAG,PDI,dW)

Зачем переносить из флэша в оперативную память?
В IARe есть модификатор __flash. Используешь его везде и все константы лежат во флэше, и в RAM не переносятся, и места не занимают.
В GCC наверно тоже что-то подобное есть. Если нет, то можно дополнительный сегмент добавить.

Да. Оперативки в AVR очень мало.
А быстродействия на мой взгляд - выше крыши.

Да, уже есть. Не так давно, но появилось. Но только в голых Сях, в плюсы решили не добавлять, типа "в стандарте плюсов такого нет". Хотя может и передумали уже, давно не отслеживал эту тему.
К сожалению, простого объявления сегмента недостаточно. Для доступа к флешу (в "обычных" AVR, про хмеги не знаю) используются совершенно другие ассемблерные команды, поэтому от рождения доступ к константам во флеше в ГЦЦ от рождения был через специальные, реализованные на встроенном ассемблере макросы pgm_read_xxxxx()

IAR при чтении флэш генерит одни команды,
при чтении/записи RAM - другие команды,
при чтении/записи EEPROM - третьи,
при чтении/записи пространства ввода/вывода - четвертые.
Программисту не надо думать в каком пространстве происходит чтение запись.
Странно, что в GCC не так.