<div dir="ltr">Two thumbs up for MBED! I really like the web based development, which allows easy coding "in the cloud" from anywhere without the trouble of having to install something locally. I'm working with another friend on a "gid meter" for the leaf that uses the mbed, CANary (search for it on mynissanleaf or mbed projects). Not that there's much you could port from that but I feel I could make a bigger contribution for the Leaf port if you go that route. :-) The CANary uses the LPC1768 variant (cortex M3).<div><br></div><div>Jeremyh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 30, 2014 at 7:56 AM, Mastro Gippo <span dir="ltr"><<a href="mailto:gipmad@gmail.com" target="_blank">gipmad@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi Mark! I will review the options and give my 2 cents later, as I'm writing this mail while sitting at the open source hardware summit and I'm meeting a lot of interesting people here. Of them, Eric Pan from seeed studio showed me this option that recently emerged: <a href="http://www.seeedstudio.com/depot/LinkIt-ONE-p-2017.html" target="_blank">http://www.seeedstudio.com/depot/LinkIt-ONE-p-2017.html</a><br>
Hope that doesn't shuffle the cards too much again! :) <br>
Regards<span class="HOEnZb"><font color="#888888"><br>
Mastro Gippo <br>
</font></span></p>
<div class="gmail_quote"><div><div class="h5">On Sep 30, 2014 4:34 PM, "Mark Webb-Johnson" <<a href="mailto:mark@webb-johnson.net" target="_blank">mark@webb-johnson.net</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div style="word-wrap:break-word"><div><br></div>And the winner is (or at least who I think the winner should be):<div><br></div><div><u><b>MBED (and probably Freescale </b></u><b><u>K64F variant)</u></b></div><div><u><b><br></b></u></div><div><div style="margin:0px;font-size:12px"><img alt="unknown.jpg" height="510" width="640" src="cid:4ED855D3-DEC9-4557-8C6D-126632828979"></div></div><div><div><div><br></div><div>Firstly, hats off to Mastro for pointing this out last year. Back then, I didn’t think much of it - it had some good points, but I am very wary of cloud projects, and closed source cloud terrifies me. But, in the past year, the project has come so far, and actually using the hardware left me very impressed.</div><div><br></div><div>I think our decision comes down to two choices:</div><div><br></div><div><ol><li>A Linux base, probably compute-module style, with Megabytes of RAM, Gigabytes of Flash, incredible flexibility but a challenge to keep power consumption down.</li><li>An embedded base, with hundreds of Kilobytes of RAM, Megabytes of Flash, and all the complexities that go along with embedded systems</li></ol></div><div><br></div><div>For me, the MBED architecture now offers a viable compromise between the two. The latest M4 processors give enough flash space (10 times what we have in our OVMS v2 hardware CPU), and RAM (64 times what we have in our OVMS v2 hardware CPU), that the limitation are lifted. More importantly, drag-and-drop programming means that even if flash space became an issue, we could always just offer different firmware for different vehicles - but this time with re-flashing being simply plugging the module into the PC and drag-and-drop the new firmware file in place. Think of it as like having a PICKIT built onto the board, but with the programming software being the file manager of the operating system - the OVMS v3 module shows up as a drive on the desktop and you just drop the new firmware onto it.</div><div><br></div><div>Let me explain, in a little more detail, how MBED works.</div><div><br></div><div><ul><li>The MBED boards actually have two processors. The larger processor runs the end-user application (OVMS in our case), and the smaller processor makes up a system called the MBED HDK, based on the CMSIS-DAP standard.</li><li>The MBED HDK consists of a USB port (standard Micro-B type) connected to the MBED HDK CPU (on the board), some control circuitry, and an ICSP connection to the main CPU.</li><li>When you plug the MBED into the host O/S, it emulates a flash drive; dropping a file onto that drive programs the file onto the main CPU flash.</li><li>It also emulates a serial port to the host O/S so when you plug it in you get a serial port to the main CPU.</li><li>It provides a CMSIS-DAP standard debugger interface (for more advanced debugging).</li><li>The board itself can be powered from the USB, during MBED development or firmware updating.</li><li>As well as support for open source GCC toolchain (and others), the MBED included access to an on-line compiler - the code is kept in the cloud, in a shared revision control system, can be compiled there, and binaries downloaded for installation on the boards.</li><li>There are a large number of open source libraries available for the MBED platform.</li><li>Coding is in C / C++.</li><li>The MBED software includes a RTOS with thread support (which should make our job much easier than the current state-based and interrupt systems).</li><li>There are lots of low-power modes to work with.</li></ul></div><div><br></div><div>The MBED platform provides the lowest barrier-to-entry I’ve ever seen for embedded computing. No serial ports necessary. Just clone the project, tweak, compile, download (with no large IDEs required). Drag-and-drop firmware flashing.</div><div><br></div><div>It is also still raw in places. For example, I purchased an NXP LPC4088 MBED board to also experiment with (512KB flash, 96KB RAM, 32MB SDRAM, dual CAN) - only to find that the firmware on the HDK for that board doesn’t support OSX (despite the board being available for a year). That said, the freescale K64F seems pretty close to what we want, and has no such issues.</div><div><br></div><div>The other part of the puzzle is how we offer this. Some people want displays, other don’t. For 2G GSM one module was fine, but for 3G we need different modules for Asia, Europe and USA. Some want Bluetooth 2.1, others 4.0 BLE. Some want Wifi, others want cheap. Some want expansion. etc. What I’m thinking of is a baseboard design, with plug-in expansion modules.</div><div><br></div><div><ul><li>The baseboard would contain the MBED HDK + main processor, power supplies, as well as connectors for vehicle, diag, expansion, and USB.</li><li>It would most likely be based off the K64F open source architecture.</li><li>We would have several (perhaps 4 or so) plug-in sockets on the baseboard, to allow expansion modules to be plugged in. Each of these sockets would have connections to the main processor as well as expansion ports.</li><li>The baseboard would give OVMS on 1x CAN port.</li><ul><li>A 3G module would provide GSM + GPS (and would expose both antenna connectors to the outside world). The expansion board for this would be the same, but we would solder on different modules depending on the frequencies required.</li><li>A CAN expansion module would use Microchip MCP2515 controllers + MCP2551 transceivers (or something like it) to take SPI bus from the main CPU and expand CAN pins on the vehicle connector. Plug it in, and the system then has one or two more CAN ports available.</li><li>A wifi expansion module would provide WIFI connectivity.</li><li>A Bluetooth expansion module would use the HC-?? style bluetooth SPP modules. Similar to the 3G module, we can simply use the same expansion board - just solder on different bluetooth modules for v2.1 or v4.0 BLE.</li><li>A generic expansion module could be used to add custom functions.</li></ul><li>For the expansion modules, I’m think of two rows of connectors (one on each side) to provide connectivity and support. Very sturdy and cheap. (something like this: <a href="https://www.sparkfun.com/products/10414" target="_blank">https://www.sparkfun.com/products/10414</a>).</li></ul></div><div><br></div><div>Anyway, those are my thoughts, and suggestions given what is available today. I started this v3 search looking for a Linux base, and really had my heart set on it. But I just can’t solve the power and complexity issues. To meet the goals of having something easy to pick up, MBED really seems the only viable option today.</div><div><br></div><div>But, this is no longer my project. There are now so many people involved, and so many end-users. We are about to hit 1,000 users on the <a href="http://openvehicles.com" target="_blank">openvehicles.com</a> website.</div><div><br></div><div>So what do others think?</div><div><br></div><div>Regards, Mark.</div><div><br></div><div>On 17 Jun, 2014, at 9:06 am, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" target="_blank">mark@webb-johnson.net</a>> wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word">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><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/" target="_blank">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><div><br></div></div></div><br></div></div><span class="">_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a><br>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
<br></span></blockquote></div>
<br>_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
<br></blockquote></div><br></div>