Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Организация pnp в embedded системах
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > Программирование
sergeeff
Коллеги!

Какие у кого есть мысли, как лучше организовать некое подобие PNP?

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

Какие есть мысли на сей счет?
Doka
очевидно что начать лучше с чтения доков по P'n'P. Оттуда и идеи заимствовать.

Кратко как это сделано для PCI-периферии:
до конфига пространства памяти и ввода-вывода недоступно
программа POST BIOS активируя сигнал IDSEL обращается в конфигурационное пространство и вычитывает структуру конфига PCI (класс устройства, требуемые ресурсы).
На основании этого - конфигурит его.
Далее если есть ROM BIOS и 2-байтная сигнатура совпала (==АА55), вычитывается это ПЗУ (в ОЗУ) и если после вычитки совпала контрольная сумма - управление передается на начало вычитанного блока.
sergeeff
Да я несколько об другом.

Например, есть функция out_lcd(char *pData, int Len), которая выводит нам некоторую строку на дисплей. Подцепили этот дисплей к плате, запустили свой firmware. Все (если все правильно, конечно) работает. Теперь отключаем дисплей, нажимаем reset и хотим, чтобы все устройство работало, а не зависало на первой же функции out_lcd. Конечно, если в этой функции не читается статус дисплея, то все так и будет работать само собой, за исключением бесполезной траты процессорного времени.

Вопрос, таким образом, состоит в более общем и, может быть, более эффективном решении подобных задач.
Andy Mozzhevilov
Цитата(sergeeff @ Feb 5 2007, 20:12) *
Да я несколько об другом.

Например, есть функция out_lcd(char *pData, int Len), которая выводит нам некоторую строку на дисплей. Подцепили этот дисплей к плате, запустили свой firmware. Все (если все правильно, конечно) работает. Теперь отключаем дисплей, нажимаем reset и хотим, чтобы все устройство работало, а не зависало на первой же функции out_lcd. Конечно, если в этой функции не читается статус дисплея, то все так и будет работать само собой, за исключением бесполезной траты процессорного времени.

Вопрос, таким образом, состоит в более общем и, может быть, более эффективном решении подобных задач.


При инициализации системы определяйте конфигурацию, если это возможно. Если устройство в конфигурации отсутствует, то функции работы с ним замените на пустые и возвращающие значения по умолчанию.
В embedded системах вряд-ли имеет смысл делать общий алгоритм типа PnP, поскольку интерфейс внешних устройств и требования к нему сложно формализовать.
umup
Я делал просто (для разных конфигураций индикаторов - несколько светодиодных и LCD) - в разьеме для подключения индикатора оставлял несколько выводов свободными, на основной плате подтягивал их резисторами на +, а в платах индикации один или несколько этих контактов заземлял, при включении устройства или перед обновлением индикации читал этот код и в зависимости от его значения использовал разные алгоритмы работы с индикацией
psL
Цитата(sergeeff @ Feb 5 2007, 18:12) *
Да я несколько об другом.

Например, есть функция out_lcd(char *pData, int Len), которая выводит нам некоторую строку на дисплей. Подцепили этот дисплей к плате, запустили свой firmware. Все (если все правильно, конечно) работает. Теперь отключаем дисплей, нажимаем reset и хотим, чтобы все устройство работало, а не зависало на первой же функции out_lcd. Конечно, если в этой функции не читается статус дисплея, то все так и будет работать само собой, за исключением бесполезной траты процессорного времени.

Вопрос, таким образом, состоит в более общем и, может быть, более эффективном решении подобных задач.


Организуйте таймаут по доступу к периферии.
Например можно даже аппаратный WD поставить, а выход его повесить на прерывание процессора - нет ответа - периферии либо не было, либо сдохла, либо отключена.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.