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.