Mark, 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: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master... 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? Regards, Michael 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