[Ovmsdev] CANBus code

[Collin Kidder]

I figured that the reason was something along those lines. Our progress
with GEVCU has been a bit slow at times because we're actively trying to
find such situations where things are too heavily tied to hardware and
abstract. Of course, we're using an ARM Cortex M3 which is 84MHz and almost
all instructions are single cycle. You're using a PIC chip and I assume you
run 16-20MHz which puts your processor speed at somewhere around 4-5MIPS
instead of the 84MIPS I've got to work with. So, I'm sensitive to the fact
that you can't really go the gonzo C++ abstract everything route that we
did.

I actually have done a lot of PIC18 programming in the past, including
CANBus programming. However, I was using the CCS compiler which has its own
canbus library. So, actually I don't really know of a good library suitable
for adoption. However, you've got it all right there in your code base
anyway. I don't see much reason that a library could not be bootstrapped by
copy/pasting canbus initialization and transmit to a new file and making
them a little more generic so that each car module can call them. From
there it would be necessary to decide just how all encompassing the library
should end up being. I'm actually the primary author of the canbus library
for the Arduino Due and I'm thinking of making that library easy enough to
use that one could write a line like this: CAN.setFilter(2, 600, 620,
CAN_STD); in order to create a filter for mailbox 2 that allows canbus
frames with id's from 600 to 620. Currently the library requires one to
input the mask and filter but I'm wondering if the end programmers really
need to care that much about how canbus works. It seems like the average
programmer will be more interested in getting the code to work with their
car. They know the ids of the frames they need so asking for the id range
seems easier on the programmer. Sure, it's harder on the writer of the
library but you only have to do it once.

I don't have any OVMS hardware but I do still have several PIC18 based
devices hanging around so maybe I'll try to come up with a decent PIC18
canbus library that isn't encumbered by license restrictions. Refresh my
memory, which compiler are you using? The free, non optimizing one you can
get with MPLAB?


On Mon, Sep 23, 2013 at 3:03 AM, Mark Webb-Johnson <mark at webb-johnson.net>wrote:

>
> I guess the answer to your question comes from the growth of OVMS from a
> project supporting one single EV to where it is today.
>
> When we switched from the single-vehicle model, to the vehicle.{h,c}
> plugin(sic) vehicle module arrangement, we did largely abstract out the
> interrupt handler and CAN message reception (so that the vehicle module
> gets the incoming CAN bus message in a simple subroutine callback), but we
> haven't done much to abstract either message transmission or CAN bus
> initialisation. Both would be sensible to do at this stage, as there is now
> considerable duplication in the individual vehicle modules. I think this
> can be cleanly done by extensions to vehicle.{h,c}. In particular, the
> polling arrangements for OBD-II style arrangements are good candidates for
> this. We do have to be careful, as that would be shared code and would
> increase firmware size for modules not using it (in particular the v1
> hardware support we are trying to maintain).
>
> Regarding using a CAN bus library, the answer is that I don't know of a
> good one. There is a Microchip PIC18C version, but it really does little
> other than very trivial abstraction. Do you, or anyone else, know of any
> good PIC18 CAN/ECAN libraries suitable for adoption?
>
> Regards, Mark.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20130923/45d0d43f/attachment.html>