Перейти к содержанию
    

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Имеется

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, jcxz said:

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

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

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

1 hour ago, KiV said:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

 

17 hours ago, KiV said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

 

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

Вам нужен mutex.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

18 часов назад, KiV сказал:

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

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

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

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

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

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

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

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...