Последние сообщения

Я вот тоже сегодня эти архивы скачал. Распаковал в QNX 6.3. И... а что с ними дальше делать?  Там есть всякие скрипты типа INSTALL. Но этот скрипт при запуске ругается на строку с shift 2. Что это значит, я не знаю. Если эту строчку удалить, то скрипт просто завершает свою работу и всё. Ничего не происходит. Такая же фигня с приложениями из каталогов bin. Они ничего не делают.  Просто завершаются и всё. Если им скормить произвольные строчки, то бывает и завершаются аварийно. Копирование всего этого добра в штатные папки каталога /usr ничего не изменило - как не работало, так и не работает.
Вот что с этой фигнёй делать-то нужно?  Или она принципиально только для QNX 6.5 и на 6.3 и не запустится вовсе?

Понятно, в чём дело. 64 - максимальный размер пакета для LowSpeed и FullSpeed. А для HeighSpeed максимальны размер 512.

При включении broadcast траффика на соседней машине, мгновенно умирает сетевой интрефейс на qnx 6.6.0 (core i5). Проверял на devnp-e1000.so и devnp-rtl8169.so.
При этом USB Ethernet dongle на этой же машине в этой же сети остается живой.
С него подключаюсь и делаю
ifconfig wm0 down
ifconfig wm0 up
и если снять траффик гигибитный интерфейс начинает отвечать.
Как с этим бороться?

[wMaxPacketSize 0x0200 1x 512 bytes]

А не знает ли кто, как может сложиться следующая ситуация: я подключил этот тепловизор к stm32f4 Discovery к USB-Host. Проект я создал в CubeMX. То есть, вся обвязка USB там точно верная. Проблема в том, что тепловизор в дескрипторе конечной точки передаёт wMaxPacketSize=0x40. И это не управляющие точки. Однако, операционным системам тепловизор по usb -vvv и lsusb -vvv сообщает о конечных точках вот что:


Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    240
      bInterfaceProtocol      1
      iInterface              6 com.flir.rosebud.fileio
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
       wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1

То есть, операционным системам тепловизор рапортует о 512 байтах. А микроконтроллеру о 64. Это вообще как так может быть? Я обыскал всю библиотеку USB для STM32 и не нашёл ничего такого, что могло бы так повлиять на решение тепловизора выдавать такие параметры. Там обычная энумерация с получение дескрипторов конфигураций и устройства и задание адреса устройства. Но что-то же заставило тепловизор выдать 64, а не 512 байт? Использую я режим USB Full Speed, 12 МБ/c. Кстати, а никто не знает, запрос SET_DESCRIPTOR позволит изменить параметры конечной точки (и вообще, для чего он применяется? В инете его что-то не используют). Я бы оставил бы это всё без внимания, но на 64 байтах я не успеваю принять все данные, хотя у контроллера аж 168 МГц частота и он вроде бы должен успевать (хотя тут и PC пропускал кадры с радостью под Linux). А конечная точка в 512 байт, думаю, позволила бы пропускать кадры гораздо реже.

Из документации на утилиту spooler


Options:
...
-g
Make the printer a global network resource.

Какие особенности и возможности дает запуск spooler с ключом -g?

спасибо

Не могли бы Вы подтвердить или опровергнуть мой тест своим независимым тестированием?

Спасибо

Не могу с Вами согласиться насчет "ошибок в QNX".

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

Не могу с Вами согласиться насчет "ошибок в QNX".

Надеюсь что мой пример независимо проверят и опровергнут.

Проблему действительно обошел "с другой стророны"...

Я так понимаю, вам просто интересно, почему так, и реальной проблемы нет?
Возможно, просто ошибка в системе. В QNX тоже должны быть ошибки - куда ж без них?

Если файл закрыть, или открывать файл на "своем", а не удаленном
контроллере, то проблемы не возникает.

Проблема при открытом "через сеть" файле ...