<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Michael,<div><br></div><div>Nice. I'll have a play with it this weekend.</div><div><br></div><div>Regards, Mark.</div><div><br></div><div>P.S. I was aware (recently) of the ISR stuff, but didn't realise the fix was so (relatively) easy. Thanks for handling this.</div><div><br><div><div>On 5 Jan, 2014, at 9:22 am, Michael Balzer <<a href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
Hi everyone,<br>
<br>
I have integrated the latest Twizy release 3.0.2 with framework
version 2.6.1 and pushed it into the main repository.<br>
<br>
Please note:<br>
<br>
<br>
1) I had to introduce a new preprocessor flag for the vehicle
polling system: OVMS_POLLER<br>
<br>
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.<br>
<br>
You'll need to add the flag to your build configurations if you use
the polling.<br>
<br>
<br>
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.<br>
<br>
There's a good info on this topic on the web:
<a class="moz-txt-link-freetext" href="http://www.xargs.com/pic/c18-isr-optim.pdf">http://www.xargs.com/pic/c18-isr-optim.pdf</a><br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
With acc and logging disabled and all Twizy features activated I now
get...<br>
<br>
RAM Used: 3152 (0xC50) Free: 176 (0xB0)<br>
Flash Used: 97756 (0x17DDC) Free: 548 (0x224)<br>
<br>
So I'm approaching the final frontier... but in another way as
expected, I always thought RAM is my problem...<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Am 31.12.2013 13:39, schrieb Michael
Balzer:<br>
</div>
<blockquote cite="mid:52C2BAFE.6010602@expeedo.de" type="cite">Hi
everyone,
<br>
<br>
sorry for dropping behind/off last months, lots of work.
<br>
<br>
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.
<br>
<br>
This update enables access to the SEVCON controller configuration
of the Twizy.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
As I've not yet integrated your latest work, I've pushed this into
my Github repository first:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/dexterbg/Open-Vehicle-Monitoring-System">https://github.com/dexterbg/Open-Vehicle-Monitoring-System</a>
<br>
<br>
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.
<br>
<br>
Just wanted to let you know in case you wonder about rising OVMS
hardware sales lately ;-)
<br>
<br>
Oh, and I wish you all a happy new year!
<br>
<br>
Regards,
<br>
Michael
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
</div>
<span><dexter.vcf></span>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br></blockquote></div><br></div></body></html>