[Ovmsdev] CAN-3 broken again?

Michael Balzer dexter at expeedo.de
Mon Jan 8 22:27:13 HKT 2018


the Twizy implementation currently depends largely on the CANopen framework. It may be possible to build a -very- restricted version without,
but the result would not be used by any Twizy driver.

The CANopen framework is also a general toolkit to discover and talk to CANopen devices, see my intro at:


The RAM usage of the manager module, while not having started a bus instance, is 24 bytes for the module state plus command registry. Command
registry follows the approach of the CAN framework to do the interface selection as a command level. So the CANopen command registry entries
consist of 2 + 3 * 13 = 41 commands.

The same command registry overhead applies to all optional components, i.e. OBD2ECU and REtools. Maybe a better solution is to make all these
components loadable like the vehicles. I saw you subclassed RE from pcp, was this meant to support the dynamic loading/init by means of the
power control command, or is there another plan on this?


Am 08.01.2018 um 01:04 schrieb Mark Webb-Johnson:
> With renault twizy and canopen enabled:
>     OVMS > module memory
>     ============================
>     Free 8-bit 78744/243064, 32-bit 29116/55900, blocks dumped = 0
> With renault twizy and canopen disabled:
>     OVMS > module memory
>     ============================
>     Free 8-bit 84928/243096, 32-bit 29720/56504, blocks dumped = 0
> I can’t compile with canopen disabled and renault twizy enabled.
> Not sure where the difference is, but it would be preferrable if these optional components didn’t consume any ram unless explicitly loaded.
> Using the class object model, and member variables, should make that relatively simple.
> Regards, Mark.

Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180108/947a9a65/attachment.htm>

More information about the OvmsDev mailing list