Twizy controller configuration / CANopen SDO protocol
Hi everyone, sorry for dropping behind/off last months, lots of work. I've not been able to catch up on the framework advances yet, but nevertheless wanted to announce a major Twizy update I'm currently working on. This update enables access to the SEVCON controller configuration of the Twizy. Low level commands allow read and write access to all SDOs. Macro commands allow to easily change common settings like maximum speed, maximum torque, power and recuperation levels and drive profile characteristics. There is a potential benefit for other vehicles from this development: I've done a basic CANopen SDO protocol implementation for this. The implementation is specific to the Twizy only because it's limited to addressing just node #1 and currently only supports expedited SDO transfers, not segmented. The node id could easily be made variable, and segmented transfers should be not much of a problem. It still is nowhere near a complete CANopen protocol implementation, but allows SDO reading and writing. Tell me if this sounds useful for other vehicles. As I've not yet integrated your latest work, I've pushed this into my Github repository first: https://github.com/dexterbg/Open-Vehicle-Monitoring-System I'll also wait for some more user feedback before going on, and I also want to implement support for the Twizy 45 before merging this in. Just wanted to let you know in case you wonder about rising OVMS hardware sales lately ;-) Oh, and I wish you all a happy new year! Regards, Michael -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
Oh darn. I knew I should have kept my Twizy... On Tuesday, December 31, 2013, Michael Balzer wrote:
Hi everyone,
sorry for dropping behind/off last months, lots of work.
I've not been able to catch up on the framework advances yet, but nevertheless wanted to announce a major Twizy update I'm currently working on.
This update enables access to the SEVCON controller configuration of the Twizy.
Low level commands allow read and write access to all SDOs. Macro commands allow to easily change common settings like maximum speed, maximum torque, power and recuperation levels and drive profile characteristics.
There is a potential benefit for other vehicles from this development: I've done a basic CANopen SDO protocol implementation for this. The implementation is specific to the Twizy only because it's limited to addressing just node #1 and currently only supports expedited SDO transfers, not segmented. The node id could easily be made variable, and segmented transfers should be not much of a problem. It still is nowhere near a complete CANopen protocol implementation, but allows SDO reading and writing. Tell me if this sounds useful for other vehicles.
As I've not yet integrated your latest work, I've pushed this into my Github repository first:
https://github.com/dexterbg/Open-Vehicle-Monitoring-System
I'll also wait for some more user feedback before going on, and I also want to implement support for the Twizy 45 before merging this in.
Just wanted to let you know in case you wonder about rising OVMS hardware sales lately ;-)
Oh, and I wish you all a happy new year!
Regards, Michael
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
-- Nikki Gordon-Bloomfield http://about.me/aminorjourney/bio email: nikki@littleCollie.com tel: +44 7901 553308
Wow, nice! It is amazing the amount of low-level stuff you guys have managed to find for the Twizy. The CANopen SDO stuff probably deserves to be in vehicle.{h,c} - along with the pid polling stuff in 2.6. Regards, Mark
On 31 Dec, 2013, at 8:39 pm, Michael Balzer <dexter@expeedo.de> wrote:
Hi everyone,
sorry for dropping behind/off last months, lots of work.
I've not been able to catch up on the framework advances yet, but nevertheless wanted to announce a major Twizy update I'm currently working on.
This update enables access to the SEVCON controller configuration of the Twizy.
Low level commands allow read and write access to all SDOs. Macro commands allow to easily change common settings like maximum speed, maximum torque, power and recuperation levels and drive profile characteristics.
There is a potential benefit for other vehicles from this development: I've done a basic CANopen SDO protocol implementation for this. The implementation is specific to the Twizy only because it's limited to addressing just node #1 and currently only supports expedited SDO transfers, not segmented. The node id could easily be made variable, and segmented transfers should be not much of a problem. It still is nowhere near a complete CANopen protocol implementation, but allows SDO reading and writing. Tell me if this sounds useful for other vehicles.
As I've not yet integrated your latest work, I've pushed this into my Github repository first:
https://github.com/dexterbg/Open-Vehicle-Monitoring-System
I'll also wait for some more user feedback before going on, and I also want to implement support for the Twizy 45 before merging this in.
Just wanted to let you know in case you wonder about rising OVMS hardware sales lately ;-)
Oh, and I wish you all a happy new year!
Regards, Michael
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
<dexter.vcf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I know a local Twizy owner. Perhaps I can convince him to buy the kit? On Thu, Jan 2, 2014 at 12:47 AM, Mark Webb-Johnson <mark@webb-johnson.net>wrote:
Wow, nice!
It is amazing the amount of low-level stuff you guys have managed to find for the Twizy.
The CANopen SDO stuff probably deserves to be in vehicle.{h,c} - along with the pid polling stuff in 2.6.
Regards, Mark
On 31 Dec, 2013, at 8:39 pm, Michael Balzer <dexter@expeedo.de> wrote:
Hi everyone,
sorry for dropping behind/off last months, lots of work.
I've not been able to catch up on the framework advances yet, but nevertheless wanted to announce a major Twizy update I'm currently working on.
This update enables access to the SEVCON controller configuration of the Twizy.
Low level commands allow read and write access to all SDOs. Macro commands allow to easily change common settings like maximum speed, maximum torque, power and recuperation levels and drive profile characteristics.
There is a potential benefit for other vehicles from this development: I've done a basic CANopen SDO protocol implementation for this. The implementation is specific to the Twizy only because it's limited to addressing just node #1 and currently only supports expedited SDO transfers, not segmented. The node id could easily be made variable, and segmented transfers should be not much of a problem. It still is nowhere near a complete CANopen protocol implementation, but allows SDO reading and writing. Tell me if this sounds useful for other vehicles.
As I've not yet integrated your latest work, I've pushed this into my Github repository first:
https://github.com/dexterbg/Open-Vehicle-Monitoring-System
I'll also wait for some more user feedback before going on, and I also want to implement support for the Twizy 45 before merging this in.
Just wanted to let you know in case you wonder about rising OVMS hardware sales lately ;-)
Oh, and I wish you all a happy new year!
Regards, Michael
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
<dexter.vcf> _______________________________________________ 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
-- Nikki Gordon-Bloomfield http://about.me/aminorjourney/bio email: nikki@littleCollie.com tel: +44 7901 553308
Hi everyone, I have integrated the latest Twizy release 3.0.2 with framework version 2.6.1 and pushed it into the main repository. Please note: 1) I had to introduce a new preprocessor flag for the vehicle polling system: OVMS_POLLER The Twizy firmware will just barely compile with it enabled, but not work (poll0() will not be called). Anyway it doesn't need the polling system, so I disabled it instead of changing something. You'll need to add the flag to your build configurations if you use the polling. 2) I have included a major stability improvement for the interrupt codes. With deeper nesting and stack usage, my crashes multiplied. On checking everything I stumbled across the info, that calling functions is among the worst things to do inside an ISR. The compiler needs to save the complete context including all temporary data on the stack, which is both very time consuming and can use a lot of stack space. There's a good info on this topic on the web: http://www.xargs.com/pic/c18-isr-optim.pdf I've implemented a separate tmpdata section for both low and high priority ISRs based on this info and had not a single crash since then. Also no CAN data has been lost since the change and the module has become rock steady on the GSM and GPS connection. The downside is, it needs some additional RAM for the ISR tmpdata sections. As both the ISR main/entry functions and all called functions need to use the separate tmpdata section, I changed all vehicle modules accordingly. Please check if everything still works. With acc and logging disabled and all Twizy features activated I now get... RAM Used: 3152 (0xC50) Free: 176 (0xB0) Flash Used: 97756 (0x17DDC) Free: 548 (0x224) So I'm approaching the final frontier... but in another way as expected, I always thought RAM is my problem... Regards, Michael Am 31.12.2013 13:39, schrieb Michael Balzer:
Hi everyone,
sorry for dropping behind/off last months, lots of work.
I've not been able to catch up on the framework advances yet, but nevertheless wanted to announce a major Twizy update I'm currently working on.
This update enables access to the SEVCON controller configuration of the Twizy.
Low level commands allow read and write access to all SDOs. Macro commands allow to easily change common settings like maximum speed, maximum torque, power and recuperation levels and drive profile characteristics.
There is a potential benefit for other vehicles from this development: I've done a basic CANopen SDO protocol implementation for this. The implementation is specific to the Twizy only because it's limited to addressing just node #1 and currently only supports expedited SDO transfers, not segmented. The node id could easily be made variable, and segmented transfers should be not much of a problem. It still is nowhere near a complete CANopen protocol implementation, but allows SDO reading and writing. Tell me if this sounds useful for other vehicles.
As I've not yet integrated your latest work, I've pushed this into my Github repository first:
https://github.com/dexterbg/Open-Vehicle-Monitoring-System
I'll also wait for some more user feedback before going on, and I also want to implement support for the Twizy 45 before merging this in.
Just wanted to let you know in case you wonder about rising OVMS hardware sales lately ;-)
Oh, and I wish you all a happy new year!
Regards, Michael
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
Michael, Nice. I'll have a play with it this weekend. Regards, Mark. P.S. I was aware (recently) of the ISR stuff, but didn't realise the fix was so (relatively) easy. Thanks for handling this. On 5 Jan, 2014, at 9:22 am, Michael Balzer <dexter@expeedo.de> wrote:
Hi everyone,
I have integrated the latest Twizy release 3.0.2 with framework version 2.6.1 and pushed it into the main repository.
Please note:
1) I had to introduce a new preprocessor flag for the vehicle polling system: OVMS_POLLER
The Twizy firmware will just barely compile with it enabled, but not work (poll0() will not be called). Anyway it doesn't need the polling system, so I disabled it instead of changing something.
You'll need to add the flag to your build configurations if you use the polling.
2) I have included a major stability improvement for the interrupt codes. With deeper nesting and stack usage, my crashes multiplied. On checking everything I stumbled across the info, that calling functions is among the worst things to do inside an ISR. The compiler needs to save the complete context including all temporary data on the stack, which is both very time consuming and can use a lot of stack space.
There's a good info on this topic on the web: http://www.xargs.com/pic/c18-isr-optim.pdf
I've implemented a separate tmpdata section for both low and high priority ISRs based on this info and had not a single crash since then. Also no CAN data has been lost since the change and the module has become rock steady on the GSM and GPS connection.
The downside is, it needs some additional RAM for the ISR tmpdata sections. As both the ISR main/entry functions and all called functions need to use the separate tmpdata section, I changed all vehicle modules accordingly. Please check if everything still works.
With acc and logging disabled and all Twizy features activated I now get...
RAM Used: 3152 (0xC50) Free: 176 (0xB0) Flash Used: 97756 (0x17DDC) Free: 548 (0x224)
So I'm approaching the final frontier... but in another way as expected, I always thought RAM is my problem...
Regards, Michael
Am 31.12.2013 13:39, schrieb Michael Balzer:
Hi everyone,
sorry for dropping behind/off last months, lots of work.
I've not been able to catch up on the framework advances yet, but nevertheless wanted to announce a major Twizy update I'm currently working on.
This update enables access to the SEVCON controller configuration of the Twizy.
Low level commands allow read and write access to all SDOs. Macro commands allow to easily change common settings like maximum speed, maximum torque, power and recuperation levels and drive profile characteristics.
There is a potential benefit for other vehicles from this development: I've done a basic CANopen SDO protocol implementation for this. The implementation is specific to the Twizy only because it's limited to addressing just node #1 and currently only supports expedited SDO transfers, not segmented. The node id could easily be made variable, and segmented transfers should be not much of a problem. It still is nowhere near a complete CANopen protocol implementation, but allows SDO reading and writing. Tell me if this sounds useful for other vehicles.
As I've not yet integrated your latest work, I've pushed this into my Github repository first:
https://github.com/dexterbg/Open-Vehicle-Monitoring-System
I'll also wait for some more user feedback before going on, and I also want to implement support for the Twizy 45 before merging this in.
Just wanted to let you know in case you wonder about rising OVMS hardware sales lately ;-)
Oh, and I wish you all a happy new year!
Regards, Michael
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Michael, I added the OVMS_POLLER as necessary, and committed that code. But, not getting much luck compiling this. The single vehicle configs (V1, V2_TR and V2_RT) compile ok. But, V2_EXPERIMENTAL gives the following error: Error - section 'MATH_DATA' can not fit the section. Section 'MATH_DATA' length=0x00000014 and V2_PRODUCTION gives: Error - section '.tmpdata' can not fit the section. Section '.tmpdata' length=0x00000024 I’m not sure why it is complaining about .tmpdata, when it should now be using high_isr_tmpdata for the code. I’ll keep looking, but I’m not sure if this approach will be so easy… Regards, Mark. On 8 Jan, 2014, at 8:08 am, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Michael,
Nice. I'll have a play with it this weekend.
Regards, Mark.
P.S. I was aware (recently) of the ISR stuff, but didn't realise the fix was so (relatively) easy. Thanks for handling this.
On 5 Jan, 2014, at 9:22 am, Michael Balzer <dexter@expeedo.de> wrote:
Hi everyone,
I have integrated the latest Twizy release 3.0.2 with framework version 2.6.1 and pushed it into the main repository.
Please note:
1) I had to introduce a new preprocessor flag for the vehicle polling system: OVMS_POLLER
The Twizy firmware will just barely compile with it enabled, but not work (poll0() will not be called). Anyway it doesn't need the polling system, so I disabled it instead of changing something.
You'll need to add the flag to your build configurations if you use the polling.
2) I have included a major stability improvement for the interrupt codes. With deeper nesting and stack usage, my crashes multiplied. On checking everything I stumbled across the info, that calling functions is among the worst things to do inside an ISR. The compiler needs to save the complete context including all temporary data on the stack, which is both very time consuming and can use a lot of stack space.
There's a good info on this topic on the web: http://www.xargs.com/pic/c18-isr-optim.pdf
I've implemented a separate tmpdata section for both low and high priority ISRs based on this info and had not a single crash since then. Also no CAN data has been lost since the change and the module has become rock steady on the GSM and GPS connection.
The downside is, it needs some additional RAM for the ISR tmpdata sections. As both the ISR main/entry functions and all called functions need to use the separate tmpdata section, I changed all vehicle modules accordingly. Please check if everything still works.
With acc and logging disabled and all Twizy features activated I now get...
RAM Used: 3152 (0xC50) Free: 176 (0xB0) Flash Used: 97756 (0x17DDC) Free: 548 (0x224)
So I'm approaching the final frontier... but in another way as expected, I always thought RAM is my problem...
Regards, Michael
Am 31.12.2013 13:39, schrieb Michael Balzer:
Hi everyone,
sorry for dropping behind/off last months, lots of work.
I've not been able to catch up on the framework advances yet, but nevertheless wanted to announce a major Twizy update I'm currently working on.
This update enables access to the SEVCON controller configuration of the Twizy.
Low level commands allow read and write access to all SDOs. Macro commands allow to easily change common settings like maximum speed, maximum torque, power and recuperation levels and drive profile characteristics.
There is a potential benefit for other vehicles from this development: I've done a basic CANopen SDO protocol implementation for this. The implementation is specific to the Twizy only because it's limited to addressing just node #1 and currently only supports expedited SDO transfers, not segmented. The node id could easily be made variable, and segmented transfers should be not much of a problem. It still is nowhere near a complete CANopen protocol implementation, but allows SDO reading and writing. Tell me if this sounds useful for other vehicles.
As I've not yet integrated your latest work, I've pushed this into my Github repository first:
https://github.com/dexterbg/Open-Vehicle-Monitoring-System
I'll also wait for some more user feedback before going on, and I also want to implement support for the Twizy 45 before merging this in.
Just wanted to let you know in case you wonder about rising OVMS hardware sales lately ;-)
Oh, and I wish you all a happy new year!
Regards, Michael
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ 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
Mark, can't look at the config right now, but if V2_* contain everything, I think that will be too much on both ROM and RAM size now. I had a similar problem with V2_RT before disabling logging and acc. Maybe you can get it to build if you disable the Twizy battery monitor and the new cfg command. Regards, Michael Am 08.01.2014 13:50, schrieb Mark Webb-Johnson:
Michael,
I added the OVMS_POLLER as necessary, and committed that code. But, not getting much luck compiling this.
The single vehicle configs (V1, V2_TR and V2_RT) compile ok.
But, V2_EXPERIMENTAL gives the following error:
Error - section 'MATH_DATA' can not fit the section. Section 'MATH_DATA' length=0x00000014
and V2_PRODUCTION gives:
Error - section '.tmpdata' can not fit the section. Section '.tmpdata' length=0x00000024
I'm not sure why it is complaining about .tmpdata, when it should now be using high_isr_tmpdata for the code.
I'll keep looking, but I'm not sure if this approach will be so easy...
Regards, Mark.
On 8 Jan, 2014, at 8:08 am, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Michael,
Nice. I'll have a play with it this weekend.
Regards, Mark.
P.S. I was aware (recently) of the ISR stuff, but didn't realise the fix was so (relatively) easy. Thanks for handling this.
On 5 Jan, 2014, at 9:22 am, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Hi everyone,
I have integrated the latest Twizy release 3.0.2 with framework version 2.6.1 and pushed it into the main repository.
Please note:
1) I had to introduce a new preprocessor flag for the vehicle polling system: OVMS_POLLER
The Twizy firmware will just barely compile with it enabled, but not work (poll0() will not be called). Anyway it doesn't need the polling system, so I disabled it instead of changing something.
You'll need to add the flag to your build configurations if you use the polling.
2) I have included a major stability improvement for the interrupt codes. With deeper nesting and stack usage, my crashes multiplied. On checking everything I stumbled across the info, that calling functions is among the worst things to do inside an ISR. The compiler needs to save the complete context including all temporary data on the stack, which is both very time consuming and can use a lot of stack space.
There's a good info on this topic on the web: http://www.xargs.com/pic/c18-isr-optim.pdf
I've implemented a separate tmpdata section for both low and high priority ISRs based on this info and had not a single crash since then. Also no CAN data has been lost since the change and the module has become rock steady on the GSM and GPS connection.
The downside is, it needs some additional RAM for the ISR tmpdata sections. As both the ISR main/entry functions and all called functions need to use the separate tmpdata section, I changed all vehicle modules accordingly. Please check if everything still works.
With acc and logging disabled and all Twizy features activated I now get...
RAM Used: 3152 (0xC50) Free: 176 (0xB0) Flash Used: 97756 (0x17DDC) Free: 548 (0x224)
So I'm approaching the final frontier... but in another way as expected, I always thought RAM is my problem...
Regards, Michael
Am 31.12.2013 13:39, schrieb Michael Balzer:
Hi everyone,
sorry for dropping behind/off last months, lots of work.
I've not been able to catch up on the framework advances yet, but nevertheless wanted to announce a major Twizy update I'm currently working on.
This update enables access to the SEVCON controller configuration of the Twizy.
Low level commands allow read and write access to all SDOs. Macro commands allow to easily change common settings like maximum speed, maximum torque, power and recuperation levels and drive profile characteristics.
There is a potential benefit for other vehicles from this development: I've done a basic CANopen SDO protocol implementation for this. The implementation is specific to the Twizy only because it's limited to addressing just node #1 and currently only supports expedited SDO transfers, not segmented. The node id could easily be made variable, and segmented transfers should be not much of a problem. It still is nowhere near a complete CANopen protocol implementation, but allows SDO reading and writing. Tell me if this sounds useful for other vehicles.
As I've not yet integrated your latest work, I've pushed this into my Github repository first:
https://github.com/dexterbg/Open-Vehicle-Monitoring-System
I'll also wait for some more user feedback before going on, and I also want to implement support for the Twizy 45 before merging this in.
Just wanted to let you know in case you wonder about rising OVMS hardware sales lately ;-)
Oh, and I wish you all a happy new year!
Regards, Michael
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
if V2_* contain everything, I think that will be too much on both ROM and RAM size now.
The V2_Experimental contains a lot, but V2_Production is just a few vehicle types. Used to be lots of room, and both OVMS_TWIZY_BATTMON and OVMS_TWIZY_CFG are disabled in that V2_Production config.
With acc and logging disabled and all Twizy features activated I now get...
RAM Used: 3152 (0xC50) Free: 176 (0xB0) Flash Used: 97756 (0x17DDC) Free: 548 (0x224)
Compiling the V2_RT_Production config, I get: RAM Used: 3152 (0xC50) Free: 567 (0x237) Flash Used: 97756 (0x17DDC) Free: 548 (0x224) That is on a Mac, with OVMS_TWIZY_BATTMON and OVMS_TWIZY_CFG enabled, but logging and acc disabled. Are you using the Windows compiler or Mac? If I switch to extended mode, I get: RAM Used: 3141 (0xC45) Free: 578 (0x242) Flash Used: 87056 (0x15410) Free: 11248 (0x2BF0) Not sure if we can use extended mode or not - if we can, it will give us a lot of breathing room. If I enable extended mode, everything compiles just fine (all configs). Supposedly the PIC18F2685 supports the C-optimised extended instruction set. Regards, Mark. On 8 Jan, 2014, at 9:11 pm, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
can't look at the config right now, but if V2_* contain everything, I think that will be too much on both ROM and RAM size now.
I had a similar problem with V2_RT before disabling logging and acc.
Maybe you can get it to build if you disable the Twizy battery monitor and the new cfg command.
Regards, Michael
Am 08.01.2014 13:50, schrieb Mark Webb-Johnson:
Michael,
I added the OVMS_POLLER as necessary, and committed that code. But, not getting much luck compiling this.
The single vehicle configs (V1, V2_TR and V2_RT) compile ok.
But, V2_EXPERIMENTAL gives the following error:
Error - section 'MATH_DATA' can not fit the section. Section 'MATH_DATA' length=0x00000014
and V2_PRODUCTION gives:
Error - section '.tmpdata' can not fit the section. Section '.tmpdata' length=0x00000024
I’m not sure why it is complaining about .tmpdata, when it should now be using high_isr_tmpdata for the code.
I’ll keep looking, but I’m not sure if this approach will be so easy…
Regards, Mark.
On 8 Jan, 2014, at 8:08 am, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Michael,
Nice. I'll have a play with it this weekend.
Regards, Mark.
P.S. I was aware (recently) of the ISR stuff, but didn't realise the fix was so (relatively) easy. Thanks for handling this.
On 5 Jan, 2014, at 9:22 am, Michael Balzer <dexter@expeedo.de> wrote:
Hi everyone,
I have integrated the latest Twizy release 3.0.2 with framework version 2.6.1 and pushed it into the main repository.
Please note:
1) I had to introduce a new preprocessor flag for the vehicle polling system: OVMS_POLLER
The Twizy firmware will just barely compile with it enabled, but not work (poll0() will not be called). Anyway it doesn't need the polling system, so I disabled it instead of changing something.
You'll need to add the flag to your build configurations if you use the polling.
2) I have included a major stability improvement for the interrupt codes. With deeper nesting and stack usage, my crashes multiplied. On checking everything I stumbled across the info, that calling functions is among the worst things to do inside an ISR. The compiler needs to save the complete context including all temporary data on the stack, which is both very time consuming and can use a lot of stack space.
There's a good info on this topic on the web: http://www.xargs.com/pic/c18-isr-optim.pdf
I've implemented a separate tmpdata section for both low and high priority ISRs based on this info and had not a single crash since then. Also no CAN data has been lost since the change and the module has become rock steady on the GSM and GPS connection.
The downside is, it needs some additional RAM for the ISR tmpdata sections. As both the ISR main/entry functions and all called functions need to use the separate tmpdata section, I changed all vehicle modules accordingly. Please check if everything still works.
With acc and logging disabled and all Twizy features activated I now get...
RAM Used: 3152 (0xC50) Free: 176 (0xB0) Flash Used: 97756 (0x17DDC) Free: 548 (0x224)
So I'm approaching the final frontier... but in another way as expected, I always thought RAM is my problem...
Regards, Michael
Am 31.12.2013 13:39, schrieb Michael Balzer:
Hi everyone,
sorry for dropping behind/off last months, lots of work.
I've not been able to catch up on the framework advances yet, but nevertheless wanted to announce a major Twizy update I'm currently working on.
This update enables access to the SEVCON controller configuration of the Twizy.
Low level commands allow read and write access to all SDOs. Macro commands allow to easily change common settings like maximum speed, maximum torque, power and recuperation levels and drive profile characteristics.
There is a potential benefit for other vehicles from this development: I've done a basic CANopen SDO protocol implementation for this. The implementation is specific to the Twizy only because it's limited to addressing just node #1 and currently only supports expedited SDO transfers, not segmented. The node id could easily be made variable, and segmented transfers should be not much of a problem. It still is nowhere near a complete CANopen protocol implementation, but allows SDO reading and writing. Tell me if this sounds useful for other vehicles.
As I've not yet integrated your latest work, I've pushed this into my Github repository first:
https://github.com/dexterbg/Open-Vehicle-Monitoring-System
I'll also wait for some more user feedback before going on, and I also want to implement support for the Twizy 45 before merging this in.
Just wanted to let you know in case you wonder about rising OVMS hardware sales lately ;-)
Oh, and I wish you all a happy new year!
Regards, Michael
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, I now also have compiled in extended mode (got no choice). I only get some warnings about static function args, not sure if they need to be static, doesn't seem so. First tests have been completely fine in both diag and live mode, so I'll use the extended mode firmware during the next days to see if anything goes wrong. Regards, Michael Am 08.01.2014 14:18, schrieb Mark Webb-Johnson:
Not sure if we can use extended mode or not - if we can, it will give us a lot of breathing room. If I enable extended mode, everything compiles just fine (all configs). Supposedly the PIC18F2685 supports the C-optimised extended instruction set.
Regards, Mark.
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
Wow, just wow! I’ve been running this (2.6.x code, with Michael’s interrupt handling enhancements, and a switch to extended mode compilation) in my car and the difference is amazing. The best indicator I have of interrupt performance is the digital speedo in the Tesla Roadster. That relies on picking up the transmission of a single CAN bus message, then following it up very quickly with a sequence of 3 override CAN bus messages. Previously it was ok, but now (with the new Interrupt code) it seems much much smoother. Well done, Michael! Great contribution. I’ll be fixing up the compiler warnings (just a difference in ‘static’ vs ‘auto’ storage mode in extended mode) and then will commit the switch to extended mode to the repository as 2.6.2. I should get this done today. Regards, Mark. On 15 Jan, 2014, at 6:19 am, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
I now also have compiled in extended mode (got no choice). I only get some warnings about static function args, not sure if they need to be static, doesn't seem so.
First tests have been completely fine in both diag and live mode, so I'll use the extended mode firmware during the next days to see if anything goes wrong.
Regards, Michael
Am 08.01.2014 14:18, schrieb Mark Webb-Johnson:
Not sure if we can use extended mode or not - if we can, it will give us a lot of breathing room. If I enable extended mode, everything compiles just fine (all configs). Supposedly the PIC18F2685 supports the C-optimised extended instruction set.
Regards, Mark.
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Thanks :-) There should also be a visible change in crash history records, my crash count with the new version is still 0. The extended mode also has been running 100% fine during the last days, so I can also check in some more Twizy & CANopen functionality later on :-) Btw, I read about the Mia also using a SEVCON Gen4. So if there's a Mia OVMS development going on somewhere: the Twizy tuning commands should be easily portable, should just need to be adapted to the other defaults. Regards, Michael Am 18.01.2014 03:46, schrieb Mark Webb-Johnson:
Wow, just wow!
I’ve been running this (2.6.x code, with Michael’s interrupt handling enhancements, and a switch to extended mode compilation) in my car and the difference is amazing.
The best indicator I have of interrupt performance is the digital speedo in the Tesla Roadster. That relies on picking up the transmission of a single CAN bus message, then following it up very quickly with a sequence of 3 override CAN bus messages. Previously it was ok, but now (with the new Interrupt code) it seems much much smoother.
Well done, Michael! Great contribution.
I’ll be fixing up the compiler warnings (just a difference in ‘static’ vs ‘auto’ storage mode in extended mode) and then will commit the switch to extended mode to the repository as 2.6.2. I should get this done today.
Regards, Mark.
On 15 Jan, 2014, at 6:19 am, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
I now also have compiled in extended mode (got no choice). I only get some warnings about static function args, not sure if they need to be static, doesn't seem so.
First tests have been completely fine in both diag and live mode, so I'll use the extended mode firmware during the next days to see if anything goes wrong.
Regards, Michael
Am 08.01.2014 14:18, schrieb Mark Webb-Johnson:
Not sure if we can use extended mode or not - if we can, it will give us a lot of breathing room. If I enable extended mode, everything compiles just fine (all configs). Supposedly the PIC18F2685 supports the C-optimised extended instruction set.
Regards, Mark.
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
Michael, Great work! I wonder if there would be a way to use this as a valet mode option? Really reduce motor settings etc? Yes, its no Tesla, but more might be useful for some. Also, could this be used to make the twizy more secure? I know it has an immobilizer but no locks on the doors, making it perhaps a target for thieves? Could OVMS he used to lock down a twizy with really poor parameters? In other words, if someone does defeat the lock and turn it on, this could event them from moving the car? On 18 Jan 2014 08:27, "Michael Balzer" <dexter@expeedo.de> wrote:
Thanks :-)
There should also be a visible change in crash history records, my crash count with the new version is still 0.
The extended mode also has been running 100% fine during the last days, so I can also check in some more Twizy & CANopen functionality later on :-)
Btw, I read about the Mia also using a SEVCON Gen4. So if there's a Mia OVMS development going on somewhere: the Twizy tuning commands should be easily portable, should just need to be adapted to the other defaults.
Regards, Michael
Am 18.01.2014 03:46, schrieb Mark Webb-Johnson:
Wow, just wow!
I’ve been running this (2.6.x code, with Michael’s interrupt handling enhancements, and a switch to extended mode compilation) in my car and the difference is amazing.
The best indicator I have of interrupt performance is the digital speedo in the Tesla Roadster. That relies on picking up the transmission of a single CAN bus message, then following it up very quickly with a sequence of 3 override CAN bus messages. Previously it was ok, but now (with the new Interrupt code) it seems much much smoother.
Well done, Michael! Great contribution.
I’ll be fixing up the compiler warnings (just a difference in ‘static’ vs ‘auto’ storage mode in extended mode) and then will commit the switch to extended mode to the repository as 2.6.2. I should get this done today.
Regards, Mark.
On 15 Jan, 2014, at 6:19 am, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
I now also have compiled in extended mode (got no choice). I only get some warnings about static function args, not sure if they need to be static, doesn't seem so.
First tests have been completely fine in both diag and live mode, so I'll use the extended mode firmware during the next days to see if anything goes wrong.
Regards, Michael
Am 08.01.2014 14:18, schrieb Mark Webb-Johnson:
Not sure if we can use extended mode or not - if we can, it will give us a lot of breathing room. If I enable extended mode, everything compiles just fine (all configs). Supposedly the PIC18F2685 supports the C-optimised extended instruction set.
Regards, Mark.
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Nikki, nice ideas. You can reduce available power simply by a CFG DRIVE command, i.e. "CFG DRIVE 10" will reduce available power to 10%. To completely disable it, "CFG DRIVE 0" should also work -- haven't tried that yet. Another option if valet mode still needs the power (i.e. hills): "CFG SPEED 10" will reduce maximum speed to 10 kph. Regards, Michael Am 18.01.2014 11:57, schrieb Nikki Gordon-Bloomfield:
Michael,
Great work!
I wonder if there would be a way to use this as a valet mode option? Really reduce motor settings etc?
Yes, its no Tesla, but more might be useful for some.
Also, could this be used to make the twizy more secure?
I know it has an immobilizer but no locks on the doors, making it perhaps a target for thieves?
Could OVMS he used to lock down a twizy with really poor parameters?
In other words, if someone does defeat the lock and turn it on, this could event them from moving the car?
On 18 Jan 2014 08:27, "Michael Balzer" <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Thanks :-)
There should also be a visible change in crash history records, my crash count with the new version is still 0.
The extended mode also has been running 100% fine during the last days, so I can also check in some more Twizy & CANopen functionality later on :-)
Btw, I read about the Mia also using a SEVCON Gen4. So if there's a Mia OVMS development going on somewhere: the Twizy tuning commands should be easily portable, should just need to be adapted to the other defaults.
Regards, Michael
Am 18.01.2014 03:46, schrieb Mark Webb-Johnson:
Wow, just wow!
I've been running this (2.6.x code, with Michael's interrupt handling enhancements, and a switch to extended mode compilation) in my car and the difference is amazing.
The best indicator I have of interrupt performance is the digital speedo in the Tesla Roadster. That relies on picking up the transmission of a single CAN bus message, then following it up very quickly with a sequence of 3 override CAN bus messages. Previously it was ok, but now (with the new Interrupt code) it seems much much smoother.
Well done, Michael! Great contribution.
I'll be fixing up the compiler warnings (just a difference in 'static' vs 'auto' storage mode in extended mode) and then will commit the switch to extended mode to the repository as 2.6.2. I should get this done today.
Regards, Mark.
On 15 Jan, 2014, at 6:19 am, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
I now also have compiled in extended mode (got no choice). I only get some warnings about static function args, not sure if they need to be static, doesn't seem so.
First tests have been completely fine in both diag and live mode, so I'll use the extended mode firmware during the next days to see if anything goes wrong.
Regards, Michael
Am 08.01.2014 14:18, schrieb Mark Webb-Johnson:
Not sure if we can use extended mode or not - if we can, it will give us a lot of breathing room. If I enable extended mode, everything compiles just fine (all configs). Supposedly the PIC18F2685 supports the C-optimised extended instruction set.
Regards, Mark.
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
_______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
Sounds like it might be cool to hook this into the valet msg. Valet ON is save limit then set speed limit to 10kph. Valet off is restore limit. Lock/Unlock could be similar. I would just be a little concerned if gsm connectivity was lost after lock/valet. Without connectivity, you couldn't unlock and it would be a real slow drive to the next cell tower :-) Mark
On 18 Jan, 2014, at 8:14 pm, Michael Balzer <dexter@expeedo.de> wrote:
Nikki,
nice ideas.
You can reduce available power simply by a CFG DRIVE command, i.e. "CFG DRIVE 10" will reduce available power to 10%.
To completely disable it, "CFG DRIVE 0" should also work -- haven't tried that yet.
Another option if valet mode still needs the power (i.e. hills): "CFG SPEED 10" will reduce maximum speed to 10 kph.
Regards, Michael
Am 18.01.2014 11:57, schrieb Nikki Gordon-Bloomfield:
Michael,
Great work!
I wonder if there would be a way to use this as a valet mode option? Really reduce motor settings etc?
Yes, its no Tesla, but more might be useful for some.
Also, could this be used to make the twizy more secure?
I know it has an immobilizer but no locks on the doors, making it perhaps a target for thieves?
Could OVMS he used to lock down a twizy with really poor parameters?
In other words, if someone does defeat the lock and turn it on, this could event them from moving the car?
On 18 Jan 2014 08:27, "Michael Balzer" <dexter@expeedo.de> wrote: Thanks :-)
There should also be a visible change in crash history records, my crash count with the new version is still 0.
The extended mode also has been running 100% fine during the last days, so I can also check in some more Twizy & CANopen functionality later on :-)
Btw, I read about the Mia also using a SEVCON Gen4. So if there's a Mia OVMS development going on somewhere: the Twizy tuning commands should be easily portable, should just need to be adapted to the other defaults.
Regards, Michael
Am 18.01.2014 03:46, schrieb Mark Webb-Johnson:
Wow, just wow!
I’ve been running this (2.6.x code, with Michael’s interrupt handling enhancements, and a switch to extended mode compilation) in my car and the difference is amazing.
The best indicator I have of interrupt performance is the digital speedo in the Tesla Roadster. That relies on picking up the transmission of a single CAN bus message, then following it up very quickly with a sequence of 3 override CAN bus messages. Previously it was ok, but now (with the new Interrupt code) it seems much much smoother.
Well done, Michael! Great contribution.
I’ll be fixing up the compiler warnings (just a difference in ‘static’ vs ‘auto’ storage mode in extended mode) and then will commit the switch to extended mode to the repository as 2.6.2. I should get this done today.
Regards, Mark.
On 15 Jan, 2014, at 6:19 am, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
I now also have compiled in extended mode (got no choice). I only get some warnings about static function args, not sure if they need to be static, doesn't seem so.
First tests have been completely fine in both diag and live mode, so I'll use the extended mode firmware during the next days to see if anything goes wrong.
Regards, Michael
Am 08.01.2014 14:18, schrieb Mark Webb-Johnson:
Not sure if we can use extended mode or not - if we can, it will give us a lot of breathing room. If I enable extended mode, everything compiles just fine (all configs). Supposedly the PIC18F2685 supports the C-optimised extended instruction set.
Regards, Mark. -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
_______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I implemented an "offline" cfg reset method -- which btw unfortunately could also be used by any thieve... well, maybe not quite "any" though ;-) Am 18.01.2014 13:55, schrieb Mark Webb-Johnson:
Sounds like it might be cool to hook this into the valet msg. Valet ON is save limit then set speed limit to 10kph. Valet off is restore limit. Lock/Unlock could be similar.
I would just be a little concerned if gsm connectivity was lost after lock/valet. Without connectivity, you couldn't unlock and it would be a real slow drive to the next cell tower :-)
Mark
On 18 Jan, 2014, at 8:14 pm, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Nikki,
nice ideas.
You can reduce available power simply by a CFG DRIVE command, i.e. "CFG DRIVE 10" will reduce available power to 10%.
To completely disable it, "CFG DRIVE 0" should also work -- haven't tried that yet.
Another option if valet mode still needs the power (i.e. hills): "CFG SPEED 10" will reduce maximum speed to 10 kph.
Regards, Michael
Am 18.01.2014 11:57, schrieb Nikki Gordon-Bloomfield:
Michael,
Great work!
I wonder if there would be a way to use this as a valet mode option? Really reduce motor settings etc?
Yes, its no Tesla, but more might be useful for some.
Also, could this be used to make the twizy more secure?
I know it has an immobilizer but no locks on the doors, making it perhaps a target for thieves?
Could OVMS he used to lock down a twizy with really poor parameters?
In other words, if someone does defeat the lock and turn it on, this could event them from moving the car?
On 18 Jan 2014 08:27, "Michael Balzer" <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Thanks :-)
There should also be a visible change in crash history records, my crash count with the new version is still 0.
The extended mode also has been running 100% fine during the last days, so I can also check in some more Twizy & CANopen functionality later on :-)
Btw, I read about the Mia also using a SEVCON Gen4. So if there's a Mia OVMS development going on somewhere: the Twizy tuning commands should be easily portable, should just need to be adapted to the other defaults.
Regards, Michael
Am 18.01.2014 03:46, schrieb Mark Webb-Johnson:
Wow, just wow!
I've been running this (2.6.x code, with Michael's interrupt handling enhancements, and a switch to extended mode compilation) in my car and the difference is amazing.
The best indicator I have of interrupt performance is the digital speedo in the Tesla Roadster. That relies on picking up the transmission of a single CAN bus message, then following it up very quickly with a sequence of 3 override CAN bus messages. Previously it was ok, but now (with the new Interrupt code) it seems much much smoother.
Well done, Michael! Great contribution.
I'll be fixing up the compiler warnings (just a difference in 'static' vs 'auto' storage mode in extended mode) and then will commit the switch to extended mode to the repository as 2.6.2. I should get this done today.
Regards, Mark.
On 15 Jan, 2014, at 6:19 am, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
I now also have compiled in extended mode (got no choice). I only get some warnings about static function args, not sure if they need to be static, doesn't seem so.
First tests have been completely fine in both diag and live mode, so I'll use the extended mode firmware during the next days to see if anything goes wrong.
Regards, Michael
Am 08.01.2014 14:18, schrieb Mark Webb-Johnson:
Not sure if we can use extended mode or not - if we can, it will give us a lot of breathing room. If I enable extended mode, everything compiles just fine (all configs). Supposedly the PIC18F2685 supports the C-optimised extended instruction set.
Regards, Mark.
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
_______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf> _______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
OK, just pushed the change to extended mode compilation. I had a to make a small change to vehicle_twizy for the production build (where the CFG define is not set). The change to temperatures (8 to 16 bit) has also been made. I also added some code to call the vehicle idle poll and 1/10th second ticker functions from within the 100ms utils.c delay. The issue here is that the 100ms delay may be called from within the functions, so there is a guard against recursion. Hopefully this didn’t break anything. I’m going for a drive soon, with this code in place. If there are no problems, I’ll build an official 2.6.2 .hex for wider testing. Regards, Mark. On 18 Jan, 2014, at 10:14 pm, Michael Balzer <dexter@expeedo.de> wrote:
I implemented an "offline" cfg reset method -- which btw unfortunately could also be used by any thieve... well, maybe not quite "any" though ;-)
Am 18.01.2014 13:55, schrieb Mark Webb-Johnson:
Sounds like it might be cool to hook this into the valet msg. Valet ON is save limit then set speed limit to 10kph. Valet off is restore limit. Lock/Unlock could be similar.
I would just be a little concerned if gsm connectivity was lost after lock/valet. Without connectivity, you couldn't unlock and it would be a real slow drive to the next cell tower :-)
Mark
On 18 Jan, 2014, at 8:14 pm, Michael Balzer <dexter@expeedo.de> wrote:
Nikki,
nice ideas.
You can reduce available power simply by a CFG DRIVE command, i.e. "CFG DRIVE 10" will reduce available power to 10%.
To completely disable it, "CFG DRIVE 0" should also work -- haven't tried that yet.
Another option if valet mode still needs the power (i.e. hills): "CFG SPEED 10" will reduce maximum speed to 10 kph.
Regards, Michael
Am 18.01.2014 11:57, schrieb Nikki Gordon-Bloomfield:
Michael,
Great work!
I wonder if there would be a way to use this as a valet mode option? Really reduce motor settings etc?
Yes, its no Tesla, but more might be useful for some.
Also, could this be used to make the twizy more secure?
I know it has an immobilizer but no locks on the doors, making it perhaps a target for thieves?
Could OVMS he used to lock down a twizy with really poor parameters?
In other words, if someone does defeat the lock and turn it on, this could event them from moving the car?
On 18 Jan 2014 08:27, "Michael Balzer" <dexter@expeedo.de> wrote: Thanks :-)
There should also be a visible change in crash history records, my crash count with the new version is still 0.
The extended mode also has been running 100% fine during the last days, so I can also check in some more Twizy & CANopen functionality later on :-)
Btw, I read about the Mia also using a SEVCON Gen4. So if there's a Mia OVMS development going on somewhere: the Twizy tuning commands should be easily portable, should just need to be adapted to the other defaults.
Regards, Michael
Am 18.01.2014 03:46, schrieb Mark Webb-Johnson: Wow, just wow!
I’ve been running this (2.6.x code, with Michael’s interrupt handling enhancements, and a switch to extended mode compilation) in my car and the difference is amazing.
The best indicator I have of interrupt performance is the digital speedo in the Tesla Roadster. That relies on picking up the transmission of a single CAN bus message, then following it up very quickly with a sequence of 3 override CAN bus messages. Previously it was ok, but now (with the new Interrupt code) it seems much much smoother.
Well done, Michael! Great contribution.
I’ll be fixing up the compiler warnings (just a difference in ‘static’ vs ‘auto’ storage mode in extended mode) and then will commit the switch to extended mode to the repository as 2.6.2. I should get this done today.
Regards, Mark.
On 15 Jan, 2014, at 6:19 am, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
I now also have compiled in extended mode (got no choice). I only get some warnings about static function args, not sure if they need to be static, doesn't seem so.
First tests have been completely fine in both diag and live mode, so I'll use the extended mode firmware during the next days to see if anything goes wrong.
Regards, Michael
Am 08.01.2014 14:18, schrieb Mark Webb-Johnson: Not sure if we can use extended mode or not - if we can, it will give us a lot of breathing room. If I enable extended mode, everything compiles just fine (all configs). Supposedly the PIC18F2685 supports the C-optimised extended instruction set.
Regards, Mark.
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
_______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf> _______________________________________________ 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
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (3)
-
Mark Webb-Johnson -
Michael Balzer -
Nikki Gordon-Bloomfield