This all sounds good.
I agree with eliminating the FT232RL. The PIC32MX795 can maintain the
serial USB feature or use a custom class USB for easier control
protocol. Serial can be more cumbersome and error prone because all
bytes are equivalent, and you have to rely upon parsing to identify
individual commands and data. Custom class USB allows you to use the
features of USB that separate commands from data and make the size of
the transfers more definitive.
OSX allows standard applications to access custom USB devices without
a custom driver.
Linux hopefully allows the same by using libusb, although I have no
experience there.
Windows seems to require a driver for everything, but I don't know
the actual limitations.
You'll probably need a USB VID and PID (Vendor ID and Product ID). If
you don't already have one then Microchip might make a PID available
once you fill out their request paperwork.
Any reason to avoid the 12V vehicle power? I suppose that simplifies
the hardware. This USB-CAN device is not useful for much except
logging unless it is plugged in to a USB host. On that note, perhaps
it's worth designing the PCB for a 12V power option, but perhaps not
populate the parts, so that someone who wants to do unattended
logging could power the board without a laptop sitting in the car.
You may not need a switch for program versus run mode - at least I've
gotten away without one, but it does make it easier for field
firmware upgrades, I suppose, if there is a switch. With the right
circuit, it might be possible to leave the switch off the PCB for the
commercial product, assuming that saves money and firmware upgrades
are not frequent.
I'll study the CAN232 manual and Sparkfun UBW32 schematic...
Brian Willoughby Sound Consulting
On Sep 1, 2013, at 18:56, Mark Webb-Johnson wrote:
Brian,
OK, let's concentrate on hardware first.
So far, as far as I've got is prototyping something using:
UBW32 (https://www.sparkfun.com/products/9713) PIC32MX795
development board.MCP2551 CAN controller (http://www.microchip.com/wwwproducts/ Devices.aspx?dDocName=en010405).
FT232RL based converter (https://www.sparkfun.com/products/718).
The FT232RL was just wired to the first async port of the PIC32,
and the MCP2551 connected straight to the PIC32 as well using the
normal CAN controller ports.That was the prototype. For production, I don't think we need the
FT232RL at all. We should be able to use the PIC32 USB and have it
present as a serial port to the host (windows, linux, osx,
Android?). I have played around some with the PIC USB library (I
built a little HID keyboard media player for my car - https:// github.com/markwj/hidmedia). But, I haven't spent much time with
the PIC32 USB framework as a serial port and have no idea how the
driver support works.Components wise, I reckon we need:
USB connector, and support components 5V-3.3V power regulator PIC32MX795 and support components MCP2551, and support components DB9 connector, either "standard" CAN-on-DB9 or OVMS-on-DB9 pinout Switch for program/run mode ICSP pins Case
I suggest to power from the USB port, not from the vehicle side
12V. The MCP2551 (and CAN bus) is 5V, but I think can be powered
directly from the USB port. The PIC32MX795 is 3.3v. But, both are
tolerant and seem to be able to be inter-connected without any
issues (the MCP2551 trigger level is <3.3V, and the PIC32MX795 is
5V tolerant on the CAN RX pin).I've used these products:
and they have a simple serial API that I am already using with my
CAN-RE-TOOL:http://www.can232.com/docs/canusb_manual.pdf
I've discussed with the factory in China, and it seems fairly
simple. They have done similar projects before, using the case
shown below. Plenty of room and we can either use a USB type B
socket, or type A plug on the end of a soldered-in cable. The PIC32
is definitely overkill, but given the price of the chip, I don't
think it is much of an issue - it will give us plenty of room to do
whatever we need.Regards, Mark.