<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 11, 2016 at 8:30 AM, Mark Webb-Johnson <span dir="ltr"><<a href="mailto:mark@webb-johnson.net" target="_blank">mark@webb-johnson.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Mastro,<div><br></div><div>512KB flash and 64KB RAM really isn’t going to be enough.</div><div><br></div><div>We are already using 100% of 96KB of flash in an 8bit environment (so at least double that for 32bit based on my experience), and that is with excluding a lot of what we really want to do and separating each vehicle out into different firmware. Then we have wifi, bluetooth, can bus logging, SD card support, FAT filesystem, etc, etc. It really wouldn’t surprise me to see our flash usage at 400KB - 500KB at launch (assuming feature set similar to what we have today). 512KB is going to be too tight.</div><div><br></div><div>1MB minimum flash. 128KB minimum RAM (although 256KB would be nice, particularly for logging buffering). I’ve we are dealing with multiple CAN buses, then a fast CPU is a bonus.</div><div><br></div><div>For comparison, the MK66FN2M0VLQ18 chip I’ve narrowed down to has 2MB flash, 256KB ram, is an M4 core, and is clocked up to 180MHz.</div><div><br></div><div>It seems that even NXP/Kinetics is moving to FreeRTOS with their kinetics SDK v2, and so that is probably the direction to choose as well for future platform compatibility. When comparing FreeRTOS vs MQX, they seem pretty much the same. But, FreeRTOS is certainly more portable.</div></div></blockquote><div><br></div><div>Still an ESP32 enthusiast, but yeah, that one has native dual CAN and quad SPI, and an ethernet MII... the power figures at full speed are up to 100mA@3v, kinda scary but it near linear ( 0.55mA/MHz ) and it has deep sleep modes under the mA... as usual, the power is mostly lost in peripherals (GPS, GSM) we really need to find the best way to enable them at will (programmatically, periodically, triggered by an I2C GPIO expander with interrupts when an idiot accidentally puts his arm in my car ;-) ) etc... Poor Twizy barely lasts a few days with the actual module :-(<br><br><br></div><div>JaXX./.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Regards, Mark.</div><div><div class="h5"><div><br><div><blockquote type="cite"><div>On 4 Feb 2016, at 10:29 PM, Mastro Gippo <<a href="mailto:gipmad@gmail.com" target="_blank">gipmad@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div> Well, to add my 2c, I've been working on a new version of the my own "OVMS" I talked about earlier with a LPC1768. I chose that MCU as it's better supported by the mbed with easy USB libraries. Mbed is disappointing me too lately, but that chip is well supported by FreeRTOS too and other toolchains are available.</div><div>I think that a USB/serial/SD bootloader can reduce flash needs (I have 512k), as multi-car firmware will not be needed as users can upload a different version easily. I have a microSD expansion slot for logging and various storage.</div><div>I'm still using a GPRS module, because here in eu I see no signs of that being discontinued anytime soon, and I can't find a 3G-4G module small enough. The GPS is a Ublox 7.</div><div>The board is 4x2cm and can be directly stacked on top of an OBD connector.</div><div>I was also planning on a LoRa/sigfox connection, but they're not exactly "realtime" (a Sigfox packet can take up to 6 minutes to reach the server).</div><div>I think that kinetics are still not user-friendly enough, and that was my main reason to stick with something mbed/arduino compatible to allow more developers to make changes.</div><div>Pic: <a href="http://www.mastrogippo.it/ct-1.jpg" target="_blank">http://www.mastrogippo.it/ct-1.jpg</a></div><div><br></div><div>Regards</div><div>MG</div><div><br></div><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 4, 2016 at 2:47 AM, Mark Webb-Johnson <span dir="ltr"><<a href="mailto:mark@webb-johnson.net" target="_blank">mark@webb-johnson.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Arthur, and others,<div><br></div><div>I’m hitting roadblock after roadblock with these automotive microcontrollers. The chips are expensive, but we could live with that. However, the bigger issue is development environments. It seems that none of the free and open development environments support these automotive processor cores (and a development environment free of encumbrance and easy to get into is one of the fundamental requirements for this project). Kind of frustrating, but when looking at US$30 for a processor, when the Cortex M4 ones are US$7, makes me rethink things.</div><div><br></div><div>I am kind of narrowing down on the Kinetics range from NXP. In particular, MK66FN2M0VLQ18 seems to give us what we need:</div><div><ul><li>ARM Cortext M4, at 180MHz max</li><li>Kinetics free development environment</li><li>2MB flash</li><li>256KB RAM</li><li>2x CAN</li><li>6x UART</li><li>3x SPI</li><li>USB</li><li>Ethernet</li></ul></div><div><br></div><div>Couple it with a CMSIS-DAP (I’m looking closely at <a href="http://www.seeedstudio.com/depot/IBDAP-CMSISDAP-JTAGSWD-Debug-Adapter-p-2568.html" target="_blank">IBDAP</a> as a base for this because of their free open source approach based on a simple US$4 LPC11U35FHI33 and gcc-compileable firmware) for firmware loading, serial over USB console, and low-cost debugging.</div><div><br></div><div>Should work fine with Kinetics Design Studio (KDS). Windows and Linux support is complete, and OSX is basic but ok. Includes a RTOS (MQX), but also supports FreeRTOS.</div><div><br></div><div>That gives us two full high-speed CANs directly on the processor. Extras would be via MCP2515 SPI on an expansion card.</div><div><br></div><div>The above seems like a workable plan. I’ve already got some FRDM-K64F boards, which are pretty close to the above and readily available to start the software development work on. At the moment, I’m trying out the Kinetics Design Studio, to see how it behaves with this arrangement and to make sure it will give us what we need in a simple development environment freely available. I should know in the next few days whether that is ok, and then we can start to nail things down. If anyone else wants to look at KDS and let me know what you think, that would be appreciated. From my understand, it is just GCC with an eclipse plugin GUI built on top.</div><div><br></div><div>Regards, Mark.</div><div><div><div><br><div><blockquote type="cite"><div>On 4 Feb 2016, at 3:28 AM, Arthur Hebert <<a href="mailto:ahebert@gmail.com" target="_blank">ahebert@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Speaking of modularity, how about having 1 or 2 CAN buses standard built-in, and additional CAN buses being optional add-ons? The additional CANs could be MCP2515 based via SPI, like <a href="http://www.mikroe.com/click/can-spi-3.3v/" target="_blank">http://www.mikroe.com/click/can-spi-3.3v/</a>.<div><br></div><div>With plenty of speed, flash, RAM and I/O pins, the software can tidily abstract the SPI comms so that CAN rx/tx functions appear the same whether built-in or module-based. </div><div><br></div><div>The advantage I see is that it doesn't constrain the primary MCU selection so much, and there are plenty of options available today. Many people will be happy with 1 or 2 CAN channels, and those who want 6 CAN channels will happily pay an extra $100 for the additional hardware. </div><div><br></div><div>-Arthur</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 2, 2016 at 11:10 AM, Julien Banchet <span dir="ltr"><<a href="mailto:jaxx@jaxx.org" target="_blank">jaxx@jaxx.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>Mark,<br><br></div>I'm a bigger fan of standardized LoRa networks than SigFox but was going to share the latter's little faire in London on Feb 16th until I realized you where in HK and not UK.<br><br></div>Nevertheless, I bet it might get some curious on the list : <br><div><br><a href="http://makers.sigfox.com/tour/" target="_blank">http://makers.sigfox.com/tour/</a><br><br></div><div>They have already deployed in 10 major agglomerations (Londres, Manchester, Liverpool, Birmingham, Glasgow, …) and are still extending.<span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>JB./.<br></div><div><br></div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, Feb 1, 2016 at 2:35 PM, Mark Webb-Johnson <span dir="ltr"><<a href="mailto:mark@webb-johnson.net" target="_blank">mark@webb-johnson.net</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div style="word-wrap:break-word"><div><br></div><div>Well, the new year is here and OVMS v3 is on the front burner now.</div><div><br></div><div>As you know, I’ve been waiting for the MBED system to settle down and the news is … it hasn’t. Sure, they’ve finally released some open beta code, but only really 1 board supported. No more online compiler. Complicated tools. RTOS worse than the old MBED. And worse is a proprietary closed-source server platform for their Internet-of-things MBED O/S. Luckily, the one board they support is the NXP FRDM-K64F that I love. I’ve tried it, and it sucks. Maybe in a year’s time…</div><div><br></div><div>I’ve been waiting and waiting for this. Can’t say how disappointed I am with the whole direction of the MBED project and closed development, closed, source approach.</div><div><br></div><div>Anyway, OVMS v2 is end of life. We can’t get the SIM908 GSM modules any more. Even if we could, 2G really doesn’t have that much longer. There are a lot of M2M devices out there, but the frequency space is just too valuable. Over the next year or two, more and more 2G capable cell towers are going to be turned off.</div><div><br></div><div>So, time to take the plunge and get on with it. I’m guessing an open source development environment, some free RTOS, and an adapted boot loader to allow us to flash from SC-CARD, USB, or something like that.</div><div><br></div><div>From an overall system architecture point of view, I think we know what we want. A board with a fast micro controller, lots of ram and flash, several CAN buses, and easy development environment, easy firmware upload for the novice, SD card, USB, ethernet, wifi, bluetooth, and some digital I/O. Then, expansion slots to plug in 3G/4G connectivity and whatever else we want.</div><div><br></div><div>We’ve now got lots of options on the wifi+bluetooth front. Within the next couple of months, the ESP32 is going to be out, and that looks really nice. Same story with 3G/4G modules. I don’t see this as an issue.</div><div><br></div><div>So let’s discuss the micro controller.</div><div><br></div><div>Let’s say we want at least 1MB flash, and at least 256KB RAM. At least. Now, we need multiple CAN ports. 2 at a minimum, but 3 or 4 would be much better. A lot of the newer cars split their stuff over multiple CAN buses, and having that support would be great. Remember that we want one system that can be used as a logger, development environment, and final production system. That puts us in ‘automotive’ territory, which is not a bad place to be.</div><div><br></div><div><ul><li>ST have some brutal micro controllers, like the STM32F769. M7 core. Up to 2MB flash, 512KB SRAM, and 3x CAN buses. All the older stuff is 2 CAN bus max, but availability of the new 3xCAN bus stuff is summer 2016. A couple supposedly available now, but I can’t find them.</li><li>NXP have a nice automotive range in the MPC micro controllers (in particular MPC56 has lots of choice, and 10 year product life time), but a strange e200z0 core that I’ve never seen/used. Again, brutal on the flash and RAM, and up to 6 CAN buses. These are their SPC5 32bit automotive MCUs. They have a ‘free’ GCC based development environment.</li><li>The NXP S32K looks good, but seems not available yet.</li></ul></div><div><br></div><div>My preference is the NXP range, but I am concerned about that e200z0 core. Really never heard of it. Anyone got any experience with this?</div><div><br></div><div>The ST stuff also looks good, but availability is tight.</div><div><br></div><div>Thoughts? Anybody have a good contact with NXP for some advice?</div><div><br></div><div>Regards, Mark.</div><div><br></div><div><br></div><div><br></div></div><br></div></div><span>_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a><br>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" rel="noreferrer" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
<br></span></blockquote></div><br></div>
<br>_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a><br>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" rel="noreferrer" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a><br><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br></div></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a><br>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" rel="noreferrer" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
<br></blockquote></div><br></div></div>
_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a><br><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br></div></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" rel="noreferrer" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
<br></blockquote></div><br></div></div>