0

I am a beginner in Android and testing Android code in which I am receiving and sending data through UART communication. Hardware for communication- MAX232 device which is connected to Raspberry Pi3 Model B and the other part of MAX232 is connected to Vending Machine Port(Rx,Tx,Gnd to communicate my android app with the Vending Machine). My communication breaks SPORADICALLY and then starts communicating. I do not know what the reason is If anyone can help me in this, please suggest. Or any other information will be needed,I will share

private static final String UART_DEVICE_NAME = "UART0"; // define in my code. **

I have to use ttyAMA0(PL011 UART) port because baudrate does not change with the core frequency like with ttyS0(MIniUART)

**

For example: If I send 100 commands one by one, I get 2-5 times this error.

**

> ERROR: Failed to open /dev/ttyAMA0: No such file or directory

**

1 Answers1

0

Same thing happens to me reading data. I do not talk to the device (particle photon) connected to it, just listen. Since i'm expecting a response frequently, anything more than a couple seconds means things have gone south on one side or the other. It didn't seem likely though that my photon code was bad, as I had done many day-long tests with other things reading the data (arduino IDE, whatever).

Anyway, I created a runnable that fires every few seconds and checks when the last received response was. If it exceeds 60 seconds (things are most certainly wrecked and not going to get any better), I'll attempt to start up the connection again (Periperhal manager's openUartDevice). The main code waits another 60 seconds before trying again if it still has not received a response.

I also added code in 'onUartDeviceError' to trigger a callback the second that goes bad (not really sure if that's ever been the culprit in this), which will attempt the same restart logic but with a much smaller wait (like 5 seconds).

Lastly I made the Pi reboot itself (and thus the attached photon) so everything starts fresh, every morning at 6am. This has solved the issue for my purposes and its been in service for somewhere in the neighborhood of two years. Due to this reliability issue I don't do anything important with the pi, it simply exists to aggregate data from a few places and provide JSON. The photon is much more reliable even if the pi stops listening to it, so it controls the important/dangerous stuff (heaters, lithium batteries). Hopes this helps a little, but maybe some reconnect logic would solve the problem.