[haker_fox 60]

14 hours ago, iiv said:

но не умею девелопить в оболочках

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

14 hours ago, iiv said:

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

Если задержки нужно знать для профайлинга, то кортексы вполне поддаются анализу. Способов разных много. Если задержки нужны для формирования пауз, то тут в любом МК лучше использовать таймер, или, что лучше, настроенную периферию. Кстати, в ассемблер кортексов тоже можно подглядывать)))

 

14 hours ago, iiv said:

64К хотя бы, тактовой от 100МГц и хотя бы 12битным АЦП с предуселителем,

С предусилителем не подскажу, но в целом вам прямая дорога на Cortex-M3/M4(F). Хотя зачем такая частота?

14 hours ago, iiv said:

бкзпроблемно скомпилировать под гнутым компилером в

Безпроблемно)

14 hours ago, iiv said:

Наличие аппаратной плавающей точки или хотя бы 32 битных целых очень желательно

Тогда точно Cortex-M3/M4 (для целых 32-бит) или Cortex-M4F с математическим сопроцессором.

14 hours ago, iiv said:

Скажите, пожалуйста, на какой контроллер посмотреть?

Повторюсь, но по перспективам на cortex-m3/m4(f)/m7.

[xvr 12]

16 hours ago, iiv said:

хотя бы 12битным АЦП с предуселителем

Ни фига себе 'хотя бы'

Вам сюда - https://www.analog.com/ru/parametricsearch/10984#/p1726=|ARM Cortex AO|ARM Cortex M3|ARM Cortex M4|ARM Cortex M4F&d=sel|0|1726|3962|4677|4678|4680|s8|s14|s10|s6|s7|s5

 

[haker_fox 60]

6 minutes ago, xvr said:

Ни фига себе 'хотя бы'

Кстати, я бы посоветова ТС не завязываться на поиск МК. Я не знаю условй его задачи, но лучше, ИМХО, АЦП внешнее. Так проще подобрать МК.

[k155la3 26]

16 hours ago, iiv said:

. . . На кортескы (в основном STMы) много раз пытался перелезть, но не умею девелопить в оболочках - я уже 30 лет сижу с командной строки в виайе (vim) в юниксподобных системах и тяжело менять привычку. Также хочется точно понимать сколько тактов задержки будет в любом месте работы программы. На атмеге всегда можно посмотреть ассемблер после компиляции и понять как это будет работать. В кортексах как-то все не прозрачно. . . . .

"тяжело менять привычку" - начинайте с этого.

"хочется точно понимать сколько тактов задержки будет" 

Получается, что Вы подсчитываете такты - интервалы, фактически "вручную" ? Что-то здесь "не так". "В консерватории надо что-то подправить". Экономите таймеры ?

"и понять как это будет работать."

От этотго тоже приходится отвыкать, я имею ввиду копание в чужом (да и своем) коде на уровне ASM. ("отлов демонов-глюков" не в счет).

 

 

 

[Obam 30]

"и понять как это будет работать."

Если ТС работал с avr, то почему не въехал в кортексы не понятно: всё то же - в память\из памяти можно только писать\читать (привет от MSP430 (-; ) в РОН\из РОНа, все операции только в РОНах. Размер данных разве "чуть" побольше.
А вообще, TC странного захотел: от 100МГц ладно без кэша, но что б без конвейера...

[iiv 17]

Огромное спасибо за ответы и советы!

 

Правильно ли я понимаю, что вариант с stm32f730i8 и метод как описано в https://stackoverflow.com/questions/51390342/creating-cortex-m7-project-from-scratch-where-to-start

должен быть наиболее оптимальным?

 

PS: я даже сильно в дебуггере не планировал отлаживаться, так как мне надобно быстро сделать несколько конструкций с обратно связью, то есть что-то измеряется на нескольких АЦПшках, на основе этого что-то вычисляется в реальном времени (тут удобнее в плавающей точке считать), а потом на основе этого пинами с разной частотой дергается, попутно передавая текущую информацию по какому-нибудь стандартному интерфейсу на основной компьютер. Скажите, пожалуйста, можно ли как-то предсказать верхнюю и нижную скорость работы вычислительного блока, я имею ввиду с учетом сбросов кеша и без оных?

 

Грубо говоря я померю (повторив миллион раз), сколько всреднем оно вычисляется, например за 1микросекунду. Можно ли будет заложить программно, что после начала работы этого блока пройдет не более 1мкс + эпсилон, когда я гарантированно получу результат, и, если да, то где почитать от чего этот эпсилон может зависеть?

 

Спасибо!

[_pv 52]

2 hours ago, iiv said:

Правильно ли я понимаю, что вариант с stm32f730i8 и метод как описано в https://stackoverflow.com/questions/51390342/creating-cortex-m7-project-from-scratch-where-to-start

должен быть наиболее оптимальным?

Особенно оптимально выглядит вот это вот самостоятельное описание дефайнов адресов регистров периферии.

Регистры периферии нынче как правило описываются не как абсолютные адреса отдельных регистров, а как структуры, с юнионами и битовыми полями, соответственно нормальный редактор кода с автодополнением, который этот хедер подхватывает, очень помогает.

2 hours ago, iiv said:

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

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

тем более что если речь про 1мкс = 200 тактов, вряд ли можно много кода написать, чтобы он исполнялся 200 тактов, но при этом не влез в 16кБ.

 

[k155la3 26]

16 hours ago, iiv said:

. . . Грубо говоря я померю (повторив миллион раз), сколько всреднем оно вычисляется, например за 1микросекунду. Можно ли будет заложить программно, что после начала работы этого блока пройдет не более 1мкс + эпсилон, когда я гарантированно получу результат, и, если да, то где почитать от чего этот эпсилон может зависеть?

Сам  не пользовался, но знаю, есть такие .... профайлеры. Этот софт, думаю, сильно упростил бы Вам жизнь, учитываю тягу к подсчетам времени.

Также посмотрите "специфические" служебные регистры процессора - там может быть счетчик времени в тактах. Сам еще только начал изучать этих монстров (F429).

 

[iiv 17]

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

 

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

 

Спасибо большое всем за классные советы, кажется теперь понятно как действовать!

[jcxz 184]

В 03.02.2019 в 00:03, iiv сказал:

я имею ввиду с учетом сбросов кеша и без оных?

Читаю в который раз и не могу понять: А зачем его (кеш) сбрасывать? И про какой кеш идёт речь? Может я что-то пропустил?... 

В 03.02.2019 в 01:42, _pv сказал:

тем более что если речь про 1мкс = 200 тактов, вряд ли можно много кода написать, чтобы он исполнялся 200 тактов, но при этом не влез в 16кБ.

Для таких времён любая SRAM будет аналогична ITCM, особенно если нет активных DMA-потоков. А значит 16КБ можно не ограничиваться, а хоть всё приложение засунуть в ОЗУ.

Но если ещё внимательнее посмотреть на характеристики работы кешей флешь и ширину шины памяти к флешь (во многих Cortex-M она имеет ширину == 256 бит), то окажется что даже линейное выполнение без всяких кешей на таких МК с широкой шиной почти аналогично выполнению из кеша на МК с большим кешем.

[jcxz 184]

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

Точно, кеш оказывается выключить можно, это очень кстати!

Зачем это делать???  

Открываем даташит на TM4C129DNCPDT, читаем: 

"The interleaved memory prefetchs 256 bits at a time. The prefetch buffers allow the maximum
performance of a 120 MHz CPU speed to be maintained with linear code or loops that fit within the
prefetch buffer."

И правда, если посчитать: На чтение одной строки кеша (256 бит) на 120МГц тактовой CPU нужно 6 тактов. Итого: 256/8бит/4байта=8команд, т.е. даже если весь ваш код будет исключительно из 4-байтовых 1-тактовых команд, то одна строка кеша это будет 8 команд. Т.е. - как минимум за 2 команды до конца текущей строки предвыборки будет считана уже следующая строка. И задержки не будет вообще.

Конечно если происходит кеш-промах (переход за пределы кеша), то необходимо 6 тактов на загрузку строки кеша. Но это детерминированное время. Загрузка идёт по отдельной шине (ICode bus) и никак не зависит от доступов к другим регионам памяти.

[_pv 52]

40 minutes ago, jcxz said:

Для таких времён любая SRAM будет аналогична ITCM, особенно если нет активных DMA-потоков. А значит 16КБ можно не ограничиваться, а хоть всё приложение засунуть в ОЗУ.

у указанного ТСом stm32f730 всё немного по другому, и частота повыше, и что там с шириной шин до остальной памяти (кроме ITCM, на которой ещё ускоритель для флэша) не знаю - смотреть надо. выделили же зачем-то отдельно они эти 16кБ ITCM RAM (for critical real-time routines).

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

6 тактов может и детерминированы, но вот сами промахи кэша не очень, и раз уж ТС так хочет отдельные такты считать как на АВР, можно и выключить.

[jcxz 184]

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

6 тактов может и детерминированы, но вот сами промахи кэша не очень

Зависит от алгоритма. Если условные переходы в пределах кеша (те условные, направление выполнения которых зависит от измеряемых данных; т.е. например переходы циклов - не в счёт), то они будут без кеш-промахов. Условные переходы, зависимые от данных да ещё дальние - не в каждом алгоритме обработки данных такие встретишь, тем более ТС вроде говорит о сигнальной обработке.

[iiv 17]

Подниму старую тему, но немного с другими ньюансами...

 

Хочу embedded linux с быстрым SPI, чтоб по нему обмениваться с микроконтроллером, или сраду микроконтроллер внутри на борту. Когда-то пробовал hardkernel.com, acmeszstems.it, pcduino, intel edison - везде SPI был страшно глючным, и, во время коммуникации напрочь блокировал основной процессор.

 

Знаю одно решение - Cyclone 5 SoC c самопально нарисованным SPI на стороне плиски и коммуникации плиска-процессор, но сложность по разводке такой платы (в основном из-за того, что надо память подцепить) превышает все желания использовать такое решение.

 

Скажите, пожалуйста, есть ли какие-то другие embedded linux решения с надежным SPI, который гарантированно бы работал бы без танцев с бубном и перекомпилляцией ядра?

 

Спасибо!

[arhiv6 14]

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

везде SPI ... во время коммуникации напрочь блокировал основной процессор. 

А Вы пробовали использовать DMA для передачи данных?