Jump to content

    

Доступ к одному аппаратному интерфейсу двух процессоров

Имеется два ARM с FreeRTOS внутри (прошивки каждого выполняют полностью идентичные функции) и один аппаратный канал связи с внешним устройством, который разделяют оба процессора (канал - только выходные сигналы). Имеется также по одному выходу и, соответственно, входу на другом процессоре для индикации занятости (1) и освобождения (0) канала.

Время обмена по каналу ~ 5 мс. Время цикла обработки данных процессором - 20 мс +-1 мс. Т.е.каждый процессор должен 5 мс работать с каналом, потом на 15 мс освободить канал и занимается своими делами. В это время канал может использовать второй процессор. Но есть один нюанс - любой процессор может быть включен или выключен в произвольный момент. При этом работающий процесор должен продолжать работать штатно а вновь подключенный - засинхронизироваться с уже работающим.

Что-то совсем запутался с приоритетами и семафорами - совсем лыжи не едут. Может кто-то подскажет правильный алгоритм для такой конфигурации?

 

Share this post


Link to post
Share on other sites
7 минут назад, KiV сказал:

Что-то совсем запутался с приоритетами и семафорами - совсем лыжи не едут. Может кто-то подскажет правильный алгоритм для такой конфигурации?

Используйте CAN - там это всё уже есть и не нужно лыжи изобретать. И сигналы занятости не нужны.

Share this post


Link to post
Share on other sites

Спасибо конечно, но:

33 минуты назад, KiV сказал:

Имеется

Это во-первых.

А во-вторых мне придется ещё пару процессоров поставить, чтобы в десяти сантиметрах от основных процессоров декодировать CAN в подобие SPI обратно для исполнительного устройства.

Share this post


Link to post
Share on other sites
1 hour ago, jcxz said:

Используйте CAN - там это всё уже есть и не нужно лыжи изобретать. И сигналы занятости не нужны.

ну отчего же....

если учесть вот это:

1 hour ago, KiV said:

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

можно и на трансиверах RS485 с TX_EN сделать - вопрос в выборе протокола поверх UART..

Классический Time Triggered protocol

Share this post


Link to post
Share on other sites

Возможно я не совсем ясно описал проблему. Дело в том, что интерфейс исполнительного устройства есть и не может быть изменен. Там уровни сигналов TTL и что-то типа синхронного SPI с сигналами тактирования, данных, выбора, разрешения и загрузки. Причем сигналы должны выдаваться в определенной витиеватой последовательности. Если использоватть CAN, RS-485 или что другое - нужно будет городить преобразователь на дополнительном процессоре из этого интерфейса в понятный внешнему устройству. Это невозможно по причине физических и финансовых ограничений.

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

Share this post


Link to post
Share on other sites

 

17 hours ago, KiV said:

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

А при чем тут фриртос вообще? Вам надо каким-то образом определить свободность интерфейса...

Share this post


Link to post
Share on other sites

Мне необходимо синхронизировать два "мастера" на одном аппаратном интерфейсе. Сигналы занятости интерфейса каждый процессор выдает другому по отдельному порту ввода/вывода.

Share this post


Link to post
Share on other sites

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

 

какой-то готовой межпроцессорной синхронизации во фриртос, имхо, из коробки нет

Share this post


Link to post
Share on other sites
11 минут назад, Johnny81 сказал:

Вам надо придумать алгоритм ...

Именно так!!!

Я никак не могу придумать этот самый алгоритм :(

Постоянно получаются гонки/дедлоки/etc... Поэтому и задал вопрос - возможно кто-то уже реализовывал подобное.

 

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

Вам нужен mutex.

Что такое mutex, semaphore, event group я знаю. У меня в алгоритме постоянно или гонки или еще какая бяка выскакивает и портит обмен :(

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Mutex хорош, когда надо разделить ресурс между двумя процессами на одном кристалле, а как выдать один мьютекс на двух отдельных кристаллах в двух программах?

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

Share this post


Link to post
Share on other sites
18 часов назад, KiV сказал:

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

FreeRTOS тут вообще ни при чём. Так как он работает в пределах одного процессора и не знает про другой.

Впрочем - как уже написали.....

20 минут назад, KiV сказал:

Mutex хорош, когда надо разделить ресурс между двумя процессами на одном кристалле, а как выдать один мьютекс на двух отдельных кристаллах в двух программах?

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

Вам для решения задачи (именно межпроцессорной синхронизации) не нужны мьютексы и т.п. средства ОС. Нужны прерывания по изменению состояний линий связи между процессорами. И механизм разрешения коллизий.

 

Межпроцессорную синхронизацию в Вашем случае как мне видится можно организовать следующими способами:

1) 2 цифровых линии запроса захвата шины от двух процессоров с логикой анализа и разрешения коллизий на прерываниях и задержках;

2) 1 аналоговая линия запроса захвата шины (анализируемая обоими CPU) с логикой анализа и разрешения коллизий на задержках;

3) механизм на основе CAN (одна линия, без CAN-драйвера) с логикой анализа и разрешения коллизий на основе аппаратных возможностей CAN (я уже предлагал выше).

Share this post


Link to post
Share on other sites
14 минут назад, jcxz сказал:

механизм разрешения коллизий

Так может кто предложить как реализовать в моей ситуации?

Share this post


Link to post
Share on other sites
2 минуты назад, KiV сказал:

Так может кто предложить как реализовать в моей ситуации?

См. выше. Механизм на основе CAN будет самым красивым и думаю - самым быстрым. Но нужен аппаратный CAN-интерфейс в МК.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now