Porting to new platform. about liblightmodbus HOT 9 CLOSED

@Jacajack I'm glad you thought it was a good idea.

I never seriously programmed in C++, I had to look up what std::vector is. But yeah, its similar to what I had in mind.

I read that std::vector allocates memory dynamically, and that is one thing, I would recommend staying away from. This is a great occasion to ask: does liblightmodbus as of now allocate memory dynamically (with malloc and such)? I forgot to check the code.

Dynamic memory allocation in not seen kindly in the real-time applications world, and since modbus is closely related to real-time applications I would try to avoid it. I am thinking that a workaround to this could be a statically allocated array, and that it's size be determined at compile time by a developer set parameter? Do you think that could be plausible?

from liblightmodbus.

@martinmarcos, I created a new branch for working on replacement for dynamic memory allocation, so if you still have any suggestions, please let me know. :)

Changes are now merged into master branch. I've also added a new script to configure the way library is built (dynamic memory allocation settings + which Modbus functions are included). Any suggestions are still welcome, if anyone is still interested.

from liblightmodbus.

That is exactly what my library does. I haven't implemented the communication part, because obviously it differs on each platform (PC, AVR or ARM).

In fact, I was planning to do pretty similar thing soon - I wrote the library in order to have some lightweight communication system in my home automation project (https://github.com/home-hub) - currently I'm working on the master module which will be based on STM F103 ARM core. (So far, I've got slave module (based on Atmel AVR) fully designed and working). I have to say, that I've never really programmed ARM cores (apart from blinking LEDs), so I guess this project may be an interesting experience, and getting some information about what you've encountered may be really useful.

I'm pleased to hear that you found my library interesting and I'm looking forward to hearing how everything went! :)

PS. Sorry for not updating the docs! I was busy working on the hardware these days and I didn't have time do the boring stuff. If you encounter any problems related with the library itself, during your project, please feel free to email me or start an issue here

from liblightmodbus.

@Jacajack, I got the library to compile for my platform. Looking good!

Now I have to test it out with an example. I got the communication part some what ready. I got two board sending each other bytes through a UART hooked up to RS485 transceivers.

I took a look at your master code and it looks like you use a timeout approach to determine if you received the whole frame and it got me thinking. Would it be possible to add a couple of auxiliary functions to the library that are platform independent but that aid the developer with the communication layer? Except for MODBUS TCP, in most cases we are going to be receiving the frame byte by byte, so it would be useful to have functions that check after receiving a couple of bytes if the frame is addressed to that specific slave and how many additional bytes to expect. Functions like these would make it easier to develop a much better communications layer. Do you think?

from liblightmodbus.

@martinmarcos, that's great! 👍

Regarding the auxiliary functions, I think that's a very good idea. Something like std::vector from C++ may be pretty helpful here. User could feed in received data byte after byte, and the push function would determine if the incoming frame is valid (length, address, all that stuff) and whether there's point in further parsing it afterwards (or just interpret it automatically, when it's convinced that everything is fine).
Obviously, we should also have functions for clearing the buffer, triggering timeouts, forcing parsing, etc. (somewhat the standard buffer operations set)
All this could be contained in another module optionally linked during compilation.

What do you think about that?

from liblightmodbus.

@martinmarcos, unfortunately yes - the library uses dynamic memory allocation (mainly during building frames), which as you said may be sometimes undesired in low-level applications, but that's just me being a bit memory-greedy. The compile time macros could be used to either disable it (why waste the code?) or change predefined memory amounts. Modbus protocol helps us here a bit, because the maximum frame length is 256b.

Also, in this case we could simply have just a statically allocated array with moving write pointer instead of the std::vector equivalent. In essence, the outcome stays pretty much the same.

By the way, do you think that the following changes should be added to the upcoming v1.3 release? (which is the first properly working one 🤣)

from liblightmodbus.

@Jacajack I'm sorry I've went out of existence like that 😅 I've been with work. I think it's great you managed to add support for static memory allocation of structures! I really what to give this a try on my board. As soon as my work schedule clears up I'll see to it and I'll let you know how it went.

Later.

from liblightmodbus.

@martinmarcos That's fine, next thing to do is to implement the helper functions we talked about above. I'll try to do that when I have some free time, because at this moment I have plenty of work on my head either. I'm going to wait for your remarks before I release official v1.3.

Also, in case you didn't notice, I've added big-endian support, so if you want, you can somehow try that out as well.

from liblightmodbus.

Alright, I will release what we've got now as v1.3 and then the rest of features described here will go as v1.31 or so.

from liblightmodbus.