2011|08|
2013|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|05|06|07|08|09|10|11|12|
2016|01|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|

2017-04-25 stackのec_process_datagramsに繋がるところ [長年日記]

kernel/ecat_protocols.c の中の ec_process_datagrams()


2017-04-24 Linuxカーネルのリスト構造体の仕組みをユーザプログラムで使う [長年日記]

/*
 大規模シミュレータを作る時に、私は、動的メモリのリスト構造体を大量に使う。
 Linuxカーネルにも、この仕組みがあるらしく、ユーザプログラムでも使う方法が
 解説されていた。
 
 http://qiita.com/chromabox/items/ea9720422d7a974f6ce
 
 c言語でリストを使う時に、役に立ちそうだったので、自分のコメントを付けた
 ものを写させて頂いている。
 
 なお、"list.h"は、kobore.net/list.h.htmlに置いてあり。
  
 */
 
/*
  gcc -g list_demo.c -o list_demo
*/
 
 
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "list.h"
 
typedef struct _tag_datas
{
  int number;
  char name[64];
  list_head _list;
}type_line;
 
const char *ndata[]=  {
  "beagle",
  "cupcake",
  "donut",
  "eclair",
  "froyo",
  "gingerbread",
  "honeycomb",
  "icecleam",
  "jellybean",
  "kitkat",
  NULL,
};
 
// 渡されたリストのエントリが最後かどうか調べる
#define list_is_entry_last(pos, head, member)   \
  &pos->member == (head)
 
int main(int argc,char *argv[])
{
  LIST_HEAD(mylist);  // mylist は リスト変数の宣言と初期化
  int nums=1,i;
  type_line *data = NULL;
  type_line *dend = NULL;
  
  // Listへ要素の追加
  for(i=0;ndata[i] != NULL;i++){
    data = (type_line *)malloc(sizeof(type_line));  // インスタンスを生成
    
    INIT_LIST_HEAD(&data->_list);  // 先頭アドレスを指定(というか「決める」)
 
    data->number = nums;           // 構造体にデータを投入
    strcpy(data->name,ndata[i]);   // 同上
 
    nums++;
 
    list_add_tail(&data->_list, &mylist);  // リスト末尾に追加、リスト先頭に追加する場合はlist_add()を使う
  }
 
  // Listを順にたぐる
  list_for_each_entry(data,&mylist,_list){   // "_list"は構造体の一つ、mylistは先頭のアドレス
    printf("%d: %s\n",data->number,data->name);
  }
  
  // Listを順にたぐりつつ、探す (基本的には上記と同じ)
  list_for_each_entry(data,&mylist,_list){
    if(strcmp(data->name,ndata[4]) == 0){  // ndata[4]と同じ文字列なら、引き出す
      printf("found ! %d: %s\n",data->number,data->name);
      break;
    }
  }
  // Listが最後まで来たかどうか
  if(list_is_entry_last(data,&mylist,_list)){
    printf("not found\n");
  }else{
    printf("continue print\n");
    // 探せたらそこから順にたどる
    // list_for_each_entry_continue だと今dataが示しているところの次から
    // list_for_each_entry_from だと今dataが示しているところになります
    list_for_each_entry_continue(data,&mylist,_list){
      printf("%d: %s\n",data->number,data->name);
    }
  }
  
  // 後始末
  list_for_each_entry_safe(data,dend,&mylist,_list){
    list_del(&data->_list);
    free((void *)data);
  }
  
  return 0;
}
 

2017-04-23 UbuntsのEmacsのshell-modeで日本語文字化けを回避する .emacs [長年日記]

;; shellの文字化けを回避
(add-hook 'shell-mode-hook
          (lambda ()
            (set-buffer-process-coding-system 'utf-8-unix 'utf-8-unix)
            ))

2017-04-22 スマホ(アンドロイド)で「現在オフラインです。」が出てきた時の対応 [長年日記]

問題の画面

修正画面の出しかた

修正方法

スマホのAPIが、rmobie.jp(×rmobie.co)であることを確認する。


2017-04-21 teratermのemacsのMetaキーの有効化 [長年日記]

[問題点]クライアント(Windows)からサーバに接続してEmacsを利用する場合、Altキーを押してもTeraTermが受け取ってしまい接続先のEmacsにMetaキーが渡せない。

[解決法] 「設定」-「キーボード」から"Metaキー → ON"とする。


2017-04-20 TeraTermのEmacsが見にくい件 [長年日記]

設定>その他の設定>表示 で以下を設定

_

INDEX色名RGB
Color_0*Black000
Color_1Red25500
Color_2緑(明)Lime02550
Color_3Yellow2552550
Color_4Blue00255
Color_5赤紫Magenta2550255
Color_6Cyan0255255
Color_7*White255255255
Color_8Gray128128128
Color_9*赤(暗)Maroon12800
Color_10*Green01280
Color_11*Olive1281280
Color_12*青(暗)Navy00128
Color_13*Purple1280128
Color_14*Teal0128128
Color_15灰(明)Silver192192192


2017-04-19 SOES: tutorial.txt ファイルリファレンス(翻訳途中) [長年日記]

SOES: tutorial.txt ファイルリファレンス
tutorial.txt File Reference

詳細説明

概要

SOESは、マイクロコントローラユーザアプリケーションに、以下のEtherCATフィールドバス通信環境を提供するライブラリです

  • EtherCAT 状態マシン
  • Mailbox インターフェース
  • プロトコル
    • CoE
    • FoE + ブートストラップテンプレート

メールボックスとプロトコルのサポートは、典型的なサンプルであり、あなたがEtherCATのアプリケーションレイヤをコントロールする為のスレーブスタックが必要となる時に役に立ちます。これらのアプリケーションで使用されるPDIは、SPIかいくつかのマイクロコントローラのインターフェースです。

以下は、どのようにSOESを立ち上げ起動させるかの幾つかの基本的なサンプルとなり、かつ、あなたがスレーブを設定するときの簡単なサンプルにもなります。全てのコードはアプリケーションの為のローカル変数またはグローバル変数で記述されています。必要なら修正や改良しても良いです。

ターゲットアプリケーションは以下の通りです

  • 入力 40ビット
    • 1ボタン 8ビット
    • 1エンコーダ 変数32ビット
  • 出力 8ビット
    • LED 8ビット
  • パラメータ
    • エンコーダ設定
  • スレーブ命令
    • リセットカウンター

SOESの上位での、翻訳または実装(?)

最初にスタートアップコードを見て下さい。このサンプルは、どのようにメイン関数を追加するかを示しており、スタートアップコードによって呼ばれることになります。このサンプルでは、mainの唯一の目的は、2つの新しいタスクを生み出すことです。一つはSOESを実行することで、もうひとつはエラーLEDをコントロールすることです。いくつかのESCは、エラーLEDの為のイベント用にRUN LED用のPINを提供しています。それがなければ、スレーブのマイクロコントローラから、それらをコントロールできます。以下SOESタスクに注力します。

int main (void)
{
   rprintp ("SOES (Simple Open EtherCAT Slave)\nsoes test\n");
/* task_spawn ("led_run", led_error, 15, 512, NULL); / task_spawn ("led_error", led_error, 15, 512, NULL); task_spawn ("soes", soes, 9, 1024, NULL); return (0); }

構成

SOESの機能は、EtherCATスレーブデバイスであり、3つの部分に分割することができます。「ハードウェアの初期化」「ソフトウェア」「アプリケーションの初期化ループ」です。では、「ハードウェアの初期化」から説明します。

  • ハードウェアの初期化
    • esc_resetは、物理的なEEPROMを使用しない場合に、ESCのために使用される特別リセットです。これは、一般的はESCハンドリングの一部ではなく、アプリケーションに固有のものです。
    • ESC_init は、SPI通信等の初期化をします
    • ESCが開始され、SPIが立ち上り動きだすのを待ち, ESCレジスタのDLステータスに問い合せします。if EEPROM loaded OK and PDI operational, eg. SPI OK.
void soes (void *arg)
{
   TXPDOsize = SM3_sml = sizeTXPDO ();
   RXPDOsize = SM2_sml = sizeRXPDO ();

_ esc_reset ();

ESC_init ((void *)spi_name);

_ task_delay (tick_from_ms (200));

_ // wait until ESC is started up

while ((ESCvar.DLstatus & 0x0001) == 0)

{

ESC_read (ESCREG_DLSTATUS, (void *) &ESCvar.DLstatus,

sizeof (ESCvar.DLstatus), (void *) &ESCvar.ALevent);

ESCvar.DLstatus = etohs (ESCvar.DLstatus);

}

// reset ESC to init state ESC_ALstatus (ESCinit); ... }
  • ソフトウェア初期化
    • ALステータスレジスタに書き込むことで、スレーブが初期化されます
    • ALステータスコードレジスタに書き込むことで、エラーをクリアします
    • アプリケーション層を停止し、データ交換を暗黙的にブロックするSyncManagersをディスエーブルします
void soes (void *arg)
{
...
   while ((ESCvar.DLstatus & 0x0001) == 0)
   {
      ESC_read (ESCREG_DLSTATUS, (void *) &ESCvar.DLstatus,
                sizeof (ESCvar.DLstatus), (void *) &ESCvar.ALevent);
      ESCvar.DLstatus = etohs (ESCvar.DLstatus);
   }

_ // reset ESC to init state

ESC_ALstatus (ESCinit);

ESC_ALerror (ALERR_NONE);

ESC_stopmbx ();

ESC_stopinput ();

ESC_stopoutput ();

// application run loop while (1) ... }
  • アプリケーションループ
    • ALeventハンドリング, ALイベントはALコントロールまたはSyncManagersの変化に関する情報を保持します。状態変化の為のALcontrolと、SyncManageは、EtherCATのアクティブSyncManagersにマッピングさたロれーカルメモリの中に書き込まれています。
  • ESC_state はステートをハンドリングします, 正常、エラー、または確認の応答で、ステートのアップダウンを行います
  • Mailbox handler, generic support of mailboxes used by all Application Layer protocols.
  • On mailbox actions we'll also check if we need to use a specific protocol handler to handle the incoming or outgoing Mailbox data.
  • Up until the now we're using the SOES protocol stack without any application specific calls. Next up we'll look at the application Code, here named DIG_process ().

    void soes (void *arg)
    {
    ...
       // application run loop
       while (1)
       {
          if((ESCvar.ALstatus & 0x0f) == ESCinit)
          {
             txpdomap = DEFAULTTXPDOMAP;
             rxpdomap = DEFAULTRXPDOMAP;
             txpdoitems = DEFAULTTXPDOITEMS;
             rxpdoitems = DEFAULTTXPDOITEMS;
          }
          ESC_read (ESCREG_LOCALTIME, (void *) &ESCvar.Time, sizeof (ESCvar.Time),
                    (void *) &ESCvar.ALevent);
          ESCvar.Time = etohl (ESCvar.Time);
    
    ESC_state (); if (ESC_mbxprocess ()) { ESC_coeprocess (); ESC_foeprocess (); ESC_xoeprocess (); } DIG_process (); }; }

    Application

    The function DIG_process is the User part of the application and could be joined by more cyclic User functions for executing other parts of the application. The example code can be split in 2 parts

    • Outputs
      • Start by evaluating if we're in a state supporting update of outputs, eg. Operational state.
      • If we're in OP we can read the current PDO data in the 3-buffer SyncManager mapped to the output SM, the default is SyncManager2, we read the ESC RAM address of SM2 and store it at the local address of the local variable Wb.LED. We'll read RXPDOsize bytes to trigger a complete SyncManager read.
      • After local variables have been refreshed we basically write the local PDO variables to the User application, ex. a GPIO.
      • Basically this is the API of the SOES toward the User Application.
      • This function also include a watchdog mechanism, if triggered it will shutdown the outputs and trigger a state changes to safe operational. AlError is updated with cause of error to inform the Master.
    void RXPDO_update (void)
    {
       ESC_read (SM2_sma, &Wb.LED, RXPDOsize, (void *) &ESCvar.ALevent);
    }
    
    void DIG_process (void) { if (App.state & APPSTATE_OUTPUT) { if (ESCvar.ALevent & ESCREG_ALEVENT_SM2) // SM2 trigger ? { RXPDO_update (); reset_wd (); gpio_set(GPIO_LED, Wb.LED & BIT(0));
    } if (!wd_cnt) { ESC_stopoutput (); // watchdog, invalid outputs ESC_ALerror (ALERR_WATCHDOG); // goto safe-op with error bit set ESC_ALstatus (ESCsafeop | ESCerror); wd_trigger = 1; } } else { reset_wd (); } ... }
    • Inputs
      • Is handled a bit simpler than outputs but in reverse order, the slave will continue update the inputs in state Safe Operational.
      • Here we first read User application data from ex. GPIO and then write to local PDO variables.
      • After the local variables have been refreshed we write those to the current PDO data 3-buffer SyncManager mapped to the input SM, the default is SyncManager3. This way we update the ESC RAM address with User Application data accessed by the EtherCAT master.
    void TXPDO_update (void)
    {
       ESC_write (SM3_sma, &Rb.button, TXPDOsize, (void *) &ESCvar.ALevent);
    }
    
    void DIG_process (void) { ... Rb.button = gpio_get(GPIO_WAKEUP); Cb.reset_counter++; Rb.encoder = Cb.reset_counter;
    TXPDO_update (); }

    ApplicationdataProcessdata

    To run application data through EtherCAT processdata we need to describe for the fieldbus what data we have and will read/write. For this we have 3 objects, the ESI file, SII-EEPROM and CoE Object Dictionary. The first 2 are mandatory and the third is a very convenient way of describing complex slaves.

    Our strategy is to keep the ESI file and the SII-EEPROM as thin as possible to avoid duplication of data that need to be maintained. Both will hold the bare minimum of mandatory + optional data to pass CTT. Optional data will be included to tell EtherCAT that detailed information can be retrieved via CoE from the OD stored in the slave it self.

    SII-EEPROM

    Snapshot from SII information matrix from EtherCAT communication slides.

    sii_pdo.png
    Our target slave is Fixed PDO and OD

    ESI-file

    Snapshot from ESI tree from EtherCAT communication slides.

    esi_pdo.png
    mandatory and optional ESI data

    To briefly give a hint what are describe in the ESI and SII we're listing a set of included elements marked M for mandatory and O for optional.

     - Vendor (M) , Describes the identity.
      - Id (M), Hex, EtherCAT Vendor ID, OD 1018.01
      - Name (M), NameType, Expedient vendor name
     - Descriptions (M), Describes the EtherCAT device(s) using elements.
      - Groups (M), Similar devices can be assigned to one group. 
       - Group (M), One group groups similar devices with slightly different features
        - Type (M), A reference handle corresponding to the GroupType value in Description:Devices:Device:Group
       - Name (M), Name for this group show by a configuration tool
      - Devices (M), Element devices may describe one or several devices with their EtherCAT features such as SyncManagers, FMMUs and Dictionaries
       - Device (O), Holds all information about the device like syncmanagers and FMMU, object dictionary, data types and the PDO mapping and assign description
       - Device ATT: Physics (M),string, Physics at individual ports
        - Type (M), Device identity 
       - Type ATT:ProductCode="#x98123467" 
       - Type ATT:RevisionNo="#x00000001"
       - Name (M), Detailed name of device shown by a configuration tool (not used for identification)
        - GroupType (M), Reference to a group (described in element Groups) to which this device should be assigned to. Name of the handle used in element Groups:Group:Type         
        - Fmmu (O), String to describe function, Outputs -> RxPDO, Inputs -> TxPDO , MBoxState -> FMMU is used to poll Input Mailbox
       - Sm (O), Description of SyncManager including start address and direction. 
        - MBoxOut Mailbox Data Master -> Slave
        - MBoxIn Mailbox Data Slave -> Master
        - Outputs Process Data Master -> Slave
        - Inputs Process Data Slave -> master  
       - Sm ATT:DefaultSize="128" , Size
       - Sm ATT:StartAddress="#x1000" , Start address
       - Sm ATT:ControlByte="#x26" , Settings , Bit [1][0] = 10, Operation mode Mailbox, 00 Buffered 3.
       - Sm ATT:Enable="1", Enabled
       - Mailbox (O), Description of available mailbox protocols
       - Mailbox ATT: DataLinkLayer="true", Support of Mailbox Data Link Layer is mandatory.
        - CoE (O), Device support CoE
        - CoE (O) ATT: SdoInfo="true" , SDO Information Service 
        - CoE (O) ATT: CompleteAccess="false" , SDO complete access not supported
        - CoE (O) ATT: PdoUpload="true", PDO description uploaded from the slave's object dictionary and SyncManager length calculated based on the same
       - Dc (O), describes synchronization modes supported by the device.
        - OpMode (O), Definition of supported operation  modes
         - Name (M), Internal Handle of operation mode
         - Desc (O(M)), description of operation mode, recommended, Free Run (no sync), SM Synchronous, DC Synchronous 
         - AssignActive (M), Value of Latch and Sync Control registers
       - Eeprom (O, use is mandatory) 
        - Data (M)
             Or
        - ByteSize (M), Byte Size of connected EEPROM device
        - ConfigData (M), First 7 words of EEPROM, Configuration Areas
        - BootStrap (O), Start address and length of mailboxes for BootStrap
    

    So to describe the application we use CoE and Object Dictionary. The mapping between Object Dictionary and the User Application are done via local variables defined as user types. The Object Dictionary itself is stored in a matrix where all the indexes are listed. Every index then have a submatrix with its subindex.

    ObjectDictionary

    The Object Dictionary used as example follow the CANopen DS301 ranges.

    • 0x0000 - 0x0FFF, Data Type Area
    • 0x1000 - 0x1FFF, Communication Area
    • 0x2000 - 0x5FFF, Manufacture specific area
    • 0x6000 - 0x6FFF, Input area
    • 0x7000 - 0x7FFF, Output area
    • 0x8000 - 0x8FFF, Configuration area
    • 0x9000 - 0x9FFF, Information area
    • 0xA000 - 0xAFFF, Diagnosis Area
    • 0xB000 - 0xBFFF, Service Transfer Area
    • 0xC000 - 0xEFFF, Reserved Area
    • 0xF000 - 0xFFFF, Device Area

    RxPDO , 0x1600 - 0x17FF TxPDO , 0x1A00 - 0x1BFF

    Example, on how the the OD index are linked. Top index, SyncManagers Communication Types. In index 0 the 0x04 indicates we have 4 SyncManagers defined. Every SyncManager is assigned a type, in index 1-4, we have standard settings SM0 = 1, SM1 = 2, SM2 = 3, SM3 = 4 from ETG 1000.6, 5.6.7.4.

    • 0, Unused
    • 1, MailBox Receive, master to slave
    • 2, MailBox Send, slave to master
    • 3, Processdata output, master to slave
    • 4, Processdata input, slave to master
    objectlist.h
    FLASHSTORE _objectlist SDOobjects[] =
    ...
      {0x1C00, OTYPE_ARRAY, 4, 0, &acName1C00[0], &SDO1C00[0]},
      
    FLASHSTORE _objd SDO1C00[] =
    { {0x00, DTYPE_UNSIGNED8, 8, ATYPE_R, &acNameNOE[0], 0x04, nil},
      {0x01, DTYPE_UNSIGNED8, 8, ATYPE_R, &acName1C00_01[0], 0x01, nil},
      {0x02, DTYPE_UNSIGNED8, 8, ATYPE_R, &acName1C00_02[0], 0x02, nil},
      {0x03, DTYPE_UNSIGNED8, 8, ATYPE_R, &acName1C00_03[0], 0x03, nil},
      {0x04, DTYPE_UNSIGNED8, 8, ATYPE_R, &acName1C00_04[0], 0x04, nil}
    

    SyncManagers channels 0-31 are listed in SDO1C10-SDO1C2F. If we look at SyncManager channel 2, we see.

    • Type 3, Processdata output, master to slave

    It got one RxPDO index 0x1600 connected, and the submatrix for 0x1600 link one PDO object index 0x7000 subindex 1. The output object 0x70000108 give you the index 0x7000, subindex 1 and PDO object length 1(byte).

    objectlist.h
    FLASHSTORE _objd SDO1C12[] =
    { {0x00, DTYPE_UNSIGNED8, 8, ATYPE_R, &acNameNOE[0], 0x01, nil},
      {0x01, DTYPE_UNSIGNED16, 16, ATYPE_R, &acNameMO[0], 0x1600, nil}
    };
      
    FLASHSTORE _objd SDO1600[] =
    { {0x00, DTYPE_UNSIGNED8, 8, ATYPE_R, &acNameNOE[0], 0x01, nil},
      {0x01, DTYPE_UNSIGNED32, 32, ATYPE_R, &acNameMO[0], 0x70000108, nil}
    };
    

    At PDO level we make the connection between the local application and the object dictionary. For all subindex in the PDO the last element is the address to the local variable.

    objectlist.h
    FLASHSTORE _objd SDO7000[] =
    { {0x00, DTYPE_UNSIGNED8, 8, ATYPE_R, &acNameNOE[0], 0x01, nil},
      {0x01, DTYPE_UNSIGNED8, 8, ATYPE_RW, &acName7000_01[0], 0, &(Wb.LED)}
    };
    

    _ utypes.h

    typedef struct { uint8 LED; } _Wbuffer;

    Beside SyncManager to PDO mapping we also have mandatory data as

    0x1000 Device Type 0x1018 Object Identity 0x10C0 SyncManager Communication Type, as we used as top index when figuring out our PDOs in the Object Dictionary.

    For a complete description of the object dictionary you can get guidance by the ETG1000.6 EcatAlProtocols

    A useful feature is the Asynchronous use of SDO parameters. In the example we have Parameter set holding an encoder scale value, just for show we also have a read only mirror value of the encoder scale. Parameters defined as a RW SDO parameter and can be written/read by SDO Download or Upload. In addition there is a ESC_objecthandler Hook on SDO Download where you can add additional logic, ex. we execute the mirror of the encoder scale value by assigning the encoder scale value to the mirror.

    objectlist.h
    FLASHSTORE _objd SDO7100[] =
    { {0x00, DTYPE_UNSIGNED8, 8, ATYPE_R, &acNameNOE[0], 0x02, nil},
      {0x01, DTYPE_UNSIGNED32, 32, ATYPE_RW, &acName7100_01[0], 0, &(encoder_scale)},
      {0x02, DTYPE_UNSIGNED32, 32, ATYPE_R, &acName7100_02[0], 0, &(encoder_scale_mirror)}
    };
    

    _ soes.c

    void ESC_objecthandler (uint16 index, uint8 subindex) { switch (index) { ... case 0x7100: { switch (subindex) { case 0x01: { encoder_scale_mirror = encoder_scale; break; } } break; } ... }

    This tutorial is just one way of doing it. Enjoy and happy coding!

    Andreas Karlsson, rt-labs AB, www.rt-labs.com


    2017-04-18 SOES: Simple Open EtherCAT Slave or SOES [長年日記]

    SOES: Simple Open EtherCAT Slave or SOES
    Simple Open EtherCAT Slave or SOES

    チュートリアル

    ここを見よtutorial.txt

    概要

    SOESはC言語で記載されたEtherCATスレーブのスタックで、学習と使用の両方を目的としたものです。 このソースを勉強することで、どのようにEtherCATスレーブが動いているのが分かるででしょう。

    バージョン1.0.01の概要は以下の通りです。

    • 任意のインターフェースを介しての、簡単なECSの読み書きの為の物理層レイヤベースのアドレスオフセット
    • データリンク層のメールボックス
    • CoE
    • オブジェクトディクショナリ
    • セグメント化された転送を包含する全サイズのSDO read/write
    • 組み込みアプリケーションに適した簡易ポータブルCコード
    • Fixed PDO マッピング
    • ブートトラップテンプレート機能つきFoE
    • リトル・ビッグエンディアンターゲットのサポート
    • 割り込みポーリング

    Legal notice

    SOES Simple Open EtherCAT Slave
    Copyright (C) 2007-2013 Arthur Ketels
    Copyright (C) 2012-2013 rt-labs

    SOES is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation.

    SOES is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

    As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License. However the source code for this file must still be made available in accordance with section (3) of the GNU General Public License.

    This exception does not invalidate any other reasons why a work based on this file might be covered by the GNU General Public License.

    The EtherCAT Technology, the trade name and logo "EtherCAT" are the intellectual property of, and protected by Beckhoff Automation GmbH.


    2017-04-15 ラズパイにsshサーバをインストールする方法 [長年日記]

     
    >sudo apt-get install openssh-server
     
    /etc/ssh/sshd_config の portの番号を替える。
     
    >sudo service ssh restart
    

    2017-04-14 「light ethercat slave」のカーネルモードをラズパイで作る [長年日記]

    「light ethercat slave」のカーネルモードをラズパイ3(ubuntu 16.04)で作ろうとしていたのですが、これが上手くいきませんでした(makeに失敗する)。

    ようやく動くようになったので、以下やり方を残しておきます。

    (Step.1) まず、"http://eetimes.jp/ee/articles/1506/22/news017_5.html"に記載されている通りのことをします。

    が、このままではsudo makeに失敗します。("4.1.19-7v"がない、とか言われます)

    >sudo apt-get install raspberrypi-kernel-headers
    >sudo apt-get update
    >sudo apt-cache search linux-headers
    >sudo rpi-update f406502f5628d32e6ca5dadac34ff7ca59f8e27f
    >sudo apt-get install linux-headers-4.1.19-v7+
    

    てなことをやったのですが、改善ありませんでした。

    Step.2) https://tiryoh.com/blog/archives/1086を参考に環境作ってみた

    >mkdir -p ~/tmp
    >cd ~/tmp
    >wget http://phil.lavin.me.uk/downloads/linux-headers-rpi/linux-headers-4.1.19-v7%2B_4.1.19-v7%2B-2_armhf.deb
     
    >sudo apt install dkms
    >sudo apt install gcc-4.7
    >sudo apt-get install -f
    >sudo dpkg -i linux-headers-4.1.19-v7+_4.1.19-v7+-2_armhf.deb
     
    >sudo chmod -R o+r /usr/src/linux-headers-4.1.19-v7+/*
    >sudo chmod -R g+r /usr/src/linux-headers-4.1.19-v7+/*
    

    (Step.3) sudo make 再び

    >sudo make 
    

    をすると、kernel/ecslave.ko が完成しました。