[Ovmsdev] Incentivising / Rewarding

Tue Sep 3 09:28:35 HKT 2013

> 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.

I really would prefer driver-less, if at all possible. A simple serial control VCP. With a powerful-enough processor (and the difference between an 8bit PIC and a 32bit PIC is US$2), we have a lot of opportunity to offload work to the USB-CAN adaptor itself (for example high-level filters), and I don't think we will be baud-rate limited. Perhaps if there is an advantage with custom class USB, we can offer both interfaces?

> 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.

Sending it in now - it is worth a try.

> Any reason to avoid the 12V vehicle power? I suppose that simplifies the hardware.

Yeah, just to keep it simple (and cheap). We would still need 5V->3.3V. Unattended logging would be cool, but only 128KB RAM in the device, and adding an SD-CARD would complicate things.

> 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.

Being able to re-flash the device from USB is definitely a requirement. We don't want people to have to go the PICKIT / ICSP route.

I'll try to rough up a schematic, to see how many components this can be brought down to. For China manufacturers, saving even 1 component brings the cost of both materials and assembly down. I remember working with the factory to remove 1 single chip costing US$1.10 down to a bunch of passive components costing US$0.10 - resulting price difference was US$3 (I think they really didn't want to use that chip, not just for the cost but also for the hassle of obtaining it).

I really want to get this to DB9 - MCP2551 - PIC32 - USB, with minimal external components.

Regards, Mark

On 3 Sep, 2013, at 6:48 AM, HONDA S-2000 <s2000 at sounds.wa.com> wrote:

> 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.
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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