[Ovmsdev] OVMS CAN-USB Call for Assistance

[HONDA S-2000]

On the topic of support libraries, Microchip has several application  
notes for CAN. These aren't necessary the only ones, or even the most  
appropriate for the PIC32, but they're some I had lying around.

AN853 - PIC18XXX8 CAN Driver with Prioritized Transmit Buffer
AN930 - J1939 C Library for CAN-Enabled PICmicro Microcontrollers
AN945 - A CANopen Stack for PIC18 ECAN Microcontrollers


As for optimization, I looked carefully at the (older) Microchip  
compiler for the PIC18, and found no real significant advantage to  
the optimized output. I decided to recommend that my client not  
bother with the license, since they were seriously strapped for cash.  
I looked at the assembly output for both optimized and unoptimized  
(using the time-limited demo of the full product), and although they  
produced different code, it wasn't exactly a night-and-day  
difference. Both versions seemed to miss out on optimizations that I  
could make with hand assembly. Also, the optimized version which used  
the alternate PIC18 C extensions did not noticeably improve the code  
or make it smaller.

The most important optimization that can be done is intelligent  
coding at the C level. Many programmers waste resources using float  
on an 8-bit that doesn't have direct support, or they repeat  
operations thousands of times unnecessarily. These sorts of problems  
cannot be fixed by an optimizing compiler, and they're much more of a  
problem.


If we're going to consider ARM, then I suggest that someone take the  
time to find out what chips (or circuits) are good candidates for the  
voltage translation. My hunch is that I/O pins on the ARM do not  
directly connect to the 12V CAN bus, especially considering that  
transients of more than 40V might appear. That said, perhaps an ARM  
solution can be accomplished with the same low chip count as the  
proposed PIC32 solution.

Brian Willoughby
Sound Consulting


On Sep 2, 2013, at 18:10, Mark Webb-Johnson wrote:
> From the development environment point of view, I don't like  
> either :-( I would really much prefer a completely open source GCC  
> based toolchain - something not crippled by commercial restrictions  
> or dumbed-down for entry level work. Microchip recently changed  
> their policy on the windows compiler, that bit us, and the PIC32  
> development tools have limited optimisation unless you buy the  
> commercial product. MBED looks good, but seems to suffer from the  
> same sort of issue - although I haven't had time yet to go into  
> detail with this. Both the PIC and MBED libraries look good, but  
> MBED seems easier to work with.
>
> Anyway, back to the topic at hand, I really want to separate the  
> OVMS v3 project from this simple CAN-USB. Most certainly, the OVMS  
> v3 hardware will have support for CAN BUS logging (most likely to  
> removable flash card, or over the network), but that is a separate  
> discussion to this. What I hope to create here is a very very  
> simple very very cheap device. Something you could build yourself  
> for perhaps US$20-30 parts, or get it retail for perhaps US$40-50.  
> Something that just does this one job, but does it simply and  
> cleanly. Something we can get sponsorship for to give away for free  
> in large numbers, or just to incentivise people or 'seed' the idea  
> of reverse engineering vehicle CAN buses.
>
> Regards, Mark.