Master slave serial communication

Thread Starter

Pramod Kumar Samal

Joined Sep 12, 2018
7
Hi,
I have been new to the forum and new to development in IOT and serial communication. I have an application running on slave Raspberry Pi which is connected to master Raspberry PI using USB serial cable. Application on master PI send commands to be processed by application on slave pi. Application on slave pi on receiving the command sends response back to master after processing it. My problem is due to any reason if the application on master pi crashes or killed, I need to terminate the application on the slave pi. But the concern here is I don;t want to change the application on the master pi. Is there any option available on the slave pi to know the application on the master had been terminated so that slave pi can kill/restart the application running on it. Attached here is an image showing the connection between the two PI.
Any suggestion will be highly appreciated.

Thanks
Pramodserial communicationflow1.png
 

trebla

Joined Jun 29, 2019
542
If master RPi sends commands on regular basis then you can add some "watchdog" timer to slave RPi which monitors received commands and gives timeout signal if commands do not arrive on given period of time.
 

Thread Starter

Pramod Kumar Samal

Joined Sep 12, 2018
7
Hi, Thanks for your reply
Concern here is if the application on the master PI closes or crashes we need to perform some specific function on the slave API. What you are suggesting will not solve the issue because if the application is idle your above scenario will not work.
 
The watchdog timer is the usual way to determine if a system crashed. That system is usually external. e.g.The watchdog times, say expects to get a pulse from software at least once a second. When it fails to get one, reset ans some flag is asserted. The processor then knows it was a watchdog event, does it's thing and re-enables the timer.
 

GetDeviceInfo

Joined Jun 7, 2009
2,192
Hi, Thanks for your reply
Concern here is if the application on the master PI closes or crashes we need to perform some specific function on the slave API. What you are suggesting will not solve the issue because if the application is idle your above scenario will not work.
It makes good sense, and fulfills what you’ve stated. If it doesn’t work, you’ve not told us something
 

Thread Starter

Pramod Kumar Samal

Joined Sep 12, 2018
7
It makes good sense, and fulfills what you’ve stated. If it doesn’t work, you’ve not told us something
Actually watchdog will work if the master pi application is idle which I dont want I want to perform some action when master pi application is closed or crashed but not in idle state. Apart from that I don't want to change the master application unless I dont have an option to solve the issue. I am really sorry if I could not able to express my point here.
 

Thread Starter

Pramod Kumar Samal

Joined Sep 12, 2018
7
The watchdog timer is the usual way to determine if a system crashed. That system is usually external. e.g.The watchdog times, say expects to get a pulse from software at least once a second. When it fails to get one, reset ans some flag is asserted. The processor then knows it was a watchdog event, does it's thing and re-enables the timer.
Dear Friend.
Thanks for your response and I really appreciate that.
Can you enlighten me on how watchdog timer will work on my current situation. Should I keep the watchdog timer on slave system? How it will get a pulse from master application that is on different system? Perhaps that will help me solve the above issue.

Thanking you in advance
Regards
Pramod
 

trebla

Joined Jun 29, 2019
542
I don't know your master app behavior but if after crashing this app terminates then you should see this via ps command, just remember this task PID. You can use some timer, for example cron, for checking PID table periodically and restart your app if necessary.
But if your master app crashes some way that OS believes it is still working this method does not work. Maybe some Linux expert can give better advice, i'm just at Linux user level :)
 

Thread Starter

Pramod Kumar Samal

Joined Sep 12, 2018
7
I don't know your master app behavior but if after crashing this app terminates then you should see this via ps command, just remember this task PID. You can use some timer, for example cron, for checking PID table periodically and restart your app if necessary.
But if your master app crashes some way that OS believes it is still working this method does not work. Maybe some Linux expert can give better advice, i'm just at Linux user level :)
Hi,
Thanks for your quick reply. PS command can give me process id of the current machine. But my master app is in a different machine while the slave application is on different machine as shown in my diagram shared above. From slave machine I can't use ps command to view process on master machine. Hope you understand my point here.

Thanks
Pramod
 

Thread Starter

Pramod Kumar Samal

Joined Sep 12, 2018
7
You either make some script on master RPI to check master app or set up terminal connection via USB from slave to master.
Both the devices are connected using USB serial cable and communicate with the same. But after application on master pi restart and sends command to slave application, slave application does not respond. Hence there is a need to restart the application on slave PI. The problem is when the application crash or restart on master slave could not recognize it.

Thanks
Pramod
 

Ya’akov

Joined Jan 27, 2019
9,044
The correct way to solve this is with a watchdog. Despite your desire to avoiding changing the application running on the RPi you must either provide a heartbeat to the other application, or provide a method for the other application to poll the application on the RPi and so provide the heartbeat for itself.

The only other alternative is to make the remote application capable of detecting a restart of the RPi application by the messages it receives and gracefully restart itself.

You wanted to avoid modifying the code but any other solution will either be excessively complicated, unreliable, or both.
 

Ya’akov

Joined Jan 27, 2019
9,044
I will add one other possibility though I consider it a silly workaround:

If you can change the code on the remote app so that it tries to ping the RPi every so often, it will not get an answer unless from the app on the RPi since it doesn’t know how, but it could get an answer from a different program that is part of the restart script for the main app.

That program could wait for the ping and answer. The remote app, getting the answer would know it had to restart and once the RPi restart program successfully gets pinged, it could start the main program.
 
You said your using USB, but you could add Ethernet. Is not being able to "reach" the master, a crash signal? Create files periodically and test? Use ps and check some parameter there?
Master creates a file and slave deletes it and see if it comes back?
 

Thread Starter

Pramod Kumar Samal

Joined Sep 12, 2018
7
Thank you every one for your time and answer. I understand best way is to modify the master app to send message to slave when application crashes or closed or maintaining some sort of heartbeat application on the master PI side to detect crash and send message to slave PI. Once again thank you every one for precious time.
Regards
Pramod
 
It can be an external thing: e.g. https://www.brentek.com/product-categories/watchdog-timer-modules

or it can be cheap: https://media.digikey.com/pdf/Data Sheets/Adafruit PDFs/3435_Web.pdf

Can't you just use the lack of USB communication?

The primary method is to use an external timer that the master has to reset once in a while. If it doesn't reset, then a flag gets set and the processer reset is asserted. When the application starts up, it can determine if it's from a watchdog event and handle the start-up appropriately. Turn-on the timer and reset the event flag.

Also see: https://www.st.com/en/reset-and-supervisor-ics/watchdog-timers.html

This https://www.st.com/en/reset-and-supervisor-ics/watchdog-timers.html#documentation doesn't save the event.
 
Top