[Ovmsdev] Incentivising / Rewarding

[Mastro Gippo]

Hi Mark,
I'd like to throw my 2 cents to the discussion.
I'm a professional developer specialized in automotive bus reverse
engineeging, in the past I worked for an automotive diagnostic company and
later for another company that developed electric car conversion kits, and
now I'm the technical director @ eV-Now! foundation Italy.
A while ago I was developing an open source ECU that would allow anyone to
do the CAN bus study with the CAN-USB function and then program the same
device to be an ECU emulator to simulate the presence of a combustion
engine in a converted electric car. Unfortunately, the project was put on
standby for various reasons.

The board, as you can see in the picture, is just an expansion board for
the awesome MBED project (www.mbed.org ) and features an sd card slot, 2
CAN transceivers, an ethernet port and an USB device port. The MBED is
awesome because it offers a lot of cool libraries and even a ready to use
and free RTOS; there is even a library to connect a 3G modem to the usb
host port of the mcu. The compiler is online and allows an easy management
of the project with an integrated cvs system, and if you don't like it,
switching to the offline (proprietary :( but some open source alternatives
based on gcc are already available) IDE is as easy as downloading the
source file. A demo board that is fully compatible with the MBED is
available from
http://www.embeddedartists.com/products/lpcxpresso/lpc1769_xpr.php , and
that includes a programmer and debugger for less than the price of the
PICKIT alone.
I know that switching from a well known platform to ARM may seem like a
very hard choice, I was a PIC lover too, but the MBED library greatly
reduces the effort of porting the code to the new device. For example,
adding an usb serial port is this easy:

#include "mbed.h"

#include "USBSerial.h"

//Virtual serial port over USB

USBSerial serial;

int main(void) {

   while(1)

   {
       serial.printf("I am a virtual serial port\r\n");

       wait(1);

   }

}

So, IMHO, basing the OVMS v3 on the LPC1769 will solve the code space
problem and transform it into an integrated CAN bus developing tool,
providing some cool features at the same time like more power an memory, sd
card data logging and dual CAN channels, for a price per MCU just slightly
higher than the PIC solution. Another advantage is that we can develop a
nice GUI that will help the user for the initial configuration of the SIM
card connecting the OVMS to the USB port.

On the topic of the protocol, I agree on the CAN232 data format, I have
that device too and all the software I've written is compatible with that
protocol API (I may consider sharing some in the future, but it's very
hacked together and specific for my job). Also, friends from the linux
community have already integrated the support on the socketcan driver, and
provided a very nice comparison of different devices APIs here:
ftp://ftp.heanet.ie/disk1/sourceforge/s/so/socketcan.berlios/SLCAN-API.pdf
I think that it will be a breeze to implement that protocol, and I can help
making it happen for very cheap (or even for free if I find some spare time
and motivation), on the mbed platform.

Let me know if you need a PCB to test, I have some spare ones that you can
solder components on, but as (I seem to understand that) you are based on
hong kong, it may be cheaper to reproduce them locally from gerbers than to
ship them from here.

Regards

Cristiano


Il giorno 29/ago/2013 03:25, "Mark Webb-Johnson" <mark at webb-johnson.net> ha
scritto:

>
> I would like to devise something to incentivise / reward people working on
> this project. Something beyond the personal satisfaction, and giving back
> to the community.
>
> What I'm thinking is to donate hardware modules to people working on new
> vehicle support. It would work something like this:
>
>
>    1. Someone steps forward to take on support for a particular vehicle.
>    2. That developer buys the hardware module, and accessories, as normal.
>    3. The vehicle_xxx.c file is written, tested, and gets to a stage
>    where it meets the milestones for that vehicle (the core functionality
>    requirements).
>    4. Open Vehicles either re-imburses the module purchase price, or
>    sends a second module to the developer concerned (option chosen by the
>    developer).
>
>
> In particular, I'd really like to incentivise work on the Leaf and iMiev
> modules.
>
> What about for past contributors? What about for people working on the
> Apps, or other parts of the system?
>
> What do people think? Would this be a good idea, or no use?
>
> Regards, Mark.
>
> P.S. What I would really like to do is get the OVMS CAN-USB adaptor
> working, and then give those out in large quantities. The more people
> decoding vehicle CAN communications, the more cars become open vehicles.
> But, to do that I need some one / people to step forward and help with
> this. The China manufacturer is standing by and asking me for the circuit
> diagram, but I've got too much on my plate at the moment to take on the
> CAN-USB hardware and firmware as well. Using a PIC32 microprocessor (with
> built-in USB support), and MCP2551 CAN controller, we can do this for a
> materials cost perhaps around US$30 (vs US$150 retail for the cheapest
> commercial units). I'll send out a separate 'appeal' for this, and see if
> anyone will step forward to help.
>
> _______________________________________________
> 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/20130902/b27a749d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20130902_105617.jpg
Type: image/jpeg
Size: 483686 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130902/b27a749d/attachment-0002.jpg>