[Ovmsdev] OVMS v3

Tue Oct 7 16:17:08 HKT 2014

Here I am! I'm happy that I helped choosing the platform, I really like the
mbed. I like even more the freescale version, as they are one of the
biggest names in automotive microcontrollers (even if our model is not an
automotive-specific one). There are devices in the same product line that
have 2 CAN buses. I had a quick chat with a Freescale engineer, John
McLellan, and asked him about the Mbed porting; he confirmed that the
binaries should be cross-compatible between similar products, and it
shouldn't be hard to add support for the second CAN bus. So we can start
developing for the Mbed board and then use another chip in production with
little effort. His office is just across the road from Mbed offices in
Austin, TX, and he told me to write him an email and he will investigate
the matter further. We even hypotized using the OVMS as a basic development
platform. So, if anyone have more questions for him, just ask and then we
can prepare an email with everything.
About the Mbed HDK, I'm not really sure if it's the right thing to include
it in the final product; it adds cost and occupies precious space. I would
find a way to use a simple bootloader.
Another note: as Jeremy points out, and as I proposed from the start, the
NXP board have 2 CAN buses and a very cheap (34$) development board
available http://www.nxp.com/demoboard/OM13000.html and has an integrated
*real* debugger that can be detached by sawing the board to save space.
Regards
Mastro Gippo

2014-10-01 21:17 GMT+02:00 Jeremy Whaling <jeremy.whaling at gmail.com>:

> 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
>>
>>
>
> _______________________________________________
> 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/20141007/5cb9d078/attachment.htm>