[Ovmsdev] OVMS v3 - Microcontroller
ahebert at gmail.com
Fri Feb 5 01:33:55 HKT 2016
I appreciate your detailed work on this. The MK66FN2M0VLQ18 looks like an
excellent solution from a hardware standpoint. I agree that the lower price
point is attractive over auto-specific parts, and it still has a good
I'm glad for the reminder that the build environment is an essential part
of the design, not just a nice-to-have. This does have a huge impact on
community involvement. I haven't used mbed or KDS, so I can't speak to that
yet. My first attempt to download KDS failed because the Java Applet NXP
uses to manage downloads didn't work in my browser. I'll try again later in
I think this is a great-sounding solution overall.
On Wed, Feb 3, 2016 at 5:47 PM, Mark Webb-Johnson <mark at webb-johnson.net>
> Arthur, and others,
> 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.
> I am kind of narrowing down on the Kinetics range from NXP. In
> particular, MK66FN2M0VLQ18 seems to give us what we need:
> - ARM Cortext M4, at 180MHz max
> - Kinetics free development environment
> - 2MB flash
> - 256KB RAM
> - 2x CAN
> - 6x UART
> - 3x SPI
> - USB
> - Ethernet
> Couple it with a CMSIS-DAP (I’m looking closely at IBDAP
> <http://www.seeedstudio.com/depot/IBDAP-CMSISDAP-JTAGSWD-Debug-Adapter-p-2568.html> 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.
> 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.
> That gives us two full high-speed CANs directly on the processor. Extras
> would be via MCP2515 SPI on an expansion card.
> 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.
> Regards, Mark.
> On 4 Feb 2016, at 3:28 AM, 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
> 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.
> On Tue, Feb 2, 2016 at 11:10 AM, Julien Banchet <jaxx at jaxx.org> wrote:
>> 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 :
>> They have already deployed in 10 major agglomerations (Londres,
>> Manchester, Liverpool, Birmingham, Glasgow, …) and are still extending.
>> On Mon, Feb 1, 2016 at 2:35 PM, Mark Webb-Johnson <mark at webb-johnson.net>
>>> 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
>>> - 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
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev