[Ovmsdev] OVMS v3

[Jeremy Whaling]

I forgot to mention in my other post, the LPC1768 *does* have two CAN
buses. The MBED version of it is $50 but it includes things like
an Ethernet transceiver which won't be necessary for a production board.
The chip itself is ~$11 on mouser.

On Wed, Oct 1, 2014 at 11:17 AM, Collin Kidder <collink at kkmfg.com> wrote:

> Yes, of course I wish that you all could go with the GEVCU hardware. It
> was discussed in the past and the GEVCU project is somewhat inching more
> toward what would have worked for OVMS as well. But, the price is certainly
> way over what seems to be tenable for your project. Many of our hardware
> choices were not the cheapest options but people are willing to spend $600
> on an ECU for their car. For telemetrics the cost aspect is much more
> important.
>
> Which is why I said that I think MBED would work fine for you. It is very
> much like the Arduino Due (using a Cortex M4 instead of the Due's M3) and
> seems like a good fit for your project. It's powerful while still being
> reasonably energy efficient, cheap, and easy to program.
>
>
> On Wed, Oct 1, 2014 at 8:00 AM, Michael Jochum <mikeljo at me.com> wrote:
>
>> Hi,
>>
>> i vote for MBED. Linux with C/C++ is fine.
>> i think the price for the GEVCU is to high for this project. Must under
>> $200 for all stuff.
>>
>> Bye
>> Michael J.
>>
>>
>> Am 01.10.2014 um 13:40 schrieb Mark Webb-Johnson <mark at webb-johnson.net>:
>>
>> Kevin, Colin,
>>
>> Last we discussed this, didn't we come to the conclusion that there
>> wasn't enough overlap between the two projects? Different goals, and most
>> importantly, requirements. I am also concerned about the US$600 cost of the
>> gevcu (without stuff like bluetooth, GSM and GPS which we need) - I don't
>> think people are going to pay that much for a telematics module.
>>
>> Or, have things changed?
>>
>> Regards, Mark
>>
>> On 1 Oct, 2014, at 7:07 pm, Kevin Sharpe <
>> kevin.sharpe at zerocarbonworld.org> wrote:
>>
>> 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  <kevin.sharpe at zerocarbonworld.org>|
>> 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)*
>>>
>>> <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
>>>
>>>
>> _______________________________________________ OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>> <unknown.jpg>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>
> _______________________________________________
> 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/20141001/d60e24dc/attachment.htm>