Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page

CAN通信の実際の開発環境について

組み込み事情にはあまり詳しくなく、現在RL78などを使ってCAN通信を色々試作しているのですが、

実際に量産するような製品でCAN通信をする場合、本当に一からCAN通信のコードを起こしているのでしょうか…

いくつかのケースを考えてみたのですが、多分以下の4パターンになるかと思います。

 

1) 毎回プロジェクトごとにコードを一から起こしている。

2) 自社開発のCANライブラリが手元にあってそれを使いまわしている。

3) CANのミドルウェア的なものを買ってきて、それを使っている。

4) 発注元から使用するミドルウェアを指定され、案件ごとに言われたミドルウェアで開発している。

 

CANの何らかの規格に適合していることを証明するコストを考えると、量産では3)か4)以外なさそうな気がするのですが、

実際の開発事情をもしよろしければ教えていただきたいです。

# つまるところ、1)や2)は避けたいのです…

  • こんにちは Sugachanceです。

    私も取り掛かり始めたころは、気になっていた話題です。
    このあたり詳しいであろうNAKAさんの降臨を待ちたいところですが…

    私見ですが
    ・下位層は自作orコード生成機能による
    ・上位層のプロトコル(J1939やCANopen)は
    自社開発して使いまわすor買ってくる

    というところではないでしょうか。売っていますし…
    完全な自動車分野の場合は分かりませんが、
    ISO26262の対応となると、ツール認定されたコンパイラ+自作コード??

    分野が自動車ではないので、RL78/Fだけではなく
    非車載品のSynergyを使うこともありますが、
    CANのコード生成(というかルネサスの保証付きのSSP)がつかえました^^

  • In reply to Sugachance:

    こんにちは。imudakです。

    お忙しいところ、返信ありがとうございます。

    下位層と上位層で分けて買う発想はなかったので、ちょっと新鮮でした。
    何か買うとなると、てっきりECUのレジスタ設定など下位層含めた全コード入っているものと
    勘違いしていました。

    あとはアプリ層から、

    InitCANOpen();
    con = openCANOpen();
    con.connect();
    ...

    みたいなイメージですね。

    それに、CANの何らかの規格(CANOpenとかJ1939とか)に適合しているか保証するには、
    やはり買ってきた何かから全コード作られないとしんどそうですね…

    Synergyが使えれば良かったのですが、お高いので多分RLあたりを使うことになりそうで、
    そうするとCS+ですらCANのコード吐いてくれないし…で悩んでます。
  • In reply to imudak:

    呼ばれて飛び出てじゃじゃじゃじゃぁ~ん! NAKA@在宅勤務です。
    imudakさん、Sugachanceさん こんばんは。

    NAKAは開発品の試作や試験がメインなので

    基本
    1) 毎回プロジェクトごとにコードを一から起こしている。
    あるいは
    2) 自社開発のCANライブラリが手元にあってそれを使いまわしている(自分で作ったものですが.....(*_*;)
    です。

    これや
    japan.renesasrulz.com/.../27498

    これなど(こっちの方がいいかな?)
    japan.renesasrulz.com/.../33462
    にRL78/F13、F14のコードが張り付けてありますので

    動作を簡単に確認するにはそんなに大変ではないかと思います。

    ※今のところ、車載で試験してもあまりトラブルになったことは無いです。

     
    外用で信頼性うんぬん言われると、責任はとれませんので、うちの会社ですと代理店経由でルネサス
    からサンプルをもらっているようです。
    車載のRH850のサンプルはあるようです。(NAKAは0から作りましたけど)
     
    代理店に相談されたらいかがでしょう?
    あるいは、代理店(萩原エレクトロニクスなど)さまでもドライバーを作ってくれますよ!


    ご検討ください。 _(._.)_ 

     

    P.S.

    事業部では 2)で、昔の資産を使いまわしているようです。


     

  • In reply to NAKA:

    NAKAさま

    こんにちは、Sugachanceです。
    降臨ありがとうございますm(_ _)m

    やはり1,2が基本なんですね!
  • In reply to NAKA:

    NAKAさん、こんにちは。
    お忙しいところ返信ありがとうございます。

    やはりさすがの自作なんですね。

    手元のCAN通信そのものは単純なので、こちらでNAKAさんに教えていただいたサンプルなど
    参考にしながら動かすことはできそうなんですが、機能安全とかCANの規格大丈夫?と言われると
    大丈夫なんですかね…としか言えなくて…

    そこで適当な外用CANのミドルウェア的なものの見積もりをもらおうとしたら、
    「うちの製品は大手の一次請けさんに買うてもらうようなもんやしねぇ(イメージ)」
    と言われてしまいました…

    そもそも関係者が、CAN通信発注したことない発注者と、CAN通信開発したことない開発者しか
    居ないので色々手探りしている状態です。

    代理店経由と言うのは思いつかなかったのでちょっと相談してみます。
    ありがとうございました。
  • CANを流用している船舶のNMEA2000は上位まで規格化されているので異なるメーカのエンジンとタコメータが接続できたりしますが、元祖の自動車業界ではデータに対するidやパケット内の構造はモデルごとで異なると思ってます。規格化がされていないのでプロジェクトごとに一から起こすしか無いように思われ、何を問題にしているか良く解ら無いのは私だけでしょうか?

    CANoeは必須だと思ってます。まずは、CANoeでデータベースを作成して、コピー&ペーストでIDEに持ってくるとタイプミスも避けられ、作業も楽になります。長いことCANを触っていないので古いのかな?

  • In reply to kijo:

    kijoさんこんにちは。

    畑違いなのでおかしな事を言っていたらすみません。

    データのidやデータ構造などのアプリケーション層の話は一から起こすこともあるだろうなと私も思うのですが、CAN通信そのものやJ1939などのプロトコル層(?)などの下位層まで自作しているのか疑問だったのです。

    例えばTCP/IPのプロトコル層とか毎回自作で実装しないので、CANも同様なのかと。

    TCP/IPの場合も石ごとにドライバが必要ですがだいたい用意されていますし、CANの場合も使えるECUは限られているので、それくらい共通なものが用意されていないのが不思議なのです。

    そこで、共通なもの=市販されているCANのミドルウェアなのかと調べ始めたところです。
  • In reply to NAKA:

    こんにちは。NAKAさん。

    なるほど。テスト項目にしろどうもコードの中身についてあまり気にしてない雰囲気だと思っていたんですが、そもそもハードが中心の世界なのでしたね…

    ソフトを入れたマイコンも、ハードから見れば他の石と同じただのハードですしね…
  • In reply to imudak:

    ペリフェラルにCANコントローラー搭載が前提と思ってます。OSI基本参照モデル7階層の4.トランスポート層のリトライと2.データリンク層の全部と1.物理層の一部をコントローラーが実行してくれます。私自身はSHで使って以来CANからは遠ざかっていてRL78ではCANを使ったことがありません。RL78F15は周辺モジュール(ハードウエア)でCANコントローラを持ってます。ハードウエアマニュアルをパラパラと見るとかなり高機能なようです。前に書いた階層よりも広範囲をカバーするかもしれません。しかし、シンプルにやるなら、
    1.ボーレートや標準IDor拡張IDやなどを初期化で設定します。(CS+のコード生成で作成できたかは記憶にありません。)
    2.送信は送信バッファーにデータを書き込んで、送信フラッグを立てるだけです。
    3.受信も必要な時に受信バッファーを読み出すだけです。
    マイコンへの実装は非常に簡単なはずです。まずは、具体的なマイコンのハードウエアマニュアルを読むことをお勧めします。RL78でCANコントローラなしでソフトだけでCAN通信するのは無理だと思います。
  • In reply to kijo:

    kijoさんこんにちは。

    > RL78でCANコントローラなしでソフトだけでCAN通信

    とかいうおこがましいことは考えていなくて、CANコントローラーついてるマイコンが前提です。
    CAN通信自体はご指摘のような方法でなんとなく出来ているんです。


    > マイコンへの実装は非常に簡単なはずです。

    このへんの感覚が多分組込強い方と違っていて、

    「ハードウェアマニュアル読んで書けたけど、
     このマイコンでこのコード書いてるのきっと自分が最初じゃない」

    と思ってしまって、だったらもっと実績のあるミドルウェアなりライブラリなりがあるんじゃないかと
    探してしまうんです…

    ハードウェアマニュアル読んでても、このような基本機能の部分は
    すべての人が理解してそれぞれ独自に実装するところじゃないでしょと言うか、
    このマニュアル作れるならライブラリも一緒につくれるでしょ、というか…
  • In reply to imudak:

    imudakさん こんにちは! NAKAです。

    先回、結構いい加減な回答でした。今日、弊社の事業部でECUを開発されている方とお話する機会があったので聞いてみました。実際はもっと厳密な感じでした。各ベンダーさん(例えば車両メーカー)に納めるための標準ソフトがあるそうです。そして、弊社内に各ベンダーさんの仕様に対応した、標準ソフトを製作する専門の部署があり、新規CPUを採用した場合は、その部署に依頼し標準ソフトを制作してもらうそうです。つまり、その部署は依頼を受けた後にベンダーの仕様に合わせたソフトを1から作ることになります。
    P.S.
    量産計画のしっかりある事業部からの依頼は受けてくれますが、僕らのような、採用されるかわからない開発部署の依頼は受け付けてくれなさそう!!! 結局、自分で1から作れ!ということになります。(~_~;)
  • In reply to NAKA:

    NAKAさん、こんにちは。


    わざわざお時間使っていただいてありがとうございます。
    「標準ソフトを製作する専門の部署」はちょっと驚きました。
    # 力技使えるって良いですね…

    そしてやはりなんとなく量産品は自作では無理な気がしてきました…

    しかし逆に考えると、そういった部署がある開発ベンダーさんに流されずに私の手元に来てしまった案件は、
    そこまで厳密にやらなくても良いのかも…

Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page