[Ovmsdev] OvmsDev Digest, Vol 24, Issue 17

Wed Jan 8 21:22:03 HKT 2014

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 at lists.teslaclub.hk> wrote:

> Send OvmsDev mailing list submissions to
>         ovmsdev at 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 at lists.teslaclub.hk
>
> You can reach the person managing the list at
>         ovmsdev-owner at 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 at expeedo.de>
> Subject: Re: [Ovmsdev] Twizy release 3.0.2
> To: ovmsdev at lists.teslaclub.hk
> Message-ID: <52CD4E70.6090608 at 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 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.teslaclub.hk/pipermail/ovmsdev/attachments/20140108/f0d6a9bd/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 8 Jan 2014 21:18:04 +0800
> From: Mark Webb-Johnson <mark at webb-johnson.net>
> Subject: Re: [Ovmsdev] Twizy release 3.0.2
> To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
> Message-ID: <795D9A3B-8D1A-4086-A371-87137A4D4E1F at webb-johnson.net>
> Content-Type: text/plain; charset="windows-1252"
>
>
> >  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.teslaclub.hk/pipermail/ovmsdev/attachments/20140108/0d0ab608/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
> End of OvmsDev Digest, Vol 24, Issue 17
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140108/295bf02a/attachment.htm>