0

I have some hard time trying to find a method to restart my state machine. In other words some part of what I ve got:

I have a module that when is powered up it stays for a debounce time of 0.5 s and then it goes in a state machine: first it send a string#anotherstring# then he start a timer of some period and when timer elapsed, it converts an analog signal/read a data (SPI,I2C) and sends that data followed by another #. The state machine goes back and start again the timer and send again the data ...

On another chip. I receive info from that module. So here is a state machine that complete the first string, second string, and then cumulates values in a buffer, again and again.

In some moment some external device ask for data, moment when the chip make some computation and sends it.

SO far so good. Every single part of this is working exept the part when the module is disconnected. Ok you may say no problem no data is send. Yes this is true, but what happens if the module is connected back. Until now to test my work I have reseted the chip disconect and connect the module. By doing this the chip is on the first state and the module goes from first state, everything is ok.

My qestion is how to determine when the device is disconected from the chip to restart the chip stat machine and to wait for the string#anotherstring# combination(first state).

Another question is how to determine if the communication is broken and not the power down. When putting back the comunication the data should be again send,preferably both modules to go from init state.

What I have in mind is to send some ack to the module from the chip. But I do not know exactly how. Basically I want this: when the module is disconected its state machine obviously start over and the chip state I want again to goes back to initial state. if the comunication of the module is unplugged some how both statemachines to start over.

I do not know if I am clear with this. but please if there are questions ask. I will come with edits if I found something.

OTHER INFO: The module and the chip are some microcontrolers, the comunicaiton is UART.

Marian-Emanuel Ionascu
  • 81
  • 1
  • 10
  • 2
    A simple method is a 'keep alive' message incorporated with a timeout. The keep alive message can be as simple as a ACK/NAK exchange. The timeout expires when no communication has occurred within the specified time limit. Upon the timeout occurring, the state machine should be reset (and a message sent commanding a state machine reset of the other device.) – user3629249 Jun 11 '14 at 20:48

1 Answers1

0

Let me sketch a basic scheme you can use on the receiving side:

On your receiving side, you'll want to time-out if no valid/complete message is received within a reasonable time frame. This way, you'll detect when the module goes offline for whatever reason at any point in time.

The state machine that receives and processes the messages will also be reset in this case. This means you'll have a timer which, for example, is started when data is received and stopped when a message was correctly and fully received. If the timer times out, any message currently being received is declared invalid and discarded, and the receiver goes back to the start, looking for the next message.

Then, you'd have to implement in the receiver the code to detect when a message starts and/or ends. So if the module always starts by sending string#anotherstring# then the receiver will wait until it sees string# for example; anything else received is ignored by the receiver. Only after the expected prefix was detected the rest of the message receiving is done.

During the whole process, the receiver's messsage timeout timer is active and if any part of the message is not received in time the receiver assumes transmission problems and goes back to waiting for the start of the next message.

JimmyB
  • 12,101
  • 2
  • 28
  • 44
  • are you suggesting here to use a client server style? For example, on the module I will send string#strign# and I can wait of a confirmation from receiver. If is not comming in a timeout resend the first combo. Else continue with sending data. On receiver I will read entire text see if it is ok, send acknolage and then receive another text and see what it is. If is not what is intended go to first comand wating, and send a message to module to restart its state machine. This is what you explained there is it? I believe I made the receiver state machine to restrictiv. – Marian-Emanuel Ionascu Jun 12 '14 at 23:24
  • No, that's not quite what I meant. - To establish a common understanding, could you please explain (again) which part of your system does what? - I read you have a "module" and "another chip", where the "module" only sends messages to the "other chip", and the "other chip" has problems figuring out if the "module" is still there. Is this a correct understanding? – JimmyB Jun 14 '14 at 21:16
  • Yes this is correct. I have 1 to 4 modules that are connected to a base module. THe modules are sending info and register to the base. When I disconect one module I want to know and deregister that module. I made a "client server" thing as follows: the base module will read entire data from the moule and base on a header the base module will figure out if a module is trying to register or just send random data. If it is trying to register the module will wait for a timeout for an aswer. After the base answered the register phase is over – Marian-Emanuel Ionascu Jun 16 '14 at 20:43
  • then the module send data. If for anoter timeut defined in base module there is no incomming bytes from that module the base will deregister the module, and eventually send a restart command to the module. It looks everything is ok. Also if the module just sends random data, the base module will send a restart command to module. if there is a uknown module it cannot react to the restart and after a timeout will be igored. – Marian-Emanuel Ionascu Jun 16 '14 at 20:45
  • This sounds like a pretty good and sophisticated algorithm you have there. I'm not quite sure what the problem is, though. - Is the problem with a new, not-registered module being connected, that cannot be addressed by the base ("unknown module [which] cannot react to the restart") because it is not yet known there? – JimmyB Jun 17 '14 at 09:40