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.
Ahh finally I can get on this project again. My OVMS v1 has refused to function properly for the past few years and I have been waiting for a major update of the module to get back into this. Can see on my installed app that you are still using my old graphics and the same app icon that we settled on a few years ago….. at least for the iOS app. I have been toying with a more universal look and feel and will give it a little push before I show the ideas to see if there is traction for a graphical change for v3…. thanks for the amazing work you guys are doing! felix b.
On 01 Feb 2016, at 14:35, Mark Webb-Johnson <mark@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Felix, For the vehicle graphics, I had a freelancer convert them to mask+grayscale style. That will allow us to colorise the graphics to custom colours, as well as reduce storage to a fraction of today’s requirements. We’ve still to address how the charger plug is displayed. It is cute, and works well for the roadster, but is probably confusing for all the other cars. Regards, Mark.
On 1 Feb 2016, at 9:48 PM, felix bonnier <felixtb@me.com> wrote:
Ahh finally I can get on this project again.
My OVMS v1 has refused to function properly for the past few years and I have been waiting for a major update of the module to get back into this. Can see on my installed app that you are still using my old graphics and the same app icon that we settled on a few years ago….. at least for the iOS app. I have been toying with a more universal look and feel and will give it a little push before I show the ideas to see if there is traction for a graphical change for v3….
thanks for the amazing work you guys are doing!
felix b.
On 01 Feb 2016, at 14:35, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Am 02.02.2016 um 01:55 schrieb Mark Webb-Johnson:
We’ve still to address how the charger plug is displayed. It is cute, and works well for the roadster, but is probably confusing for all the other cars.
I added a specific charger overlay for the Twizy in the latest update, the logic is easily extendable for other cars, I just need the overlay images. If someone wants to do such an image: the overlay needs to fit the ol_car_ image. For the Twizy that's: https://github.com/openvehicles/Open-Vehicle-Android/blob/gcm/OpenVehicleApp... ...and the charger plug overlay is: https://github.com/openvehicles/Open-Vehicle-Android/blob/gcm/OpenVehicleApp... The overlays can also differ by charge mode or other criteria, just extend the overlay naming accordingly and describe the logic. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I think that is how it is in the Android App, but not iOS. Which reminds me: I’m about to start the process of trying to build a Google Play store version of the current Android App. Wish me luck ;-) Mark.
On 2 Feb 2016, at 4:36 PM, Michael Balzer <dexter@expeedo.de> wrote:
Am 02.02.2016 um 01:55 schrieb Mark Webb-Johnson:
We’ve still to address how the charger plug is displayed. It is cute, and works well for the roadster, but is probably confusing for all the other cars.
I added a specific charger overlay for the Twizy in the latest update, the logic is easily extendable for other cars, I just need the overlay images.
If someone wants to do such an image: the overlay needs to fit the ol_car_ image. For the Twizy that's: https://github.com/openvehicles/Open-Vehicle-Android/blob/gcm/OpenVehicleApp... <https://github.com/openvehicles/Open-Vehicle-Android/blob/gcm/OpenVehicleApp/src/main/res/drawable-nodpi/ol_car_twizy_diamondblackwithivygreen.png>
...and the charger plug overlay is: https://github.com/openvehicles/Open-Vehicle-Android/blob/gcm/OpenVehicleApp... <https://github.com/openvehicles/Open-Vehicle-Android/blob/gcm/OpenVehicleApp/src/main/res/drawable-nodpi/ol_car_twizy_chargeport.png>
The overlays can also differ by charge mode or other criteria, just extend the overlay naming accordingly and describe the logic.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Would it not be nicer to just do a simple generic design and background color etc... With POSSIBLY only the cars being model specific.......?! I will show you a couple of ideas in a week or so. Best /felix b. Sent from somewhere in our beautiful universe.....
On 02 Feb 2016, at 09:36, Michael Balzer <dexter@expeedo.de> wrote:
Am 02.02.2016 um 01:55 schrieb Mark Webb-Johnson: We’ve still to address how the charger plug is displayed. It is cute, and works well for the roadster, but is probably confusing for all the other cars.
I added a specific charger overlay for the Twizy in the latest update, the logic is easily extendable for other cars, I just need the overlay images.
If someone wants to do such an image: the overlay needs to fit the ol_car_ image. For the Twizy that's: https://github.com/openvehicles/Open-Vehicle-Android/blob/gcm/OpenVehicleApp...
...and the charger plug overlay is: https://github.com/openvehicles/Open-Vehicle-Android/blob/gcm/OpenVehicleApp...
The overlays can also differ by charge mode or other criteria, just extend the overlay naming accordingly and describe the logic.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
The Particle Electron has recently caught my attention: https://www.particle.io/cellular. Actual performance and usability are unknown, since the first units don't ship until later this month, but it has some attractive features: - low-cost M2M-oriented international SMS/data plans ($3/mo. for 20k messages) - STM32F205 MCU with *1MB flash*, 128k RAM and *2 CAN buses* - free development IDE: https://www.particle.io/dev - also a free web-based dev environment at https://build.particle.io (I assume/hope this will support the Electron cellular board when it comes out) I know it doesn't come close to meeting the RAM requirements, but the cellular plan is a pretty big draw IMO. Perhaps worth using this module in conjunction with another board with a better MCU? -Arthur On Mon, Feb 1, 2016 at 5:35 AM, Mark Webb-Johnson <mark@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Generally I think 3G doesn’t make a lot of sense. A new platform should be 4G capable. As far as I know 2G is more likely to stay longer than 3G. I know already some areas in Germany and Austria where you can find 4G and maybe 2G, but no 3G. For example seeedstudio retargeted their Rephone 3G module to 4G after some investigations about the future of 3G. (https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-sou...) Just my 2 cents Dominik
On 01 Feb 2016, at 18:30, Arthur Hebert <ahebert@gmail.com> wrote:
The Particle Electron has recently caught my attention: https://www.particle.io/cellular <https://www.particle.io/cellular>. Actual performance and usability are unknown, since the first units don't ship until later this month, but it has some attractive features: low-cost M2M-oriented international SMS/data plans ($3/mo. for 20k messages) STM32F205 MCU with 1MB flash, 128k RAM and 2 CAN buses free development IDE: https://www.particle.io/dev <https://www.particle.io/dev> also a free web-based dev environment at https://build.particle.io <https://build.particle.io/> (I assume/hope this will support the Electron cellular board when it comes out) I know it doesn't come close to meeting the RAM requirements, but the cellular plan is a pretty big draw IMO. Perhaps worth using this module in conjunction with another board with a better MCU?
-Arthur
All, what about opening our garden, providing a public park which could be used for several features beside the scope of this group? 3G/4G Wlan Bluetooth GPS whatever could be added / replaced easily…. what i mean is vocabulary like: - raspberry pi - CarPI (CarPC) - OBD - smartphone speedometer gadgets (sure really useless - but the mainstream love it) - Harry´s laptimer support (http://www.gps-laptimer.de <http://www.gps-laptimer.de/>) // video: Harry's LapTimer GPS/OBD II Video Overlay - Nordschleife with 911 GTS <https://www.youtube.com/watch?v=fTCNhmsFZBE> https://www.youtube.com/watch?v=fTCNhmsFZBE <https://www.youtube.com/watch?v=fTCNhmsFZBE> - Wlan.. repeater - hotspot… (my favorit) this could also enable add on development…. - spotify - surround view parking (raspian & openCV?) // AVM: AVM (Around View Monitoring /monitor ) 4CH camera become 360 degree Parking Guidance System <https://www.youtube.com/watch?v=1Q9iVoSvjGk> https://www.youtube.com/watch?v=1Q9iVoSvjGk <https://www.youtube.com/watch?v=1Q9iVoSvjGk> - KITT Watch - car call? - replace Infotainment systems - SmartAutomation like OpenHab integration (They call it „Binding“ - Tesla Model S Binding is already integrated - did they overtake us? ;-) http://www.openhab.org <http://www.openhab.org/> views? Michael Am 01.02.2016 um 18:51 schrieb Dominik Westner <ovms@nikwest.de>: Generally I think 3G doesn’t make a lot of sense. A new platform should be 4G capable. As far as I know 2G is more likely to stay longer than 3G. I know already some areas in Germany and Austria where you can find 4G and maybe 2G, but no 3G. For example seeedstudio retargeted their Rephone 3G module to 4G after some investigations about the future of 3G. (https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-sou... <https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-source-and-modular-p/posts/1468366>) Just my 2 cents Dominik
On 01 Feb 2016, at 18:30, Arthur Hebert <ahebert@gmail.com <mailto:ahebert@gmail.com>> wrote:
The Particle Electron has recently caught my attention: https://www.particle.io/cellular <https://www.particle.io/cellular>. Actual performance and usability are unknown, since the first units don't ship until later this month, but it has some attractive features: low-cost M2M-oriented international SMS/data plans ($3/mo. for 20k messages) STM32F205 MCU with 1MB flash, 128k RAM and 2 CAN buses free development IDE: https://www.particle.io/dev <https://www.particle.io/dev> also a free web-based dev environment at https://build.particle.io <https://build.particle.io/> (I assume/hope this will support the Electron cellular board when it comes out) I know it doesn't come close to meeting the RAM requirements, but the cellular plan is a pretty big draw IMO. Perhaps worth using this module in conjunction with another board with a better MCU?
-Arthur
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Michael, That is the general idea. Provide a base platform that people could use for all sorts of things. But, the choice of operating system and platform type has a big bearing on this. If we want to do things like instrument clusters, infotainment, car PCs, etc, then the platform is very different than one intended as an embedded CAN gateway. The processor power requirement to take 4 video streams and real-time stitch them into a single overhead camera view, is non trivial. There is a conflict there for the low power requirement. Regards, Mark.
On 2 Feb 2016, at 3:30 AM, Michael Eymann <Michael.Eymann@networkz.de> wrote:
All,
what about opening our garden, providing a public park which could be used for several features beside the scope of this group?
3G/4G Wlan Bluetooth GPS whatever could be added / replaced easily….
what i mean is vocabulary like: - raspberry pi - CarPI (CarPC) - OBD - smartphone speedometer gadgets (sure really useless - but the mainstream love it) - Harry´s laptimer support (http://www.gps-laptimer.de <http://www.gps-laptimer.de/>) // video: Harry's LapTimer GPS/OBD II Video Overlay - Nordschleife with 911 GTS <https://www.youtube.com/watch?v=fTCNhmsFZBE> https://www.youtube.com/watch?v=fTCNhmsFZBE <https://www.youtube.com/watch?v=fTCNhmsFZBE> - Wlan.. repeater - hotspot… (my favorit)
this could also enable add on development…. - spotify - surround view parking (raspian & openCV?) // AVM: AVM (Around View Monitoring /monitor ) 4CH camera become 360 degree Parking Guidance System <https://www.youtube.com/watch?v=1Q9iVoSvjGk> https://www.youtube.com/watch?v=1Q9iVoSvjGk <https://www.youtube.com/watch?v=1Q9iVoSvjGk> - KITT Watch - car call? - replace Infotainment systems - SmartAutomation like OpenHab integration (They call it „Binding“ - Tesla Model S Binding is already integrated - did they overtake us? ;-) http://www.openhab.org <http://www.openhab.org/>
views?
Michael
Am 01.02.2016 um 18:51 schrieb Dominik Westner <ovms@nikwest.de <mailto:ovms@nikwest.de>>:
Generally I think 3G doesn’t make a lot of sense. A new platform should be 4G capable. As far as I know 2G is more likely to stay longer than 3G. I know already some areas in Germany and Austria where you can find 4G and maybe 2G, but no 3G.
For example seeedstudio retargeted their Rephone 3G module to 4G after some investigations about the future of 3G. (https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-sou... <https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-source-and-modular-p/posts/1468366>)
Just my 2 cents
Dominik
On 01 Feb 2016, at 18:30, Arthur Hebert <ahebert@gmail.com <mailto:ahebert@gmail.com>> wrote:
The Particle Electron has recently caught my attention: https://www.particle.io/cellular <https://www.particle.io/cellular>. Actual performance and usability are unknown, since the first units don't ship until later this month, but it has some attractive features: low-cost M2M-oriented international SMS/data plans ($3/mo. for 20k messages) STM32F205 MCU with 1MB flash, 128k RAM and 2 CAN buses free development IDE: https://www.particle.io/dev <https://www.particle.io/dev> also a free web-based dev environment at https://build.particle.io <https://build.particle.io/> (I assume/hope this will support the Electron cellular board when it comes out) I know it doesn't come close to meeting the RAM requirements, but the cellular plan is a pretty big draw IMO. Perhaps worth using this module in conjunction with another board with a better MCU?
-Arthur
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I agree with the basic idea of a low-power CAN bridge/gateway. It might even make sense to keep it simple with only serial connections to expander boards, whether USB, SPI, or something along those lines. Radio - whether WiFi or cellular - seems to add a lot in terms of power requirements, not to mention the restrictions on placement within the car and the casing so that radio waves are not blocked. Is it absolutely necessary to have radio on the base model? In any event, lots of on-board storage is a good idea, whether it's CPU Flash or external. The external can be SMD on the board, or removable cards. Putting an extra parallel or serial Flash chip on board could be a lot cheaper than having a removable card, but I haven't done price comparisons. Basically, I think that a design like the Raspberry Pi, with it's full operating system, is quite a bit overkill in terms of power and capability. A much smaller system seems to make more sense, provided that 2 to 4 CAN busses are possible. I'm open to any design so long as it's not power hungry, because I don't want it draining the battery. I still have one of the OVMS v2 models, but I must confess that I've not done any development with it despite having lots of Microchip PIC programming experience. Brian On Feb 1, 2016, at 5:13 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
That is the general idea. Provide a base platform that people could use for all sorts of things.
But, the choice of operating system and platform type has a big bearing on this. If we want to do things like instrument clusters, infotainment, car PCs, etc, then the platform is very different than one intended as an embedded CAN gateway. The processor power requirement to take 4 video streams and real-time stitch them into a single overhead camera view, is non trivial. There is a conflict there for the low power requirement.
Regards, Mark.
Hi, I love the OpenCV part, though I'll have to find a way to retofit powersteering and brake actuators in a Twizy, that said, it all shoots way beyond the scope of OVMS (even a v4/v5) imho... but, but, but... an OVMS module shall be the bridge and the low-level comms offloader for an optionnal "Hyper Smart OpenCV Dashboard Music Streaming thingy" that a sister project can take over :-) (my opinion again) So yeah, It needs to be beefy, and the ESP32 seems to be a nice candidate and embeds by itself a nice load of functions (Wifi and BLE!) http://www.pighixxx.com/test/2015/12/esp32-processor-pinout/ It has no CAN, but it has SPI (can't tell how many on this pinout) and plenty of HS GPIOs for native or soft UARTs. Having 2 CANbuses shouldn't be an issue (I'll let those who fathomed that more than me tell me wrong otherwise) I don't believe everyone needs a 2/3/4G stack, not counting that those radios end up being the big bucks of the BOM. Instead, would it be possible to envision a naked board with an extension bus and i2c, interrupts, multiplexed (or not) enable and power lanes? (an edge fitted socket for example, each extension board presents another socket) The motivation for this particular request is: - It lowers the base cost, with knowledge it can be enhanced, and still carries Wifi+BTBLE for local connectivity with an ESP32 - I doubt my Twizy will ever be stolen to be brought out of LoRa range, and those networks are being deployed quickly, no need for power hungry GSM stacks (that empty my Twizys' 12V battery in 3 days, driving me nuts by the way) - I might want a home brewed I2C GPIO extender on it, a socket makes it easy to make (or a stepper motor drivers to pilot a paintball gun turret fitted on the roof and shoot *ssholes) - The hypothetical day I upgrade to a Tesla 3, I can add that 5G Module that wasn't out yet ;-) Just thoughts, JaXX On Mon, Feb 1, 2016 at 8:30 PM, Michael Eymann <Michael.Eymann@networkz.de> wrote:
All,
what about opening our garden, providing a public park which could be used for several features beside the scope of this group?
3G/4G Wlan Bluetooth GPS whatever could be added / replaced easily….
what i mean is vocabulary like: - raspberry pi - CarPI (CarPC) - OBD - smartphone speedometer gadgets (sure really useless - but the mainstream love it) - Harry´s laptimer support (http://www.gps-laptimer.de) // video: Harry's LapTimer GPS/OBD II Video Overlay - Nordschleife with 911 GTS <https://www.youtube.com/watch?v=fTCNhmsFZBE> https://www.youtube.com/watch?v=fTCNhmsFZBE - Wlan.. repeater - hotspot… (my favorit) this could also enable add on development…. - spotify - surround view parking (raspian & openCV?) // AVM: AVM (Around View Monitoring /monitor ) 4CH camera become 360 degree Parking Guidance System <https://www.youtube.com/watch?v=1Q9iVoSvjGk> https://www.youtube.com/watch?v=1Q9iVoSvjGk - KITT Watch - car call? - replace Infotainment systems - SmartAutomation like OpenHab integration (They call it „Binding“ - Tesla Model S Binding is already integrated - did they overtake us? ;-) http://www.openhab.org
views?
Michael
Am 01.02.2016 um 18:51 schrieb Dominik Westner <ovms@nikwest.de>:
Generally I think 3G doesn’t make a lot of sense. A new platform should be 4G capable. As far as I know 2G is more likely to stay longer than 3G. I know already some areas in Germany and Austria where you can find 4G and maybe 2G, but no 3G.
For example seeedstudio retargeted their Rephone 3G module to 4G after some investigations about the future of 3G. ( https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-sou... )
Just my 2 cents
Dominik
On 01 Feb 2016, at 18:30, Arthur Hebert <ahebert@gmail.com> wrote:
The Particle Electron has recently caught my attention: https://www.particle.io/cellular. Actual performance and usability are unknown, since the first units don't ship until later this month, but it has some attractive features:
- low-cost M2M-oriented international SMS/data plans ($3/mo. for 20k messages) - STM32F205 MCU with *1MB flash*, 128k RAM and *2 CAN buses* - free development IDE: https://www.particle.io/dev - also a free web-based dev environment at https://build.particle.io (I assume/hope this will support the Electron cellular board when it comes out)
I know it doesn't come close to meeting the RAM requirements, but the cellular plan is a pretty big draw IMO. Perhaps worth using this module in conjunction with another board with a better MCU?
-Arthur
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Julien, It seems that our thinking is similar. I view OVMS as the CAN processor - perhaps a bridge/gateway - and telematics module. User Interface, Car PC, etc, systems are best handled externally by something that starts up and shuts down with the ignition switch and can suck as much power as your home PC. OVMS has to keep running, in as low power mode as possible, as telematics are required even when the car is off. Regarding ESP32, that is top of our shortlisted devices for wifi/bluetooth. But, it depends on release schedule. We want OVMS v3 to be FCC and CE certified, and that means we must use FCC+CE certified modules for the comms parts. The overall goal is for OVMS v3 to be the microprocessor, power, CAN, USB, ethernet, wifi, and bluetooth, as a base module. Then, everything else (including cellular) are optional plugin modules. We could make wifi+bluetooth optional, but I suspect that they will not add dramatically to the cost/complexity to include as standard. This has got to go in an automotive environment, so plugin modules will most likely go on some sturdy headers on the board. Regards, Mark.
On 2 Feb 2016, at 3:34 PM, Julien Banchet <jaxx@jaxx.org> wrote:
Hi,
I love the OpenCV part, though I'll have to find a way to retofit powersteering and brake actuators in a Twizy, that said, it all shoots way beyond the scope of OVMS (even a v4/v5) imho... but, but, but... an OVMS module shall be the bridge and the low-level comms offloader for an optionnal "Hyper Smart OpenCV Dashboard Music Streaming thingy" that a sister project can take over :-) (my opinion again)
So yeah, It needs to be beefy, and the ESP32 seems to be a nice candidate and embeds by itself a nice load of functions (Wifi and BLE!) http://www.pighixxx.com/test/2015/12/esp32-processor-pinout/ <http://www.pighixxx.com/test/2015/12/esp32-processor-pinout/>
It has no CAN, but it has SPI (can't tell how many on this pinout) and plenty of HS GPIOs for native or soft UARTs. Having 2 CANbuses shouldn't be an issue (I'll let those who fathomed that more than me tell me wrong otherwise)
I don't believe everyone needs a 2/3/4G stack, not counting that those radios end up being the big bucks of the BOM.
Instead, would it be possible to envision a naked board with an extension bus and i2c, interrupts, multiplexed (or not) enable and power lanes? (an edge fitted socket for example, each extension board presents another socket)
The motivation for this particular request is: - It lowers the base cost, with knowledge it can be enhanced, and still carries Wifi+BTBLE for local connectivity with an ESP32 - I doubt my Twizy will ever be stolen to be brought out of LoRa range, and those networks are being deployed quickly, no need for power hungry GSM stacks (that empty my Twizys' 12V battery in 3 days, driving me nuts by the way) - I might want a home brewed I2C GPIO extender on it, a socket makes it easy to make (or a stepper motor drivers to pilot a paintball gun turret fitted on the roof and shoot *ssholes) - The hypothetical day I upgrade to a Tesla 3, I can add that 5G Module that wasn't out yet ;-)
Just thoughts,
JaXX
On Mon, Feb 1, 2016 at 8:30 PM, Michael Eymann <Michael.Eymann@networkz.de <mailto:Michael.Eymann@networkz.de>> wrote: All,
what about opening our garden, providing a public park which could be used for several features beside the scope of this group?
3G/4G Wlan Bluetooth GPS whatever could be added / replaced easily….
what i mean is vocabulary like: - raspberry pi - CarPI (CarPC) - OBD - smartphone speedometer gadgets (sure really useless - but the mainstream love it) - Harry´s laptimer support (http://www.gps-laptimer.de <http://www.gps-laptimer.de/>) // video: Harry's LapTimer GPS/OBD II Video Overlay - Nordschleife with 911 GTS <https://www.youtube.com/watch?v=fTCNhmsFZBE> https://www.youtube.com/watch?v=fTCNhmsFZBE <https://www.youtube.com/watch?v=fTCNhmsFZBE> - Wlan.. repeater - hotspot… (my favorit)
this could also enable add on development…. - spotify - surround view parking (raspian & openCV?) // AVM: AVM (Around View Monitoring /monitor ) 4CH camera become 360 degree Parking Guidance System <https://www.youtube.com/watch?v=1Q9iVoSvjGk> https://www.youtube.com/watch?v=1Q9iVoSvjGk <https://www.youtube.com/watch?v=1Q9iVoSvjGk> - KITT Watch - car call? - replace Infotainment systems - SmartAutomation like OpenHab integration (They call it „Binding“ - Tesla Model S Binding is already integrated - did they overtake us? ;-) http://www.openhab.org <http://www.openhab.org/>
views?
Michael
Am 01.02.2016 um 18:51 schrieb Dominik Westner <ovms@nikwest.de <mailto:ovms@nikwest.de>>:
Generally I think 3G doesn’t make a lot of sense. A new platform should be 4G capable. As far as I know 2G is more likely to stay longer than 3G. I know already some areas in Germany and Austria where you can find 4G and maybe 2G, but no 3G.
For example seeedstudio retargeted their Rephone 3G module to 4G after some investigations about the future of 3G. (https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-sou... <https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-source-and-modular-p/posts/1468366>)
Just my 2 cents
Dominik
On 01 Feb 2016, at 18:30, Arthur Hebert <ahebert@gmail.com <mailto:ahebert@gmail.com>> wrote:
The Particle Electron has recently caught my attention: https://www.particle.io/cellular <https://www.particle.io/cellular>. Actual performance and usability are unknown, since the first units don't ship until later this month, but it has some attractive features: low-cost M2M-oriented international SMS/data plans ($3/mo. for 20k messages) STM32F205 MCU with 1MB flash, 128k RAM and 2 CAN buses free development IDE: https://www.particle.io/dev <https://www.particle.io/dev> also a free web-based dev environment at https://build.particle.io <https://build.particle.io/> (I assume/hope this will support the Electron cellular board when it comes out) I know it doesn't come close to meeting the RAM requirements, but the cellular plan is a pretty big draw IMO. Perhaps worth using this module in conjunction with another board with a better MCU?
-Arthur
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 02/02/2016 08:49 AM, Mark Webb-Johnson wrote:
Julien,
It seems that our thinking is similar.
I view OVMS as the CAN processor - perhaps a bridge/gateway - and telematics module. User Interface, Car PC, etc, systems are best handled externally by something that starts up and shuts down with the ignition switch and can suck as much power as your home PC. OVMS has to keep running, in as low power mode as possible, as telematics are required even when the car is off. Exactly, my whole point, plus, that part, externalized, with a standardized way of communicating with the OVMS (uart/bt + ethernet/wifi+mqtt,http://api) will give a full freedom of implementation of the Heavyweight part. BTW: one of the extension boards could be a power-control board with power state signaling, MOSFETs, and a watchdog for that part
Regarding ESP32, that is top of our shortlisted devices for wifi/bluetooth. But, it depends on release schedule. We want OVMS v3 to be FCC and CE certified, and that means we must use FCC+CE certified modules for the comms parts. I don't know if their distribution of 200 beta boards was a cap limit, but maybe shooting a mail to beta@espressif.com might be worth it, asking them for approximate timelines with it, no ?
The overall goal is for OVMS v3 to be the microprocessor, power, CAN, USB, ethernet, wifi, and bluetooth, as a base module. Then, everything else (including cellular) are optional plugin modules. We could make wifi+bluetooth optional, but I suspect that they will not add dramatically to the cost/complexity to include as standard. This has got to go in an automotive environment, so plugin modules will most likely go on some sturdy headers on the board. BT/BLE I believe is a minimum to have: It will allow people to have a locally connected Android App (without pumping data over a slow, optionnal and maybe misconfigured GSM stack) and without any hassle at that, latency can be sub 0.5s which is bareable for live metrics... plus, not all phones implement USB OTG correctly... and it's cablefree, which non-DIYers might appreciate.
Form factor wise, my edge connector idea might not be that great, we'd end up with a lonnnngg serie of boards, maybe stackable as an arduino shield ? connectors are cheap, easier for the DIYer, no need to design long pathways that get in the way for signals from border to border...
Regards, Mark.
On 2 Feb 2016, at 3:34 PM, Julien Banchet <jaxx@jaxx.org <mailto:jaxx@jaxx.org>> wrote:
Hi,
I love the OpenCV part, though I'll have to find a way to retofit powersteering and brake actuators in a Twizy, that said, it all shoots way beyond the scope of OVMS (even a v4/v5) imho... but, but, but... an OVMS module shall be the bridge and the low-level comms offloader for an optionnal "Hyper Smart OpenCV Dashboard Music Streaming thingy" that a sister project can take over :-) (my opinion again)
So yeah, It needs to be beefy, and the ESP32 seems to be a nice candidate and embeds by itself a nice load of functions (Wifi and BLE!) http://www.pighixxx.com/test/2015/12/esp32-processor-pinout/
It has no CAN, but it has SPI (can't tell how many on this pinout) and plenty of HS GPIOs for native or soft UARTs. Having 2 CANbuses shouldn't be an issue (I'll let those who fathomed that more than me tell me wrong otherwise)
I don't believe everyone needs a 2/3/4G stack, not counting that those radios end up being the big bucks of the BOM.
Instead, would it be possible to envision a naked board with an extension bus and i2c, interrupts, multiplexed (or not) enable and power lanes? (an edge fitted socket for example, each extension board presents another socket)
The motivation for this particular request is: - It lowers the base cost, with knowledge it can be enhanced, and still carries Wifi+BTBLE for local connectivity with an ESP32 - I doubt my Twizy will ever be stolen to be brought out of LoRa range, and those networks are being deployed quickly, no need for power hungry GSM stacks (that empty my Twizys' 12V battery in 3 days, driving me nuts by the way) - I might want a home brewed I2C GPIO extender on it, a socket makes it easy to make (or a stepper motor drivers to pilot a paintball gun turret fitted on the roof and shoot *ssholes) - The hypothetical day I upgrade to a Tesla 3, I can add that 5G Module that wasn't out yet ;-)
Just thoughts,
JaXX
On Mon, Feb 1, 2016 at 8:30 PM, Michael Eymann <Michael.Eymann@networkz.de <mailto:Michael.Eymann@networkz.de>> wrote:
All,
what about opening our garden, providing a public park which could be used for several features beside the scope of this group?
3G/4G Wlan Bluetooth GPS whatever could be added / replaced easily….
what i mean is vocabulary like: - raspberry pi - CarPI (CarPC) - OBD - smartphone speedometer gadgets (sure really useless - but the mainstream love it) - Harry´s laptimer support (http://www.gps-laptimer.de <http://www.gps-laptimer.de/>) // video: Harry's LapTimer GPS/OBD II Video Overlay - Nordschleife with 911 GTS <https://www.youtube.com/watch?v=fTCNhmsFZBE> https://www.youtube.com/watch?v=fTCNhmsFZBE - Wlan.. repeater - hotspot… (my favorit) this could also enable add on development…. - spotify - surround view parking (raspian & openCV?) // AVM: AVM (Around View Monitoring /monitor ) 4CH camera become 360 degree Parking Guidance System <https://www.youtube.com/watch?v=1Q9iVoSvjGk> https://www.youtube.com/watch?v=1Q9iVoSvjGk - KITT Watch - car call? - replace Infotainment systems - SmartAutomation like OpenHab integration (They call it „Binding“ - Tesla Model S Binding is already integrated - did they overtake us? ;-) http://www.openhab.org <http://www.openhab.org/>
views?
Michael
Am 01.02.2016 um 18:51 schrieb Dominik Westner <ovms@nikwest.de <mailto:ovms@nikwest.de>>:
Generally I think 3G doesn’t make a lot of sense. A new platform should be 4G capable. As far as I know 2G is more likely to stay longer than 3G. I know already some areas in Germany and Austria where you can find 4G and maybe 2G, but no 3G.
For example seeedstudio retargeted their Rephone 3G module to 4G after some investigations about the future of 3G. (https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-sou...)
Just my 2 cents
Dominik
On 01 Feb 2016, at 18:30, Arthur Hebert <ahebert@gmail.com <mailto:ahebert@gmail.com>> wrote:
The Particle Electron has recently caught my attention: https://www.particle.io/cellular. Actual performance and usability are unknown, since the first units don't ship until later this month, but it has some attractive features:
* low-cost M2M-oriented international SMS/data plans ($3/mo. for 20k messages) * STM32F205 MCU with *1MB flash*, 128k RAM and *2 CAN buses* * free development IDE: https://www.particle.io/dev * also a free web-based dev environment at https://build.particle.io <https://build.particle.io/> (I assume/hope this will support the Electron cellular board when it comes out)
I know it doesn't come close to meeting the RAM requirements, but the cellular plan is a pretty big draw IMO. Perhaps worth using this module in conjunction with another board with a better MCU?
-Arthur
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
My preference for connectors is those 0.1” SIP/DIP ones. They are extremely vibration resistant, breadboard compatible, stackable, etc. When layed out properly, they also allow you to stack expansion over existing board components, without sacrificing much space. For bringing out lots of pins, not so good. But for enough for one or two expansion slots they work well. Regards, Mark.
On 2 Feb 2016, at 4:59 PM, Julien (JaXX) Banchet <jaxx@jaxx.org <mailto:jaxx@jaxx.org>> wrote:
On 02/02/2016 08:49 AM, Mark Webb-Johnson wrote:
Julien,
It seems that our thinking is similar.
I view OVMS as the CAN processor - perhaps a bridge/gateway - and telematics module. User Interface, Car PC, etc, systems are best handled externally by something that starts up and shuts down with the ignition switch and can suck as much power as your home PC. OVMS has to keep running, in as low power mode as possible, as telematics are required even when the car is off. Exactly, my whole point, plus, that part, externalized, with a standardized way of communicating with the OVMS (uart/bt + ethernet/wifi+mqtt,http://api <http://api/>) will give a full freedom of implementation of the Heavyweight part. BTW: one of the extension boards could be a power-control board with power state signaling, MOSFETs, and a watchdog for that part
Regarding ESP32, that is top of our shortlisted devices for wifi/bluetooth. But, it depends on release schedule. We want OVMS v3 to be FCC and CE certified, and that means we must use FCC+CE certified modules for the comms parts. I don't know if their distribution of 200 beta boards was a cap limit, but maybe shooting a mail to beta@espressif.com <mailto:beta@espressif.com> might be worth it, asking them for approximate timelines with it, no ?
The overall goal is for OVMS v3 to be the microprocessor, power, CAN, USB, ethernet, wifi, and bluetooth, as a base module. Then, everything else (including cellular) are optional plugin modules. We could make wifi+bluetooth optional, but I suspect that they will not add dramatically to the cost/complexity to include as standard. This has got to go in an automotive environment, so plugin modules will most likely go on some sturdy headers on the board. BT/BLE I believe is a minimum to have: It will allow people to have a locally connected Android App (without pumping data over a slow, optionnal and maybe misconfigured GSM stack) and without any hassle at that, latency can be sub 0.5s which is bareable for live metrics... plus, not all phones implement USB OTG correctly... and it's cablefree, which non-DIYers might appreciate.
Form factor wise, my edge connector idea might not be that great, we'd end up with a lonnnngg serie of boards, maybe stackable as an arduino shield ? connectors are cheap, easier for the DIYer, no need to design long pathways that get in the way for signals from border to border...
Regards, Mark.
On 2 Feb 2016, at 3:34 PM, Julien Banchet < <mailto:jaxx@jaxx.org>jaxx@jaxx.org <mailto:jaxx@jaxx.org>> wrote:
Hi,
I love the OpenCV part, though I'll have to find a way to retofit powersteering and brake actuators in a Twizy, that said, it all shoots way beyond the scope of OVMS (even a v4/v5) imho... but, but, but... an OVMS module shall be the bridge and the low-level comms offloader for an optionnal "Hyper Smart OpenCV Dashboard Music Streaming thingy" that a sister project can take over :-) (my opinion again)
So yeah, It needs to be beefy, and the ESP32 seems to be a nice candidate and embeds by itself a nice load of functions (Wifi and BLE!) http://www.pighixxx.com/test/2015/12/esp32-processor-pinout/ <http://www.pighixxx.com/test/2015/12/esp32-processor-pinout/>
It has no CAN, but it has SPI (can't tell how many on this pinout) and plenty of HS GPIOs for native or soft UARTs. Having 2 CANbuses shouldn't be an issue (I'll let those who fathomed that more than me tell me wrong otherwise)
I don't believe everyone needs a 2/3/4G stack, not counting that those radios end up being the big bucks of the BOM.
Instead, would it be possible to envision a naked board with an extension bus and i2c, interrupts, multiplexed (or not) enable and power lanes? (an edge fitted socket for example, each extension board presents another socket)
The motivation for this particular request is: - It lowers the base cost, with knowledge it can be enhanced, and still carries Wifi+BTBLE for local connectivity with an ESP32 - I doubt my Twizy will ever be stolen to be brought out of LoRa range, and those networks are being deployed quickly, no need for power hungry GSM stacks (that empty my Twizys' 12V battery in 3 days, driving me nuts by the way) - I might want a home brewed I2C GPIO extender on it, a socket makes it easy to make (or a stepper motor drivers to pilot a paintball gun turret fitted on the roof and shoot *ssholes) - The hypothetical day I upgrade to a Tesla 3, I can add that 5G Module that wasn't out yet ;-)
Just thoughts,
JaXX
On Mon, Feb 1, 2016 at 8:30 PM, Michael Eymann < <mailto:Michael.Eymann@networkz.de>Michael.Eymann@networkz.de <mailto:Michael.Eymann@networkz.de>> wrote: All,
what about opening our garden, providing a public park which could be used for several features beside the scope of this group?
3G/4G Wlan Bluetooth GPS whatever could be added / replaced easily….
what i mean is vocabulary like: - raspberry pi - CarPI (CarPC) - OBD - smartphone speedometer gadgets (sure really useless - but the mainstream love it) - Harry´s laptimer support ( <http://www.gps-laptimer.de/>http://www.gps-laptimer.de <http://www.gps-laptimer.de/>) // video: Harry's LapTimer GPS/OBD II Video Overlay - Nordschleife with 911 GTS <https://www.youtube.com/watch?v=fTCNhmsFZBE> https://www.youtube.com/watch?v=fTCNhmsFZBE <https://www.youtube.com/watch?v=fTCNhmsFZBE> - Wlan.. repeater - hotspot… (my favorit)
this could also enable add on development…. - spotify - surround view parking (raspian & openCV?) // AVM: AVM (Around View Monitoring /monitor ) 4CH camera become 360 degree Parking Guidance System <https://www.youtube.com/watch?v=1Q9iVoSvjGk> https://www.youtube.com/watch?v=1Q9iVoSvjGk <https://www.youtube.com/watch?v=1Q9iVoSvjGk> - KITT Watch - car call? - replace Infotainment systems - SmartAutomation like OpenHab integration (They call it „Binding“ - Tesla Model S Binding is already integrated - did they overtake us? ;-) http://www.openhab.org <http://www.openhab.org/>
views?
Michael
Am 01.02.2016 um 18:51 schrieb Dominik Westner < <mailto:ovms@nikwest.de>ovms@nikwest.de <mailto:ovms@nikwest.de>>:
Generally I think 3G doesn’t make a lot of sense. A new platform should be 4G capable. As far as I know 2G is more likely to stay longer than 3G. I know already some areas in Germany and Austria where you can find 4G and maybe 2G, but no 3G.
For example seeedstudio retargeted their Rephone 3G module to 4G after some investigations about the future of 3G. ( <https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-source-and-modular-p/posts/1468366>https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-source-and-modular-p/posts/1468366 <https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-source-and-modular-p/posts/1468366>)
Just my 2 cents
Dominik
On 01 Feb 2016, at 18:30, Arthur Hebert < <mailto:ahebert@gmail.com>ahebert@gmail.com <mailto:ahebert@gmail.com>> wrote:
The Particle Electron has recently caught my attention: <https://www.particle.io/cellular>https://www.particle.io/cellular <https://www.particle.io/cellular>. Actual performance and usability are unknown, since the first units don't ship until later this month, but it has some attractive features: low-cost M2M-oriented international SMS/data plans ($3/mo. for 20k messages) STM32F205 MCU with 1MB flash, 128k RAM and 2 CAN buses free development IDE: <https://www.particle.io/dev>https://www.particle.io/dev <https://www.particle.io/dev> also a free web-based dev environment at <https://build.particle.io/>https://build.particle.io <https://build.particle.io/> (I assume/hope this will support the Electron cellular board when it comes out) I know it doesn't come close to meeting the RAM requirements, but the cellular plan is a pretty big draw IMO. Perhaps worth using this module in conjunction with another board with a better MCU?
-Arthur
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Oh, and also important to bring out some expansion via sockets on side of case. In particular for digital I/O. Regards, Mark.
On 2 Feb 2016, at 5:21 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
My preference for connectors is those 0.1” SIP/DIP ones. They are extremely vibration resistant, breadboard compatible, stackable, etc.
<PastedGraphic-3.tiff> <PastedGraphic-2.tiff>
When layed out properly, they also allow you to stack expansion over existing board components, without sacrificing much space.
For bringing out lots of pins, not so good. But for enough for one or two expansion slots they work well.
Regards, Mark.
On 2 Feb 2016, at 4:59 PM, Julien (JaXX) Banchet <jaxx@jaxx.org <mailto:jaxx@jaxx.org>> wrote:
On 02/02/2016 08:49 AM, Mark Webb-Johnson wrote:
Julien,
It seems that our thinking is similar.
I view OVMS as the CAN processor - perhaps a bridge/gateway - and telematics module. User Interface, Car PC, etc, systems are best handled externally by something that starts up and shuts down with the ignition switch and can suck as much power as your home PC. OVMS has to keep running, in as low power mode as possible, as telematics are required even when the car is off. Exactly, my whole point, plus, that part, externalized, with a standardized way of communicating with the OVMS (uart/bt + ethernet/wifi+mqtt,http://api <http://api/>) will give a full freedom of implementation of the Heavyweight part. BTW: one of the extension boards could be a power-control board with power state signaling, MOSFETs, and a watchdog for that part
Regarding ESP32, that is top of our shortlisted devices for wifi/bluetooth. But, it depends on release schedule. We want OVMS v3 to be FCC and CE certified, and that means we must use FCC+CE certified modules for the comms parts. I don't know if their distribution of 200 beta boards was a cap limit, but maybe shooting a mail to beta@espressif.com <mailto:beta@espressif.com> might be worth it, asking them for approximate timelines with it, no ?
The overall goal is for OVMS v3 to be the microprocessor, power, CAN, USB, ethernet, wifi, and bluetooth, as a base module. Then, everything else (including cellular) are optional plugin modules. We could make wifi+bluetooth optional, but I suspect that they will not add dramatically to the cost/complexity to include as standard. This has got to go in an automotive environment, so plugin modules will most likely go on some sturdy headers on the board. BT/BLE I believe is a minimum to have: It will allow people to have a locally connected Android App (without pumping data over a slow, optionnal and maybe misconfigured GSM stack) and without any hassle at that, latency can be sub 0.5s which is bareable for live metrics... plus, not all phones implement USB OTG correctly... and it's cablefree, which non-DIYers might appreciate.
Form factor wise, my edge connector idea might not be that great, we'd end up with a lonnnngg serie of boards, maybe stackable as an arduino shield ? connectors are cheap, easier for the DIYer, no need to design long pathways that get in the way for signals from border to border...
Regards, Mark.
On 2 Feb 2016, at 3:34 PM, Julien Banchet < <mailto:jaxx@jaxx.org>jaxx@jaxx.org <mailto:jaxx@jaxx.org>> wrote:
Hi,
I love the OpenCV part, though I'll have to find a way to retofit powersteering and brake actuators in a Twizy, that said, it all shoots way beyond the scope of OVMS (even a v4/v5) imho... but, but, but... an OVMS module shall be the bridge and the low-level comms offloader for an optionnal "Hyper Smart OpenCV Dashboard Music Streaming thingy" that a sister project can take over :-) (my opinion again)
So yeah, It needs to be beefy, and the ESP32 seems to be a nice candidate and embeds by itself a nice load of functions (Wifi and BLE!) http://www.pighixxx.com/test/2015/12/esp32-processor-pinout/ <http://www.pighixxx.com/test/2015/12/esp32-processor-pinout/>
It has no CAN, but it has SPI (can't tell how many on this pinout) and plenty of HS GPIOs for native or soft UARTs. Having 2 CANbuses shouldn't be an issue (I'll let those who fathomed that more than me tell me wrong otherwise)
I don't believe everyone needs a 2/3/4G stack, not counting that those radios end up being the big bucks of the BOM.
Instead, would it be possible to envision a naked board with an extension bus and i2c, interrupts, multiplexed (or not) enable and power lanes? (an edge fitted socket for example, each extension board presents another socket)
The motivation for this particular request is: - It lowers the base cost, with knowledge it can be enhanced, and still carries Wifi+BTBLE for local connectivity with an ESP32 - I doubt my Twizy will ever be stolen to be brought out of LoRa range, and those networks are being deployed quickly, no need for power hungry GSM stacks (that empty my Twizys' 12V battery in 3 days, driving me nuts by the way) - I might want a home brewed I2C GPIO extender on it, a socket makes it easy to make (or a stepper motor drivers to pilot a paintball gun turret fitted on the roof and shoot *ssholes) - The hypothetical day I upgrade to a Tesla 3, I can add that 5G Module that wasn't out yet ;-)
Just thoughts,
JaXX
On Mon, Feb 1, 2016 at 8:30 PM, Michael Eymann < <mailto:Michael.Eymann@networkz.de>Michael.Eymann@networkz.de <mailto:Michael.Eymann@networkz.de>> wrote: All,
what about opening our garden, providing a public park which could be used for several features beside the scope of this group?
3G/4G Wlan Bluetooth GPS whatever could be added / replaced easily….
what i mean is vocabulary like: - raspberry pi - CarPI (CarPC) - OBD - smartphone speedometer gadgets (sure really useless - but the mainstream love it) - Harry´s laptimer support ( <http://www.gps-laptimer.de/>http://www.gps-laptimer.de <http://www.gps-laptimer.de/>) // video: Harry's LapTimer GPS/OBD II Video Overlay - Nordschleife with 911 GTS <https://www.youtube.com/watch?v=fTCNhmsFZBE> https://www.youtube.com/watch?v=fTCNhmsFZBE <https://www.youtube.com/watch?v=fTCNhmsFZBE> - Wlan.. repeater - hotspot… (my favorit)
this could also enable add on development…. - spotify - surround view parking (raspian & openCV?) // AVM: AVM (Around View Monitoring /monitor ) 4CH camera become 360 degree Parking Guidance System <https://www.youtube.com/watch?v=1Q9iVoSvjGk> https://www.youtube.com/watch?v=1Q9iVoSvjGk <https://www.youtube.com/watch?v=1Q9iVoSvjGk> - KITT Watch - car call? - replace Infotainment systems - SmartAutomation like OpenHab integration (They call it „Binding“ - Tesla Model S Binding is already integrated - did they overtake us? ;-) http://www.openhab.org <http://www.openhab.org/>
views?
Michael
Am 01.02.2016 um 18:51 schrieb Dominik Westner < <mailto:ovms@nikwest.de>ovms@nikwest.de <mailto:ovms@nikwest.de>>:
Generally I think 3G doesn’t make a lot of sense. A new platform should be 4G capable. As far as I know 2G is more likely to stay longer than 3G. I know already some areas in Germany and Austria where you can find 4G and maybe 2G, but no 3G.
For example seeedstudio retargeted their Rephone 3G module to 4G after some investigations about the future of 3G. ( <https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-source-and-modular-p/posts/1468366>https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-source-and-modular-p/posts/1468366 <https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-source-and-modular-p/posts/1468366>)
Just my 2 cents
Dominik
On 01 Feb 2016, at 18:30, Arthur Hebert < <mailto:ahebert@gmail.com>ahebert@gmail.com <mailto:ahebert@gmail.com>> wrote:
The Particle Electron has recently caught my attention: <https://www.particle.io/cellular>https://www.particle.io/cellular <https://www.particle.io/cellular>. Actual performance and usability are unknown, since the first units don't ship until later this month, but it has some attractive features: low-cost M2M-oriented international SMS/data plans ($3/mo. for 20k messages) STM32F205 MCU with 1MB flash, 128k RAM and 2 CAN buses free development IDE: <https://www.particle.io/dev>https://www.particle.io/dev <https://www.particle.io/dev> also a free web-based dev environment at <https://build.particle.io/>https://build.particle.io <https://build.particle.io/> (I assume/hope this will support the Electron cellular board when it comes out) I know it doesn't come close to meeting the RAM requirements, but the cellular plan is a pretty big draw IMO. Perhaps worth using this module in conjunction with another board with a better MCU?
-Arthur
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 02/02/2016 10:24 AM, Mark Webb-Johnson wrote:
Oh, and also important to bring out some expansion via sockets on side of case. In particular for digital I/O. Yeah, things need to come out :-)
I had something like this in mind: http://www.rtd.com/IDAN/IDAN_selection.htm Of course, at a smaller cheaper scale, Two rows of single pins leaving two borders free for connectors, maybe plastic frames that people will drill themselves for their 2$ OVMS expansion Protoshield (think : https://www.sparkfun.com/products/7914 ), or, simply optionnal framing at all, just need to keep nylon spacers We can even imagine 1U and 2U heights :-) Wild thought : Would it be totally crazy to have it in Arduino sizing and separating the CPU (+BT/Wifi if ESP32) and the Power+Can in two boards for easier replacement, and broader attraction to tinkering ? CAN components end up more expensive than a handful of ESP8266 (Sorry, French exageration), but CAN is robust and is not likely to change enough before we get to OMVS v4 ... Actually, CAN itself would be a module. JB./.
Regards, Mark.
On 2 Feb 2016, at 5:21 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
My preference for connectors is those 0.1” SIP/DIP ones. They are extremely vibration resistant, breadboard compatible, stackable, etc.
<PastedGraphic-3.tiff> <PastedGraphic-2.tiff>
When layed out properly, they also allow you to stack expansion over existing board components, without sacrificing much space.
For bringing out lots of pins, not so good. But for enough for one or two expansion slots they work well.
Regards, Mark.
On 2 Feb 2016, at 4:59 PM, Julien (JaXX) Banchet <jaxx@jaxx.org <mailto:jaxx@jaxx.org>> wrote:
On 02/02/2016 08:49 AM, Mark Webb-Johnson wrote:
Julien,
It seems that our thinking is similar.
I view OVMS as the CAN processor - perhaps a bridge/gateway - and telematics module. User Interface, Car PC, etc, systems are best handled externally by something that starts up and shuts down with the ignition switch and can suck as much power as your home PC. OVMS has to keep running, in as low power mode as possible, as telematics are required even when the car is off. Exactly, my whole point, plus, that part, externalized, with a standardized way of communicating with the OVMS (uart/bt + ethernet/wifi+mqtt,http://api) will give a full freedom of implementation of the Heavyweight part. BTW: one of the extension boards could be a power-control board with power state signaling, MOSFETs, and a watchdog for that part
Regarding ESP32, that is top of our shortlisted devices for wifi/bluetooth. But, it depends on release schedule. We want OVMS v3 to be FCC and CE certified, and that means we must use FCC+CE certified modules for the comms parts. I don't know if their distribution of 200 beta boards was a cap limit, but maybe shooting a mail to beta@espressif.com might be worth it, asking them for approximate timelines with it, no ?
The overall goal is for OVMS v3 to be the microprocessor, power, CAN, USB, ethernet, wifi, and bluetooth, as a base module. Then, everything else (including cellular) are optional plugin modules. We could make wifi+bluetooth optional, but I suspect that they will not add dramatically to the cost/complexity to include as standard. This has got to go in an automotive environment, so plugin modules will most likely go on some sturdy headers on the board. BT/BLE I believe is a minimum to have: It will allow people to have a locally connected Android App (without pumping data over a slow, optionnal and maybe misconfigured GSM stack) and without any hassle at that, latency can be sub 0.5s which is bareable for live metrics... plus, not all phones implement USB OTG correctly... and it's cablefree, which non-DIYers might appreciate.
Form factor wise, my edge connector idea might not be that great, we'd end up with a lonnnngg serie of boards, maybe stackable as an arduino shield ? connectors are cheap, easier for the DIYer, no need to design long pathways that get in the way for signals from border to border...
Regards, Mark.
On 2 Feb 2016, at 3:34 PM, Julien Banchet <jaxx@jaxx.org> wrote:
Hi,
I love the OpenCV part, though I'll have to find a way to retofit powersteering and brake actuators in a Twizy, that said, it all shoots way beyond the scope of OVMS (even a v4/v5) imho... but, but, but... an OVMS module shall be the bridge and the low-level comms offloader for an optionnal "Hyper Smart OpenCV Dashboard Music Streaming thingy" that a sister project can take over :-) (my opinion again)
So yeah, It needs to be beefy, and the ESP32 seems to be a nice candidate and embeds by itself a nice load of functions (Wifi and BLE!) http://www.pighixxx.com/test/2015/12/esp32-processor-pinout/
It has no CAN, but it has SPI (can't tell how many on this pinout) and plenty of HS GPIOs for native or soft UARTs. Having 2 CANbuses shouldn't be an issue (I'll let those who fathomed that more than me tell me wrong otherwise)
I don't believe everyone needs a 2/3/4G stack, not counting that those radios end up being the big bucks of the BOM.
Instead, would it be possible to envision a naked board with an extension bus and i2c, interrupts, multiplexed (or not) enable and power lanes? (an edge fitted socket for example, each extension board presents another socket)
The motivation for this particular request is: - It lowers the base cost, with knowledge it can be enhanced, and still carries Wifi+BTBLE for local connectivity with an ESP32 - I doubt my Twizy will ever be stolen to be brought out of LoRa range, and those networks are being deployed quickly, no need for power hungry GSM stacks (that empty my Twizys' 12V battery in 3 days, driving me nuts by the way) - I might want a home brewed I2C GPIO extender on it, a socket makes it easy to make (or a stepper motor drivers to pilot a paintball gun turret fitted on the roof and shoot *ssholes) - The hypothetical day I upgrade to a Tesla 3, I can add that 5G Module that wasn't out yet ;-)
Just thoughts,
JaXX
On Mon, Feb 1, 2016 at 8:30 PM, Michael Eymann <Michael.Eymann@networkz.de> wrote:
All,
what about opening our garden, providing a public park which could be used for several features beside the scope of this group?
3G/4G Wlan Bluetooth GPS whatever could be added / replaced easily….
what i mean is vocabulary like: - raspberry pi - CarPI (CarPC) - OBD - smartphone speedometer gadgets (sure really useless - but the mainstream love it) - Harry´s laptimer support (http://www.gps-laptimer.de) // video: Harry's LapTimer GPS/OBD II Video Overlay - Nordschleife with 911 GTS <https://www.youtube.com/watch?v=fTCNhmsFZBE> https://www.youtube.com/watch?v=fTCNhmsFZBE - Wlan.. repeater - hotspot… (my favorit) this could also enable add on development…. - spotify - surround view parking (raspian & openCV?) // AVM: AVM (Around View Monitoring /monitor ) 4CH camera become 360 degree Parking Guidance System <https://www.youtube.com/watch?v=1Q9iVoSvjGk> https://www.youtube.com/watch?v=1Q9iVoSvjGk - KITT Watch - car call? - replace Infotainment systems - SmartAutomation like OpenHab integration (They call it „Binding“ - Tesla Model S Binding is already integrated - did they overtake us? ;-) http://www.openhab.org <http://www.openhab.org/>
views?
Michael
Am 01.02.2016 um 18:51 schrieb Dominik Westner <ovms@nikwest.de>:
Generally I think 3G doesn’t make a lot of sense. A new platform should be 4G capable. As far as I know 2G is more likely to stay longer than 3G. I know already some areas in Germany and Austria where you can find 4G and maybe 2G, but no 3G.
For example seeedstudio retargeted their Rephone 3G module to 4G after some investigations about the future of 3G. (https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-sou...)
Just my 2 cents
Dominik
On 01 Feb 2016, at 18:30, Arthur Hebert <ahebert@gmail.com> wrote:
The Particle Electron has recently caught my attention: https://www.particle.io/cellular. Actual performance and usability are unknown, since the first units don't ship until later this month, but it has some attractive features:
* low-cost M2M-oriented international SMS/data plans ($3/mo. for 20k messages) * STM32F205 MCU with *1MB flash*, 128k RAM and *2 CAN buses* * free development IDE: https://www.particle.io/dev * also a free web-based dev environment at https://build.particle.io (I assume/hope this will support the Electron cellular board when it comes out)
I know it doesn't come close to meeting the RAM requirements, but the cellular plan is a pretty big draw IMO. Perhaps worth using this module in conjunction with another board with a better MCU?
-Arthur
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Dominik, The idea is to make the cellular modem an (optional) plug-in board. This is necessary for two reasons: a) Technology changes (2G->3G->4G). b) Universal modems (such as quad band 2G that work everywhere in the world) aren’t really possible in the 3G/4G space, so we need different modems for different parts of the world. Happy to look at both 3G and 4G options as the time draws near. Quite frankly, there are a huge number of options out there for this. I consider this one of the easiest parts of the project. Regards, Mark.
On 2 Feb 2016, at 1:51 AM, Dominik Westner <ovms@nikwest.de> wrote:
Generally I think 3G doesn’t make a lot of sense. A new platform should be 4G capable. As far as I know 2G is more likely to stay longer than 3G. I know already some areas in Germany and Austria where you can find 4G and maybe 2G, but no 3G.
For example seeedstudio retargeted their Rephone 3G module to 4G after some investigations about the future of 3G. (https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-sou... <https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-source-and-modular-p/posts/1468366>)
Just my 2 cents
Dominik
On 01 Feb 2016, at 18:30, Arthur Hebert <ahebert@gmail.com <mailto:ahebert@gmail.com>> wrote:
The Particle Electron has recently caught my attention: https://www.particle.io/cellular <https://www.particle.io/cellular>. Actual performance and usability are unknown, since the first units don't ship until later this month, but it has some attractive features: low-cost M2M-oriented international SMS/data plans ($3/mo. for 20k messages) STM32F205 MCU with 1MB flash, 128k RAM and 2 CAN buses free development IDE: https://www.particle.io/dev <https://www.particle.io/dev> also a free web-based dev environment at https://build.particle.io <https://build.particle.io/> (I assume/hope this will support the Electron cellular board when it comes out) I know it doesn't come close to meeting the RAM requirements, but the cellular plan is a pretty big draw IMO. Perhaps worth using this module in conjunction with another board with a better MCU?
-Arthur
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Well, the first units shipped late last year to people who funded the early kickstarter campaign. I've got one of those and I'm on the list for 4 more when the first batch of general release units ship later this month. The Electron seems pretty nice from what I've seen. I haven't played with it much. One thing that kind of sucks with this sort of cellular is that it nearly requires that you use their lithium battery. You also need a really beefy power supply to keep it running. I don't know what OVMS currently uses but you'd probably be looking at a 10w power supply to ensure that all components stay running. Electron seems to use their proprietary cloud network by default so I'm not sure how well that would mesh with OVMS. But, it has a cellular modem and it's open source so I don't see any reason it could not be reprogrammed to use a custom cloud network. On Mon, Feb 1, 2016 at 12:30 PM, Arthur Hebert <ahebert@gmail.com> wrote:
The Particle Electron has recently caught my attention: https://www.particle.io/cellular. Actual performance and usability are unknown, since the first units don't ship until later this month, but it has some attractive features:
low-cost M2M-oriented international SMS/data plans ($3/mo. for 20k messages) STM32F205 MCU with 1MB flash, 128k RAM and 2 CAN buses free development IDE: https://www.particle.io/dev also a free web-based dev environment at https://build.particle.io (I assume/hope this will support the Electron cellular board when it comes out)
I know it doesn't come close to meeting the RAM requirements, but the cellular plan is a pretty big draw IMO. Perhaps worth using this module in conjunction with another board with a better MCU?
-Arthur
On Mon, Feb 1, 2016 at 5:35 AM, Mark Webb-Johnson <mark@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Arthur, There is another like this: https://konekt.io/ <https://konekt.io/> and those guys sell just the SIMs and data plans (actually seem cheaper than particle.io <http://particle.io/>). I’ve got a couple of SIMs from them that I’ve been testing for a while. Seems fine. Just cellular data, and no SMS. The issue, of course, is that these are cellular only. No bluetooth. No wifi. We’re looking for something with all three. The single or dual can buses are also an issue. And the elephant in the closet is the proprietary back end - if these guys shut down, so would we. Regards, Mark.
On 2 Feb 2016, at 1:30 AM, Arthur Hebert <ahebert@gmail.com> wrote:
The Particle Electron has recently caught my attention: https://www.particle.io/cellular <https://www.particle.io/cellular>. Actual performance and usability are unknown, since the first units don't ship until later this month, but it has some attractive features: low-cost M2M-oriented international SMS/data plans ($3/mo. for 20k messages) STM32F205 MCU with 1MB flash, 128k RAM and 2 CAN buses free development IDE: https://www.particle.io/dev <https://www.particle.io/dev> also a free web-based dev environment at https://build.particle.io <https://build.particle.io/> (I assume/hope this will support the Electron cellular board when it comes out) I know it doesn't come close to meeting the RAM requirements, but the cellular plan is a pretty big draw IMO. Perhaps worth using this module in conjunction with another board with a better MCU?
-Arthur
On Mon, Feb 1, 2016 at 5:35 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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/...), 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@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@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@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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/ <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@jaxx.org <mailto:jaxx@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/ <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@webb-johnson.net <mailto:mark@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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. 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. 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. The board is 4x2cm and can be directly stacked on top of an OBD connector. 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). 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. Pic: http://www.mastrogippo.it/ct-1.jpg Regards MG On Thu, Feb 4, 2016 at 2:47 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
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@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@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 02/04/2016 03:29 PM, Mastro Gippo wrote:
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. 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. 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. Actually, 3G might disappear before 2G in EU, simply because too many vital services depend on it, down to railway track switches... The board is 4x2cm and can be directly stacked on top of an OBD connector. 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). The more I read about it, the more Sigfox is to be excluded, the 100bps throughput gives up to 2 seconds of over-the-air time for the limited payload of 12bytes, the infrastructure is good though, I know the team a little bit and they do good stuff (when you end up living in Toulouse, you have to be part of the hackerspace mouvement :-) ), but the tech itself has it's limitations, and a 2s transmit time makes it likely to make it impossible to get a complete message in a moving vehicule, and without ACK, the message is transmitted 3 times "just in case"... it's a big handful of time occupation where you'd like realtime telemetry. And, you're allowed 140 messages/day, with back-off punishments if you go beyond that.
LoRa suffers less from this, but then it will depend on the operators density and the economic model they'll push out... I'm sure there are SigFox lovers here: don't get me wrong: It's great technology for static or mostly static, event triggered sensors, that can be today deployed in vast areas and/or dense cities, with clean and easy APIs and frontend to set up your callback URLs... I can imagine half a billion applications to it, from a moisture detector in a middle of a football field to smoke detectors in a forests canopees. I just don't think that specific tech is adapted to the automotive industry JaXX
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. Pic: http://www.mastrogippo.it/ct-1.jpg
Regards MG
On Thu, Feb 4, 2016 at 2:47 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
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@gmail.com <mailto:ahebert@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@jaxx.org <mailto:jaxx@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@webb-johnson.net <mailto:mark@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mastro, 512KB flash and 64KB RAM really isn’t going to be enough. 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. 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. 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. 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. Regards, Mark.
On 4 Feb 2016, at 10:29 PM, Mastro Gippo <gipmad@gmail.com> wrote:
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. 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. 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. The board is 4x2cm and can be directly stacked on top of an OBD connector. 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). 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. Pic: http://www.mastrogippo.it/ct-1.jpg <http://www.mastrogippo.it/ct-1.jpg>
Regards MG
On Thu, Feb 4, 2016 at 2:47 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote: 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@gmail.com <mailto:ahebert@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/ <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@jaxx.org <mailto:jaxx@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/ <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@webb-johnson.net <mailto:mark@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On Thu, Feb 11, 2016 at 8:30 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Mastro,
512KB flash and 64KB RAM really isn’t going to be enough.
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.
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.
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.
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.
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 :-( JaXX./.
Regards, Mark.
On 4 Feb 2016, at 10:29 PM, Mastro Gippo <gipmad@gmail.com> wrote:
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. 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. 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. The board is 4x2cm and can be directly stacked on top of an OBD connector. 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). 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. Pic: http://www.mastrogippo.it/ct-1.jpg
Regards MG
On Thu, Feb 4, 2016 at 2:47 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
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@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@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
ESP32 look great. I tried to get in on the beta, but no chance. Production modules coming in April. We can’t run on it (too limited in CAN, flash, ram, etc), but we can use it as a peripheral to handle bluetooth+wifi. Power is not so much an issue so long as we can shut these things down when we don’t need them (or put them in low power mode). I think we just need to know how to do this and make sure we can do this from day#1. Regards, Mark.
On 11 Feb 2016, at 4:54 PM, Julien Banchet <jaxx@jaxx.org> wrote:
On Thu, Feb 11, 2016 at 8:30 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote: Mastro,
512KB flash and 64KB RAM really isn’t going to be enough.
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.
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.
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.
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.
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 :-(
JaXX./.
Regards, Mark.
On 4 Feb 2016, at 10:29 PM, Mastro Gippo <gipmad@gmail.com <mailto:gipmad@gmail.com>> wrote:
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. 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. 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. The board is 4x2cm and can be directly stacked on top of an OBD connector. 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). 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. Pic: http://www.mastrogippo.it/ct-1.jpg <http://www.mastrogippo.it/ct-1.jpg>
Regards MG
On Thu, Feb 4, 2016 at 2:47 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote: 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@gmail.com <mailto:ahebert@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/ <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@jaxx.org <mailto:jaxx@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/ <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@webb-johnson.net <mailto:mark@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, 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 temperature rating. 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 Windows. I think this is a great-sounding solution overall. -Arthur On Wed, Feb 3, 2016 at 5:47 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
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@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@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (11)
-
Arthur Hebert -
Collin Kidder -
Dominik Westner -
felix bonnier -
HONDA S-2000 -
Julien (JaXX) Banchet -
Julien Banchet
-
Mark Webb-Johnson -
Mastro Gippo -
Michael Balzer -
Michael Eymann