ひでみのアイデア帳 2018-09-26T14:46:14+09:00 urn:uuid:32c34578-c4da-8d90-5f18-1740239359ee Ultra96でUbuntuのXウィンドウ表示に挑戦してみた urn:uuid:83a4ed17-de42-2fe5-bc5c-c7b17b553235 Ultra96でUbuntuのXウィンドウ表示に挑戦してみた

FPGAの部屋@marsee101さんがUltra96でDebianとWLANが動かせたということでほったらかしにしていたUbuntuでのWLANを確認したら動作した。

何に引っかかってたか?

よくわからな良いけどwpa_supplicantの設定をミスってたようで・・・

ただ、それだけでした。

Xorgを立ち上げてみるか・・・

WLAN繋がればaptできるので、インストールできる手間が一気に解消される。

そこで、XorgをインスコしてGUIを表示できないか挑戦してみた。

Ultra96のUbuntu環境は16.04.5LTSをベースファイルから構築している。

Xorgインスコしたけどarmsocドライバが無い

インスコしているUbuntuはarm64版でXorgはインスコできるんだけど、armsocドライバがない。

armsocドライバは探してみるとarmhf版しかない。

???

64bit版でドライバが変わったのかな?

apt sourceでソースコードをダウンロードしてビルドしようとしても64bitではサポートしていないというエラーが発生。

どうしたものかな・・・

Xilinxのデモイメージ

ソースコード解析職人の@VengineerからXilinxの「OpenGLWESのデモ」でX-Windowのデモがあると教えてもらったのでUltra96で試してみたら・・・

  • Ubuntu 15.04
  • とにかく、GUIの操作が重い!
  • xorg.confの設定はarmsocドライバを使用

深くは追いかけなかったがUbuntuでarmsocドライバできるのは現時点でarmhfしか選択肢がない。

じゃぁ、YoctoでX-Windowビルドしたら?

Yoctoもcore-image-satoでX-Windowを構築できるので試してみると、Xorgのドライバはarmsocだった。

ただし、Yoctoはフルビルド環境なのでarmsocドライバもビルドしていたので特に問題ない。

まとめ

Ubuntu 64bit環境にはXorgのarmsocドライバが無いので64bit環境でX-Windowを立ち上げるのはほぼ不可能なのかな?

XilinxのようにOpenGLESを使用するためだけdのGUI表示だけであれば、32bit環境でも良いのだけど、ウィンドウ操作が重いのを見るだけで、無理に32bit環境使う必要もないんじゃない?

と、諦めた。

]]>
2018-09-24T10:00:58+09:00 ひでみ hidemi@sweetcafe/jp <h1>Ultra96でUbuntuのXウィンドウ表示に挑戦してみた</h1> <p><a href="http://marsee101.blog19.fc2.com/">FPGAの部屋</a>の<a href="https://twitter.com/marsee101">@marsee101</a>さんがUltra96でDebianとWLANが動かせたということでほったらかしにしていたUbuntuでのWLANを確認したら動作した。</p> <h2>何に引っかかってたか?</h2> <p>よくわからな良いけどwpa_supplicantの設定をミスってたようで・・・</p> <p>ただ、それだけでした。</p> <h2>Xorgを立ち上げてみるか・・・</h2> <p>WLAN繋がればaptできるので、インストールできる手間が一気に解消される。</p> <p>そこで、XorgをインスコしてGUIを表示できないか挑戦してみた。</p> <p>Ultra96のUbuntu環境は16.04.5LTSをベースファイルから構築している。</p> <h2>Xorgインスコしたけどarmsocドライバが無い</h2> <p>インスコしているUbuntuはarm64版でXorgはインスコできるんだけど、armsocドライバがない。</p> <p>armsocドライバは探してみるとarmhf版しかない。</p> <p>???</p> <p>64bit版でドライバが変わったのかな?</p> <p>apt sourceでソースコードをダウンロードしてビルドしようとしても64bitではサポートしていないというエラーが発生。</p> <p>どうしたものかな・・・</p> <h2>Xilinxのデモイメージ</h2> <p>ソースコード解析職人の<a href="https://twitter.com/Vengineer">@Vengineer</a>からXilinxの「<a href="http://www.wiki.xilinx.com/Zynq+UltraScale%EF%BC%8B+MPSoC+Ubuntu+part+2+-+Building+and+Running+the+Ubuntu+Desktop+From+Sources">OpenGLWESのデモ</a>」でX-Windowのデモがあると教えてもらったのでUltra96で試してみたら・・・</p> <ul> <li>Ubuntu 15.04</li> <li>とにかく、GUIの操作が重い!</li> <li>xorg.confの設定はarmsocドライバを使用</li> </ul> <p>深くは追いかけなかったがUbuntuでarmsocドライバできるのは現時点でarmhfしか選択肢がない。</p> <h2>じゃぁ、YoctoでX-Windowビルドしたら?</h2> <p>Yoctoもcore-image-satoでX-Windowを構築できるので試してみると、Xorgのドライバはarmsocだった。</p> <p>ただし、Yoctoはフルビルド環境なのでarmsocドライバもビルドしていたので特に問題ない。</p> <h2>まとめ</h2> <p>Ubuntu 64bit環境にはXorgのarmsocドライバが無いので64bit環境でX-Windowを立ち上げるのはほぼ不可能なのかな?</p> <p>XilinxのようにOpenGLESを使用するためだけdのGUI表示だけであれば、32bit環境でも良いのだけど、ウィンドウ操作が重いのを見るだけで、無理に32bit環境使う必要もないんじゃない?</p> <p>と、諦めた。</p>
Vivado 2018.2でDPI-C urn:uuid:220c363e-176f-c3cb-c5a4-e14ca85be869 Vivado 2018.2でDPI-C

前に書いたのがVivado 2017.2版だったのでVivado 2018.2で良いこと起こってないか確認してみました。

でも、特に変わってなかった・・・

参照

Vivado 2018.2のDPI-C

 Vivado 2018.2のDPI-Cの対応状況はユーザーガイド(UG900)の「Vivadoシミュレータのダイレクトプログラミングインターフェイス(DPI)」を参照して下さい。

 DPI-Cを使用するにはxscコンパイラを使用し、xscがclang、GNUリンカを呼び出しコンパイルすることができます。

SystemVerilogの合成可能なセット

 ユーザーガイド(UG900)の「付録B:Vivado シミュレータのSystemVerilogサポート」でVivadoのシミュレータがサポートしているSystemVerilogの合成可能なセットの一覧が「表B-1:SystemVerilog 1800-2009の合成可能なセット」として示されています。

 また、「表B-2:サポートされるダイナミック タイプ コンストラクト」でシミュレーションでよく使用されるテストベンチの機能の一部がサポートされています。

xsc

xscはシミュレーションで使用するCソースコードをコンパイルするコンパイラです。

一撃コンパイル

$ xsc function.c
$ xelab -svlog file.sv -sv_lib dpi

二段階コンパイル

$ xsc -compile function.c -work sample
$ xsc -link sample/function.lnx64.o -work sample

CとSysnemVerilogの境界で使用可能なデータ型

SystemVerilog C 備考
byte char
shortint short int
int int
longint long long
real double
shortreal float
chandle void *
string const char *
bit unsigned char sv_0、sv_1

svdpi.hを使用した場合で使用可能なデータ型

SystemVerilog C 備考
logic、reg unsigned char sv_0、sv_1、sv_z、sv_x
bitの配列(パック型) svBitVecVal svdpi.hで定義
logic/regの配列(パック型) svLogicVecVal svdpi.hで定義
enum enum
パック型struct、union 配列として渡される
bit、logicのアンパック型配列 配列として渡される
アンパック型struct structとして渡される
アンパック型unions structとして渡される
配列を開く svOpenArrayHandle

シミュレーション環境の生成

export_ip_user_files

 プロジェクトからIP/IP Integraterファイルを生成及びエクスポートします。

export_ip_user_files -of_objects [get_files ./Zynq7000.srcs/sources_1/bd/Zynq7000/Zynq7000.bd] -no_script -force -quiet

シミュレーション環境のエクスポート

 ターゲットシミュレータのシミュレーションスクリプトをエクスポートします。

export_simulation  -export_source_files -force -directory "../exportsim" -simulator xsim  -ip_user_files_dir "./Zynq7000.ip_user_files" -ipstatic_source_dir "./Zynq7000.ip_user_files/ipstatic" -use_ip_compiled_libs

vlog.prj、vhdl.prjの修正

exportsim/xsimnに生成されたvlog.prjとvhdl.prjのパスが間違えて生成されているので次のように修正します。

修正前 修正後
srcs/srcs srcs
"srcs/ip/Zynq7000 "srcs/ip/Zynq7000/xil_defaultlib

tb_Zynq7000.shへ追加

エクスポート後の実行スクリプトは単にシミュレーションするだけの内容になっているので修正が必要です。

修正前

```txt:修正前 elaborate() { xelab --relax --debug typical --mt auto -L axi_lite_ipif_v3_0_4 -L lib_cdc_v1_0_2 -L interrupt_control_v3_1_4 -L axi_gpio_v2_0_19 -L xil_defaultlib -L proc_sys_reset_v5_0_12 -L axi_infrastructure_v1_1_0 -L smartconnect_v1_0 -L axi_protocol_checker_v2_0_3 -L axi_vip_v1_1_3 -L processing_system7_vip_v1_0_5 -L xlconstant_v1_1_5 -L xlconcat_v2_1_1 -L xilinx_vip -L unisims_ver -L unimacro_ver -L secureip -L xpm --snapshot tb_Zynq7000 xil_defaultlib.tb_Zynq7000 xil_defaultlib.glbl -log elaborate.log }


### 修正後

```txt
elaborate()
{
  cp ../../function.c .
  cp ../../socket.c .
  xsc function.c socket.c
  xelab -sv_lib dpi -dpiheader dpi.h --relax --debug typical --mt auto -L axi_lite_ipif_v3_0_4 -L lib_cdc_v1_0_2 -L interrupt_control_v3_1_4 -L axi_gpio_v2_0_19 -L xil_defaultlib -L proc_sys_reset_v5_0_12 -L axi_infrastructure_v1_1_0 -L smartconnect_v1_0 -L axi_protocol_checker_v2_0_3 -L axi_vip_v1_1_3 -L processing_system7_vip_v1_0_5 -L xlconstant_v1_1_5 -L xlconcat_v2_1_1 -L xilinx_vip -L unisims_ver -L unimacro_ver -L secureip -L xpm --snapshot tb_Zynq7000 xil_defaultlib.tb_Zynq7000 xil_defaultlib.glbl -log elaborate.log
}

実行

$ ./tb_Zynq7000.sh

プロジェクトデータ

github置いてます。

今回はsocket通信も追加してみました。

]]>
2018-09-20T21:09:47+09:00 ひでみ hidemi@sweetcafe/jp <h1>Vivado 2018.2でDPI-C</h1> <p>前に書いたのがVivado 2017.2版だったのでVivado 2018.2で良いこと起こってないか確認してみました。</p> <p>でも、特に変わってなかった・・・</p> <h2>参照</h2> <ul> <li><a href="https://japan.xilinx.com/support/documentation-navigation/design-hubs/dh0010-vivado-simulation-hub.html">Vivado デザイン ハブ - ロジック シミュレーション</a></li> <li><a href="https://japan.xilinx.com/support/documentation/sw_manuals_j/xilinx2018_2/ug900-vivado-logic-simulation.pdf">UG900: Vivado Design Suite ユーザーガイド ロジックシミュレーション</a></li> </ul> <h2>Vivado 2018.2のDPI-C</h2> <p> Vivado 2018.2のDPI-Cの対応状況はユーザーガイド(UG900)の「Vivadoシミュレータのダイレクトプログラミングインターフェイス(DPI)」を参照して下さい。</p> <p> DPI-Cを使用するにはxscコンパイラを使用し、xscがclang、GNUリンカを呼び出しコンパイルすることができます。</p> <h2>SystemVerilogの合成可能なセット</h2> <p> ユーザーガイド(UG900)の「付録B:Vivado シミュレータのSystemVerilogサポート」でVivadoのシミュレータがサポートしているSystemVerilogの合成可能なセットの一覧が「表B-1:SystemVerilog 1800-2009の合成可能なセット」として示されています。</p> <p> また、「表B-2:サポートされるダイナミック タイプ コンストラクト」でシミュレーションでよく使用されるテストベンチの機能の一部がサポートされています。</p> <h2>xsc</h2> <p>xscはシミュレーションで使用するCソースコードをコンパイルするコンパイラです。</p> <h4>一撃コンパイル</h4> <pre><code class="txt">$ xsc function.c $ xelab -svlog file.sv -sv_lib dpi</code></pre> <h4>二段階コンパイル</h4> <pre><code class="txt">$ xsc -compile function.c -work sample $ xsc -link sample/function.lnx64.o -work sample</code></pre> <h2>CとSysnemVerilogの境界で使用可能なデータ型</h2> <table> <thead> <tr> <th>SystemVerilog</th> <th>C</th> <th>備考</th> </tr> </thead> <tbody> <tr> <td>byte</td> <td>char</td> <td></td> </tr> <tr> <td>shortint</td> <td>short int</td> <td></td> </tr> <tr> <td>int</td> <td>int</td> <td></td> </tr> <tr> <td>longint</td> <td>long long</td> <td></td> </tr> <tr> <td>real</td> <td>double</td> <td></td> </tr> <tr> <td>shortreal</td> <td>float</td> <td></td> </tr> <tr> <td>chandle</td> <td>void *</td> <td></td> </tr> <tr> <td>string</td> <td>const char *</td> <td></td> </tr> <tr> <td>bit</td> <td>unsigned char</td> <td>sv_0、sv_1</td> </tr> </tbody> </table> <p>svdpi.hを使用した場合で使用可能なデータ型</p> <table> <thead> <tr> <th>SystemVerilog</th> <th>C</th> <th>備考</th> </tr> </thead> <tbody> <tr> <td>logic、reg</td> <td>unsigned char</td> <td>sv_0、sv_1、sv_z、sv_x</td> </tr> <tr> <td>bitの配列(パック型)</td> <td>svBitVecVal</td> <td>svdpi.hで定義</td> </tr> <tr> <td>logic/regの配列(パック型)</td> <td>svLogicVecVal</td> <td>svdpi.hで定義</td> </tr> <tr> <td>enum</td> <td>enum</td> <td></td> </tr> <tr> <td>パック型struct、union</td> <td>配列として渡される</td> <td></td> </tr> <tr> <td>bit、logicのアンパック型配列</td> <td>配列として渡される</td> <td></td> </tr> <tr> <td>アンパック型struct</td> <td>structとして渡される</td> <td></td> </tr> <tr> <td>アンパック型unions</td> <td>structとして渡される</td> <td></td> </tr> <tr> <td>配列を開く</td> <td>svOpenArrayHandle</td> <td></td> </tr> </tbody> </table> <h2>シミュレーション環境の生成</h2> <h3>export_ip_user_files</h3> <p> プロジェクトからIP/IP Integraterファイルを生成及びエクスポートします。</p> <pre><code class="txt">export_ip_user_files -of_objects [get_files ./Zynq7000.srcs/sources_1/bd/Zynq7000/Zynq7000.bd] -no_script -force -quiet</code></pre> <h3>シミュレーション環境のエクスポート</h3> <p> ターゲットシミュレータのシミュレーションスクリプトをエクスポートします。</p> <pre><code class="txt">export_simulation -export_source_files -force -directory "../exportsim" -simulator xsim -ip_user_files_dir "./Zynq7000.ip_user_files" -ipstatic_source_dir "./Zynq7000.ip_user_files/ipstatic" -use_ip_compiled_libs</code></pre> <h3>vlog.prj、vhdl.prjの修正</h3> <p>exportsim/xsimnに生成されたvlog.prjとvhdl.prjのパスが間違えて生成されているので次のように修正します。</p> <table> <thead> <tr> <th>修正前</th> <th>修正後</th> </tr> </thead> <tbody> <tr> <td>srcs/srcs</td> <td>srcs</td> </tr> <tr> <td>&quot;srcs/ip/Zynq7000</td> <td>&quot;srcs/ip/Zynq7000/xil_defaultlib</td> </tr> </tbody> </table> <h2>tb_Zynq7000.shへ追加</h2> <p>エクスポート後の実行スクリプトは単にシミュレーションするだけの内容になっているので修正が必要です。</p> <h3>修正前</h3> <p>```txt:修正前 elaborate() { xelab --relax --debug typical --mt auto -L axi_lite_ipif_v3_0_4 -L lib_cdc_v1_0_2 -L interrupt_control_v3_1_4 -L axi_gpio_v2_0_19 -L xil_defaultlib -L proc_sys_reset_v5_0_12 -L axi_infrastructure_v1_1_0 -L smartconnect_v1_0 -L axi_protocol_checker_v2_0_3 -L axi_vip_v1_1_3 -L processing_system7_vip_v1_0_5 -L xlconstant_v1_1_5 -L xlconcat_v2_1_1 -L xilinx_vip -L unisims_ver -L unimacro_ver -L secureip -L xpm --snapshot tb_Zynq7000 xil_defaultlib.tb_Zynq7000 xil_defaultlib.glbl -log elaborate.log }</p> <pre><code> ### 修正後 ```txt elaborate() { cp ../../function.c . cp ../../socket.c . xsc function.c socket.c xelab -sv_lib dpi -dpiheader dpi.h --relax --debug typical --mt auto -L axi_lite_ipif_v3_0_4 -L lib_cdc_v1_0_2 -L interrupt_control_v3_1_4 -L axi_gpio_v2_0_19 -L xil_defaultlib -L proc_sys_reset_v5_0_12 -L axi_infrastructure_v1_1_0 -L smartconnect_v1_0 -L axi_protocol_checker_v2_0_3 -L axi_vip_v1_1_3 -L processing_system7_vip_v1_0_5 -L xlconstant_v1_1_5 -L xlconcat_v2_1_1 -L xilinx_vip -L unisims_ver -L unimacro_ver -L secureip -L xpm --snapshot tb_Zynq7000 xil_defaultlib.tb_Zynq7000 xil_defaultlib.glbl -log elaborate.log }</code></pre> <h2>実行</h2> <pre><code class="txt">$ ./tb_Zynq7000.sh</code></pre> <h2>プロジェクトデータ</h2> <p><a href="http://github.com/aquaxis/svDemo">github</a>置いてます。</p> <p>今回はsocket通信も追加してみました。</p>
ラズパイストリーミングをUltra96でメモリに保存する urn:uuid:968b9c8d-9935-e05a-e94d-2b572a62da9c ラズパイストリーミングをUltra96でメモリに保存する

昨日は次のコマンドにてラズパイのカメラ映像をストリーミングしてPC上で表示させた。

gst-launch-1.0 -v rtspsrc location=rtsp://192.168.1.204:9000/ ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink

ライズパイのストリーミングをUltra96で受信して、メモリにブチ込むためにappsinkでgstreamerのプログラムを組むことを考えたけど、それはそれで面倒でしょ。

たかが、FPGAの画像処理モジュールの検証環境を作るためにgstreamerの開発から作るのも面倒だしね。

そこでfdsinkで横着する。

つまり、コマンドは次のようにする。

gst-launch-1.0 -v rtspsrc location=rtsp://192.168.1.204:9000/ ! rtph264depay ! avdec_h264 ! videoconvert ! capsfilter caps="video/x-raw,format=RGBx" ! fdsink fd=1

FPGAの回路はRGBAの32bitなので処理にしているのでfdsinkで出力させるのはRGBxで32bitにする。

横着して次のプログラムを組む。

fdsinkで標準出力に出した画像データを標準入力で読み込んでメモリに保存する。

#define WIDTH 640
#define HEIGHT 480
int main() {
  size_t frame_size = WIDTH*HEIGHT*sizeof(unsigned int);
  unsigned int *frame = malloc(frame_size);
  unsigned int *buf;

  fd = open( "/dev/mem", O_RDWR | O_SYNC );
  if( fd == -1 ){
    printf( "Can't open /dev/mem.\n" );
    return 0;
  }
 buf = mmap( NULL, MAP_LENG,
               PROT_READ | PROT_WRITE,
                           MAP_SHARED, fd,
                           offset & 0xFFFF0000);
  if( buf == MAP_FAILED ){
    printf( "Error: mmap()\n" );
    return 0;
  }

  while(fread(frame, frame_size, 1, stdin) == 1) {
    fwrite(buf, frame, frame_size);
  }

  return 0;
}

転送コストがかかるけど、検証用の環境だから良いのよ。

これでFPGAモジュールの実機検証ができたら、4カメラ入力のボードをどうするか本格的に考えることにしよう。

]]>
2018-08-26T18:38:51+09:00 ひでみ hidemi@sweetcafe/jp <h1>ラズパイストリーミングをUltra96でメモリに保存する</h1> <p>昨日は次のコマンドにてラズパイのカメラ映像をストリーミングしてPC上で表示させた。</p> <pre><code class="txt">gst-launch-1.0 -v rtspsrc location=rtsp://192.168.1.204:9000/ ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink</code></pre> <p>ライズパイのストリーミングをUltra96で受信して、メモリにブチ込むためにappsinkでgstreamerのプログラムを組むことを考えたけど、それはそれで面倒でしょ。</p> <p>たかが、FPGAの画像処理モジュールの検証環境を作るためにgstreamerの開発から作るのも面倒だしね。</p> <p>そこでfdsinkで横着する。</p> <p>つまり、コマンドは次のようにする。</p> <pre><code class="txt">gst-launch-1.0 -v rtspsrc location=rtsp://192.168.1.204:9000/ ! rtph264depay ! avdec_h264 ! videoconvert ! capsfilter caps="video/x-raw,format=RGBx" ! fdsink fd=1</code></pre> <p>FPGAの回路はRGBAの32bitなので処理にしているのでfdsinkで出力させるのはRGBxで32bitにする。</p> <p>横着して次のプログラムを組む。</p> <p>fdsinkで標準出力に出した画像データを標準入力で読み込んでメモリに保存する。</p> <pre><code class="txt">#define WIDTH 640 #define HEIGHT 480 int main() { size_t frame_size = WIDTH*HEIGHT*sizeof(unsigned int); unsigned int *frame = malloc(frame_size); unsigned int *buf; fd = open( "/dev/mem", O_RDWR | O_SYNC ); if( fd == -1 ){ printf( "Can't open /dev/mem.\n" ); return 0; } buf = mmap( NULL, MAP_LENG, PROT_READ | PROT_WRITE, MAP_SHARED, fd, offset &amp; 0xFFFF0000); if( buf == MAP_FAILED ){ printf( "Error: mmap()\n" ); return 0; } while(fread(frame, frame_size, 1, stdin) == 1) { fwrite(buf, frame, frame_size); } return 0; }</code></pre> <p>転送コストがかかるけど、検証用の環境だから良いのよ。</p> <p>これでFPGAモジュールの実機検証ができたら、4カメラ入力のボードをどうするか本格的に考えることにしよう。</p>
Raspi Camera + Ultra96 urn:uuid:b2486968-ca05-5822-0dcf-fce36a0ebb54 Raspi Camera + Ultra96

ちょっと、忘れないうちに・・・

今、下図の構成でラズパイZERO-Wのカメラ映像をWiFiでUltra96へ飛ばす。

ラズパイ側

ラズパイのカメラからストリームでUltra96で映像を飛ばす。

ストリームを送信するのはVLCを使う。

$ sudo apt install vlc

gstreamerでも良いんだけど、VLCだと下記のコマンドで送信する。

$  raspivid -n -o - -t 0 -w 640 -h 480 -fps 15 | clvc -vvv stream:///dev/stdio --sout '#rtp{sdp=rtsp://:9000}' :demux=h264-fps=15

Ultra96側

Ultra96はgstreamerで受信して、H264を解いてからバッファに入れられるように組む。

Yocto Projectでgstreamerを組み込んでいるのでビルドできたら試そう

PC

その前にPCでストリーミングしてみよう。

gst-launch-1.0 -v rtspsrc location=rtsp://192.168.1.204:9000/ ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink

これでPCでラズパイカメラの映像を表示することができた。

]]>
2018-08-25T22:07:10+09:00 ひでみ hidemi@sweetcafe/jp <h1>Raspi Camera + Ultra96</h1> <p>ちょっと、忘れないうちに・・・</p> <p>今、下図の構成でラズパイZERO-Wのカメラ映像をWiFiでUltra96へ飛ばす。</p> <p><img src="./files/Rasp-Ultra96.png" alt="" /></p> <h2>ラズパイ側</h2> <p>ラズパイのカメラからストリームでUltra96で映像を飛ばす。</p> <p>ストリームを送信するのはVLCを使う。</p> <pre><code class="txt">$ sudo apt install vlc</code></pre> <p>gstreamerでも良いんだけど、VLCだと下記のコマンドで送信する。</p> <pre><code class="txt">$ raspivid -n -o - -t 0 -w 640 -h 480 -fps 15 | clvc -vvv stream:///dev/stdio --sout '#rtp{sdp=rtsp://:9000}' :demux=h264-fps=15</code></pre> <h2>Ultra96側</h2> <p>Ultra96はgstreamerで受信して、H264を解いてからバッファに入れられるように組む。</p> <p>Yocto Projectでgstreamerを組み込んでいるのでビルドできたら試そう</p> <h2>PC</h2> <p>その前にPCでストリーミングしてみよう。</p> <pre><code class="txt">gst-launch-1.0 -v rtspsrc location=rtsp://192.168.1.204:9000/ ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink</code></pre> <p>これでPCでラズパイカメラの映像を表示することができた。</p>
9年ぶりの母艦更新 urn:uuid:f750e2af-b9fe-a2d8-b5db-afaf394a068a 9年ぶりの母艦更新

 Zynq MPSoCを合成するようになって、顕著にメモリ不足で処理能力低下が発生するようになり耐えきれなくなったので母艦を更新した。

 私の場合、母艦での作業は基本的に時間がかかる処理用に使っている。

 例えば、Yocto Projectのbitbakeを流すとか2日かかっててもいいようなものを流すとかが主な使用方法だ。

 Vivadoはタブレットで使っているけど、実はタブレットの方で遅くなったのだ。

 タブレットのメモリは8GBなんだけど、まぁ、Swap Outしちゃんだな。

 そこでZynq MPSoC系は母艦で処理することにして、X-Windowでタブレットに飛ばしてくればいいかなぁと、今回の母艦更新に繋がったわけです。

下表は左が更新前、右が更新後の母艦です。

Acer Aspire 3935-CF61 Tsukumo AeroMini MI7J-D180T
タイプ ノートPC MiniITX
CPU Core 2 Duo P8600(2.4GHz 2COre) Core i7-8700 (3.2GHz/TB4.6GHz 6Core)
メモリ 4GB 32GB
メモリ規格 DDR3 PC3-8500 PC4-21300)
SSD 200GB 500GB
OS Ubuntu 16.04.5LTS Ubuntu 18.04.1LTS
モニタ

9年も経てば、CPUも様変わりしますわな。

母艦といえど、設置面積は取りたくなかったのでMiniITXで小さめのケースを探したけど、Tsukumoのケースが一番気に入ったのでそのままBTOで購入した。

これでZynq MPSoCとYocto Projectの同時進行をタブレットのUbuntu 18.04LTS上で行えるぞ。

]]>
2018-08-23T21:12:47+09:00 ひでみ hidemi@sweetcafe/jp <h1>9年ぶりの母艦更新</h1> <p> Zynq MPSoCを合成するようになって、顕著にメモリ不足で処理能力低下が発生するようになり耐えきれなくなったので母艦を更新した。</p> <p> 私の場合、母艦での作業は基本的に時間がかかる処理用に使っている。</p> <p> 例えば、Yocto Projectのbitbakeを流すとか2日かかっててもいいようなものを流すとかが主な使用方法だ。</p> <p> Vivadoはタブレットで使っているけど、実はタブレットの方で遅くなったのだ。</p> <p> タブレットのメモリは8GBなんだけど、まぁ、Swap Outしちゃんだな。</p> <p> そこでZynq MPSoC系は母艦で処理することにして、X-Windowでタブレットに飛ばしてくればいいかなぁと、今回の母艦更新に繋がったわけです。</p> <p>下表は左が更新前、右が更新後の母艦です。</p> <table> <thead> <tr> <th></th> <th>Acer Aspire 3935-CF61</th> <th>Tsukumo AeroMini MI7J-D180T</th> </tr> </thead> <tbody> <tr> <td>タイプ</td> <td>ノートPC</td> <td>MiniITX</td> </tr> <tr> <td>CPU</td> <td>Core 2 Duo P8600(2.4GHz 2COre)</td> <td>Core i7-8700 (3.2GHz/TB4.6GHz 6Core)</td> </tr> <tr> <td>メモリ</td> <td>4GB</td> <td>32GB</td> </tr> <tr> <td>メモリ規格</td> <td>DDR3 PC3-8500</td> <td>PC4-21300)</td> </tr> <tr> <td>SSD</td> <td>200GB</td> <td>500GB</td> </tr> <tr> <td>OS</td> <td>Ubuntu 16.04.5LTS</td> <td>Ubuntu 18.04.1LTS</td> </tr> <tr> <td>モニタ</td> <td>有</td> <td>無</td> </tr> </tbody> </table> <p>9年も経てば、CPUも様変わりしますわな。</p> <p>母艦といえど、設置面積は取りたくなかったのでMiniITXで小さめのケースを探したけど、Tsukumoのケースが一番気に入ったのでそのままBTOで購入した。</p> <p>これでZynq MPSoCとYocto Projectの同時進行をタブレットのUbuntu 18.04LTS上で行えるぞ。</p>