[Ovmsdev] OVMS v3

[Mastro Gippo]

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:
http://www.seeedstudio.com/depot/LinkIt-ONE-p-2017.html
Hope that doesn't shuffle the cards too much again! :)
Regards
Mastro Gippo
 On Sep 30, 2014 4:34 PM, "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)*
>
> [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/202eede4/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/202eede4/attachment-0002.jpg>