An interesting move from Google Android http://www.openautoalliance.net/#about Best regards Dr. Eng. Ignacio González Alonso. On Wed, Jan 8, 2014 at 2:19 PM, <ovmsdev-request@lists.teslaclub.hk> wrote:
Send OvmsDev mailing list submissions to ovmsdev@lists.teslaclub.hk
To subscribe or unsubscribe via the World Wide Web, visit http://lists.teslaclub.hk/mailman/listinfo/ovmsdev or, via email, send a message with subject or body 'help' to ovmsdev-request@lists.teslaclub.hk
You can reach the person managing the list at ovmsdev-owner@lists.teslaclub.hk
When replying, please edit your Subject line so it is more specific than "Re: Contents of OvmsDev digest..."
Today's Topics:
1. Re: Twizy release 3.0.2 (Michael Balzer) 2. Re: Twizy release 3.0.2 (Mark Webb-Johnson)
----------------------------------------------------------------------
Message: 1 Date: Wed, 08 Jan 2014 14:11:12 +0100 From: Michael Balzer <dexter@expeedo.de> Subject: Re: [Ovmsdev] Twizy release 3.0.2 To: ovmsdev@lists.teslaclub.hk Message-ID: <52CD4E70.6090608@expeedo.de> Content-Type: text/plain; charset="iso-8859-15"; Format="flowed"
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
participants (1)
-
Nacho