
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div>OK. I’ve completed an (exhausting, taken up far too many evenings over the past three months) review of what is available. Below are my summary conclusions on each of the hardware platforms I’ve tried.<div><br></div><div>This eMail just shows the five options. The follow-up eMail explains which one I think is best, and why. I’ve provided links for further reading, and am willing to answer questions on any.</div><div><br></div><div>Regards, Mark.</div><div><br></div><div><u><b>1] PIC32 (I tried UBW32 devkit, based on PIC32MX795)</b></u></div><div><br></div><div><a href="http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC32MX795F512L">http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC32MX795F512L</a></div><div><a href="https://www.sparkfun.com/products/9713">https://www.sparkfun.com/products/9713</a></div><div><div style="margin: 0px; font-size: 12px;"><img alt="unknown.jpg" apple-inline="yes" id="72D6C6B0-53F8-4B93-B798-47686F777CFB" height="206" width="640" apple-width="yes" apple-height="yes" src="cid:C33D84A0-41C0-418D-AB5F-BE83D7B8C331"></div></div><div><br></div><div>Specification:</div><div><br></div><div><ul class="MailOutline"><li>PIC32MX795 32bit CPU @80MHz</li><li>128KB of RAM</li><li>512KB of Flash</li><li>USB Bootloader (with special client OS software for firmware upload)</li><li>2xCAN</li><li>Embedded design</li><li>Power consumption: 120mA (@5V) = 0.6W</li></ul></div><div><br></div><div>Pros: Cheap, dual CAN, low power with plenty of lower power modes.</div><div>Cons: Microchip Toolchain, Microchip proprietary libraries, steep learning curve.</div><div><br></div><div>Similar to what we are doing today with OVMS v1 and v2 - just a more powerful CPU with more ram + flash.</div><div><br></div><div>Biggest drawback is the horrible proprietary Microchip development environment and libraries.</div><div><br></div><div><u><b>2] BeagleBone Black</b></u></div><div><br></div><div><a href="http://beagleboard.org/black">http://beagleboard.org/black</a></div><div><div style="margin: 0px; font-size: 12px;"><img alt="unknown.jpg" apple-inline="yes" id="2EE4D9AA-271A-4BC9-BF08-A31DEA97B942" height="486" width="640" apple-width="yes" apple-height="yes" src="cid:F80583D2-35D7-499C-8A9E-7C84F9E8725F"></div></div><div><br></div><div>Specification:</div><div><br></div><div><ul class="MailOutline"><li>AM335x ARM® Cortex-A8 @1GHz</li><li>512MB of RAM</li><li>4GB of Flash</li><li>USB plug-and-play disk</li><li>No CAN</li><li>Linux O/S</li><li>Power consumption: 300mA - 450mA (@5V) = 1.5W - 2.25W</li></ul></div><div><br></div><div><div>Pros: Plenty of RAM+Flash, plug-and-play.</div><div>Cons: Power consumption, complex low-power modes, lack of CAN although better connectivity that Pi.</div></div><div><br></div><div>The idea here is that we use the beagle bone black as the base, then add our stuff as a plug-in board (called ‘cape’) on top.</div><div><br></div><div>I like this one, but the biggest drawback is power consumption. We’d also have a lot of messing about to do with the kernel to get support for anything other than USB.</div><div><br></div><div><u><b>3] Raspberry Pi</b></u></div><div><br></div><div><a href="http://en.wikipedia.org/wiki/Raspberry_Pi">http://en.wikipedia.org/wiki/Raspberry_Pi</a></div><div><div style="margin: 0px; font-size: 12px;"><img alt="unknown.jpg" apple-inline="yes" id="0B4444BC-F97F-4F0E-8FCD-90C97BEE3E6B" height="476" width="640" apple-width="yes" apple-height="yes" src="cid:44261ECF-A91D-4AB4-AFF8-DAC746A38075"></div></div><div><div><div><br></div><div><div>Specification:</div><div><br></div><div><ul class="MailOutline"><li>ARM1176JZF-S (ARMv6k) @700MHz</li><li>256MB or 512MB of RAM</li><li>Flash via SD-Card</li><li>No USB plug-and-play or disk mode</li><li>No CAN</li><li>Linux O/S</li><li>Power consumption: 400mA (@5V) = 1.5W - 2.0W</li></ul></div></div><div><br></div><div><div><div>Pros: Cheap for Linux.</div><div>Cons: Power consumption, complex low-power modes, lack of CAN and poor expansion.</div></div></div><div><br></div><div><div>The idea here is that we use the raspberry pi as the base, then add our stuff as a plug-in board on top. Alternatively, there is also the Raspberry Pi compute platform, which would plug into our board just like the CM-T355 below.</div></div><div><br></div><div>Biggest drawback is power consumption, and lack of I/O. The beagle bone black really seems to beat out the Raspberry Pi for connectivity options.</div><div><br></div><div><u><b>4] CM-T335 Compute Module</b></u></div><div><br></div><div><a href="http://compulab.co.il/products/computer-on-modules/cm-t335/#specs">http://compulab.co.il/products/computer-on-modules/cm-t335/#specs</a></div><div><div style="margin: 0px; font-size: 12px;"><img alt="unknown.jpg" apple-inline="yes" id="6F02A16D-2A9F-4E53-8E44-BAF3D92ABDB0" height="514" width="640" apple-width="yes" apple-height="yes" src="cid:A7102EF0-26DE-42E1-9B48-3C8EF406B46F"></div></div><div><br></div><div><div><div>Specification:</div><div><br></div><div><ul class="MailOutline"><li>Texas Instruments AM3354 CPU @600MHz</li><li>128MB to 512MB of RAM</li><li>128MB to 1GB Flash</li><li>No USB plug-and-play or disk mode</li><li>Up to 2x CAN</li><li>Optional WIFI+Bluetooth on-board</li><li>Linux O/S</li><li>Power consumption: 40mA - 120mA (@12V) = 0.5W - 1.5W</li></ul></div></div></div><div><br></div><div><div><div>Pros: Embedded Linux, dual CAN, built-in-wifi+bluetooth.</div><div>Cons: Complex low-power modes, restricted I/O options.</div></div></div><div><br></div><div>The idea here is that we build our own base board with all the I/O we need, and plug in this module to provide the compute power (and wifi/bluetooth connectivity).</div><div><br></div><div>Biggest drawback is price, and restrictive options on I/O connectivity.</div><div><br></div><div><u><b>5] MBED (Freescale freedom FRDM-K64F)</b></u></div><div><br></div><div><a href="https://mbed.org/platforms/FRDM-K64F/">https://mbed.org/platforms/FRDM-K64F/</a></div><div><div style="margin: 0px; font-size: 12px;"><img alt="unknown.jpg" apple-inline="yes" id="688BE974-EC11-43CE-9BBF-73BB0AF8E91A" height="510" width="640" apple-width="yes" apple-height="yes" src="cid:76CB1185-176B-4A7D-B935-31A475D88DDA"></div></div><div><br></div><div><div>Specification:</div><div><br></div><div><ul class="MailOutline"><li>Freescale K64F Kinetis K64 MCU (MK64FN1M0VLL12) @120MHz</li><li>256KB of RAM</li><li>1MB of Flash</li><li>USB plug-and-play (both disk and serial, although serial needs driver for windows)</li><li>1xCAN</li><li>Embedded design</li><li>Power consumption: 190mA (@5V) = 1W</li></ul><div><br></div></div></div><div><div><div>Pros: Plenty of RAM+Flash, plug-and-play disk + serial, RTOS, low barrier to entry.</div><div>Cons: Only single CAN, dual CPU arrangement.</div></div></div><div><br></div><div>The idea here is that we use our own board, based on the open source schematics of this one. This would be a reference design that we would tweak to do what we need.</div><div><br></div><div>Biggest drawback here is complexity. We’ve got to build it all ourselves.</div><div><br></div><div>ENDS</div><div><br></div><div>On 17 Jun, 2014, at 9:06 am, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net">mark@webb-johnson.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Mastro,<div><br></div><div>Actually, an opportune time as I've made some progress. I'll reply to your mail here, but take into account the follow-up discussions.</div><div><br></div><div><ul class="MailOutline"><li>The requirements of the OVMS community are diverse. Some want pre-heating, some want relay control, some want a display, some want to reprogram their ECUs, some want GSM, and others want none of these. What we are trying to build is a framework that can be adapted by others.<br><br></li><li>I am stunned that nothing like this exists on the market. I've spent the past six months looking for a low-power, low-cost, module with wifi+bluetooth and a development environment. Linux/RTOS/whatever. But, I haven't found anything perfect. I understand Kevin's frustration - it seems that GEVCU and OVMS could base on the same hardware, but even with that there appear to be difference in requirement that would just drive up costs for OVMS (or drive down functionality for GEVCU).<br><br></li><li>On the GEVCU front, I tend to agree with Rickard's comment that the two systems complement each other, but are very different. OVMS could be a telematics module for GEVCU, and would add great functionality to that project.<br><br></li><li>I spent some time looking at a modular approach. Design a base board with CPU, power and CAN buses. Have that base board support plug-in modules for wifi, bluetooth, cellular, etc. In that way, we can use pre-certified modules, and the user buys what they need. But, the problem with this approach is that if what you need is bluetooth+wifi+cellular, the cost is driven up considerably.<br><br></li><li>Talking to the China factories, it turns out that bluetooth/wifi is cheap as hell and trivial to implement - so long as we are ARM based. They laugh when we mention Microchip. They are stunned when we say we don't run Linux.<br><br></li><li>A data plan just for the car is expensive (particular in some countries like USA), but if we can offer hotspot functionality then it can be shared with other devices in the car. For that, we would need to be Linux based.<br><br></li><li>On the power front, I don't really see the problem as being low power while running, but rather the ability to support a sleep mode when the car is off. We don't need low power always - we just need it for the 90% of the time the car is sitting idle, not charging, not driving. The CPU is not an issue here - they all support a deep sleep mode and we can reduce power requirement to quite literally a trickle. The problem is the comms. We need to be able to be remotely 'woken up' and keeping these GSM/Wifi/Bluetooth modules low power while supporting network stacks is just not possible. The established industry uses USSD messages to remotely wake up their systems, and now I understand why. A GSM module can be designed to be in deep sleep, with very little power usage, but still able to receive a USSD message.<br><br></li><li>GSM modules like the TELIT and SIMCOM are interesting in that they support running code inside the module itself. This is something we haven't taken advantage of, but offers us the opportunity of offloading a significant amount of what we do.<br><br></li><li>For me, the requirement comes down to a base framework and module that supports:<br></li><ul><li>32bit CPU with enough grunt, and a low-power sleep mode</li><li>Dual CAN</li><li>Async + I2C + SPI + GPIO expansion</li><li>SD-Card</li><li>USB</li><li>Lots of RAM and FLASH</li><li>Wifi</li><li>Bluetooth</li><li>Optional GSM</li><li>Optional display (or can we get away with bluetooth to a cellphone?)<br><br></li></ul><li>What is interesting is the advent of low-cost Linux frameworks that are very close to what we need. Things like the BeagleBone and RasberryPi are fascinating, but really designed for HDMI video output - and the overhead of GPU + HDMI is a huge power drain. The closest I've found to what we require is (<a href="http://compulab.co.il/products/computer-on-modules/cm-t335/">http://compulab.co.il/products/computer-on-modules/cm-t335/</a>) - pretty amazing little device - low power, wifi+bluetooth, dual CAN, up to 512MB RAM and 1GB FLASH, for around US$50 (in horrendous quantities). I'm working with my contacts in China to see if we can base on a dev board something like that. If they can make Android phones for US$50, we should be able to get the guts of such a device for something similar. Then, add on GSM, take it from a BOM to a product, and we're probably looking at something still <US$150 but with so much more. The closest thing to ideal I've found at the moment is build a baseboard (connectors, power, CAN buses, etc) and have slots to take that CM-T335 module and an optional GSM module. But, I still think we can find something on the China market even closer to what we want/need.</li></ul></div><div><br></div><div>Anyway, those are my thoughts. My conclusion is that to me it seems sensible to work from a low-power linux base with built in dual-can, wifi + bluetooth.</div><div><br></div><div>Regards, Mark.</div></div></blockquote></div><br></div></body></html>