<div dir="ltr">It's true, there is some complexity, and I do assume multiplexing the SPI bus(es). Each additional CAN port would need 2 I/O pins (CS and interrupt) in addition to the single set of shared SPI pins (MISO/MOSI/SCK). My thinking is that it's a lot easier to source an MCU with plenty of interrupt pins than to source one with plenty of CAN buses. <div><br></div><div>If an off-the-shelf CAN-SPI module will suffice (here's two more: <a href="http://modtronix.com/im1can.html" target="_blank">http://modtronix.com/im1can.html</a> and <a href="http://www.amazon.com/Quentacy%C2%AE-MCP2515-TJA1050-Receiver-controller/dp/B0152VCIA6" target="_blank">http://www.amazon.com/Quentacy%C2%AE-MCP2515-TJA1050-Receiver-controller/dp/B0152VCIA6</a>), then the BOM doesn't have to explode. The BOM would need some additional header pins/sockets to receive the module, which I assume are already in the BOM for other modular items.</div><div><br></div><div>While vehicle CAN buses are fast and busy, a handful of the many IDs is all that's needed (in my experience). With proper masks and filters set at boot-time, the hardware will ignore the bulk of CAN traffic without costing the MCU a single extra processor cycle. </div><div><br></div><div>With the complexity, I admit it's not the most appealing solution I can dream of. Yet, I think it's feasible and therefore worth considering if the design process finds itself in a corner at some point.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 3, 2016 at 12:00 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>We might be hitting a form of limit already at this point.<br></div>CAN buses are busy and highspeed themselves, and not many well known MCUs have enough SPI busses for that matter (even big computer grade processors)... I fear it's going to involve multiplexing and buffers, with an exploding BOM.<br></div><div>I mean, CAN busses are another kind of beasts imho... It isn't a natively shared I2C, or a bit-bangable soft serial port<br></div>I could be wrong on proportions, but i sense complexity in the force.<br><br></div>JaXX<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 3, 2016 at 8:28 PM, Arthur Hebert <span dir="ltr"><<a href="mailto:ahebert@gmail.com" target="_blank">ahebert@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><span><font color="#888888"><div><br></div><div>-Arthur</div></font></span></div><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:0 0 0 .8ex;border-left:1px #ccc 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:0 0 0 .8ex;border-left:1px #ccc 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>
</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></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>