[Ovmsdev] OVMS CAN-USB Call for Assistance

Wed Sep 4 21:53:30 HKT 2013

Yes, they don't say much, but my gues is that it's just an atmega
(just to add another mcu to the list! :) ) with 3 mcp2515 SPI
controllers + transceivers. Let us know if they tell you more! :)
 MG

2013/9/4 Mark Webb-Johnson <mark at webb-johnson.net>:
> The canb.us system looks cool. But, short on details. I'll contact them to see if they have more detail on the circuit design.
>
>> On 3 Sep, 2013, at 8:19 pm, Mastro Gippo <gipmad at gmail.com> wrote:
>>
>> Here are my considerations:
>> - the final device will obviously not be an mbed expansion board, but
>> will be a single board with just the mcu. Starting with the mbed is
>> good because all the hardware is already laid out well, especially the
>> ethernet chipset (I was not confident about messing around with it).
>> Also, buying one mbed gives you access to the online compiler and all
>> the libraries, just see it as a "license" and a "donation" to support
>> the project. Then you can move to the lpcxpresso for the next
>> prototypes, and for the final version you just make your own pcb.
>> These boards are very handy to have around anyway.
>> - the ARM core runs at 96mhz, postscaled from the 12mhz crystal
>> - I'm not 100% sure about it, but from what I recall it is possible to
>> load code from an external source on the ARM device, so virtually no
>> limits there. And while it's true that 32 bit code will take up more
>> space, it's also true that you should be able to optimize it better
>> having a bigger instruction set. Finally, while the PIC is in the
>> higher range of microchip's portfolio, the ARM is in the middle-low
>> range of the NXP portfolio, so it may be upgradable now or in the
>> future.
>> - it's been a while since I last looked up C compilers for PICs, but
>> there should be some gcc compiler available. Project pinguino comes to
>> mind: http://pinguino.cc/ they claim that they have a gcc toolchain
>> for PIC32. I'm pretty sure that mbed have a gcc toolchain too.
>> - I just found out about another new project, the Canbus triple:
>> http://www.canb.us/ apart from having an awesome domain name, they
>> made that cool device for a price point that is just 15$ above your
>> target. Maybe you can contact them to arrange a collaboration.
>> Regards
>> Cristiano
>>
>>
>> 2013/9/3 Mark Webb-Johnson <mark at webb-johnson.net>:
>>>
>>>>>> 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.
>>>> 128KB can be enough if the logging is both specific to a certain subset of messages, and compressed or compacted. In any event, I imagine that a simply USB charger could keep the board powered for unattended logging.
>>>
>>> Neat idea. That can keep the cost down, and keep things simple. Just a little cigarette lighter USB charger, or perhaps one of those external batteries, should do the job.
>>>
>>>>> 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).
>>>> So, passives do not count as a whole component, not compared to a chip?
>>>
>>> Supposedly not. Or, at least they don't concern themselves with them. I suspect that the factories have rolls of hundreds of thousands of these components, ready to go. Sometimes if I specify a 2.3k resistor, for example, they will come back and ask to substitute with 2.2k - but that happens surprisingly rarely. Their biggest concern seems to be the ICs - or maybe they are just concentrating on things that cost more than a buck.
>>>
>>> Years ago, I remember we were hand-building these little opto-isolation circuit boards for US$15 a piece. We needed a batch of about 200, and the factory came back with a few minor changes and a minimum order quantity of 2,000 at a per-unit cost of US$1. So, we got 2,000 of them for less than the price of our hand-built 200. It is amazing how cheaply things can be in quantity from China. And, for all people denigrate the Chinese factories, quality can be amazing if you find the right people. OVMS v1 (hand built and soldered) was a pain in the arse. OVMS v2 (automated, on a single board) has had <0.5% failure rate.
>>>
>>> For modules like OVMS (and presumably this little CAN-USB), the magic quantity seems to be about 100 nowadays. At that quantity, we can get machine-soldered boards - and the difference between hand and machine soldered is like night and day for quality. At that quantity, we can also get customised metal enclosures (although I suspect the quantity would be higher for a customised plastic enclosure).
>>>
>>> Regards, Mark.
>>>
>>>> On 3 Sep, 2013, at 11:35 AM, HONDA S-2000 <s2000 at sounds.wa.com> wrote:
>>>>
>>>>
>>>> On Sep 2, 2013, at 18:28, Mark Webb-Johnson wrote:
>>>>>> 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?
>>>>
>>>> Offloading is possible no matter what class the device is. Baud-rate is not really the issue. The one thing I've noticed is that the serial protocol can get really messy, and that's basically about separating commands from data, or otherwise detecting the boundaries of packets of information. That's what the USB protocol is good for, and it can really simplify the protocol. Also, I've seen some designs where the device gets stuck in data mode, requiring the device to be restarted to get back into command mode, and that wouldn't be an issue with a custom class.
>>>>
>>>> Multiple interfaces would be a great way to gain the advantages of both approaches, time permitting.
>>>>
>>>>
>>>>>> 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.
>>>> 128KB can be enough if the logging is both specific to a certain subset of messages, and compressed or compacted. In any event, I imagine that a simply USB charger could keep the board powered for unattended logging.
>>>>
>>>>
>>>>> 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).
>>>> So, passives do not count as a whole component, not compared to a chip?
>>>>
>>>>> I really want to get this to DB9 - MCP2551 - PIC32 - USB, with minimal external components.
>>>>
>>>> I don't see why that wouldn't be possible. A lot easier than the OVMS, which has lots of cool features and subboards.
>>>>
>>>> Brian
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev