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.