<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>(changed subject, to better reflect what this discussion is about)</div><div><br></div>Wow, I feel really privileged to have Brian and Mastro involved in this discussion (given both your backgrounds). Thanks for your time and support, guys.<div><br></div><div>Regarding ARM vs PIC, I really have no preference.</div><div><ul class="MailOutline"><li><span style="font-size: 25px; ">Looking at the LPC1769 referenced, it has 512KB flash and 64KB RAM, running at 12MHz, with 4xUART, 2xCAN and USB. US$26.</span></li><li><span style="font-size: 25px; ">Looking at the UWB32 (PIC32MX795), it has 512KB flash, 128KB RAM, running at 80MHz, with 6xUART, 2xCAN and USB. US$40.</span></li></ul></div><div><br></div><div>That said, we wouldn't be using either board directly, so it is probably fairer to compare raw processor prices, and they both seem to cost about the same and have about the same capabilities.</div><div><br></div><div>Quite frankly, 512KB flash in a 32bit platform, vs 96KB flash in an 8bit platform, is not going to make a lot of difference long-term. Sure, we'll have more flash space initially (but remember 32bit code takes up more space then 8bit code), but we'll eventually outgrow it. The extra RAM space will make a difference (64KB/128KB vs 3KB now!). The ability to upload new firmware via USB is a must, as it will allow us to have vehicle-specific firmware and make the most of the available space.</div><div><br></div><div>From the development environment point of view, I don't like either :-( I would really much prefer a completely open source GCC based toolchain - something not crippled by commercial restrictions or dumbed-down for entry level work. Microchip recently changed their policy on the windows compiler, that bit us, and the PIC32 development tools have limited optimisation unless you buy the commercial product. MBED looks good, but seems to suffer from the same sort of issue - although I haven't had time yet to go into detail with this. Both the PIC and MBED libraries look good, but MBED seems easier to work with.</div><div><br></div><div>Anyway, back to the topic at hand, I really want to separate the OVMS v3 project from this simple CAN-USB. Most certainly, the OVMS v3 hardware will have support for CAN BUS logging (most likely to removable flash card, or over the network), but that is a separate discussion to this. What I hope to create here is a very very simple very very cheap device. Something you could build yourself for perhaps US$20-30 parts, or get it retail for perhaps US$40-50. Something that just does this one job, but does it simply and cleanly. Something we can get sponsorship for to give away for free in large numbers, or just to incentivise people or 'seed' the idea of reverse engineering vehicle CAN buses.</div><div><br></div><div>Regards, Mark.</div><div><br><div><div>On 3 Sep, 2013, at 6:24 AM, HONDA S-2000 <<a href="mailto:s2000@sounds.wa.com">s2000@sounds.wa.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">How much is your CAN expansion board for the MBED?<br><br>I'm not sure what the difference is between the LPC1769 that you recommend and the LPC1768 that MBED lists as currently available. One obvious difference is that the LPC1769 is about US$118. The LPC1768 is $49<br><br><a href="http://mbed.org/handbook/Order">http://mbed.org/handbook/Order</a><br><br>My concern is that by the time you make the CAN expansion board, with all the costs associated with that, you might as well put the main CPU on the same board and not be stuck buying a retail platform. Buying two boards is surely going to cost more than one, unless there is something tricky like radio antenna design involved.<br><br>As for PIC versus ARM or even AVR or MSP430, it doesn't really matter what the processor is. All of these CPU chips have $49 or even $5 (MSP430) evaluation boards and device support libraries.<br><br>Brian Willoughby<br>Sound Consulting<br><br><br>On Sep 2, 2013, at 04:11, Mastro Gippo wrote:<br><blockquote type="cite">Hi Mark,<br>I'd like to throw my 2 cents to the discussion.<br>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.<br>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.<br><br>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.<br>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:<br><br>#include "mbed.h"<br><br>#include "USBSerial.h"<br><br>//Virtual serial port over USB<br><br>USBSerial serial;<br><br>int main(void) {<br><br> while(1)<br><br> {<br> serial.printf("I am a virtual serial port\r\n");<br><br> wait(1);<br><br> }<br><br>}<br><br>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.<br><br>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<br>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.<br><br>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.<br><br>Regards<br><br>Cristiano<br><br><br><br>Il giorno 29/ago/2013 03:25, "Mark Webb-Johnson" <mark@webb-johnson.net> ha scritto:<br><blockquote type="cite">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.<br><br></blockquote></blockquote>_______________________________________________<br>OvmsDev mailing list<br>OvmsDev@lists.teslaclub.hk<br>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br></blockquote></div><br></div></body></html>