[Ovmsdev] Twizy release 3.0.2

Wed Jan 8 21:18:04 HKT 2014

>  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 at 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 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> 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
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> 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
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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