[Ovmsdev] OVMS v3

Collin Kidder collink at kkmfg.com
Tue Sep 30 22:53:44 HKT 2014

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>

> And the winner is (or at least who I think the winner should be):
> *MBED (and probably Freescale **K64F variant)*
> [image: unknown.jpg]
> 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140930/72a8ab8e/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/20140930/72a8ab8e/attachment-0002.jpg>

More information about the OvmsDev mailing list