[Harbinger 10]

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

Впрочем, это несколько необычный случай. NXP выпустили LPC800 специально на замену 900-м восьмибитникам, даже распиновку постарались максимально приблизить.

[1891ВМ12Я 0]

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

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

[Eddy_Em 1]

больше всего ненавидел в AVR (тьфу на мой ник, как поменять?) так это то, что там очень мало RAMы.

Т.е. то, что там по сути 0 периферии, никак не смущало?

А между тем, элементарный STM8 рвет самый наблатыканный 8-битный авр!

[VCucumber 0]

Что??? AVR на 200 МГц?

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

 

Ethernet

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

 

[AI7 0]

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

 

Дело в том, что чтобы прикрутить к AVR-ке отладчик по JTAG, нужно забрать у неё под это дело весьма дефицитные ножки.

Это не проблема для АВР, только надо использовать другой отладчик.

Использую отладчик, где через пару ножек (тактовый сигнал и сигнал данных) программно выбрасывается байт в отладчик, вполне достаточно для отладки.

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

У меня в отладчике есть некоторая защита, поэтому под тактовый сигнал также можно использовать занятую ножку, но с некоторыми ограничениями.

 

[zhevak 0]

Это не проблема для АВР, только надо использовать другой отладчик.

Использую отладчик, где через пару ножек (тактовый сигнал и сигнал данных) программно выбрасывается байт в отладчик, вполне достаточно для отладки.

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

У меня в отладчике есть некоторая защита, поэтому под тактовый сигнал также можно использовать занятую ножку, но с некоторыми ограничениями.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

[zhevak 0]

Это не проблема для АВР, только надо использовать другой отладчик.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

[gerber 7]

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

[Smoky 0]

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

 

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

[juvf 10]

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

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

 

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

полазил на али... нашел стм8 по 12 р за процессор, правда с 8 кб флеша. Буду пробовать упихнуть код в 8 кБ. Если получится - в серию пойдет стм.

И ни при чем тут творческое состояние АВР-разработчиков. Сделают камень микрочип на архитектуре арв по цене $0,1 за шт с достаточной периферией - будет вам армия активно творческих АВР-разработчиков.

 

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

 

[MrYuran 16]

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

У National есть примочка, которую можно зашить в ардуину и превратить её в слейв для LabView.

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

Битики в портах и регистрах нынче любят колупать не только лишь все..

[Zlumd 0]

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

На ассемблере что-ли пишете? На С пофигу в какой памяти константы лежат.

На мой взгляд самое в хмегах - аппаратное шифрование. Редко у каких армов оно есть. У 8-битников тем более.

Многим тербуется обновление прошивки в контроллере. В отрытом виде отдавать прошивку плохо.

А программное шифрование работает в 100-1000 раз медленнее.

 

[zhevak 0]

На ассемблере что-ли пишете? На С пофигу в какой памяти константы лежат.

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

[V_G 8]

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

Да, пишу на ассемблере.

Да, отлаживаю на всех Авр'овских интерфейсах (JTAG,PDI,dW)

[Zlumd 0]

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

Зачем переносить из флэша в оперативную память?

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

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

В GCC наверно тоже что-то подобное есть. Если нет, то можно дополнительный сегмент добавить.

 

Да. Оперативки в AVR очень мало.

А быстродействия на мой взгляд - выше крыши.