[Ovmsdev] V3 progress

[Mark Webb-Johnson]

The issue is that for the MQTT and GATT protocols (generic IoT style), we need to provide granular updates. It just seems simpler to store things in that way in the first place. That way, the MQTT and GATT code in OVMS v3 can just publish all metrics in the same way - no need for per-metric logic. It is also trivial then to add per-vehicle custom metrics, as necessary.

Doing it that way, we do take a hit on storage (RAM). But, even if each metric took say 50 bytes, over 80 metrics that is <4KB. About the stack for one task thread (of which we have more than a dozen already). I’m frankly more worried about task bloat, and in particular the massive wifi and bluetooth protocol stacks, then the metrics.

Flash size is probably not much different either way.

Regards, Mark.

> On 9 Oct 2017, at 4:53 AM, HONDA S-2000 <s2000 at audiobanshee.com> wrote:
> 
> 
> On Oct 8, 2017, at 2:40 AM, Tom Parker <tom at carrott.org> wrote:
>> On 04/10/17 02:30, Mark Webb-Johnson wrote:
>>> I just added the very basic ones, as a starting point and proof of concept. Hadn’t decided if I needed anything special for the bitmapped ones at the time (either a new MetricBitmap type, or extend MetricInt). Looking at how things have evolved, and bearing in mind the GAPP bluetooth stuff, and OVMS v3 MQTT, it seems that each bit should be a metric of their own. Not too hard for ovms_server_v2 to convert that back to an integer bitmap, for backwards compatibility. To do that, car_doors1 becomes:
>> 
>> I fully support the concept of storing the data in the most appropriate format and serializing it into the v2 message in the v2 server code. I like the idea of storing the bit field stuff as separate boolean objects.
> 
> What are the specific advantages of having boolean "objects" as opposed to standard C bit fields? The compiler can certainly emit more efficient code for bit fields.
> 
> I almost always find an advantage to using objects in any design. However, there are also many examples where using standard C types can make the code way more efficient and execute much faster. Sometimes it's difficult to predict which way to go in a design until after you've tried out one of the options in running code.
> 
> 
>> I don't know if you can do anything clever with C++ to use less memory while preserving a nice API within the vehicle code, but we probably have enough memory to not need to worry too much?
> 
> It may not be true of all C++ compilers, but in my embedded experience I have found that grouping all of the boolean member variables together in the class definition allows them to be automatically grouped into a bit field. As soon as you have another type interleaved between boolean member variables, the compiler no longer efficiently groups them into the same word. I have been able to save a lot of memory in embedded firmware by merely editing the class headers to change the order of member variables and move the booleans together.
> 
> I tend to avoid using C++ in my own designs, but it is sometimes possible to make good use of the language. I have noticed a trend in the industry of using C++ where it is inappropriate (e.g. only one instance of any object, and no inheritance). In other words, I think it's best not to try too hard to make everything "C++" unless you can see a distinct advantage that is only possible with that language. Good design structure is way more important than the language.
> 
> In our example, I think that the communications protocol needs to be efficient, even more so than the embedded code. With OVMS v2, we ran out of Flash and other memory, and while it seems that v3 has space to burn I wouldn't recommend being too wasteful.
> 
> Brian Willoughby
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev