[ViKo 1]

4 минуты назад, MDD сказал:

цену на 103 серию

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

[MDD 0]

Just now, ViKo said:

Есть много новых хороших серий. На букву G, например.

Уже накупил макеток G030, G431,G474. Ковыряю на досуге. На форуме уже описывал некоторые свои грабли с G030...

Но осадочек от "кидка" остался. Где гарантия, что он не повторится...

[adnega 10]

29 минут назад, MDD сказал:

Уже накупил макеток G030, G431,G474. Ковыряю на досуге. На форуме уже описывал некоторые свои грабли с G030...

Но осадочек от "кидка" остался. Где гарантия, что он не повторится...

Мы экстренно с F051 на G070 перепрыгнули в этом месяце, просто потому, что F051 сейчас нет на складе. МК новый, есть особенности, в документации ошибки, но осваивать нужно :)) Я вот очень рад сложивмися обстоятельствам, иначе так бы и сидели на F051.

Макетки с G4 уже полгода на столе пылятся, кста.

[jcxz 185]

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

В ардуино-подобных платах защита неактуальна. Это любительский и образовательный проект.

Для "ардуино-подобных плат" и низкое потребление также не актуально. В том стиле написания ПО, с делеями. Да и уровень квалификации разработчиков там в основной массе - не тот, чтобы о микроамперах потребления думать.

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

Объем ОЗУ включает в себя и исполняемый код. Это во первых.

Не факт . Уже много лет как существует куча других МК, умеющих исполнять код из флешки, подключенной через SPI/dual-SPI/quad-SPI. Скорей всего здесь то же самое.

[my504 2]

1 hour ago, AlexandrY said:

Упустили аббревиатуру XIP в даташите. Это значит что прога исполняется прямо их внешней сериальной флеши. 
 

Тем хуже. Тогда, внимание, вопрос.

Частота клоков на QSPI - 133 МГц. Это ограничено как самим МК, так и примененной в Pico памятью Winbond W25Q16JV. Даже без учета всяких мелких накладных расходов в потоке QSPI, скорость передачи данных будет ограничена полубайтом за клок. То есть для передачи ОДНОЙ инструкции длиной в 32 разряда потребуется 8 клоков. Делим 133 на 8 - получаем 16,6 МГц. Я понимаю, есть кэш. Но его размер всего 16 кБ - это во первых, а во вторых, как ни крути, производительность будет сильно зависеть от способности компилятора минимизировать загрузки кэша.... И это все для ДВУХ ЯДЕР!!!

 

 

[jcxz 185]

11 минут назад, my504 сказал:

То есть для передачи ОДНОЙ инструкции длиной в 32 разряда потребуется 8 клоков. Делим 133 на 8 - получаем 16,6 МГц.

Открою Вам страшную тайну (только никому не говорите): Внутренние флеши во всех МК работают не на частоте ядра, а как правило на частоте около 20-30МГц - т.е. примерно то же самое!  

И при этом ширина шины к флешь не у всех из них 128...256 бит, у младших моделей (малопотребляющих) - меньше = 32...64.

 

Цитата

Я понимаю, есть кэш.

Вот именно. А если теперь ещё вспомнить, что бОльшую часть времени (>95%) типичные программы выполняются как правило в циклах, то и никакого ущерба скорости выполнения Вы просто не заметите. Попробуйте как-нибудь - убедитесь.  

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

в ОЗУ.

 

PS: И, кстати: О каких 32-битных инструкциях речь? Там вроде M0+ -ядра, у которых насколько знаю в основном - 16-битные инструкции.  

[my504 2]

17 minutes ago, jcxz said:

Открою Вам страшную тайну.....бОльшую часть времени (>95%) типичные программы выполняются как правило в циклах, то и никакого ущерба скорости выполнения Вы просто не заметите.

Неувязочка...

МК, в отличии от процессоров общего назначения с ОС, предназначен для выполнения задач реального времени. А все эти задачи, особенно под управлением RTOS, достаточно хаотично перезагружают задачи с одной стороны и должны обеспечивать минимальную латентность обработчиков прерываний с другой. В каком месте там 95% исполняются в циклах? И как повлияет загрузка кэша обработчиком прерываний или вытесняющей задачей?

Ну и латентность вызова функций находящихся в разных концах флеша может быть легко проверена, чтобы подтвердить или опровергнуть ваше утверждение. Так в 70 МИПС-овом dsPIC33E на вызов функции в произвольном месте флеша требуется ровно ДВА машинных цикла. То есть ни о каком кэше там и речи не идет. Почти аналогично, но с производительностью 100 МИПС дела обстоят у dsPIC33C.

Два машинных цикла уходит на сброс конвейера, а не загрузку кэша.

Вы не ответили на мой предыдущий вопрос. Увы.

ЗЫ. Шина инструкций внутри МК имеет разрядность инструкций самого МК. Это не считая разных приемов параллельного чтения из физически разных флешей, чтобы минимизировать время доступа.

[jcxz 185]

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

И как повлияет загрузка кэша обработчиком прерываний или вытесняющей задачей?

Вы как-нибудь попробуйте на практике. Вместо пустых теоретизирований. Я работал с таким МК, выполняющим код напрямую из quad-SPI и знаю о чём говорю.

И чтобы увидеть циклы - просто посмотрите любую программу. Наличие RTOS не отменяет циклов.

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

Вы не ответили на мой предыдущий вопрос. Увы.

Не видел никакого вопроса.

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

ЗЫ. Шина инструкций внутри МК имеет разрядность инструкций самого МК.

Читайте внимательнее - я говорил про:

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

шины к флешь

а не шину инструкций.

[my504 2]

13 minutes ago, jcxz said:

Вы как-нибудь попробуйте на практике. Вместо пустых теоретизирований. Я работал с таким МК, выполняющим код напрямую из quad-SPI и знаю о чём говорю.

Вообще то я говорю о ПРАКТИКЕ. Своей практике. Я пытаюсь примерить СВОЙ код на архитектуру с QSPI. и не понимаю каким образом МОЙ код будет работать на подобной архитектуре без заметного ущерба для скорости. Напомню, речь идет о кэше всего на 8К инструкций без учета необходимости работы с константами в том же самом флеше. Я не интересуюсь кто с чем работал. меня интересуют вполне конкретные случаи и как компилятор и архитектура с ними справляются.

ЗЫ. Я не путаю шину инструкций с шиной флеши. Я упомянул, что секции флеша читаются параллельно кратно широкой шиной по сравнению с IBUS.

ЗЗЫ. Вопрос не обязательно содержит вопросительный знак на конце. Иногда это просто изложение непонятной сущности.

[Plain 168]

7 часов назад, ViKo сказал:

С 2016 года разрабатывали, гора родила мышь

История повторяется как фарс. Мы начали работать на PIC где-то в 1994-м году, поэтому когда спустя годы, Atmel вдруг стала рекламировать ещё не существующие детали, мы весьма удивились, потому что уже тогда было понятно, что это шило на мыло, а когда они ещё и долго не могли поставить их производство, наше доверие Microchip заметно укрепилось, затем оценили качество ихних бумажек, да, а далее ещё с ихней памятью началась чехарда.

[adnega 10]

Критические по быстродействию участки кода загружаются в ОЗУ. Медленное - хранится по внешней flash в малоногом корпусе. Я зам с QSPI не работал, но - это вообще круто, т.к. можно не только ПЗУ внешнего навесить, но и ОЗУ (PSRAM тот же). А если еще и МК аппаратно поддерживает и в общую память ремапит, дык, это просто сказка.

Куда хуже у тех же STM32F - внешняя память начинается более-менее со 100/144-ногих "монстров".

[my504 2]

13 minutes ago, adnega said:

Критические по быстродействию участки кода загружаются в ОЗУ.

Тут встает вопрос об архитектуре ОЗУ - наличию у ОЗУ параллельных шин для возможности разделить память данных и память инструкций. Иначе всякий доступ к ОЗУ будет вставлять пузырьки в конвейер. Я уже не говорю про ДМА...

Аппаратный ремап QSPI в общее адресное пространство ничего по факту узкого горлышка не решает. Если в обсуждаемой архитектуре можно весь (или почти весь) код загнать в ОЗУ, тогда нет никакой проблемы. Просто есть удобная фича для размещения каких нибудь массивов констант во внешней памяти. Тем более, я так полагаю, решение о маппировании кода в ОЗУ/флеше принимает сам программист соответствующими атрибутами кода... Или нет?

[jcxz 185]

47 минут назад, my504 сказал:

Вообще то я говорю о ПРАКТИКЕ. Своей практике. Я пытаюсь примерить СВОЙ код на архитектуру с QSPI. и не понимаю каким образом МОЙ код будет работать на подобной архитектуре без заметного ущерба для скорости.

Когда я начинал проект на LPC4370 (где код находился во внешней quad-SPI, хотя частотой повыше), то тоже были сомнения. Но потом запустил, посмотрел загрузку CPU при выполнении типичного кода из флешь и ОЗУ, и увидел разницу всего в несколько %. И успокоился на этот счёт. Чего и вам желаю.  

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

47 минут назад, my504 сказал:

Вопрос не обязательно содержит вопросительный знак на конце.

Значит я не понял где он.

[AlexandrY 3]

41 minutes ago, my504 said:

Тут встает вопрос об архитектуре ОЗУ - наличию у ОЗУ параллельных шин для ...

Эк вы возбудились. Эт же чип для цветомузыки, кнопок, индикаторов.
Производительность ему нужна только для того чтобы быстрее питоновские скрипты исполнять и  не обременять юзеров ассемблером от слова вообще. 
Кому нужна нереальная производительность в QFN корпусе ждет https://developer.arm.com/ip-products/processors/cortex-m/cortex-m55

[my504 2]

55 minutes ago, AlexandrY said:

Эк вы возбудились. Эт же чип для цветомузыки, кнопок, индикаторов.
Кому нужна нереальная производительность в QFN

Тут речь о "нереальной производительности" вообще не шла. Речь шла о чипе с двумя ядрами М0+ с частотой 133 МГц за 4 доллара (в составе платы с флешем, естественно). И сравнении этого сооружения с обычными чипами с набортным флешем. Получается, что это ни разу не убийца обычных МК, а просто нишевый продукт для конкуренции с Ардуинами на их поле. И только.