[Ovmsdev] Twizy release 3.0.2

Wed Jan 8 21:11:12 HKT 2014

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 at webb-johnson.net 
> <mailto:mark at 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 at expeedo.de <mailto:dexter at 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 at 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 at lists.teslaclub.hk 
>>> <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk 
>> <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140108/f0d6a9bd/attachment.htm>