[jcxz 217]

2 часа назад, kan35 сказал:

В нашем случае, даже если бы была флэш, то наделать зоопарк контроллеров от 8кб до 4мб не представляется реалистичным в короткие сроки, поэтому внешняя флэш - решение даже скорее логичное

Полностью согласен. Во всех моих проектах SPI-flash как правило всё равно имеется. Для хранения разного рода данных. Почему бы не использовать её же и для загрузки прошивки в ОЗУ МК? А высвободившееся место на кристалле МК отдать под ОЗУ (того же объёма). Набортное ОЗУ - более ценный ресурс, чем флешь.
Только вопрос с защитой прошивки от копирования решить.

[makc 212]

2 часа назад, Raven сказал:

Вам все сразу подавай! 🙂 Пока не умеют - это ж отдельная дополнительная технология. АМУР - это первая ласточка. Дальше - больше.

Нет, не всё и сразу, но о рынке и применениях нужно думать при разработке, иначе нечего путного не будет приблизительно никогда. В этом плане мне ближе подход Миландра, который купил ядро у CloudBear, а не взял тормозное и бесплатное ядро SCR1 от Syntacore. Причем, уверен, Микрон мог сделать и полностью своё ядро, более оптимальное для этого случая, но не сделал. Почему?

2 часа назад, Raven сказал:

Дальше - больше. Темпы расширения линеек не будут такими же, как на Западе (бюджеты не те, и экосистема отечественной электроники только начинает восстанавливаться, пока нет эффекта масштаба), но процесс определенно пошел.

Насчёт больше - не уверен. Судя по этому опусу под гордым названием Амур, за ним стоит простой принцип "слепили из того, что было", чтобы было. А теперь пытаются подтянуть под это базу, но в итоге всё равно это выглядит реализацией принципа "что получилось, то и хотели". Процесс же идёт в CloudBear и Syntacore, а также других подобных организациях, которые готовы предложить на рынке что-то новое. Надеюсь, что я ошибаюсь. 

2 часа назад, Raven сказал:

Но даже и сегмент "импортозамещательных пильных изделий" - это очень хороший начальный базис, чтобы профинансировать дальнейшие шаги.

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

 

1 час назад, jcxz сказал:

Полностью согласен. Во всех моих проектах SPI-flash как правило всё равно имеется. Для хранения разного рода данных. Почему бы не использовать её же и для загрузки прошивки в ОЗУ МК?

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

1 час назад, jcxz сказал:

А высвободившееся место на кристалле МК отдать под ОЗУ (того же объёма). Набортное ОЗУ - более ценный ресурс, чем флешь.

Безусловно, полностью с вами согласен. Но этот МК явно не блещет объемами. Се ля ви...

1 час назад, jcxz сказал:

Только вопрос с защитой прошивки от копирования решить.

А их (разработчиков и "заказчиков") это не волновало и не волнует, т.к. и так будут брать и ещё причмокивать от удовольствия. Но не мы. 

Судя по всему никто этот вопрос в обозримом будущем решать не будет, т.к. это делается не для открытого рынка. 

[mantech 42]

13 часов назад, kan35 сказал:

выводная микросхема за 50центов (8мб) не сильно ударит по карману, тем более сам контроллер дорогой настолько, что его обвязка это прямо скажем - статистическая погрешность по затратам

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

9 часов назад, makc сказал:

Судя по всему никто этот вопрос в обозримом будущем решать не будет, т.к. это делается не для открытого рынка.

Ну если так, то тему вообще можно закрывать, ибо тем, "кому надо" и так найдут в нужных местах)))

Изменено 18 января пользователем mantech

[makc 212]

5 минут назад, mantech сказал:

Тогда какой смысл в импортозамещении?

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

6 минут назад, mantech сказал:

Ну вот серьезно, для работы в системе нужен МК и флеш, ну хорошо требуют "отечественное", МК купили, а флеш?? 

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

21 минуту назад, mantech сказал:

Ну если так, то тему вообще можно закрывать, ибо тем, "кому надо" и так найдут в нужных местах)))

Общение в любом случае скорее полезно, чем вредно. Вдруг кто-то из принимающих решение прочитает нашу тему или кто-то из его подчинённых донесет до него мысли из этой темы...

[kan35 7]

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

С sip нет проблем, это чистая косметика. У нас это делают и довольно уже давно. Но по честному - многим ли не хватит места на плате под 8 выводный соик? Смарт часы или мобильники у нас что-ли производят?? Так зачем лишаться гибкости, мне нравится внешняя память. Кому то хватит и 512кб, а кому-то нужно 16мб или более.

[makc 212]

23 минуты назад, kan35 сказал:

С sip нет проблем, это чистая косметика. У нас это делают и довольно уже давно. Но по честному - многим ли не хватит места на плате под 8 выводный соик? Смарт часы или мобильники у нас что-ли производят??

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

Про смарт-часы на Амуре шутку оценил. Мобильники...

PS: https://elvees.ru/chip/processors-multicore/eliot - вот хороший пример того, что бы хотелось получить. А что получилось ...

[HardEgor 71]

8 минут назад, makc сказал:

PS: https://elvees.ru/chip/processors-multicore/eliot - вот хороший пример того, что бы хотелось получить. А что получилось ...

Технология изготовления – TSMC 40ULP.

[TOG 0]

17 hours ago, kan35 said:

И я уверен, что контроллер потенциально зайдет много куда, но меня две вещи беспокоят - получится ли снизить цену хотя бы рублей до 200 и будет ли стабильным качество… ну и еще вопрос конечно - сможет ли Микрон нашлепать миллионы Амуров в год… 

Если в следующей версии они сделают защиту прошивки, то может и зайдет.

[jcxz 217]

15 часов назад, makc сказал:

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

Не во всех проектах важно минимально возможное время старта ПО. Да и "медленно" - понятие растяжимое. Если МК имеет quad-SPI, умеющий работать на тактовой ядра, то даже от дефолтного RC-генератора 16МГц скорость загрузки будет = 8МБ/сек. Что думаю - вполне приемлемо для большинства применений.

Да и работают же как-то DSP, почти поголовно без флешевые? Да и много других МК нормально обходятся без флешь. Причём - среди высокопроизводительных таких больше.

 

И зачем кеш для внутренней ОЗУ МК? Это ОЗУ во всех МК такого уровня и так работает на частоте ядра.

Кеш используют для медленной встроенной флеши МК. Здесь он не нужен.

 

PS: Даже если минимальное время старта ПО важно, то тоже решаемо: Разбиваем ПО на две части:

1) часть, для которой критически важен быстрый старт;

2) всё остальное.

Первая часть будет загрузчиком, которую собственно и грузит и запускает встроенный ROM-загрузчик МК. Максимально быстро. И он же, в фоне, запускает загрузку ч.2. Так можно обеспечить старт ч.1 даже за пару мсек.

[makc 212]

12 минут назад, jcxz сказал:

Не во всех проектах важно минимально возможное время старта ПО. Да и "медленно" - понятие растяжимое. Если МК имеет quad-SPI, умеющий работать на тактовой ядра, то даже от дефолтного RC-генератора 16МГц скорость загрузки будет = 8МБ/сек.

Давайте посчитаем вместе требуемую скорость работы с памятью для используемого ядра SCR1 https://github.com/syntacore/scr1 . На частоте 16 МГц при compressed-командах (2 байта на команду) ПСП памяти для исполнения без циклов ожидания (одна команда на такт, конвейер) получается приблизительно 32 МБ/с при условии выполнения линейного участка кода, но т.к. команды идут смешанные, то можно оценить потребную ПСП процентов на 50 больше, т.е. 48 МБ/с. ПСП QSPI, о которой вы пишете, получается в шесть раз меньше требуемой. Хм... Это разве не медленно? Или я заблуждаюсь?

18 минут назад, jcxz сказал:

Да и работают же как-то DSP, почти поголовно без флешевые? Да и много других МК нормально обходятся без флешь. Причём - среди высокопроизводительных таких больше.

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

18 минут назад, jcxz сказал:

Кеш используют для медленной встроенной флеши МК. Здесь он не нужен.

Здесь он нужен для медленной внешней флеш-памяти, которая в разы тормознее внутренней. См. выше.

19 минут назад, jcxz сказал:

PS: Даже если минимальное время старта ПО важно, то тоже решаемо: Разбиваем ПО на две части:

Я вообще говоря имел в виду не время старта, а скорость исполнения из внешнего флеша. Ну да ладно, при  наличии желания и Амура можно придумать много разных вариантов. Но мне пока, к счастью, это не грозит.

 

[mantech 42]

4 часа назад, makc сказал:

вот хороший пример того, что бы хотелось получить.

Ну это хоть уже можно ставить куда-то, хотя под программу там опять же внешний чип нужен, и он импортный...

1 час назад, jcxz сказал:

И зачем кеш для внутренней ОЗУ МК? Это ОЗУ во всех МК такого уровня и так работает на частоте ядра.

Не у всех. В СТМах там только TCM память на частоте ядра, а она далеко не все ОЗУ.

[jcxz 217]

15 минут назад, mantech сказал:

Не у всех. В СТМах там только TCM память на частоте ядра

В первый раз слышу.   Которые на ядре Cortex-M? Уверены? Это в каких STM-ах? Назовите конкретные, в которых основное встроенное ОЗУ работает не на частоте ядра.

[makc 212]

2 часа назад, jcxz сказал:

В первый раз слышу.   Которые на ядре Cortex-M? Уверены? Это в каких STM-ах? Назовите конкретные, в которых основное встроенное ОЗУ работает не на частоте ядра.

Могу предположить, что речь идёт о памяти, которая подключена к периферийным шинам AXI и используется в основном для работы с DMA.

[jcxz 217]

10 минут назад, makc сказал:

Могу предположить, что речь идёт о памяти, которая подключена к периферийным шинам AXI и используется в основном для работы с DMA.

Пускай так. Но в каких именно МК она работает не на частоте ядра?

Причём mantech утверждает, что в этих МК вся ОЗУ, кроме TCM, работает не на частоте ядра.

[mantech 42]

50 минут назад, jcxz сказал:

Но в каких именно МК она работает не на частоте ядра?

STM32F407

Up to 192+4 Kbytes of SRAM including 64- Kbyte of CCM (core coupled memory) data RAM

Изменено 18 января пользователем mantech