<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">Am 04.11.2012 04:11, schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote
cite="mid:2523242A-4520-42BA-BC88-644783A6491B@webb-johnson.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>A while ago, Michael Balzer suggested to me that it would be
best to have one firmware supporting all cars.</div>
</blockquote>
<br>
That wasn't me. The idea sounds good, but...<br>
<br>
- car platforms to be supported will increase steadily now, there
are lots to come in the next years<br>
- even cars with decent builtin online monitoring systems lack some
functionality for nerds like us<br>
- there will be a need for custom product configuration per car
anyway, as cabling and antenna configuration will be different<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
So, maybe the data and protocol models need to be generalized first?
Or am I missing something?<br>
<br>
Regards,<br>
Michael<br>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
</body>
</html>