Serial Interrupt в OpenGL, какая структура идти? - PullRequest
Новая
       49

Serial Interrupt в OpenGL, какая структура идти?

0 голосов
/ 02 января 2012

Я пишу программное обеспечение OpenGL, которое управляется UART (последовательным с помощью Boost :: asio) в C ++ под Linux.

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

Как вызвать функцию рисования OpenGL из функции обратного вызова UART?

Конечно, я смогу запустить его:

  1. Использование любого из методов IPC (PIPE, Socket, Semaphore)
  2. Передать функцию рисования OpenGL или ее класс в качестве переменной для обратного вызова UART
  3. Собираем все в один класс

Я сталкивался со многими подобными случаями и реализовал их по-разному. Но я все еще не могу понять, что является правильным ответом.

Лично мне не нравятся PIPE или файловые IO IPC, единственная оставшаяся опция - это сокет, семафор и разделяемая память, которые я всегда использовал.

Ответы [ 2 ]

2 голосов
/ 02 января 2012

Как вызвать функцию рисования OpenGL из функции обратного вызова UART?

Не.

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

Это не tty, но Linux evdev, но общая идея остается той же: это небольшая демонстрационная программа, которая показывает, как читать входные данные из трехмерного космического навигатора Connextion и обрабатывать их в трехмерной сцене, визуализируя ее с помощью OpenGL: http://homepages.physik.uni-muenchen.de/~Wolfgang.Draxinger/stuff/spaceball.tar.bz2

0 голосов
/ 02 января 2012

Зависит от приложения, конечно.

Имеет много смысла для функции обратного вызова последовательной связи для доступа к состоянию OpenGL, но если вы делаете прототип / проверку концепции, зачем делать вашу работу тяжелее?

Общая память - хороший вариант; обратный вызов может поместить данные куда-нибудь, вызвать поток рисования и дождаться его завершения. (И это только один шаг от обратного вызова, вызывающего саму функцию рисования.)

Хотя я мог бы предпочесть передачу сообщений. Когда данные получены, обратный вызов может упаковать и отправить (скопировать) их в поток рисования, который может получить их после получения. Это даст дополнительное преимущество: код UART не будет ждать в коде чертежа, хотя это вряд ли будет проблемой, учитывая скорость OpenGL, особенно по сравнению с последовательной связью.

...