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