[Ovmsdev] Twizy release 3.0.2

Michael Balzer dexter at expeedo.de
Sun Jan 5 09:22:24 HKT 2014


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140105/5668e3f8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140105/5668e3f8/attachment-0002.vcf>


More information about the OvmsDev mailing list