[Ovmsdev] Incentivising / Rewarding

[HONDA S-2000]

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:
>
> http://www.can232.com
>
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130902/ede62802/attachment.htm>