Это и так было очевидно. Просто была надежда, что слухи до вас доходят быстрее, чем до прочих.


Ну и как по вашим ощущениям, линейка SAM D дальше развиваться будет или заглохнет на D21? И в частности (ближе к этой теме), не собираются ли встроить WINC1500 во внутрь D21, т.е. объединить их в одном корпусе подобно тому, как это было сделано в SAM R?

Будет развиваться. Недавний анонс L21 тому пример.

Это одна из главных идей. Я не в курсе конкретных планов и сроков, но это очень удачный трюк, так как поместить 2 чипа в один корпус гораздо проще чем разместить логику обоих их на одной подложке. Особенно это верно для трансиверов с большой и сложной аналоговой частью. Что-то похожее вероятно произойдет и с BTLE.


PS: А какое направление развития D21 конкретно интересует? Пока что я вижу сильное желание понизить потребление, что вылилось в L21.

Сообщение отредактировал ataradov - Apr 16 2015, 04:45

Какая же Вы, Xenia, молодец !

По поводу протокола взаимодействия - всё-таки кое-что описано в WINC1500_Software_Design_Guide, но ожидалось, что это описание будет намного более подробным.
Есть мнение, что в скором времени появится больше информации по этому протоколу.
А вообще, мне кажется, для общего удобства обсуждение WINC1500 стоит вынести в отдельную тему...

В общем, вот тема по WINC1500

Меня интересует направление ... чтобы ног было больше! Скажем, ХМеги бывают 100-ногими, а SAM D/L - максимум 64.

Конечно, если SAM D/L позиционировать для детских игрушек (как это делается сейчас), то им вовсе не обязательно даже быть 32-разрядными. Но если уж их позиционировать на ступень выше, чем ХМега, то они должны, как минимум, перекрывать возможности ХМег по части контроллерских функций. Т.е. нужно больше таймеров, SPI, I2C, UART, да и просто портов I/O. А этого не только нет, но и как будто специально было урезано. И не только этого - к ХМеге можно еще внешнюю память подключить, а к этим нельзя.

Вот получается, что над ХМегой образовался вакуум: SAM D/L до ее полных возможностей не дотягивает (хотя и по ряду параметров превосходит), SAM7 устарел, AT32UC3 похоронили, а вверху маячит SAM4, но это уже слишком серьзное и дорогое решение (топовый МК).

В принципе идеально в качестве контроллера смотрелся UC3, а потому, если и отказываться от платформы AVR32 в пользу ARM/Cortex, то надо было делать для UC3 полноценную замену, а не гномика D20 .

Это уже немного оффтоп тут.

А вообще действительно, ни один МК на ARM (даже SAM G/E/S/V) не покрывает по периферии старшие Xmega. Интересно, что в моей практике это не было проблемой, так что я даже не замечал этой разницы. Хотя этот факт может удержать Xmega на плаву.

Неправда, вы это заметили, т.к. на своем же сайте провисли между SAMD20 и SAM4S. И если бы в этой пропасти существовал бы обитаемый островок, то вы бы туда обязательно приземлились.

Никакой связи с реальной жизнью на том сайте нет. Там даже проектов реальных нет, только экспериментальный генератор заголовков, который я уже забросил. И я его начал делать так как мне не нравится таскать с собой 50 файлов для каждого МК. Но в реальности все это поддерживать очень сложно и я смирился.

Единственная причина выбора 4S и D20 - это то, что в одном все регистры выравнены на 32 бит, во втором часть регистров 8-и и 16-и битные. Ну и факт, что D20 был единственным МК из этой серии в тот момент.

Сайт не обновлялся больше года.

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

Пожалуй, вы правы. Я же на серию SAM G успела махнуть рукой, т.к. у них нет USB.

И только сейчас, после ваших слов, обнаружила, что USB присутствует у SAM G55 (эта версия совсем недавно появилась). Однако, добавив USB, у него отрезали 36 ног, т.к. в отличие от остальных SAM G, в 100-ногом корпусе он уже не выпускается.

G55 совсем новый, мы платы с ними только в прошлом месяце получили.

Абсолютное большинство использует корпус WLCSP49, так как эти чипы позиционируются как Sensor Hub - числодробилка данных с сенсоров и передача их в основной процессор. А для этого большие корпуса не нужны никому.

Так я именно на то и пеняю, что все, как полоумные , бросились числа дробить и электричество экономить. Тогда как мне хотелось бы хоть какого-нибудь прогресса вдали от мобильных гаджетов. Т.е. хотелось бы, что контроллеры тоже развивались, обрастая периферией, а не кастрировались по таймерам, интерфейсам, портам и ногам в угоду экономии электричества. В толк не возьму, зачем мне D21 собой в кармане носить, а тем паче электричество экономить, если он к USB подключен. Да и вообще, EMBEDDED это когда контроллер в какое-то устройство встроен для его автоматизации, у которого с собственным питанием проблем нет.

Wearable и Internet of Things - без этого сейчас никак .

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

Ну и в беспроводном мире низкое потребление - первая необходимость.

Что этим дело кончится, с самого начала было ясно, когда еще "умный дом" решили строить. После чего стало очевидно, что проблема не в том, чтобы дому дать ум (практически любой стационарный компьютер для этой цели годится), а в том, чтобы вещи того ума слушались! В противном случае эта затея обречена на тотальную автоматизацию всего и вся, что по затратам на порядки превосходит затраты на "домашний ум".

Однако все эти вещи не умные, а скорее ПОСЛУШНЫЕ. Т.е. по существу содержат в себе схему удаленного контроля, чтобы дом мог манипулировать вещью. А для этой цели вполне годится мелкий контроллер, более рассчитанный на "связь с центром", нежели на сложные управленческие функции.


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

Однако хотелось бы, чтобы и полноценные master-контроллеры не загнивали. Т.е. тут совершенно не надо объединять их в одну группу и предъявлять к ним одни и те же требования. Тем более что эти требования очевидно различны, а порой и противоречат друг другу.

Идея "под каждый параметр по отдельному контроллеру, а центральный процессор обрабатывает стекающуюся от них информацию и рассылает указания" возможно хороша для умного дома, но для управления сложными устройствами совершенно непригодна! Непригодна потому, что здесь мы снова получаем асинхронную систему управления, когда все делается неспешно, решения принимаются наверху, а низы только бумаги пишут . И мы видим, как в такой системе slave-контроллер начинает неминуемо вырождаться. Зачем, скажем, slave-контроллеру прерывания по событиям, если реакция на эти события последует не раньше, чем бумага не уйдет наверх, а оттуда назад не вернется указание, что надо делать?

Я определенно сгущаю краски, но тенденция именно такова. Стало сложно найти многофункциональный контроллер, поскольку производители заняты разработкой мелких узкоспециализированных процессоров, которые все меньше походят на контроллеры. Вот и в этой теме интерес тоже вертится вокруг того, как сделать "умный Wi-Fi", а то, что этот умница ничего другого не будет уметь делать, никого не волнует. Т.е. снова в очередной раз от контроллера остается одна единственная функция, а все остальное безжалостно отрубается.

В качестве master - контроллеров все чаще применяют SAMA5. Даже там, где МК хватило бы за глаза. Но писать и отлаживать под Linux проще и в конечном итоге выходит дешевле для мелко- и средне-серийных устройств, даже с учетом более высокой цены процессора.