<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
This is the growth over a selection of main releases:<br>
<br>
<font face="monospace">Date Size Version<br>
2018-04-08 2100352 3.1.003/ovms3.bin<br>
2018-04-17 2111536 3.1.004/ovms3.bin<br>
2018-05-01 2172176 3.1.005/ovms3.bin<br>
2018-05-20 2247760 3.1.006/ovms3.bin<br>
2018-06-18 2311072 3.1.007/ovms3.bin<br>
2018-08-18 2386640 3.1.009/ovms3.bin<br>
2018-11-04 2503744 3.1.011/ovms3.bin<br>
2019-05-12 2933840 3.2.002/ovms3.bin<br>
2020-08-04 2943440 3.2.014/ovms3.bin<br>
2020-09-02 2957216 3.2.015/ovms3.bin<br>
2021-03-05 3189808 3.2.016/ovms3.bin<br>
2021-09-29 3309536 3.2.017/ovms3.bin<br>
2021-11-22 3318000 3.2.018/ovms3.bin<br>
2021-11-22 3367696 3.3.001/ovms3.bin<br>
2022-03-07 3396208 3.3.002/ovms3.bin<br>
2022-09-03 3406816 3.3.003/ovms3.bin<br>
2024-03-23 3675344 3.3.004/ovms3.bin<br>
2025-07-18 3895696 3.3.005/ovms3.bin<br>
<br>
<img src="cid:part1.Jj2c6vlV.Uv5omIZ0@expeedo.de" alt=""><br>
<br>
<br>
</font>So extending the partition size to 6 MB will buy us quite
some time.<br>
<br>
Regarding Javascript/DBC vehicles, Michael Geddes' work on this is
quite advanced, and really needs some tester now trying to implement
an actual vehicle, to see what's missing.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 08.12.25 um 07:01 schrieb Mark
Webb-Johnson via OvmsDev:<br>
</div>
<blockquote type="cite"
cite="mid:1EAA8F91-A8E9-43D0-9705-CF40927F337A@webb-johnson.net">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Michael, Carsten,
<div><br>
</div>
<div>I think that if targeting things to cull, we would need to be
balance size vs importance. For example, the RE tools mentioned
is just 10KB total size. By comparison TPMS is 9KB, and web
server is 538KB.</div>
<div><br>
</div>
<div>We learned with OVMS v2 that the biggest culprits in the
long-run are always the vehicle modules. The core system stays
pretty stable, but the space required for *all* vehicle modules
grows with the number of vehicles supported.</div>
<div><br>
</div>
<div>I don’t think we can simply switch to 32MB flash, as that
would abandon the existing users. We would also need to source a
standard certified 32MB module (which I don’t think Espressif
offer themselves).</div>
<div><br>
</div>
<div>Looking at the partition table:</div>
<div><br>
</div>
<blockquote
style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div>
<div><font face="Andale Mono"># OVMS 16MB flash ESP32
Partition Table</font></div>
<div><font face="Andale Mono"># Name, Type, SubType, Offset,
Size</font></div>
<div><font face="Andale Mono">nvs, data, nvs, 0x9000,
0x4000</font></div>
<div><font face="Andale Mono">otadata, data, ota, 0xd000,
0x2000</font></div>
<div><font face="Andale Mono">phy_init, data, phy, 0xf000,
0x1000</font></div>
<div><font face="Andale Mono">factory, app, factory,
0x10000, 4M</font></div>
<div><font face="Andale Mono">ota_0, app, ota_0, ,
4M</font></div>
<div><font face="Andale Mono">ota_1, app, ota_1, ,
4M</font></div>
<div><font face="Andale Mono">store, data, fat, ,
1M</font></div>
</div>
</blockquote>
<div><br>
</div>
<div>Assuming we could (and that is a big assumption given our
older SDK) change that at runtime, then a possible migration
path could be:</div>
<div><br>
</div>
<div>
<ol class="MailOutline">
<li>Have our code support both old and new partition table
formats, and refuse to update to old format if firmware >
4MB. Get that code out into the hands of users.</li>
<li>Provide a migration tool for partition table:</li>
<ol class="MailOutline">
<li>Copy running code to factory (from ota_0 or ota_1,
whichever is current).</li>
<li>Reboot</li>
<li>Change partition table (most likely replacing the entire
table with a binary blob of the new format)</li>
<ol class="MailOutline">
<li>factory 4MB -> ota_0 same offset, 6MB size</li>
<li>ota_0 -> ota_1 6MB offset, 6MB size</li>
</ol>
<li>Change boot to ota_0.</li>
<li>Reboot</li>
</ol>
<li>Liase with factory so new modules use new partition format
(and ship with firmware that supports it).</li>
<li>Wait a reasonable time for users to update before
releasing any firmware > 4MB.</li>
</ol>
</div>
<div><br>
</div>
<div>That would work more similarly to other more modern ESP
frameworks which don’t bother with ‘factory’. It would allow us
another 50% expansion. But it does run the risk of bricking
(requiring espflash to recover) during the process.</div>
<div><br>
</div>
<div>But longer-term, the solution to me seems to be to allow the
vehicle module code to overlay - so only the single vehicle you
choose is loaded. And (absent any dynamic linking of modular
code in freertos), the only straightforward way of doing that I
know of is migrating vehicle support to Javascript (which comes
along with a host of other advantages - most notably not having
to be a C++ embedded developer to add/refine vehicle support).</div>
<div><br>
</div>
<div>Regards, Mark.<br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On 7 Dec 2025, at 4:39 PM, Carsten Schmiemann via
OvmsDev <a class="moz-txt-link-rfc2396E" href="mailto:ovmsdev@lists.openvehicles.com"><ovmsdev@lists.openvehicles.com></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<div
style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Hi Michael,
<div><br>
</div>
<div>
<div>It was to be expected that we would eventually
run out of flash storage. That’s why I would
immediately question whether we should detach
ourselves from components that aren’t really being
used. We could even start a survey or something like
that.</div>
<div><br>
</div>
<div>For example, the RE tools — the idea behind them
is great, but without documentation they’re not easy
to use, and every time I tried to work with them, it
just resulted in crashes.</div>
<div><br>
</div>
<div>Then there’s the question of who actually uses
Telnet, SSH, the Duktape framework, the DBC parser,
OBD2ECU, or CANopen (yes, the Twizy integration is
the only one that uses it). </div>
<div><br>
</div>
<div>All great ideas, but in the end, how many users
really make use of them?</div>
<div>The fewer active components we have to maintain,
the ‘easier’ it would also be to port the code to a
more current ESP-IDF version — and that would bring
significant benefits such as improved networking
features, including firewall capabilities and a much
more stable switching between LTE and Wi-Fi. I’ve
looked at llanges attempts and it’s extremely tough.</div>
<div><br>
</div>
<div>As an example, in my own custom firmware builds,
I don’t enable the components (and of course not all
vehicles, so not 100 percent representative)
mentioned above. This requires small modifications
in the code because, for example, the ESP logger is
missing but referenced in another file, etc. But my
firmware file is only about 2.8 MB.</div>
<div><br>
</div>
<div>Just my 2 cents</div>
<div>Carsten</div>
<div><br>
</div>
<div>
<blockquote type="cite">
<div>Am 07.12.2025 um 08:57 schrieb Michael Balzer
via OvmsDev
<a class="moz-txt-link-rfc2396E" href="mailto:ovmsdev@lists.openvehicles.com"><ovmsdev@lists.openvehicles.com></a>:</div>
<br class="Apple-interchange-newline">
<div>
<div>FYI: use `make size-components` to create a
report on all component sizes (`make
size-files` for source file level).<br>
<br>
Unsurprisingly the webserver is on top, even
with all assets precompressed already.<br>
<br>
<br>
<b><u>Top 10 components:</u></b><br>
<br>
<font face="monospace">Per-archive
contributions to ELF file:<br>
Archive File DRAM .data &
.bss IRAM Flash code & rodata Total<br>
libovms_webserver.a 0 255
0 134342 399846 534443<br>
libstdc++.a 149 5640
0 141045 72513 219347<br>
libmain.a 15 2104
0 139216 40086 181421<br>
libduktape.a 0 0
0 141641 20367 162008<br>
libvehicle_renaulttwizy. 0 29
0 86517 75357 161903<br>
libc-psram-workaround.a 1854 66
18391 118283 10943 149537<br>
liblwip.a 17 3873
0 118366 16722 138978<br>
libnet80211.a 938 9042
10475 92339 21900 134694<br>
libmbedtls.a 100 560
76 107079 26785 134600<br>
libvehicle_vweup.a 8 8
0 60846 43432 104294</font><br>
<br>
<br>
<b><u>Vehicles:</u></b><br>
<br>
<font face="monospace">Per-archive
contributions to ELF file:<br>
Archive File DRAM .data &
.bss IRAM Flash code & rodata Total<br>
libvehicle_renaulttwizy. 0 29
0 86517 75357 161903<br>
libvehicle_vweup.a 8 8
0 60846 43432 104294<br>
libvehicle_mgev.a 156 26
0 47756 33998 81936<br>
libvehicle_smarteq.a 82 15
0 59267 19527 78891<br>
libvehicle_smarted.a 0 9
0 48481 28801 77291<br>
libvehicle_renaultzoe_ph 4 10
0 44622 29564 74200<br>
libvehicle.a 0 68
0 57735 12062 69865<br>
libvehicle_bmwi3.a 0 2
0 33370 14357 47729<br>
libvehicle_minise.a 9432 2
0 35360 2210 47004<br>
libvehicle_hyundai_ioniq 176 7
0 32921 13425 46529<br>
libvehicle_nissanleaf.a 0 3
0 35491 8941 44435<br>
libvehicle_kiasoulev.a 240 9
0 32508 5473 38230<br>
libvehicle_kianiroev.a 108 7
0 24070 4006 28191<br>
libvehicle_mitsubishi.a 0 5
0 21645 3893 25543<br>
libvehicle_boltev.a 0 5
0 15999 7864 23868<br>
libvehicle_niu_gtevo.a 4 12
0 18248 3733 21997<br>
libvehicle_maxus_edelive 156 3
0 10713 7477 18349<br>
libvehicle_renaultzoe.a 0 6
0 14828 2859 17693<br>
libvehicle_maxus_euniq56 156 3
0 8363 6840 15362<br>
libvehicle_voltampera.a 0 5
0 13221 1932 15158<br>
libvehicle_hyundai_ioniq 0 3
0 11081 3191 14275<br>
libvehicle_teslaroadster 0 6
0 10367 2238 12611<br>
libvehicle_thinkcity.a 0 3
0 6114 3449 9566<br>
libvehicle_jaguaripace.a 0 8
0 5445 3941 9394<br>
libvehicle_fiatedoblo.a 0 2
0 4262 2126 6390<br>
libvehicle_teslamodels.a 0 2
0 5361 948 6311<br>
libvehicle_toyotarav4ev. 0 2
0 5023 1255 6280<br>
libvehicle_maxus_t90.a 0 3
0 2567 2204 4774<br>
libvehicle_byd_atto3.a 0 2
0 3503 947 4452<br>
libvehicle_energica.a 0 1
0 3319 880 4200<br>
libvehicle_demo.a 0 2
0 3205 795 4002<br>
libvehicle_maxus_euniq6. 0 2
0 2470 1182 3654<br>
libvehicle_fiat500.a 0 2
0 2838 732 3572<br>
libvehicle_zombie_vcu.a 0 4
0 1882 1259 3145<br>
libvehicle_mercedesb250e 0 2
0 2113 955 3070<br>
libvehicle_zeva.a 0 2
0 2209 688 2899<br>
libvehicle_dbc.a 0 2
0 1278 1395 2675<br>
libvehicle_cadillac_c2_c 0 7
0 1293 1105 2405<br>
libvehicle_maple60s.a 0 2
0 1416 698 2116<br>
libvehicle_chevrolet_c6_ 0 2
0 1053 1049 2104<br>
libvehicle_obdii.a 0 2
0 957 1007 1966<br>
libvehicle_teslamodel3.a 0 2
0 458 713 1173<br>
libvehicle_none.a 0 2
0 418 684 1104<br>
libvehicle_track.a 0 2
0 416 680 1098</font><br>
<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 06.12.25 um
10:33 schrieb Michael Balzer via OvmsDev:<br>
</div>
<blockquote type="cite"
cite="mid:6aad0365-f942-45ea-948d-5b9d67fc7073@expeedo.de">
Everyone, <br>
<br>
with the latest vehicle additions, the
firmware size has now grown to 4,015,328
bytes in build 3.3.005-485-gc4664881.
<br>
<br>
Our flash partitioning scheme is currently
designed to provide three firmware
partitions (factory, ota_0 & ota_1) of
4MB = 4,194,304 bytes each.
<br>
<br>
So we've now got 178,976 bytes = ~4% left. <br>
<br>
Options beyond the 4 MB limit: <br>
<br>
a) split features, e.g. vehicle support,
into two or more builds <br>
<br>
b) repartition into two firmware partitions
of 6 MB each, reusing the factory partition
for OTA
<br>
<br>
c) switch to an ESP32 WROOM module with 32
MB flash (possible?) <br>
<br>
We've got some time left, new vehicles
normally don't need that much space, I just
wanted to raise awareness.
<br>
<br>
Regards, <br>
Michael <br>
<br>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:OvmsDev@lists.openvehicles.com"
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
<br>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a><br>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a><br>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Am Rahmen 5 * D-58313 Herdecke
Fon 02330 9104094 * Handy 0176 20698926</pre>
<br>
</body>
</html>