Determining which command caused SERIN2 to trigger?

[CuriousOne]

Hello again.

I have this simple line:

serin2 portc.4,84,[STR textline\8\13]

So it waits till there are 8 consecutive bytes received or enter received and then proceeds to next code.
Is there a way to determine what caused it to go to next code? this was due to enter pressed or 8 bytes received?

Only solution comes to my mind is to store copy of TEXTLINE array and upon reception of new data, compare these values and see, if there were any changes written to array. But I guess, there might be a simpler way for all that?

[Ioannis]

Maybe use wait(13) to check the string textline for CR and then decide what was received?

Something like ARRAYREAD textline,not_cr_found,[wait(13)]

will jump to not_cr_found. So 8 bytes were received that were not a CR.

Have not tested.

Ioannnis

[CuriousOne]

I want to receive serial data from PC, sent via COPY command via serial, like COPY asdf.txt > COM1 to MCU and write it to I2C eeprom.
So for this I need a loop with SERIN2, which will receive 1 byte and write it to EEPROM. But how to force serin2 wait indefinitely, until the transfer starts, and furthermore, force it to stop, when transfer ends?

[tumbleweed]

If you want to do this a byte at a time (or even a few bytes) then you need to enable hardware handshaking on the PC side of things and have the pic assert an RTS output after each byte.

Or, use a terminal emulator that can add delays between bytes and cross your fingers.

Either way, there's no real way to know when the transfer ends other that adding some timeout (and crossing your fingers).
If you're actually sending a text file then you could always add something to the end of the file.

[CuriousOne]

I have 24C64 connected to PIC18F45K80 and want to update it's content from PC (about 2KB of font and string data). So to avoid unsoldering, connecting to programmator and then soldering back each time I need EEPROM update, I thought, I maybe use serial connection for that.
I assembled the test circuit using HT42B534 USB<>Serial bridge and it works fine when I send strings via TeraTerm or RealTerm, but when I send some small file (even 4 byte) via the COPY command, I end up receiving garbage at PIC side.

[tumbleweed]

That's to be expected. The COPY command is basically going to send bytes out at the speed of the serial baud rate, which if you're set to 9600 baud is about 1msec/byte.
The pic however takes much longer than that to update the EEPROM (typ 4ms/byte for the K80, no max specified) so the pic uart overruns. Faster baud rates are even worse.

Teraterm has a 'send file' function which you can use, and tweak the time per byte to slow it down enough to work.

[CuriousOne]

All that was too complicated and time-intensive, so I wrote a simple code - I flash 1KB data to on-chip eeprom of 18F, then use small PBP code to write it to 24C64