Shop OBEX P1 Docs P2 Docs Learn Events
Controller Area Network driver — Parallax Forums

Controller Area Network driver

lyons5959lyons5959 Posts: 13
edited 2008-11-06 08:11 in Propeller 1
Hopefully my search was correct and no one has brought this up yet.

I have noticed a MCP2515 object in the exchange. It is for interfacing with a CAN controller. The CAN network is becoming increasingly popular and interfacing with it as well. Most serious uControllers have native CAN support.

What I would like to know if there is anyone out there that has worked on a CAN driver to run a controller natively on the Propeller? If not and if there is interest, would anyone like to help write one if it is possible?


Michael Lyons

Comments

  • evanhevanh Posts: 15,662
    edited 2008-11-03 22:08
    I'd be interested in helping. But as of yet I've not looked at all.

    Are you looking for standards based support? Eg, DeviceNet and CANopen.
  • simonlsimonl Posts: 866
    edited 2008-11-04 23:42
    Yes indeed - Stephen Moraco (?) has been doing loads of work with Propeller and CAN; see his blog @ propcandev.blogspot.com/

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cheers,
    Simon

    www.norfolkhelicopterclub.com

    You'll always have as many take-offs as landings, the trick is to be sure you can take-off again wink.gif
    BTW: I type as I'm thinking, so please don't take any offence at my writing style smile.gif
  • evanhevanh Posts: 15,662
    edited 2008-11-05 21:20
    I just had a quick glance at that blog and note the Prop is not doing any control work. Looks like it's just an SPI - RS232 bridge to give him access to the MCP2515 from a PC.

    Now if he didn't need the MCP2515 then that would be something.
  • lyons5959lyons5959 Posts: 13
    edited 2008-11-05 22:19
    I've seen the same. His routines for interfacing with the MCP2515 are in the object exchange. They are well documented and work well at all speeds.

    However, the object of this post is to see if anyone has done work on a native CAN driver for the Propeller. If not, the objective becomes gauging the interest in coding one.
  • simonlsimonl Posts: 866
    edited 2008-11-06 00:36
    Ah, sorry - hadn't picked-up on that angle.

    Is it possible to i/f the Prop to CAN? I thought CAN has some weird voltages (though it was a very long time ago that I got interested in CAN, so I'm probably wrong there!)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cheers,
    Simon

    www.norfolkhelicopterclub.com

    You'll always have as many take-offs as landings, the trick is to be sure you can take-off again wink.gif
    BTW: I type as I'm thinking, so please don't take any offence at my writing style smile.gif
  • pemspems Posts: 70
    edited 2008-11-06 02:19
    simonl said...
    Ah, sorry - hadn't picked-up on that angle.

    Is it possible to i/f the Prop to CAN? I thought CAN has some weird voltages (though it was a very long time ago that I got interested in CAN, so I'm probably wrong there!)

    That's the reason for CAN transceivers burger.gif

    I have read a bit about CAN operation and it didn't look like something impossible for a prop, even for 1Mbps which is maximum in-spec CAN speed. Obviously will need to be implemented in assembly for speed reasons.
    I would imagine it being quite tedious of an implementation though - although not as tedious as USB


    A native CAN implementation would be very welcome, i imagine, for various prop usages in harsh/noisy environments (industrial, automotive, etc)
  • godzichgodzich Posts: 74
    edited 2008-11-06 08:11
    Hi,

    I was wondering the same -how come no-one has·already designed a CAN PASM object? Or if someone has, then he/she does not want to share [noparse]:([/noparse]

    Running a full CAN protocol at full speed (1Mbit/s) in PASM on only one COG would be no problem whatsoever - if well written. I have myself also considered writing one. In any case, you will need the external tranciever chip, whatever CAN solution you use. That is just a simple and cheap level converter. Such chips exists that runs on 3.3V, the same voltage as the prop is using.

    Any higher level protocols must run on an additinal COG(s), but the emulation of a CAN controller would probably fit nicely into one COG. Such an (well documented and well implemented) object would be a welcome addition in the object exchange forum. Wonder why not the guys at Parallax already have written one, it would emphasize the propeller's status in embedded industrial applications?! Ok, the folks at Parallax are busy designing Prop II and writing better documentation for the Prop I tongue.gif

    Christian

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    The future does not exist - we must invent it!
Sign In or Register to comment.