[Ovmsdev] CANBus code

[Mark Webb-Johnson]

Yes, we're using the MCC18 compiler from Microchip.

Any help you can provide for this would be most appreciated. For the less experienced developers, the initialisation code (masks, etc) is tough to understand. As you say, all they want is the IDs.

One thing I can do quite easily is to re-work the vehicle.{h,c} interface for vehicle_fn_poll0 and vehicle_fn_poll1. These are the two CAN callbacks. We can easily extract the filter, message ID, and 8 bytes of message, and pass them as arguments to the function. Every vehicle module I've seen does pretty much the same thing with these and putting all that code in one place would save us some flash.

Regards, Mark.

On 23 Sep, 2013, at 8:46 PM, Collin Kidder <collink at kkmfg.com> wrote:

> 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.
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130923/511e1253/attachment.htm>