One approach I have taken is the following:
Use a packet start/end byte ( some data you will not usually include in your actual data. i.e. if you use ASCII, use a non-ascii byte like 7E, 05, something like that), this makes it easy to reset your software: just look for a start-packet byte in your stream. Use a “length” byte telling you how long the packet should be, compute a CRC-8 (lots of free code on the net) of the packet data itself and include this in your data. RS-485 is also a bus when is half duplex mode. So you might want to include a source address ( who sent the data )…
Here’s a format I have used
byte-0 7E (start/end packet)
byte-1 Length (including CRC but excluding end-packet)
byte-2 Source (who sent this message - use whatever numbers you want: 1=server,2=logger,3=sensor1,etc…)
byte-2-250 Data itself (try to exclude start and end packets indicators
byte- CRC calculated over the everything from source to all data bytes
byte 7E (end packet)
To start your state machine, look for 7E-7E.
This requires a simple state machine but will give you a way to reject bad information, regardless where the noise comes from.
Control the RTS bit using one GPIO. Set to 1 before a transmit and 0 as soon as you are done.
An approach like this gives you a bus where you can have secure data and you can have multiple sensors contributing.
For example: you can have sensors that emit data, loggers that simply write the data to some storage system, and actuators that wait for some sensor data and act on it. You simply continuously read from the bus. Which ever element in on your bus waits for whatever it wants to, simply by looking at the source. If a sensor is reporting temperature, it does not care about everything else on the bus. If I am a logger, I listen to everything on the bus and display the data. If you have a smart element, it may listen to temperature sensors, process the reading with some logic, and then decide to send a command to a solenoid or relay, for example.
If you have crucial data, you may need to resend a command twice. Assume you need to turn off a heating element for example, You may want to resend the command twice or include something from the element itself that responds with a status like “element turned off”. This is serial, shit happens. Logging text is one thing, turning on a pump/heating element and then off may cause harm so you want to make sure the system has heard your command.
As suggested reading, anything about networking will do. Learn the principles in there. The principles you learn will apply to any complex system with multiple nodes. Wether you decide to use RS485, RF, WiFi, and anything else in between.
Good luck - once you get started with this stuff it is a lot of fun.