GD32F330 - новые мк от GigaDevice - Страница 10

ptr · 17.04.2018, 10:50

Сообщение от Easyrider83

Уж лучше тогда сразу брать

Понятие "лучше" или "хуже" может быть применимо только по отношению к конкретной задаче. Иногда STM8 за 40 рублей лучше, а иногда 192ГБ оперативки и 16 ядер Xeon мало. Причем оба случая из моей практики за этот месяц.

mike-y-k · 17.04.2018, 11:47

ptr, в последнем случае вполне можно и кластер пользовать, правда при наличии у целевого ПО возможности с ним работать

.
На сотне Raspberry PI Zero попробовали кластер, тормоза уже на обмене данным и управлении начались - там совсем другая производительность нужна

.

Конечно простой ногодрыг на RPI делать смешно, но многие универсальные/адаптируемые/гибкие/… задачи там решаются проще, а при наличии Q1 grade компонентов (automotive) уже и к промышленным решениям достаточно близко.

Easyrider83, это уже для особых любителей садомазохистский вариант.
Несколько раз сталкивался с разными allwinner и сопровождение не оставило положительных эмоций. На уровне пользователя вроде ничего, но чуть ниже…

CERGEI1982 · 17.04.2018, 13:02

Хорошо, сделайте прогноз что будет после stm32 ? Какие ресурсы будут чтоб экономить и писать на низком уровне, настраивая выводы и т д...
Сначала был асем под пики, сейчас си, а дальше?

ptr · 17.04.2018, 16:23

Сообщение от mike-y-k

можно и кластер пользовать

Все можно. Но иногда проще памяти добавить и ядер.

Сообщение от mike-y-k

На сотне Raspberry PI Zero попробовали кластер

В таком кластере, в первую очередь, высокоскоростная шина нужна для межпроцессорного обмена, причем интегрированная в CPU. Например, HyperTransport или QuickPath. Производительность как раз решающей роли не играет.

Сообщение от mike-y-k

Конечно простой ногодрыг на RPI делать смешно, но многие универсальные/адаптируемые/гибкие/… задачи там решаются проще, а при наличии Q1 grade компонентов (automotive) уже и к промышленным решениям достаточно близко.

Я ничего не имею против RPI. Я вообще ничего не имею ничего против любого микроконтроллера, системы на чипе, микрокомпьютера и даже мэйнфреймов. "Если звезды зажигают, значит это кому-то нужно!"

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

Сообщение от CERGEI1982

Хорошо, сделайте прогноз что будет после stm32 ? Какие ресурсы будут чтоб экономить и писать на низком уровне, настраивая выводы и т д...
Сначала был асем под пики, сейчас си, а дальше?

SoC будет. Причем центральные ядра вообще не будут иметь доступа к низкоскоростному вводу-выводу. Для этого будут использоваться переферийные. А по мере развития этой конструкции, язык обмена между центральными и переферийными ядрами унифицируется до такой степени, что эти перефирийные ядра хоть и будут иметь свою firmware, но нужды в нее лезь у обычного смертного уже не будет.

CERGEI1982 · 17.04.2018, 16:32

Сообщение от ptr

SoC будет. Причем центральные ядра вообще не будут иметь доступа к низкоскоростному вводу-выводу. Для этого будут использоваться переферийные. А по мере развития этой конструкции, язык обмена между центральными и переферийными ядрами унифицируется до такой степени, что эти перефирийные ядра хоть и будут иметь свою firmware, но нужды в нее лезь у обычного смертного уже не будет.

Можно пример?

ptr · 17.04.2018, 17:05

Сообщение от CERGEI1982

Можно пример?

Пример прогноза на будущее? )))

Любой современный десктоп или ноутбук уже использует сейчас подобную идеологию. HDD, Ethernet, WiFi, USB и даже клавитура с мышью - все имеют встроенный микроконтроллер, обслуживающий ввод-вывод. Так же, когда мы программируем PLC с компьютера, мы тоже свободны в выборе средств. Посмотрите на уже существующий спектр средств разработки для PLC.

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

CERGEI1982 · 17.04.2018, 18:58

Значит остановимся на распбери пай

mike-y-k · 17.04.2018, 19:02

CERGEI1982, CPLD, FPGA,… вполне нормальная ветвь развития для работы с низкоуровневыми обработками. Возможно появится отдельный класс с низкими скоростями работы (33MHz для SPI обмена) при большой емкости в модулях, вентиляхи богатой периферией ADC/DAC/шины.

ptr, а писали, что архитектуру S/360 негде использовать

. В вашем сообщении она в классическом виде. Осталось оттуда перенести работу с перифеей (у IBM это таки имеется) по образу и подобию.
А наличие контроллеров в периферии как раз вполне обоснованно - в такой архитектуре таки самый дорогой и критичный ресурс - CPU, и его надо максимально разгрузить от несвойственной работы.
Кстати они совсем не сейчас (явно не сегодняшние

) возникли. Это на XT/AT почти все было на россыпи логики, хотя на устройствах во множестве использовался отдельный собственный контроллер. Даже клавиатура и мышь с USART и потом USB в промежутке к хосту.
И SoC тут просто миниатюризация и рост производительности, а пока вполне SoM достаточно, коих уже имеется немало.
SoC востребован будет при большом и стабильном рынке, поскольку его сильно универсальным делать немного смысла, примеры тоже имеются.

AR_Favorit, таки совсем не, ну или почти не. Уровень вхождения явно повыше будет.
Возможность построения иерархических и распределённых систем со сниженной стоимостью и сложностью создания UI, сильно более богатая и развитая логика обработки. Не надо собирать свой сервер в коде и почти на каждое изменение перезаливать прошивку - минимум tomcat (можно и полный на старших моделях) и дальше уже вполне обычная работа со страницами и скриптами. А периферия на МК, освобожденная от попытки засунуть туда много лишнего, занята именно своими задачами с минимумом затрат на общение с хостом.
В итоге при оптимуме стоимости максимум производительности, а на хосте в промежутках можно и погоду показывать на фоне музыки

и не просто разные звуки издавать к событиям, а озвучивать сообщения…

ptr · 17.04.2018, 19:56

Сообщение от mike-y-k

SoC тут просто миниатюризация и рост производительности

То ли я недостаточно понятно выразился, то ли Вы меня не поняли. Как раз SoC тут необходим, иначе или не будет у ведущих ядер доступа к памяти перефийных ядер, или обилие шин интерфейса с памятью у чипов не позволит сделать решение дешевым. Дороги не так сами кристаллы, сколько их выводы.

mike-y-k · 17.04.2018, 21:32

ptr, прямой доступ к памяти периферийных контроллеров на постоянной основе?
Иерархическая суперпозиция DMA контроллеров и управления ими?
Таки тут весьма резонный вопрос о необходимости. Для такого очень узкая ниша возможна.
Обмен по любой имеющейся шине закрывает эту придуманную функциональность без необходимости городить дополнительную сущность на кристалле или в гибриде, да и не даст это никаких преимуществ, кроме удорожания.
Любое периферийное оборудование в текущем его виде все это и так делает.
SoC в этой ситуации просто уберёт разводку, изготовление, пайку платы, сократив количество компонентов в конечном изделии. Но выигрыш появится лишь при выпуске того SoC очень большими партиями - затраты на его разработку сильно больше производства SoM.