LINUX.ORG.RU

Управление триггером физической установки


0

0

Язык - python. GUI - PyQt3. Доступ к модулям через VME-шный драйвер и самописанную библиотеку (на С + биндинг в python), скрывающую детали контроллеров корзин, их внешней шины и её контроллера. Детали - далее в обсуждении.

>>> Просмотр (1280x1024, 168 Kb)

★★

Проверено: Pi ()

Re: Управление триггером физической установки

60000 занимает столько же знакомест, что и 6e+04, но гораздо нагляднее %)

anonymous ()

Re: Управление триггером физической установки

Зачот. А то проприетарный labview всех достал уже)

michwill ★★★★★ ()

Re: Управление триггером физической установки

А вот и нет, 6e+04 куда нагладнее. Это журналисты любят писать, что Земля погибнет через 5000000000 лет и что была получена нанопроволока диаметром 0.000000001 м

michwill ★★★★★ ()

Re: Управление триггером физической установки

Шрифты...

Sikon ★★★ ()

Re: Управление триггером физической установки

> Зачот. А то проприетарный labview всех достал уже)

а я что, я только за. Если дрова для всяго железа лабе под линукс найду то можно и взяться. Только как это шефу аргументировать то...

firsttimeuser ★★★★★ ()

Re: Управление триггером физической установки

Strip_tiz )

anonymous ()

Re: Управление триггером физической установки

А что это?

anonymous ()

Re: Управление триггером физической установки

Лучше бы PyQt4, чтобы не тянуть устаревшую библиотеку.

troorl ★★ ()

Re: Управление триггером физической установки

Херня непонятная, но выглядит сильно. Зачёт.

gpg ()

Re: Управление триггером физической установки

VME-шный драйвер - это что? Для доступа к оборудованию на шине VME? Если да, то что за железо, какая материнка, проц? Было бы куда интереснее, чем питон с кутэ.

scaldov ★★ ()

Re: Управление триггером физической установки

> Если да, то что за железо, какая материнка, проц? Было бы куда интереснее, чем питон с кутэ.

предыстория:

"... Bit 3 became a part of SBS Technologies, Inc. in November of 1996 and changed its name to SBS Bit 3. However, SBS Bit 3 continues to be its own subsidiary of SBS."
http://www.computerhope.com/comp/bit3.htm

"SBS Technologies, Inc., (Nasdaq: SBSE) founded in 1986, designed and built open architecture embedded computer products that enable original equipment manufacturers to serve the commercial, communication and government markets. SBS was headquartered in Albuquerque, New Mexico.

In 2006, SBS Technologies was acquired by GE Fanuc Embedded Systems. The SBS headquarters in Albuquerque is now the headquarters for GE Fanuc Embedded Systems."
http://en.wikipedia.org/wiki/SBS_Technologies

"GE Fanuc Embedded Systems, a unit of General Electric Company"
http://en.wikipedia.org/wiki/GE_Fanuc_Embedded_Systems

наглядный пример того, как акулы капитализма жрут друг друга с потрохами и это хорошо, пока выигрывает потребитель. А сама железяка это host bus adapter к корзине vme:

"Although single board computers can be used to provide specialized processing and I/O capabilities, they are not the only solution. For certain types of applications, a bus adapter is a viable alternative, and may even be the best choice. In cases where a bus adapter can replace of a single board computer, it has a lower total system cost, allows for easier upgrades and migrations to different platforms, enhances performance and shortens development time and time to market."
http://www.gefanucembedded.com/products/family/145

хотя её в каталоге производителя нет, но пользователей немало, да и сделана она на славу, короче популярная в узком кругу вещица, посему есть народ пишущий под неё драйверы:

"'vmedrv' is a device driver for Linux 2.x for the PCI-VME bus adapter Model 616/617/618/620 manufactured by SBS Technologies (Bit3). The vmedrv driver is a loadable module with full VME interface functionality, such as programmed I/O, memory mapped access (mmap()), VME interrupt handling, and DMA data transfer.
...
The licence for this software is set as "LGPL Version 2.1"."
http://www.awa.tohoku.ac.jp/~sanshiro/kinoko-e/vmedrv/

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

надеюсь интерес удовлетворил. Подробности об интерфейсном железе гораздо менее интересны и полезны, чем то, для чего оно используется. Если в проекте строительства типового дома сборка и обслуживание крана занимает бОльшую часть, то архитектора надо гнать взашей ;)

filin ★★ ()

Re: Управление триггером физической установки

про приложение на python и менюхи на PyQt3 я рассказывать не буду, всё стандартно. Расскажу про доступ к корзинам, это не совсем тривиально.

Есть хост бас адаптер к корзине VME, позволяющий отобразить адресное пространство VME-модулей в адресное пространство процесса на хосте через драйвер от японца. В каждом случае это делается через спец железку и спец драйвер. Углублённый интерес это представляет только для писателей драйверов под адаптеры шин внешних для PC.

В корзину VME (http://en.wikipedia.org/wiki/VMEbus) втыкаются модули выполняющие разнообразные роли и использующие общую шину VME для обмена данными (боже, пишу как в детском саду, ладно будет меньше глупых вопросов), например роль адаптеров к шинам внешним уже по отношению к шине вме, в нашем случае это древние шины Q-Bus и СУММА branch highway (аналог CAMAC). Разработчики этих модулей-адаптеров уже позаботились о нас и в адресном пространстве процесса мы совершенно прозрачно видим регистры контроллеров прицепленных к Q-Bus и СУММА branch highway. Проблем несколько:
* размер окна отображённого через VME тоже должен быть достаточно большим чтобы вместить регистры нужных контроллеров (тривиально),
* набрать перемычками на модулях-адаптерах и контроллерах их уникальные базовые адреса и верно их указывать при обращении к ним, иначе получается как в анекдоте: включаешь свет в туалете, а включается кофемолка, включаешь телевизор, а звенит входной звонок,
* должен соблюдаться протокол доступа к шине

Контроллер управляемый через внешнюю шину Q-Bus или СУММА branch highway являются контроллером внутренней шины своей корзины (СУММА или МИСС, как и CAMAC), но не отображает эту шину в адресное пространство процесса, а позволяет посылать команды модулям использующим внутреннюю шину корзины. Углубляться далее интересно только тем кто использует эти модули.

Шины Q-Bus и СУММА branch highway могут быть доступны разными способами, например, через контроллеры являющиеся vme-модулями, через прямой PCI контроллер, через промежуточный контроллер Q-Bus -> СУММА_branch_highway, не суть важно, нужен програмный слой абстракции, который позволил бы менять интерфейсные модули (и промежуточные шины), без изменения кода использующего конечные модули. С этой целью была написана библиотека на С.

filin ★★ ()

Re: Управление триггером физической установки

Писать на С++ не хотелось, тк хотелось огрести будущих возможных 
проблем с портированием и биндингами по минимуму, поэтому был выбран 
С. Являясь (какое слово интересное: три гласные и все буквы "я") 
большим любителем виртуальных функций, я не мог без них обойтись, 
поэтому был придуман простенький механизм, каждый класс содержит указатель на таблицу виртуальных функций в предке или в явном виде у себя (если есть дополнительные вирт функции и таблица предка расширяется):

struct abstract_branch_controller {

	struct abstract_controller ctl;

  uint32_t branch_num; /* branch number */

  struct _abstract_branch_controller_vt_t *_vt; /* virtual funcs table */
};
...
struct _abstract_branch_controller_vt_t {
  struct _abstract_controller_vt_t _vt; // parent vt
  void (* branch_cnaf16)( void *,
                          uint32_t,
                          uint32_t,
                          uint32_t,
                          uint32_t,
                          uint16_t * );
  void (* branch_cnaf32)( void *,
                          uint32_t,
                          uint32_t,
                          uint32_t,
                          uint32_t,
                          uint32_t * );
  void (* zero) ( void * );
  uint16_t (* Q)( void * );
  uint16_t (* X)( void * );
};

во время инициализации объекта вначале ОБЯЗАТЕЛЬНО инициализируется предок:

int
abstract_branch_controller_init( struct abstract_branch_controller *self,
                                 struct abstract_host_interface *host_interface,
                                 addr_t window_base,
                                 addr_t window_size,
                                 uint32_t branch_number )
{
  int rv = 0;
  // init parent before any init in child!
  rv = abstract_controller_init( &(self->ctl),
                                 host_interface,
                                 window_base,
                                 window_size );
  // init own vt, make it in EVERY case!
  abstract_branch_controller_set_vt( self,
                                     abstract_branch_controller_get_vt() );
  self->branch_num = branch_number;
  return rv;
}

для вызова виртуальной функции пишется _один_раз_ коммутатор в исходном тексте класса, где эта функция впервые появляется:

void
zero_branch( void *self )
{
  // virtual funcs commutator
  (*((struct abstract_branch_controller *)self)->_vt->zero)( self );
}

и сами виртуальные функции, которые переписываются если нужно в потомках и видны только в файле где они описаны:

static void
_zero( void *self )
{
  fprintf( stderr, "abstract_branch_controller_zero( %p )\n", self );
}
...

наконец функции, инициализирующие таблицу виртуальных функций:

struct _abstract_branch_controller_vt_t * abstract_branch_controller_get_vt()
{
  static struct _abstract_branch_controller_vt_t vt; // there are own virtual funcs besides parent funcs
  static is_vt_inited = 0; // to prevent vt reinitialization during subsequent calls
  if ( ! is_vt_inited ) {
    vt._vt           = *abstract_controller_get_vt();
    vt.branch_cnaf16 = _branch_cnaf16;
    vt.branch_cnaf32 = _branch_cnaf32;
    vt.zero          = _zero;
    vt.Q             = _Q;
    vt.X             = _X;
    vt._vt.name      = "abstract_branch_controller";
    is_vt_inited = 1;
  }
  return &vt;
}

void
abstract_branch_controller_set_vt( void *self,
                                   struct _abstract_branch_controller_vt_t *vt )
{
  struct abstract_branch_controller *s = (struct abstract_branch_controller *)self;
  s->_vt = vt;
  s->ctl._vt = &(vt->_vt); // else virtual funcs commutators in parent will work incorrectly
}

filin ★★ ()

Re: Управление триггером физической установки

конечно, чтобы таблица виртуальных функций предка работала правильно 
в коммутаторах предка, предка надо помещать ПЕРЕД ВСЕМИ членами класса

struct le20 {

  struct abstract_branch_controller br_ctl; // the first member in the defined structure to guarantee right casting to the parent in virtual funcs commutators

  //! Command register 1 (crates 1,2,3)
  struct {
    struct register16 r16;

    union {
      struct {
        uint16_t A : 4;
        uint16_t N : 5;
        uint16_t F : 5;
        uint16_t C : 2;
      } wbits;

      struct {
        uint16_t L1_16;
      } rbits;
      uint16_t w;
    } buf;
  } Com1R;
...

при создании биндинга в питон наличие кучи развесистых вложенных 
структур-объединений может добавить головной боли автору биндинга
даже при наличии генератора.
К счастью есть ctypeslib (useful additions to the ctypes FFI library,
http://pypi.python.org/pypi/ctypeslib/0.5.4a), способный генерить
биндинги с помощью gcc-xml (http://www.gccxml.org/HTML/Index.html,
кстати поддерживается Roman Yakovenko).
Для доступа к родным сишным функциям и переменным есть модуль питона
ctypes, с помощью которого доступ в С из питона становится почти
тривиальным:

import sys
from ctypes import *

# load funcs...
lib=CDLL("libmylib.so")

class BranchController:
    def __init__( self, host_iface, use_hardware=True ):
        self.host_iface = host_iface
        self.use_hw = use_hardware

    def cnaf16( self, c, n, a, f ):
        if not self.use_hw:
            print 'BranchController::cnaf16( ', c,', ', n,', ', a,', ', f,' )'
            return
        data = c_ushort( 0 )
        lib.branch_cnaf16( byref(self.branch_ctl), c, n, a, f, byref(data) )

...

from BranchController import *

class LE20( BranchController ):
    def __init__( self, host_iface, base, branch_num, use_hardware=True ):
        BranchController.__init__( self, host_iface, use_hardware )
        if not use_hardware:
            return
        self.branch_ctl = abstract_branch_controller()

        lib.le20_init( byref(self.branch_ctl), byref(host_iface.c_type()), base, c_uint(branch_num) )
        if lib.map_controller( byref(self.branch_ctl) ):
            raise BranchControllerInitError( "can't init LE20 with base "+str(base) )
        data = c_ushort( 0 )
        lib.zero_branch( byref(self.branch_ctl) )        
        lib.branch_cnaf16( byref(self.branch_ctl), 1, 28, 9, 26, byref(data) ) # clear
        lib.branch_cnaf16( byref(self.branch_ctl), 1, 28, 9, 24, byref(data)

реализация логики конечных модулей на питоне становится легко
изменяемой (поменял - перезапустил) и малословной, например:

import CrateModule

class R8( CrateModule.CrateModule ):
    def __init__( self, branch_ctl, crate_num, mod_num ):
        CrateModule.CrateModule.__init__( self, branch_ctl, crate_num, mod_num )

    def readInputs( self ):
        return self._read_af( 0, 0 )

    def testLam( self ):
        return self._read_af( 0, 8 )

    def readInputsAndReset( self ):
        return self._read_af( 0, 2 )

    def reset( self ):
        self._af( 0, 9 )

    def disableL( self ):
        self._af( 0, 24 )

    def enableL( self ):
        self._af( 0, 26 )

    def testTr( self ):
        return self._read_af( 0, 27 )


к словам в сишном тексте типа "abstract" просьба не придираться, множественное наследование в описанном механизме запрещено, на возгласы "велосипед!", не отвечаю, спасибо за внимание

filin ★★ ()

Re: Управление триггером физической установки

библиотеку планирую выложить в публичный доступ попозже, когда она будет причёсана и написана документация

filin ★★ ()

Re: Управление триггером физической установки

да, конечными модулями я называю модули в корзинах являющиеся конечным пунктом назначения при путешествии ОТ компьютера, с которыми и ведётся "разговор" с помощью библиотеки. Скорость выполнения на современном ЦПУ даже для приложения на питоне настолько велика, что занимает пренебрежимое время по сравнению с самим вводом-выводом в большинстве случаев. Данные с интенсиметра пучка на скриншоте изображены синим графиком, Фурье образ фиолетовым.

filin ★★ ()

Re: Управление триггером физической установки

> А вот и нет, 6e+04 куда нагладнее.

там кнопочки есть "exp", они меняют формат представления fixed/exponential в соответствующей колонке специально для любителей разного формата ;)

> у него шрифтовой фгм

само такое

> Шрифты...

со шрифтами проблема одна: большие, чтобы все видели без напряга и маленькие чтобы всё влезло, какие быстро подошли, те и выбраны

> Strip_tiz )

это кто-то развлекался переименованием (имена выбираются пользователями), чес слово не я

> А что это?

> Херня непонятная, но выглядит сильно. Зачёт.

это часть большой по нашим меркам установки для физических экспериментов

> Лучше бы PyQt4, чтобы не тянуть устаревшую библиотеку.

кому это она устаревшая? работает - не трожь!

фурье генерю питоновским модулем, правда нормированное, его перемасштабирование оказалось тем ещё развлечением

filin ★★ ()

Re: Управление триггером физической установки

ну вот, столько писал, старался, можно сказать нёс свет в массы, а обсудить не с кем, "многа букаф никто не асилил" что-ли?

filin ★★ ()

Re: Управление триггером физической установки

;%№*?"№!

наши сёня канадцев в хоккей пердолят за мировое золото, а я забылллл посмотреть, вот куда все делись!!

АААААА!!!!!!!

filin ★★ ()

Re: Управление триггером физической установки

> А вот и нет, 6e+04 куда нагладнее. Это журналисты любят писать, что Земля погибнет через 5000000000 лет и что была получена нанопроволока диаметром 0.000000001 м

А вот и да. Когда будет столько же нулей, сколько в 5000000000, вот тогда и переводи в e+XX. А на дву, трех, четырех можно и лучше обычные циферки рисовать :)

anonymous ()

Re: Управление триггером физической установки

> ну вот, столько писал, старался, можно сказать нёс свет в массы, а обсудить не с кем, "многа букаф никто не асилил" что-ли?

Не боись, перевариваем :) Зачет за работу.

anonymous ()

Re: Управление триггером физической установки

> библиотеку планирую выложить в публичный доступ попозже, когда она будет причёсана и написана документация

Хы, исходя из собственного субъективного опыта, вот на этой фразе обрывается путь к свободе 90% программ и библиотек :)

anonymous ()

Re: Управление триггером физической установки

Графики на Qwt рисуешь?

anonymous ()

Re: Управление триггером физической установки

> физической установки

Это Slackware? Русские физики выбирают только Slackware! :)

Bioreactor ★★★★★ ()

Re: Управление триггером физической установки

Интересно!
А почему не swig? Я пытался юзать ctype но для меня оказалось очень неудобной чтукой, swig всё же всё автоматизирует хорошо.

stalkerg ★★★★★ ()

Re: Управление триггером физической установки

> Графики на Qwt рисуешь?

да, уже лет 5 как, даже свою написал на её основе, но к сожалению до релиза не дошло, как сказал товарищ "исходя из собственного субъективного опыта, вот на этой фразе обрывается путь к свободе 90% программ и библиотек :)". Qwt умеет далеко не всё что потребно, а с ROOT'ом каждый раз наступаю на какие-нибудь его гланды при использовании в реальной жизни, а кто говорит что гланд нет, тот не использовал его по-настоящему :Е. Последний пример: в системе запуска заданий на кластере (SGE, но это не важно), ломались задания, написанные товарищем на питоне и использующие ROOT. Оказалось ROOT обнаруживал в окружении выставленную переменную DISPLAY (отнаследованную заданием из exec демона, который получил её при перезапуске в удалённой х-сессии), пытался коннектиться через неё, получал по ушам и ломал задание несмотря на то, что никакие окошки в задании не открываются. Workaround - удалять переменную DISPLAY до импорта рутовских модулей (либо в задании, либо при перезапуске exec демона). Разбираться пришлось часа три.

filin ★★ ()

Re: Управление триггером физической установки

> Хы, исходя из собственного субъективного опыта, вот на этой фразе обрывается путь к свободе 90% программ и библиотек :)

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

filin ★★ ()

Re: Управление триггером физической установки

всегда с уважением смотрел на тех, кто делает реальную работу :)

Ingwar ★★★★★ ()

Re: Управление триггером физической установки

когда выбирал вариант прошлой осенью, что-то меня насторожило в генераторах типа SIP и SWIG, кроме того вообще не хотелось писать интерфейсные файлы или приспосабливать хедеры:

"Eric S. Raymond(http://en.wikipedia.org/wiki/Eric_S._Raymond) в своей книге "Искусство Прграммирования в Unix"(http://en.wikipedia.org/wiki/The_Art_of_Unix_Programming) ... Правило Порождения(http://en.wikipedia.org/wiki/Code_generation): Избегай ручной работы, пиши программы, которые пишут программы когда можешь"

http://www.linux.org.ru/view-message.jsp?msgid=1125500&page=1

filin ★★ ()

Re: Управление триггером физической установки

> Русские физики выбирают только Slackware! :)

русские физики выбирают то, на чём в данный момент можно работать, VMS, Tru64 на ваксах и альфах, Solaris на спарках и тд, выбор дистрибутива GNU/Linux -- кому что нравится


"Eric S. Raymond(http://en.wikipedia.org/wiki/Eric_S._Raymond) в своей книге "Искусство Прграммирования в Unix"(http://en.wikipedia.org/wiki/The_Art_of_Unix_Programming)
...
* Правило Разнообразия: Не верь утверждениям 'единственно верный путь'"

http://www.linux.org.ru/jump-message.jsp?msgid=1125500&cid=1126188

filin ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.