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.