[Ovmsdev] OVMS v3 - Microcontroller

Thu Feb 4 04:46:38 HKT 2016

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.

If an off-the-shelf CAN-SPI module will suffice (here's two more:
http://modtronix.com/im1can.html and
http://www.amazon.com/Quentacy%C2%AE-MCP2515-TJA1050-Receiver-controller/dp/B0152VCIA6),
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.

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.

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.

On Wed, Feb 3, 2016 at 12:00 PM, Julien Banchet <jaxx at jaxx.org> wrote:

> We might be hitting a form of limit already at this point.
> 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.
> I mean, CAN busses are another kind of beasts imho... It isn't a natively
> shared I2C, or a bit-bangable soft serial port
> I could be wrong on proportions, but i sense complexity in the force.
>
> JaXX
>
> On Wed, Feb 3, 2016 at 8:28 PM, Arthur Hebert <ahebert at gmail.com> wrote:
>
>> 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
>> http://www.mikroe.com/click/can-spi-3.3v/.
>>
>> 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.
>>
>> 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.
>>
>> -Arthur
>>
>> On Tue, Feb 2, 2016 at 11:10 AM, Julien Banchet <jaxx at jaxx.org> wrote:
>>
>>> Mark,
>>>
>>> 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.
>>>
>>> Nevertheless, I bet it might get some curious on the list :
>>>
>>> http://makers.sigfox.com/tour/
>>>
>>> They have already deployed in 10 major agglomerations (Londres,
>>> Manchester, Liverpool, Birmingham, Glasgow, …) and are still extending.
>>>
>>> JB./.
>>>
>>>
>>> On Mon, Feb 1, 2016 at 2:35 PM, Mark Webb-Johnson <mark at webb-johnson.net
>>> > wrote:
>>>
>>>>
>>>> Well, the new year is here and OVMS v3 is on the front burner now.
>>>>
>>>> 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…
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> So let’s discuss the micro controller.
>>>>
>>>> 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.
>>>>
>>>>
>>>>    - 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.
>>>>    - 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.
>>>>    - The NXP S32K looks good, but seems not available yet.
>>>>
>>>>
>>>> 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?
>>>>
>>>> The ST stuff also looks good, but availability is tight.
>>>>
>>>> Thoughts? Anybody have a good contact with NXP for some advice?
>>>>
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20160203/574a6979/attachment.htm>