• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

RTL8195A USBH (DWC OTG) + UVC

pvvx

Активный участник сообщества
Всё-же замучал lib_usbd.a, lib_usbh.a, lib_uvc.a ...
Пока успехи только в тестах получения картинки JPEG c USB-камеры отличной от типа, указанного у Ameba (она дороже модуля):)
Код:
===== Enter Image: Test UVC/USB ====
WdgPeriod = 10000 ms

CLK CPU         83333333 Hz
RAM heap        1274168 bytes
TCM heap        64768 bytes
>atuvc s

Wait_usb_ready = 0
UVC_probe -> Available heap 0x135778
v4l2_probe -> Available heap 0x1335d0
Init uvc stream = 0
unknown format--try MJPEG instead
uvc_v4l2_try_format:
select MJPG frame No.10 (320 * 240)
setting frame interval to 1/30
set frame interval 1/30
UVC set parameters = 0
vb2_streamon:
Streamon successful
Start UVC thrd...
Jpeg at 0x30000000[3413]:
[Addr]   .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
30000000 ff d8 ff db 00 84 00 05 03 04 04 04 03 05 04 04 ................
....
30000D50 95 23 3f ff d9                                  .#?..

Jpeg at 0x300249f0[3546]:
[Addr]   .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
300249F0 ff d8 ff db 00 84 00 05 03 04 04 04 03 05 04 04 ................
....
300257C0 d5 58 80 a5 eb cd 00 7f ff d9                   .X........

Jpeg at 0x300493e0[3529]:
[Addr]   .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
300493E0 ff d8 ff db 00 84 00 05 03 04 04 04 03 05 04 04 ................
....
3004A1A0 b5 25 5b 20 5a 29 0c ff d9                      .%[ Z)...

Jpeg at 0x3006ddd0[3546]:
[Addr]   .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
3006DDD0 ff d8 ff db 00 84 00 05 03 04 04 04 03 05 04 04 ................
....
Перекинуть на TFT, или по WiFi, сменить разрешение картинки и прочее проблем нет, т.к. используется урезанный UVC от Linux 3.xx ...
Поток видео ещё не "акклиматизировал" для других типов камер...
Возможно в скором добью до самой дешевой USB-web камеры с али без всяких там Jpeg-гов, за 140 рупь...
Omiky Advanced USB 2.0 50.0 М Камера ПК HD Веб Камера Веб Камеры для Ноутбуков Desktop 2017 1 ШТ. купить на AliExpress
Снимок1597.jpg
 
Последнее редактирование:

pvvx

Активный участник сообщества
В текущем варианте закрытых либ (цельно-тянутых из open-source исходников Linux) у Ameba поддерживается всего 1 формат и одна их любимая камера (Logitech C170 web cam).
В общем есть вопрос - стандартный UVC должен поддерживать Uncompressed YUV formats YUY2, NV12, ... но в реальных реализациях на Linux это есть? Или только получение картинки для "Uncompressed" ?
(*nix же всегда отстой? :) )
 

sharikov

Active member
В текущем варианте закрытых либ (цельно-тянутых из open-source исходников Linux) у Ameba поддерживается всего 1 формат и одна их любимая камера (Logitech C170 web cam).
В общем есть вопрос - стандартный UVC должен поддерживать Uncompressed YUV formats YUY2, NV12, ... но в реальных реализациях на Linux это есть? Или только получение картинки для "Uncompressed" ?
(*nix же всегда отстой? :) )
YUV2 в linux есть и точно поддерживается (проверял).
Усб камер с NV12 не встречал.
От этих форматов применительно к амебе толку ноль целых ноль десятых.
Софтверно несжатый формат больше 1-2 fps не тянет 400MHz arm926 с ddr2 памятью и нормальными кэшами. Посчитайте размер кадра YUV2.
Чтобы работать с несжатыми форматами видео нужно либо аппаратный кодер (с преобразованием форматов) либо процессор N Ghz.
 

pvvx

Активный участник сообщества
YUV2 в linux есть и точно поддерживается (проверял).
Усб камер с NV12 не встречал.
От этих форматов применительно к амебе толку ноль целых ноль десятых.
Софтверно несжатый формат больше 1-2 fps не тянет 400MHz arm926 с ddr2 памятью и нормальными кэшами. Посчитайте размер кадра YUV2.
Чтобы работать с несжатыми форматами видео нужно либо аппаратный кодер (с преобразованием форматов) либо процессор N Ghz.
А устраивает и 2 кадра 320x200. Это же не для просмотра человеком, а всякие датчики...
YUY2 - 4:2:2 -> 8bit. 320*200 = 64 килобайта кадр всего. WiFi у нас по TCP даже 1.2МБайта/сек...

В текущей реализации Ameba c JPG в 640x480 уже иногда (при качественной картинке и камере + коэф. сжатия - пока беру по умолчанию = 0) не хватает размера сегментов буферов USB:
Код:
UVC stream init...
UVC_probe -> Available heap 0x135a98
v4l2_probe -> Available heap 0x1338f0
Set video format information...
uvc_v4l2_try_format:
select MJPG frame No.1 (640 * 480)
setting frame interval to 1/30
set frame interval 1/30
Start camera...

vb2_streamon:
Streamon successful

Jpeg at 0x30000000[64172]
Вот уже размер картинки 64 кило. На больших разрешениях сразу кричит - каюк буферу (global_buf[]) с любой камерой:
Код:
uvc_v4l2_try_format:
select MJPG frame No.2 (1280 * 720)
setting frame interval to 1/30
set frame interval 1/30
Start camera...
vb2_streamon:
Streamon successful
uvc_video_decode_data:
Frame complete (overflow).
Jpeg at 0x30000000[150000]
Используется uint8_t global_buf[4][200000], описанный в uvc_queue.c . Пустого места ещё дофига: RAM heap 1267792 bytes - это не ESP :).
У нас же есть все заголовки:
RTL00_WEB\USDK\component\common\video\v4l2\inc
RTL00_WEB\USDK\component\common\drivers\usb_class\host\uvc\inc
RTL00_WEB\USDK\component\soc\realtek\8195a\fwlib\ram_lib\usb_otg\include
... (утекшие стараниями сборщиков MBED)
и т.д. В них и писано - что это сборка из www.usb.org/developers/devclass_docs/USB_Video_Class_1_1.zip, V4L2 driver helper framework,
USB Communications Device Class (CDC) definitions, //dwh/usb_iip/dev/software/otg/linux/drivers, master/host side Linux-USB kernel driver API ...
Ну а т.к. сами дрова USB стандартные (оболочка то уже есть), то проблем прикрутить что из linux не много... Дизасм->СИ либ показал 80% соответствие с исходниками от Linux, иначе бы и не полез - столько хламу "реверснуть" нереально...
 
Последнее редактирование:

pvvx

Активный участник сообщества
YUV2 в linux есть и точно поддерживается (проверял).
Такого нема в uapi_videodev2.h.
Усб камер с NV12 не встречал.
От этих форматов применительно к амебе толку ноль целых ноль десятых.
Софтверно несжатый формат больше 1-2 fps не тянет 400MHz arm926 с ddr2 памятью и нормальными кэшами. Посчитайте размер кадра YUV2.
Чтобы работать с несжатыми форматами видео нужно либо аппаратный кодер (с преобразованием форматов) либо процессор N Ghz.
Ну вот и фрейм от USB-Cam за 100 руб, остальное мало интересует :) :
Код:
uvc_v4l2_try_format:
select YUYV frame No.3 (320 * 240)
setting frame interval to 1/30
set frame interval 1/30
Start camera...

vb2_streamon:
Streamon successful

Frame at 0x30000000[104640]:
[Addr]   .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
30000000 50 66 52 90 57 64 3b 93 3d 6d 3c 8c 3a 6d 39 8e PfR.Wd;.=m<.:m9.
30000010 3a 6c 3b 8f 3f 6c 3c 90 3b 70 3a 8e 3d 6c 3f 90 :l;.?l<.;p:.=l?.

End Frame:
[Addr]   .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
300198A0 58 59 67 9a 60 5d 58 98 5d 5c 5a a1 53 5c 48 9b XYg.`]X.]\Z.S\H.
300198B0 41 69 3d 95 40 68 3b 94 39 6b 36 92 33 6e 33 92 Ai=.@h;.9k6.3n3.

uvc_stream_off.
Код:
                    uvc_ctx.fmt_type = V4L2_PIX_FMT_YUYV;
                    uvc_ctx.width = 320; // 320; // 640; // 1280;
                    uvc_ctx.height = 200; // 200; // 480; // 720;
                    uvc_ctx.frame_rate = 30;
                    uvc_ctx.compression_ratio = 0;

                    if(v4l_set_param(uvc_ctx.fmt_type, &uvc_ctx.width, &uvc_ctx.height, &uvc_ctx.frame_rate, &uvc_ctx.compression_ratio) < 0) {
...
Ограничения на форматы в Ameba в
Код:
int uvc_set_param(uvc_fmt_t fmt_type, int *width, int *height, int *frame_rate, int *compression_ratio) {
  int result;
  if ( fmt_type == 1 )
  {
    result = v4l_set_param(V4L2_PIX_FMT_MJPEG, width, height, frame_rate, compression_ratio); // 0x47504A4D "MJPG"
  }
  else if ( fmt_type == 2 )
  {
    result = v4l_set_param(V4L2_PIX_FMT_H264, width, height, frame_rate, compression_ratio); // 0x34363248 "H264"
  }
  else
  {
    DiagPrintf("\n\runknown format--try MJPEG instead");
    result = v4l_set_param(V4L2_PIX_FMT_MJPEG, width, height, frame_rate, compression_ratio); // 0x47504A4D "MJPG"
  }
  return result;
}
Цель то "спортивная" - WiFi Сam на RTL за дешево. :) Потом уже всё остальное, если взлетит и протоптать...
Дешевле указанной камеры на али пока не видел.

v4l2-ctl на OPI про неё USB2.0 PC CAMERA (1908:2311) пишет:
Код:
# v4l2-ctl --all
Driver Info (not using libv4l2):
        Driver name   : uvcvideo
        Card type     : USB2.0 PC CAMERA
        Bus info      : usb-sunxi-ehci-1
        Driver version: 1.1.1
        Capabilities  : 0x04000001
                Video Capture
                Streaming
Video input : 0 (Camera 1: ok)
Format Video Capture:
        Width/Height      : 640/480
        Pixel Format      : 'YUYV'
        Field             : None
        Bytes per Line    : 1280
        Size Image        : 614400
        Colorspace        : Default
        Transfer Function : Default
        YCbCr Encoding    : Default
        Quantization      : Default
Crop Capability Video Capture:
        Bounds      : Left 0, Top 0, Width 640, Height 480
        Default     : Left 0, Top 0, Width 640, Height 480
        Pixel Aspect: 1/1
Streaming Parameters Video Capture:
        Capabilities     : timeperframe
        Frames per second: 30.000 (30/1)
        Read buffers     : 0

# v4l2-ctl -D -d /dev/video0 --list-formats-ext
Driver Info (not using libv4l2):
        Driver name   : uvcvideo
        Card type     : USB2.0 PC CAMERA
        Bus info      : usb-sunxi-ehci-1
        Driver version: 1.1.1
        Capabilities  : 0x04000001
                Video Capture
                Streaming
ioctl: VIDIOC_ENUM_FMT
        Index       : 0
        Type        : Video Capture
        Pixel Format: 'YUYV'
        Name        : YUV 4:2:2 (YUYV)
                Size: Discrete 640x480
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.067s (15.000 fps)
                Size: Discrete 352x288
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.067s (15.000 fps)
                Size: Discrete 320x240
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.067s (15.000 fps)
                Size: Discrete 176x144
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.067s (15.000 fps)
                Size: Discrete 160x120
                        Interval: Discrete 0.033s (30.000 fps)
                        Interval: Discrete 0.067s (15.000 fps)
Cheap USB Web Camera teardown, analysis and examples
 
Последнее редактирование:

pvvx

Активный участник сообщества
Ни как не удается закрыть все USB/UVC - постоянно что-то остается в heap. Ameba походу вообще не предусмотрела deinit-ы и полное освобождение динамических и переинициализацию статических ресурсов данных драйверов... Поток принимается, но если остановить, то не перезапустить без перезагрузки.
Посчитайте размер кадра YUV2.
Пример потока в 352 * 288, 1665 фреймов (задаю в параметрах тестовой процедуры для new_console):
Код:
>atuvc 4 1665
USB init...
USB ID 2311:1908
UVC stream init...
UVC_probe -> Available heap 0x135fe0
v4l2_probe -> Available heap 0x134cf8
Set video format...
uvc_v4l2_try_format:
select YUYV frame No.2 (352 * 288)
setting frame interval to 1/1
set frame interval 1/15
--- Camera Control ---
 Brightness:
        max: 255 min: 0 step: 1
        current value: 128
 Contrast:
        max: 255 min: 0 step: 1
        current value: 130
 Saturation:
        max: 255 min: 0 step: 1
        current value: 64
 Hue:
        max: 127 min: -127 step: 1
        current value: 0
 Gamma:
        max: 8 min: 1 step: 1
        current value: 4
 Power Line Frequency:
        current value: 1
 Sharpness:
        max: 15 min: 0 step: 1
        current value: 13
 Backlight Compensation:
        max: 5 min: 1 step: 1
        current value: 1
Start camera...
vb2_streamon:
Streamon successful
329o-0e-0a-267n l-44% 30s-34MB
333o-0e-0a-0n l-0% 30s-34MB
333o-0e-0a-0n l-0% 30s-34MB
333o-0e-0a-0n l-0% 30s-34MB
333o-0e-0a-0n l-0% 30s-34MB // расшивровка DiagPrintf("\n\r%do-%de-%da-%dn %ds-%dMB", ok_cnt, err_cnt, async_cnt, nobuf_cnt, v16 / 1000, frame_size / 1024); в uvc_video_complete()
UVC Stream Free.
vb2_streamoff:
Streamoff successful
uvc_v4l2_release:
uvc_v4l2_release
v4l2_probe <- Available heap 0x134cf8
UVC_probe <- Available heap 0x135d20
USB deinit.
Т.е. имеем 34MБ в 30 секунд на 100 рублевой камерке в YUYV 352х288... При хороших условиях в эфире такой поток улетит по WiFi без сжатий.
А пока поток никуда не идет, только тест приема от uvc дров - надо доковырять ещё много мелочи.
При этом, что есть по производительности:
Код:
CPU total run time is 75685
TaskName        DeltaRunTime    percentage
loguart         209             <1%
IDLE            75115           99%
TCP_IP          0               <1%
uvc_prb_t       55              <1%
USB_OTG_T       37              <1%
Tmr Svc         0               <1%

Task List:
==================================================
Name      Status Priority HighWaterMark TaskNumber
loguart         R       4       699     5
IDLE            R       0       39      2
uvc_prb_t       B       2       1811    10
TCP_IP          B       9       951     4
USB_OTG_T       B       5       797     8
Tmr Svc         S       1       480     3
 
Последнее редактирование:

pvvx

Активный участник сообщества
Полупечальные итоги с UVC на сегодня:

Примеры из пакетов к UVC Linux работают на 80%.

К примеру копирование кусков и малые замены не тяжелых процедур из v4l-utils/utils/v4l2-ctl at master · gjasny/v4l-utils · GitHub
приводят к полному перечню характеристик web-камеры (расширенный и заточенный на требуемое применение аналог команды [inline]v4l2-ctl --list-formats-ext[/inline]).
Для камеры (USB ID: 045e:075d) Microsoft LifeCam Cinema:
Код:
> atuvci
USB init...
USB ID 75d:45e
UVC stream init...
UVC_probe -> Available heap 0x134ff8
v4l2_probe -> Available heap 0x132e50

--- Camera Control ---

 Brightness:
        max: 255 min: 30 step: 1
        current value: 133
 Contrast:
        max: 10 min: 0 step: 1
        current value: 5
 Saturation:
        max: 200 min: 0 step: 1
        current value: 83
 White Balance Temperature, Auto:
        max: 1 min: 0 step: 1
        current value: 1
 Power Line Frequency:
        current value: 1
 White Balance Temperature:
        max: 10000 min: 2800 step: 1
        current value: 2800
 Sharpness:
        max: 50 min: 0 step: 1
        current value: 25
 Backlight Compensation:
        max: 10 min: 0 step: 1
        current value: 0

--- Camera Formats ---

Video Capture 0: Pixel Format: 'YUYV', YUV 4:2:2 (YUYV)
 Size: Discrete 640x480
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 1280x720
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 960x544
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 800x448
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 640x360
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 424x240
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 352x288
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 320x240
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 800x600
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 176x144
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 160x120
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 1280x800
  Discrete: 10 fps

Video Capture 1: Pixel Format: 'MJPG', MJPEG
 Size: Discrete 640x480
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 1280x720
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 960x544
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 800x448
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 640x360
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 800x600
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 416x240
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 352x288
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 176x144
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 320x240
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
 Size: Discrete 160x120
  Discrete: 30 fps
  Discrete: 20 fps
  Discrete: 15 fps
  Discrete: 10 fps
  Discrete: 7 fps
USB Stop.
>
Можно и такое [inline]dwc_otg_hcd_dump_state()[/inline] (dwc - дрова USB) (пример кода dwc_otg/dwc_otg_hcd.c at master · nfeske/dwc_otg · GitHub ) :
Код:
>atusbi
USB hub reset...

************************************************************
HCD State:
  Num channels: 5
  Channel 0:
    dev_addr: 2, ep_num: 0, ep_is_in: 0
    speed: 2
    ep_type: 0
    max_packet: 64
    data_pid_start: 3
    multi_count: 1
    xfer_started: 0
    xfer_buff: 0x10060c2c
    xfer_len: 8
    xfer_count: 0
    halt_on_queue: 0
    halt_pending: 0
    halt_status: 0
    do_split: 0
    complete_split: 0
    hub_addr: 0
    port_addr: 0
    xact_pos: 0
    requests: 1
    qh: 0x100041a8
  Channel 1:
    dev_addr: 2, ep_num: 0, ep_is_in: 1
    speed: 2
    ep_type: 0
    max_packet: 64
    data_pid_start: 2
    multi_count: 1
    xfer_started: 0
    xfer_buff: 0x10061120
    xfer_len: 64
    xfer_count: 0
    halt_on_queue: 0
    halt_pending: 0
    halt_status: 0
    do_split: 0
    complete_split: 0
    hub_addr: 0
    port_addr: 0
    xact_pos: 0
    requests: 1
    qh: 0x100041a8
  Channel 2:
    dev_addr: 2, ep_num: 0, ep_is_in: 0
    speed: 2
    ep_type: 0
    max_packet: 64
    data_pid_start: 2
    multi_count: 1
    xfer_started: 0
    xfer_buff: 0x10003dc0
    xfer_len: 0
    xfer_count: 0
    halt_on_queue: 0
    halt_pending: 0
    halt_status: 0
    do_split: 0
    complete_split: 0
    hub_addr: 0
    port_addr: 0
    xact_pos: 0
    requests: 1
    qh: 0x100041a8
  Channel 3:
    dev_addr: 2, ep_num: 0, ep_is_in: 1
    speed: 2
    ep_type: 0
    max_packet: 64
    data_pid_start: 2
    multi_count: 1
    xfer_started: 0
    xfer_buff: 0x10061130
    xfer_len: 64
    xfer_count: 0
    halt_on_queue: 0
    halt_pending: 0
    halt_status: 0
    do_split: 0
    complete_split: 0
    hub_addr: 0
    port_addr: 0
    xact_pos: 0
    requests: 1
    qh: 0x100041a8
  Channel 4:
    dev_addr: 2, ep_num: 0, ep_is_in: 0
    speed: 2
    ep_type: 0
    max_packet: 64
    data_pid_start: 2
    multi_count: 1
    xfer_started: 0
    xfer_buff: 0x10003dc0
    xfer_len: 0
    xfer_count: 0
    halt_on_queue: 0
    halt_pending: 0
    halt_status: 0
    do_split: 0
    complete_split: 0
    hub_addr: 0
    port_addr: 0
    xact_pos: 0
    requests: 1
    qh: 0x100041a8
  non_periodic_channels: 0
  periodic_channels: 0
  NP Tx Req Queue Space Avail: 0
  NP Tx FIFO Space Avail: 0
  P Tx Req Queue Space Avail: 0
  P Tx FIFO Space Avail: 0
************************************************************

USB Stop.
>
но это никакой надобности не имеет, кроме тестов...
Всякие потоки video-capture запускаются и как-то работают, но сбоят.
И проблемки сбоев такие:
В доке по RTL8195A объява, что уровни D+ и D- USB в 500 mV, а замер дает значительно меньшие амплитуды при подключении USB устройства. Есть какой-то резистор, подключаемый к ножке чипа, но до него пока не добрался... Возможно, что и попался какой глючный модуль, но пока нет времени на перепайку его...
Снимок1602.gif
Снимок1603.gif
Так-же ещё сидят какие-то глюки в совте и дрова виснут (нет проверок на то, что устройство отключилось или сбойнуло, а дешевые камеры только так и пашут. Ameba и UVC в лунихе применяют подход Arduino - работает только под наблюдением и если всё OK - иначе, если какой сбой, пользователь обязан перезагружать систему :)).
Кто поможет всё это до-расковырять и привести в нормальный вид?
В нормальном виде надо долепить полное освобождение ресурсов после работы USB/UVC и полное отключение USB контроллера + возможность возобновления и пересброса устройств на USB и самого хоста. Этих частей в закрытых либах нет - всё писано для Arduino, а в ней не принято иметь деинициализаций устройств на ходу :)
Код:
Disassembly of section .text._usb_deinit:
00000000 <_usb_deinit>:
   0:    4770          bx    lr
Disassembly of section .text.usb_lowlevel_stop:
00000000 <usb_lowlevel_stop>:
   0:    2000          movs    r0, #0
   2:    4770          bx    lr
PS: Ameba API над UVC уже выкинул - он ограничивает всё на свете под их любимые камеру, dev-board и их хотелки... Оно мало кому нужно, т.к. есть дрова USB Host с ioctl (в Android аналогичные) + почти стандартный UVС c ioctl (на всё это документации в инете море). Верхний уровень можно и проще заимствовать с мелкими поправками из линух приложений.
 
Последнее редактирование:

pvvx

Активный участник сообщества
Работают конструкции такого плана:
Код:
int _uvc_get_user_ctrl(struct v4l2_control *user_ctrl) {
    struct v4l2_queryctrl queryctrl;
    int result;
    struct video_device *vdev = video_devdata();

    memset(&queryctrl, 0, sizeof(queryctrl));

    queryctrl.id = user_ctrl->id;

    if (!vdev->fops->unlocked_ioctl(VIDIOC_QUERYCTRL, &queryctrl)) {
        printf("\r\n %s:\n", queryctrl.name);
        if (!(queryctrl.flags & 1) && queryctrl.type != 3)
            printf("\tmax: %d min: %d step: %d\n", (int) queryctrl.maximum, (int) queryctrl.minimum, (int) queryctrl.step);
    }
    result = vdev->fops->unlocked_ioctl(VIDIOC_G_CTRL, user_ctrl);
    if (!result) {
        printf("\tcurrent value: %d\n", (int) user_ctrl->value);
    }
    return result;
}

int _uvc_set_user_ctrl(struct v4l2_control *user_ctrl) {
    return video_devdata()->fops->unlocked_ioctl(VIDIOC_S_CTRL, user_ctrl);
}

void uvc_chow_camera_ctrl(void)
{
    {
        printf("\r\n--- Camera Control ---\n");
        struct v4l2_control uctrl;
        uint32 id;
        for (id = V4L2_CID_BASE; id < V4L2_CID_LASTP1; id++) {
            uctrl.id = id;
            _uvc_get_user_ctrl(&uctrl);
        }
    }
}
RTL00MP3/uapi_videodev2.h at master · pvvx/RTL00MP3 · GitHub
 

pvvx

Активный участник сообщества
Удалось немного стабилизировать потерю камер путем подключения более мощного БП и перепайке разъема USB-Host. Некоторые камерки запросто потребляют за 200 mA и более.
PC CAMERA (1908:2311 - та которая самая дешевая) сама сняла своё потребление (YUYV frame, 160x120) и передала в потоке по TCP:
Снимок1607.jpg
Но присутствующие сбои в потоке дров usbh.a пока не удалось локализовать и запатчить...:(
Проявляются они, как битые линии на кадре, выдернутые из другого куска:
Снимок1608.jpg
Что-то сбоит в Ameba дровах...
 

pvvx

Активный участник сообщества
Текущие баги драйвера UVC USB...
Просмотр в raw-yuvplayer записи 1000 кадров по TCP в режиме потока YUYV 160 * 120 c дешевой USB-web камеры, указанной в первом сообщении темы.

Размер одного фрейма (кадра) в байтах YUYV равен width*height*2.
160*120 -> 38400 байт (37.5 кбайт)
640*480 -> 614400 байт (600 кбайт)
Драйвер USB-UVC от Ameba, по непонятным причинам, ограничен на кадр до сотни кбайт.
При этом использует буфер в uint8_t global_buf[4][200000] (4 по 200 кило)...
При увеличении размера кадра не справляется с трафиком от камеры и "полосит" - где-то нарушается атомарность сборки пакетов от USB в буфера. Надо переделывать на скипание фреймов/кадров, если USB не успевает "распарсить" поток, хотя статистика подсчета принятых байт в UVC уходит за более пары мегабайт в сек...
--------------
Исходники данного теста UVC “как есть” для RTL8195A: RTL00_UVC20170925.zip
Использует SDK из GitHub - pvvx/RTL00MP3: RTL00(RTL8710AF) Test MP3
В коде правиться IP компа, транслируем и запускаем в RAM модуля. Устанавливаем соединение с AP, на компе запускается \RTL00_UVC\windows\yuyv_tcp_server.exe, в console модуля дается команда “atrfm 100” – передать 100 фреймов. Программой yuvplayer.exe смотрим что принялось, установив параметры потока (YUYV и 160 * 120).
 
Последнее редактирование:

pvvx

Активный участник сообщества
Вывести картинки на WEB странице модуля можно, но надо конвертор на javascript.
Кто может предложить преобразователь YUYV на javascript (не только для классов Android, но и для PC)?
 

pvvx

Активный участник сообщества
Может всё таки кто подскажет, куда копать по поводу "полосатостей" в UVC с данным драйвером от Ameba и самой дешевой USB-Web-Cam?
А то пока не дается... :(
Размер кадра принятого с USB в норме, но нарушены некоторые пиксели в фрейме кадра...
Длина сбитых данных явно не равна длине делений на фреймы передач по USB... Толи кто-то сбивает DMA, то-ли ещё влияют какие прерывания с уровнем приоритетов в RTOS... В общем - пока загадка и примитивными изменениями не корректируется.
Проверки на согласование либ с Ameba Arduino так-же не выдали ничего хорошего, кроме массы других багов и ограничений, особенно в настройках параметров Lwip для передачи на статические, сильно ограниченные буфера на пару кило, когда чип имеет два мегабайта свободной памяти :) У Ameba для Arduino и Mbed всё такое, ограниченное и не дописанное...
 
Последнее редактирование:

sharikov

Active member
Может всё таки кто подскажет, куда копать по поводу "полосатостей" в UVC с данным драйвером от Ameba и самой дешевой USB-Web-Cam?
А то пока не дается...
1 отключить совсем wifi и другую периферию. одиночный кадр класть в озу и сливать по uart
2 проверить где размещаются дескрипторы усб контроллера. если в sdram - перенести в sram
3 проверить где размещаются обработчики прерываний usbh. перенести их в tcm sram. попытаться перенести в tcm весь код который участвует в приеме кадра
4 на другом hs устройстве например флэшке с заведомо известным содержимым убедиться что bulk transfer работает исправно (сутки непрерывного чтения без ошибок данных). выполнить то же при активном обмене wifi.
5 не терять время понапрасну. например imx25 c памятью ddr2 тоже не тянет несжатый yuv2 поток с usb камеры - не хватает пропускной способности памяти при конкурируещем доступе. модули на mt7688an c 64м ddr2 памятью стоят на 1,5-2 доллара дороже 8195.
 

pvvx

Активный участник сообщества
1 отключить совсем wifi и другую периферию. одиночный кадр класть в озу и сливать по uart
2 проверить где размещаются дескрипторы усб контроллера. если в sdram - перенести в sram
3 проверить где размещаются обработчики прерываний usbh. перенести их в tcm sram. попытаться перенести в tcm весь код который участвует в приеме кадра
4 на другом hs устройстве например флэшке с заведомо известным содержимым убедиться что bulk transfer работает исправно (сутки непрерывного чтения без ошибок данных). выполнить то же при активном обмене wifi.
5 не терять время понапрасну. например imx25 c памятью ddr2 тоже не тянет несжатый yuv2 поток с usb камеры - не хватает пропускной способности памяти при конкурируещем доступе. модули на mt7688an c 64м ddr2 памятью стоят на 1,5-2 доллара дороже 8195.
У меня в том-то и интерес, чтобы запустить самую фиговую и дешевую web камерку :)
С MJPEG камерами по rtsp всё проще, даже в rtlDuino при отладке-загрузке и в RAM работает:
Жрут только камеры с MJPEG много - за 120 мА.
А с показанной в видео, висящей на проводе дешевой камерой с YVUV, что-то не хочет - полосит при самом малом потоке 160x120 и не более 15 кадров в сек... Скорее всего что-то в самих кодах USB/UVC. Амеба их настроили только для своей камеры и возможно что вписали для коррекции сборки фреймов - они и не катит для YVUV...
Увеличением размера фрейма для увеличения размера кадра к YVUV ещё не занимался - но там всё проще - надо только время на дизасм->си для правки размеров жестко прописанных буферов и объявления uint8_t global_buf[6][150000] в uvc_queue.с...
На других модулях показанные 2 камеры вообще не работают. На RPI или любом *nix - тоже. (На Ameba Arduinio - так-же не пашут) :p Не катят там настройки или ещё чего в линкусовском варианте UVC (но устойчиво пашут в Win-де :)). И надо сделать на расчет RAM до 2-х МБ, потому без разницы где копать - в вашем модуле или в RTL-ке...
 
Последнее редактирование:

sharikov

Active member
На других модулях показанные 2 камеры вообще не работают. На RPI или любом *nix - тоже. (На Ameba Arduinio - так-же не пашут) :p Не катят там настройки или ещё чего в линкусовском варианте UVC (но устойчиво пашут в Win-де :)).
Пишут что на RPI 1908:2311 работают
Pi Zero works with 3 USB cameras and ethernet - Raspberry Pi Forums
 

pvvx

Активный участник сообщества
Они видимо бывают разные - с MJPEG и без :) Китайцы же на али их продают по разной цене...
Многие пишут, что они глючат. Та, что у меня - надо заводить, типа в ней есть EEPROM и без начальных предварительных танцев с бубном не всегда работает. Вторая - аналогично - сначала надо включить в родное ПО и выставить режим, потом работает и на роутере....
Ну а т.к. решил поковыряться в UVC и урезать его с RTSP до пары МБ, то данные камерки = самое то :)

На модулях с 128 МБ DRAM тоже проблемы, но иного плана Захват видео с USB камер на устройствах под управлением Linux :)

Побочно выявилось, что в Ameba Arduino и SDK, Ameba даже не может настроить Lwip на RTL8195A.
Банальная передача фрейма кадра в TCP сокет не пашет из-за установленных в его опциях ограничений на статические буфера:
lwip_write(remote_fd, vfrmb.pbuf, vfrmb.frame_size);
На этом просто виснет (и это при свободных более 1,5МБ Heap). Можно передавать только кусочками:
Код:
                    int x = vfrmb.frame_size;
                    unsigned char * pch = vfrmb.pbuf;
                    while(x) {
                        if(x > 2*TCP_MSS) {
                            lwip_write(remote_fd, pch, 2*TCP_MSS);
                            pch += 2*TCP_MSS;
                            x -= 2*TCP_MSS;
                        } else {
                            lwip_write(remote_fd, pch, x);
                            x = 0;
                        }
                    }
На борьбу и исправление таких глупостей всё время и уходит при расковыривании того, что надо добыть...
 
Последнее редактирование:

sharikov

Active member
Они видимо бывают разные - с MJPEG и без :) Китайцы же на али их продают по разной цене...
Многие пишут, что они глючат. Та, что у меня - надо заводить, типа в ней есть EEPROM и без начальных предварительных танцев с бубном не всегда работает. Вторая - аналогично - сначала надо включить в родное ПО и выставить режим, потом работает и на роутере....
Заказал вашу камеру марки говно по ссылке на али вверху.
Камеры с одинаковым vid /pid не могут быть разными. А дефектными - запросто.

На борьбу и исправление таких глупостей всё время и уходит при расковыривании того, что надо добыть...
Вот именно!
Вместо создания продукта 90% времени тратится на обход багов, и недоделок и глупостей sdk. На*й такой модуль нужен ? Деньги заказчик платит не за ковыряния а за результат (по крайней мере мне).
 

pvvx

Активный участник сообщества
Вот именно!
Вместо создания продукта 90% времени тратится на обход багов, и недоделок и глупостей sdk. На*й такой модуль нужен ? Деньги заказчик платит не за ковыряния а за результат (по крайней мере мне).
А есть другие предложения, где полностью существует рабочее SDK на WiFi SoC с полной поддержкой возможностей внутренних потрохов?
Я пока не встречал, даже по космической цене за SDK.
В случае с RTL8195 есть кучка из SDK и возможность всё это осилить одному для решения требуемой задачи, а вот с другими такой постановки вопроса нет. Если что не так, то даже оф. поддержка особо платной SDK не спасет по срокам. Они не будут модифицировать алгоритмы под ваши хотелки и вместо решения задачи вам придется заняться поиском вариантов на других модулях, у других производителей и довольствоваться другими ограничениями. :)
Вспоминайте хотя бы пример, на что был способен ESP8266 после появления в течении первого года: Только на глюки и перегрев до выхода из строя, а чтобы собрать какой пример на нем, требовался большой бубен и долгая пляска с ним :)
С RTL-ками начальная ситуация во многих аспектах лучше.
Заказал вашу камеру марки говно по ссылке на али вверху.
Камеры с одинаковым vid /pid не могут быть разными. А дефектными - запросто.
vid:pid китайцам не указ. Какой хотят, такой и впишут, если есть возможность.
А тут случай аналогичный - нет полного даташита на контроллер данной камерки. Т.е. опять ваше Вот именно! :)
С другой камерой, тоже самое. Стандартный UVC выскакивает, не дождавшись ответа от неё совсем немного. Видимо разный подход при включении передачи потока - она его начинает выводить, когда застабилизируется после включения, на что уходит много времени - от пару сек. Так-же ей надо предварительно дать нестандартные команды переключения в режим например поддержки JPEG если до этого она работала в YVUV, иначе вообще не будет включать выдачу потока. Команды не уточнял, т.к. есть её софт на винде и он это переключает. Но это выяснил уже в результате копаний с RTL.

Первый кадр у дешевой камеры выдается почти сразу, после переключения в режим вывода потока, но он ужасен, как и последующие - яркость стабилизируется построчно (начало кадра черное, далее просветление, может быть и нарушена синхронизация оцифровки по строкам от самой матрицы) и более менее адаптация на яркость и изображение происходит только после N-кадров отработки её потрахов. Т.е. просто включить её для съема одного кадра и вырубить не выйдет, что сильно ограничивает автономные устройства... Это значит, что требуются опять танцы с бубном. Например, если съемка стационарна, то предварительное задание параметров с прошлой съемки может ускорить вывод уже нормального кадра при отключенной авто-яркости и т.д. ...
@sharikov А по вашему надо искать другой SDK и контроллер с более 300 МБ DDRAM, чтобы уменьшить потребление автономного устройства? :) Между прочим про настройки LwIP указал именно для вас. Был уже разбор полетов про это, и именно вы используете у LwIP статические буфера в своих примерах, что не годиться для многих применений и требует дополнительной пляски с бубном при наличии динамической "кучи" к 2МБ в SDRAM у RTL8195. Т.е. смысл в LwIP socket теряется. В моих вариантах SDK и rtlDuino в LwIP изначально используются динамические буфера и размеры передаваемых socket-ом блоков данных ограничены имеющейся набортной RAM.
Аналогично надо переписать и UVC на RTL - на использование динамических буферов, иначе текущие ограничения не дают возможности работать с YVUV, а при использовании MJPEG камер бездарно отъедают RAM от других задач.
 
Последнее редактирование:

pvvx

Активный участник сообщества
Заказал вашу камеру марки г по ссылке на али вверху.
Не пашет в Omega2+
MicrosoftВ® LifeCam Cinema(TM) работает, но у неё режим со сжатием есть...
Только вот жрет это всё неприлично:
Снимок1637.jpg
Голый модуль Omega2p + камера с JPEG 1280x720 30 FPS по установкам, а FPS на выходе WiFi пока не смотрел (не интересно для сжатого камерой видео)... и звука нет, хотя в камере есть :)
 
Последнее редактирование:

pvvx

Активный участник сообщества
В общем добаловался.
Слепил себе и в своем rtlDuino тестик на этой дешманской камере...
RTL8195A_UVC_YUYV.gif
Передает по TCP пачками по 100 кадров видео в фрейме/файле...
В rtlDuino это выходит в поток по WiFi TCP ~300КБ сек и 8 кадров в сек. Кадры пропускает, т.к. написано последовательным циклом: запрос кадра и передача, запрос нового текущего кадра и передача... А дрова USB-UVC принимают каждый кадр от камеры...
Далее буду подключать вывод на TFT видео с этой камеры...
Дешманская камера кушает 80mA 5V. При её максимальном потоке и разрешении, как и средние пиковые токи - к 110 mA. MJPEG камеры кушают со средними пиками за 800 mA. Точно эти значения не измерял, но если на БП поставить ограничение в 700 mA, то большинство MJPEG камерок валятся при инициализации.
----
Может кто подкинет javascript приема по websocket потока YUYV и вывода в окно? Пусть хоть пару маленьких кадров в сек :)
 
Последнее редактирование:
Сверху Снизу