[jcxz 0]

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

Хочу embedded linux с быстрым SPI, чтоб по нему обмениваться с микроконтроллером, или сраду микроконтроллер внутри на борту.

Так если МК - внутри (т.е. - в том же чипе), то зачем для обмены с ним SPI? Для обмена - использовать средства межъядерной коммуникации.

Или я не понял вопроса....

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

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

Когда-то давно я использовал OMAP-L137. Там было одно ядро на которое можно было поставить линух. И было другое ядро, которое можно было использовать stand alone. SPI там был вполне себе нормальным. Правда он не нужен для межъядерного обмена.

А сейчас вроде как у STM появились подобные чипы: STM32MP1 (Cortex-A + Cortex-M). И не думаю что SPI там плох. Хотя опять-же - для межъядерного обмена он не нужен.

[iiv 0]

6 hours ago, jcxz said:

А сейчас вроде как у STM появились подобные чипы: STM32MP1 (Cortex-A + Cortex-M). И не думаю что SPI там плох. Хотя опять-же - для межъядерного обмена он не нужен.

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

 

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

 

 

[iiv 0]

6 hours ago, arhiv6 said:

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

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

[jcxz 0]

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

тут действительно SPI не нужен, хотя, чтоб попробовать, там опять с памятью возиться и разводить надо...

Зачем? Есть же отладки на нём.

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

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

Насчёт линуха не подскажу.

[aaarrr 0]

33 minutes ago, iiv said:

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

Увы, в случае SPI остается только выяснять "способности" в каждом конкретном случае. То есть даже наличие поддержки DMA в драйвере ничего не гарантирует,

т.к. основные сценарии использования SPI в SoC - "загрузиться с флешки и забыть до следующего включения" или "раз в секунду протащить два байта с датчика",

причем последний встречается значительно реже.

[iiv 0]

16 hours ago, aaarrr said:

Увы, в случае SPI остается только выяснять "способности" в каждом конкретном случае.

спасибо! Ага, я тоже примерно также предполагал исходя из своего опыта. А вот интересно, а как тогда люди поступают, если им надо много (мегабайты в секунду) получать-принимать на embedded linux, причем просто МК не тянет сами вычисления, например, из-за того, что памяти мало... У меня постоянно такие задачи встречаются, пока пользую Cyclone 5 SoC, но удобных готовых плат нет, а разводка DDR2 не есть очень простое занятие...

[_3m 0]

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

А вот интересно, а как тогда люди поступают, если им надо много (мегабайты в секунду) получать-принимать на embedded linux, причем просто МК не тянет сами вычисления, например, из-за того, что памяти мало... У меня постоянно такие задачи встречаются, пока пользую Cyclone 5 SoC, но удобных готовых плат нет, а разводка DDR2 не есть очень простое занятие...

Люди в таких случаях используют USB. Можно его сколько угодно ругать (и по делу!) но USB единственный интерфейс который точно будет иметь минимум "нюансов" на любом SOC. Драйвера I2C, SPI как правило с "сюрпризами" а то и вовсе нерабочие.

[aaarrr 0]

2 minutes ago, _3m said:

Люди в таких случаях используют USB.

Таки да. При всей дикости, есть неоспоримые плюсы:

- он стандартный

- достаточно скоростной

- есть в каждом утюге

- можно с удобством отлаживать железку на хосте

 

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

[_pv 0]

ну ещё ethernet есть, куда более стандартный чем usb :), но по скорости малость проигрывает usb, и есть хоть и не в каждом утюге, но вполне встречается, и [R]MII можно напрямую друг в дружку воткнуть без физики если речь про соединение на одной плате.

А регистры dma и spi нельзя через /dev/mem и mmap напрямую сконфигурировать на пересылку определённого куска, чтобы без кривых драйверов? но от изучения возможностей в каждом конкретном случае это конечно никак не избавит.

47 minutes ago, aaarrr said:

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

на вывод параллельные же lcd тоже вымерли не везде.

[aaarrr 0]

13 minutes ago, _pv said:

А регистры dma и spi нельзя через /dev/mem и mmap напрямую сконфигурировать на пересылку определённого куска, чтобы без кривых драйверов?

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

осваивать который только ради SPI очень накладно.

[iiv 0]

Спасибо большое всем за интересную информацию!!!

 

Да, как-то раньше не видел проблемы... Всегда боялся ставить хоть USB, хоть Ethernet, так как при большом трафике и их неопределенных задержках можно на буферизацию не вписаться во всю память микроконтроллера, которой обычно десятки килобайт всего-то и при 10МБ/с она за несколько миллисекунд кончается...

[jcxz 0]

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

Всегда боялся ставить хоть USB, хоть Ethernet, так как при большом трафике и их неопределенных задержках можно на буферизацию не вписаться во всю память микроконтроллера, которой обычно десятки килобайт всего-то и при 10МБ/с она за несколько миллисекунд кончается...

Самый быстрый и наименее латентный способ пересылки в другой процессор: пересылка в соседнее ядро через общую память. Никакой из обсуждавшийся интерфейсов даже близко не лежал по скорости с этим методом. Не знаю как под линуксом, но если stand alone, то и написать драйвер для такого обмена проще чем возиться с USB/Ethernet/SPI.

Так что если есть возможность - я бы предпочёл многоядерный МК.

Уж не говоря о том что и отладка упростится. Ибо отладка двух одновременно работающих в реальном времени независимых МК - то ещё удовольствие.

[iiv 0]

2 hours ago, jcxz said:

Самый быстрый и наименее латентный способ пересылки в другой процессор: пересылка в соседнее ядро через общую память. ... Ибо отладка двух одновременно работающих в реальном времени независимых МК - то ещё удовольствие. 

полностью подпишусь под каждым вашим словом. Мой скромный опыт примерно о том же говорит, единственно, я вместо второго ядра таскал с SoC плиски.

 

3 hours ago, jcxz said:

Так что если есть возможность - я бы предпочёл многоядерный МК.

да, верно, но тут-то вся собака-то и порылась.

 

Нормальные не тормозные ядра с гигафлопсом и более на плавающей точке с малыми кортексами, которые умеют дрыгать ногами в реальном времени как-то без NDA сложно найти, а если что и находится, то прелесть разводки такого монстра и запуск на нем линукса - ужасно муторное дело. А покупные готовые борды (кто, кстати, кроме hardkernel.com) в силу кривой разводки реал-таймовой части зачастую не позволяют общаться с внешней периферией достаточно быстро.

 

Если думать в сторону одинаковых ядер, пусть, к примеру, 4 ядра, каждое на свой SPI (это уже на переферию), то тут у линукса не все в порядке, так как он норовит забросить процессы на то ядро, где крутится этот SPI и все опять или кладется, или все танцуют с бубном и все равно ничего не выходит.

[haker_fox 0]

3 hours ago, jcxz said:

Самый быстрый и наименее латентный способ пересылки в другой процессор: пересылка в соседнее ядро через общую память.

+1, тем более всё это поддерживается производителем.

 

Например, у двухядерного LPC4337 каждое ядро может дёрнуть прерывание для другого ядра. Таким образом они могут привлечь внимание друг друга. Я делал для такого обмена что-то типа пакетного протокола, как для последовательного канала: код функции, количество байт данных, данные (если есть). Контрольную сумму только не прикручивал. Но, разумеется, вариантов тут вагон и маленькая тележка.

[gosha-z 0]

15 hours ago, iiv said:

А вот интересно, а как тогда люди поступают, если им надо много (мегабайты в секунду) получать-принимать на embedded linux, причем просто МК не тянет сами вычисления, например, из-за того, что памяти мало...

Zynq/ZynqMP или аналоги от Intel/Altera, вопрос религиозный. Данные затягиваем в PL часть, там обрабатываем и выдаем по DMA в PS часть, где живет Linux или bare-metal app.