[Ovmsdev] Merging in Twizy and Volt/Ampera work

Mark Webb-Johnson mark at webb-johnson.net
Sun Nov 4 21:21:05 HKT 2012


> That wasn't me.

Whoops. Michael Jochum...

> ROM space is plenty, I'm more concerned about the RAM usage. Can those car specific #pragma udata globals easily be replaced by a dynamic object to be allocated on module init?

The Microchip compiler has an 'overlay' facility. We can put them in the same memory bank so they all overlay each other. You are correct - RAM is the concern.

> So it seems to be necessary to implement some dynamic data / protocol configuration model as well? I.e. divide into a common set of properties available on most car models plus a dynamic car special feature property set.


I think the existing model should work for the EVs I've seen. There are some problems that will need to be fixed (e.g.; imperial-only units for ranges), and some extensions made (e.g.; 2 extra doors for saloon style cars), but those are pretty small.

For major new feature specific to a particular vehicle, I was hoping we can handle those by the command protocol. We could, for instance, route commands 100-200 directly through to the vehicle modules for response. We could also add hooks for the vehicle modules to directly transmit messages out (the protocol itself is extensible and new message types can be easily added).

> l (btw: I can only read up to line 201 of docs/OVMS_Protocol.doc using UTF-16 -- rest is garbled)

Yes, I've noticed that. From what I can see, it is just garbage tacked on the end but I've been meaning to convert this to a better document. We have full revision control on this.

> The Twizy has 14 cell packs (14S 2P we think) and we've got their voltages on CAN. Even for the small Twizy pack + data compression this will need some RAM (or server traffic + App support).

I think that stuff like this is going to be _very_ hard to fit in ram, but does it actually need to be stored? Say we have 16 can bus messages to send out. We could just use a 2byte bit array with a bit high indicating we need the figure. If the message arrives on the can bus, and the corresponding bit it high, it can get queued for transmission directly, then the bit cleared. I'm not sure if that is clear (hard to explain it in writing), but what I'm saying is have a mechanism for the can driver to be able to queue stuff for transmission directly from the incoming can message. So, rather than storing 16 messages for transmission, we don't need to store any - just have a flag to say 'transmit the values when it next comes off the bus'.

> So, maybe the data and protocol models need to be generalized first?

I think it just needs to be documented better, and expanded as necessary. Let's then see how things fit into that. I'll work on this now, as both Michael's need this urgently.

Regards, Mark.

On 4 Nov, 2012, at 8:37 PM, Michael Balzer <dexter at expeedo.de> wrote:

> 
> Am 04.11.2012 04:11, schrieb Mark Webb-Johnson:
>> A while ago, Michael Balzer suggested to me that it would be best to have one firmware supporting all cars.
> 
> That wasn't me. The idea sounds good, but...
> 
> - car platforms to be supported will increase steadily now, there are lots to come in the next years
> - even cars with decent builtin online monitoring systems lack some functionality for nerds like us
> - there will be a need for custom product configuration per car anyway, as cabling and antenna configuration will be different
> 
> ROM space is plenty, I'm more concerned about the RAM usage. Can those car specific #pragma udata globals easily be replaced by a dynamic object to be allocated on module init?
> 
> Also, not only the CAN module may need car specific adaption. I've not yet completely read into the server protocol (btw: I can only read up to line 201 of docs/OVMS_Protocol.doc using UTF-16 -- rest is garbled), but got the impression it contains some common and some Tesla specific data. If we have to integrate specific data from every model supported, the data stream can become quite fat. So it seems to be necessary to implement some dynamic data / protocol configuration model as well? I.e. divide into a common set of properties available on most car models plus a dynamic car special feature property set.
> 
> Example: one of my next ideas is a cell monitor to get a history of the cell voltage levels, so I can detect and alert about cell failures early. The Twizy has 14 cell packs (14S 2P we think) and we've got their voltages on CAN. Even for the small Twizy pack + data compression this will need some RAM (or server traffic + App support). The Tesla has an 11S 9S 69P configuration (?), so that would need much more history RAM + possibly another data layout -- if the voltages are on CAN at all.
> 
> Another example I already stumbled on: the car_doors1 flag 0x04 (charge port open) is currently used by net_sms_stat(), if it's not set, it assumes "not charging". So even some standard functions rely on Tesla specific data.
> 
> So, maybe the data and protocol models need to be generalized first? Or am I missing something?
> 
> Regards,
> Michael
> 
> -- 
> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
> <dexter.vcf>_______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev




More information about the OvmsDev mailing list