[Ovmsdev] OVMS v3

Wed Oct 1 19:07:56 HKT 2014

It¹s been interesting to watch the GEVCU development and the inevitable move
to a more robust hardware platform which will be based on the Cinch
Enclosure and connector (version 6). Something many people wanted at the
start of the project.

IMO we need a robust hardware platform and the more we can focus software
developers on a single platform the better for us allŠ my vote is hardware
that¹s compatible with GEVCU and the amazing libraries that exist today
(including Colin¹s excellent CAN library).

Kevin Sharpe | Founder & Chair of Trustees
Tel: +44 122 566 7544 ext: 800 | Skype: zerocarbonworld
kevin.sharpe at zerocarbonworld.org  <mailto:kevin.sharpe at zerocarbonworld.org>
| www.zerocarbonworld.org <http://www.zerocarbonworld.org/>  |
twitter.com/zerocarbonworld <http://twitter.com/ZCWcharlie>

Zero Carbon World is a UK Registered Charity #1141347
From:  Collin Kidder <collink at kkmfg.com>
Reply-To:  OVMS Developers <ovmsdev at lists.teslaclub.hk>
Date:  Tuesday, 30 September 2014 15:53
To:  OVMS Developers <ovmsdev at lists.teslaclub.hk>
Subject:  Re: [Ovmsdev] OVMS v3

I haven't really been involved with your OVMS project but I have continued
to follow it with interest. I really like what you're doing. With the GEVCU
project we went through much the same discussion you're having. We obviously
settled on using the Arduino Due (eventually rolling our own board based on
the Cortex M3 from the Due). The MBed has many similarities to the Arduino
Due hardware-wise but uses a totally different development environment and
library.

Ultimately I think you are making the right choice. It's very tempting to
see something like the BeagleBone Black and want to go that route. But,
development of code for something like the BBB is much more complicated
unless you write it all in Python. LINUX is awesome on the desktop but I'm
not convinced that it is worth the trouble for small embedded projects.
Dealing with the complications that linux brings will just make the project
more complex and difficult to jump into.

I know of other people using the MBED platform for vehicle use and it seems
to be going well for them. I don't see anything really wrong with MBED and I
think it will serve your uses very well. In my view going with the MBED
platform would serve you well and propel your project into the future.

-Collin Kidder

On Tue, Sep 30, 2014 at 10:34 AM, Mark Webb-Johnson <mark at webb-johnson.net>
wrote:
> 
> And the winner is (or at least who I think the winner should be):
> 
> MBED (and probably Freescale K64F variant)
> 
> 
> 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.
> 
> I think our decision comes down to two choices:
> 
> 1. A Linux base, probably compute-module style, with Megabytes of RAM,
> Gigabytes of Flash, incredible flexibility but a challenge to keep power
> consumption down.
> 2. An embedded base, with hundreds of Kilobytes of RAM, Megabytes of Flash,
> and all the complexities that go along with embedded systems
> 
> 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.
> 
> Let me explain, in a little more detail, how MBED works.
> 
> * 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.
> * 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.
> * 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.
> * 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.
> * It provides a CMSIS-DAP standard debugger interface (for more advanced
> debugging).
> * The board itself can be powered from the USB, during MBED development or
> firmware updating.
> * 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.
> * There are a large number of open source libraries available for the MBED
> platform.
> * Coding is in C / C++.
> * The MBED software includes a RTOS with thread support (which should make our
> job much easier than the current state-based and interrupt systems).
> * There are lots of low-power modes to work with.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> * The baseboard would contain the MBED HDK + main processor, power supplies,
> as well as connectors for vehicle, diag, expansion, and USB.
> * It would most likely be based off the K64F open source architecture.
> * 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.
> * The baseboard would give OVMS on 1x CAN port.
>> * 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.
>> * 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.
>> * A wifi expansion module would provide WIFI connectivity.
>> * 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.
>> * A generic expansion module could be used to add custom functions.
> * 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: https://www.sparkfun.com/products/10414).
> 
> 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.
> 
> 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 openvehicles.com
> <http://openvehicles.com>  website.
> 
> So what do others think?
> 
> Regards, Mark.
> 
> On 17 Jun, 2014, at 9:06 am, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
>> Mastro,
>> 
>> 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.
>> 
>> * 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.
>> * 
>> * 
>> * 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).
>> * 
>> * 
>> * 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.
>> * 
>> * 
>> * 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.
>> * 
>> * 
>> * 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.
>> * 
>> * 
>> * 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.
>> * 
>> * 
>> * 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.
>> * 
>> * 
>> * 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.
>> * 
>> * 
>> * For me, the requirement comes down to a base framework and module that
>> supports:
>>> * 32bit CPU with enough grunt, and a low-power sleep mode
>>> * Dual CAN
>>> * Async + I2C + SPI + GPIO expansion
>>> * SD-Card
>>> * USB
>>> * Lots of RAM and FLASH
>>> * Wifi
>>> * Bluetooth
>>> * Optional GSM
>>> * Optional display (or can we get away with bluetooth to a cellphone?)
>>> * 
>> * 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 (http://compulab.co.il/products/computer-on-modules/cm-t335/) - 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.
>> 
>> 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.
>> 
>> Regards, Mark.
> 
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 

_______________________________________________ OvmsDev mailing list
OvmsDev at lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20141001/625645b7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknown.jpg
Type: image/jpeg
Size: 125629 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20141001/625645b7/attachment-0002.jpg>