Receive data on lopy through serial

[robert-hh]

@crumble If Pin conflict is the issue, one can reassign the UART Tx/Rx to other Pins, usign the uart.init() method https://docs.pycom.io/chapter/firmwareapi/pycom/machine/UART.html

[monersss]

@crumble unfortunately it was a pin problem, when connected to pins 21 and 20 as serial TXD and RXD data is stored on SD without any problem

[monersss]

@robert-hh I have managed to read and write a jpg file using lopy and store it on SD after assigning different pins for uart.
When i try to do the same with the same jpg and store it on flash the file is being corrupted, number of bytes is different and somewhere in the middle of a file binary data are totally different then those of original file, i am using this code:

from machine import UART
import pycom
import time
from machine import SD
import os

#sd = SD()
#os.mount(sd,'/sd')
#os.listdir('/sd')


uart = UART(1, baudrate=115200, pins = ('P21', 'P20'), timeout_chars=2000)
while True:
    data = uart.read(25)
    print(data)
    if data != None:
        with open('/flash/pliki/mon','ab') as f:
            f.write(data)
            f.close()

What may be causing file corruption?

[robert-hh]

@monersss Flash is way slower than the SD, so jou are simply loosing data, because there is no flow control. For SD that works, because the firmware buffers some bytes, and that grants a time window for storing. AFAIK, the receive buffer is 256 bytes. Besides that, you code is highly ineffcient, because you open and close the file for every chunk of data. You could try it this way around:

from machine import UART
import pycom
import time
from machine import SD
import os

#sd = SD()
#os.mount(sd,'/sd')
#os.listdir('/sd')


uart = UART(1, baudrate=115200, pins = ('P21', 'P20'), timeout_chars=2000)
with open('/flash/pliki/mon','ab') as f:
    while True:
        data = uart.read(25)
        print(".")
        if data is not None:
            f.write(data)
        else:
            break
f.close()

The f.close() is still there, but not needed due to the with... clause. The file system has an internal 4k buffer, unless that is full or the fiel is closed, nothing will be written. You should also not print the data, because that also consumes time. If that does not work, you'll need a handshake protocol between sender and receiver.

[livius]

@monersss
You also can decrease speed of transmision e.g 9600
but the best is what we suggest you at start
you must of course have some protocol implementing.
especially you can send info with e.g. md5 hash of portion of data back and if this is ok send more if not then repeat...

[monersss]

@livius tried with lower speed, result is the same. I have never written a protocol So i am not really sure how to do it..
Another thing is That i would like my lopy to stop reading data when the whole for example 20 kB file was received, how can i do that??

[livius]

@monersss by protocol implementing we mean simple thing

1. you send command to destination "START_JPG"
2. you send back e.g. "OK" or "UNKNOW"
3. you send e.g 200Bytes of jpg + CRC(or MD5 or what you need to verify}
4. you read that data and calculate CRC and compare and you send back "OK" or "retry" or "cancel"
   ....

all in your hand (look in google for e.g. handshake protocol)

[robert-hh]

@monersss At the moment, with my example, that happens when you get a timeout. But again, that would require some "out-of-band" signaling, meaning: in addition to the "payload", the jpg file, some control information must be exchanged. And that is part of a protocol. That could be pretty simple. If I grab one out of the air, it could be:
Define record types, where the first letter defines the type of the record, followed by 3 bytes record length, followed by the payload, like:
'fnnn': filename (of length nnn)
'd128': data
'x000': done
You would first receive 4 bytes, decode type and length, and then receive further 'length' bytes. And for every record received, your LoPy would send a confirmation, like the three bytes: "ok!" or "bad", in case of errors (or just a single byte).
That would implement flow control and the EOF signal. It does not have other elements like check sums and sequence control. But you might not need that.