I'm developing a simple RS485 based MODBUS server application on a Microchip PIC micro-controller and need to know best practices to follow on its application side. I can guide myself to get the hardware layer working.

From my understanding, the MODBUS server has a database of application specific registers upon which the client performs R&W operations through commands.

Now this database needs to be run-time updatable based on device operation and should also be persistent so that device status can be recovered after power reset. Also, the client can ask for register read in contiguous manner (for e.g. read 10 registers from ID 2121). Based on all the requirements, I'm thinking of creating two copies of the database - one on RAM and the other on flash / eeprom. The one on RAM would simply be a set of arrays and the one on flash / eeprom would be block of memory locations. Upon power-up, contents from the flash will be copied to the RAM locations and all the run-time R&W operations thereon will be performed on the RAM copy itself. Now, there could be two ways to transfer the latest data from RAM to flash:

  1. Do it instantly when any of the data changes
  • Client will be notified about operation success only when data is transferred to NV memory
  • Could invite too many flash/eeprom operations
  1. Do it periodically
  • Less transactions with the NV memory
  • There could be data loss if power goes down before transfer was complete, and worse client would think that data was successfully written to the server.

Is my understanding correct till now? If yes, which of the two ways is usually followed? Or is there a better one?

  • 1
    \$\begingroup\$ What this all about has to do with Modbus? \$\endgroup\$ Commented Aug 13, 2019 at 7:01
  • \$\begingroup\$ Create the database with pointers. Don't have the master change the NV settings too often. \$\endgroup\$
    – Jeroen3
    Commented Aug 13, 2019 at 7:06
  • \$\begingroup\$ @MarkoBuršič, Thanks for responding! Yes, this does not directly relate to MODBUS at least on the protocol side, but my query is surely on how do people implement the database at the modbus slave side. \$\endgroup\$ Commented Aug 13, 2019 at 10:14
  • \$\begingroup\$ @Jeroen3, Thanks for respnding! So do you suggest that I should be maintaining a copy on the ram (or heap) accessed by pointers? If that's the case, then when should I be transferring the updated data from RAM to NV memory? \$\endgroup\$ Commented Aug 13, 2019 at 10:14
  • 1
    \$\begingroup\$ You don't necessarily need a second copy in RAM, if you'll do the instant update in flash/eeprom. Try to minimize a read-write bits (Inputs) and registers (Holding Registers) count. Put them into contiguous blocks of say 64/128/256 bytes and burn them in a single go in a dedicated memory segment while keeping the pointer to the latest block, apply all the "How to emulate EEPROM efficiently in flash" best practices to not to stress flash too much, etc, etc. \$\endgroup\$ Commented Aug 13, 2019 at 14:34

1 Answer 1


The choice of how to store your database is largely up to your own requirements, not really a modbus question. As for good things to do for modbus I'd recommend implementing some register that provide identification details, to allow automatic probing, and serial numbers, or other fixed numbers that can be used to verify that the device is your device. You can even provide registers to blink your led to help locate the device.

Also, don't feel limited to a single block of registers. Use them as logical blocks if you can, rather than trying to make a hard 1:1 map to your variables. This makes it easier to group and expand things down the road.

Try and avoid special casing on the register count. It's perfectly legitimate (protocol wise) that "reading 4@0x2000" gives you different data than "reading 2@0x2000 + 2@0x2002" but it's just going to confuse your users.

Try and make sure to actually be consistent with byte ordering. Try and stick to big endian like the rest of the protocol.

  • \$\begingroup\$ Welcome to EE.SE! I like your answer, but I think I would prefer "possible" instead of "legitimate" in your penultimate sentence. "Legitimate" could mean "as allowed by the protocol", which is how I think you meant it; however, it could also be understood as "a proper thing to do", which I don't think is your intention :) \$\endgroup\$
    – marcelm
    Commented Sep 3, 2019 at 14:09
  • \$\begingroup\$ I feel that the context of "try and avoid doing this, it's legal, but it will confuse your users" should have been sufficient, but hey, I'll edit it anyway :) \$\endgroup\$
    – Karl P
    Commented Sep 3, 2019 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.