Serial comms with PC using simple flow control - how to do?
Erlend
Posts: 612
The only thing I found on OBEX was a Kermit driver, but it was not easy for me to understand. I need a way to spool over a large text file from the PC to the Prop, where it will by be written into the high end of the 64K EEPROM, one piece at a time.
Writing (from DAT strings) into EEPROM works fine, but I am struggling to find the best approach to doing a controlled PC-Prop serial transfer. I do not have a programming environment (or current experience) for the PC side of it, so I depend on available functionality in some PC terminal software. Some sort of xon/xoff should do. Don't need parity check and stuff.
I want to:
Repeat while not eof
set ready to receive from pc
receive a byte
set not ready for pc
write the byte to eeprom
Are there any good examples somewhere of how to code (spin) XON/XOFF or other flow control supported by simple pc terminal software? What is the recommended pc terminal software?
Where should I start?
Erlend
Writing (from DAT strings) into EEPROM works fine, but I am struggling to find the best approach to doing a controlled PC-Prop serial transfer. I do not have a programming environment (or current experience) for the PC side of it, so I depend on available functionality in some PC terminal software. Some sort of xon/xoff should do. Don't need parity check and stuff.
I want to:
Repeat while not eof
set ready to receive from pc
receive a byte
set not ready for pc
write the byte to eeprom
Are there any good examples somewhere of how to code (spin) XON/XOFF or other flow control supported by simple pc terminal software? What is the recommended pc terminal software?
Where should I start?
Erlend
Comments
If you just want to spool via terminal, the simplest method there is to use the BAUD rate as bandwidth control, and (optionally) send a ACK-Verify-OK byte per page from the Prop, and a SlowDown byte if the Page-Buffer overruns.
- The slow-down signal uses 'eyeball feedback' to lower the Baud rate
eg suppose your EEPROM specs a write time of 16 ms and has a Page size of 16, that could be supported by a buffer of >32 bytes (so you can store next page while loading/polling the first.
Indicated Baud rate is slower than 1 byte / ms, or 10,000 baud. (Plug in the values for your EEPROM).
Communication with a PC Application
https://www.parallax.com/sites/default/files/downloads/AN018-CommPC-v1.0.pdf
Communication with a PC Application
Abstract: Many embedded applications share
information with external devices, and the
preferred connection between devices is asynch
ronous serial communications. The multicore
architecture of the P8X32A enables the designer to create and deploy device-to-device
communications strategies with no impact on
the primary application code. In this example
a deployed communications support cog mana
ges data between the main application and
the serial I/O firmware, using VB.NET and the P8X32A QuickStart board.
But for a small amount of data, it's so much simpler to just chop it into a few chunks, represent it as DAT declarations, and program it directly from a "loader" image.
Why are you wanting to use a slower, more cumbersome approach?
Xon/Xoff used to work with PCs a long long time ago but since they "improved" their serial receive capacity by increasing the depth of their FIFOs this has proved ineffective as flow control just gets buffered in hardware like everything else.
But if I send files across serial to the EEPROM I at least manage this so that I do page writes of 64 or 128 bytes at a time with a typical page write time of 5ms. You don't need handshake to do this but either limit the baud rate or just use simple delays after each line which most terminals support.
I would try as others have suggested, simply limit the baud rate to something like 9600 or slower. If you need high performance serial data into the prop, look at the FT245. It's parallel FIFO, so it requires 10 data lines, IIRC, on the prop.
I'll see if I can find a simple pc terminal software that can send plain text files, but really I should speed up my Python learning and write a simple sender myself.
Erlend
EDIT: RealTerm seems to fit the bill. I am thinking if I write to eeprom byte by byte instead of in sets of 128 I do not need to worry about pausing at all, neither about handling end of file wrt the 128 size.
EDIT: Simple Serial by Chip Gracey and others is an easy to understand spin method for doing simple rx/tx. Now I have all I need to start putting together my own code.
I'm attaching a demo that implements receiving a file into the high eeprom using Xon/Xoff flow control. The demo uses "*" as the EOF character, but that could be anything.
Under CoolTerm, you have to enable 19200 baud with Xon checked. The serial receive buffer has to hold at least 128 characters (which is the page size of a 24LC512 eeprom). Then connect to the Prop and choose the Connection/SendTextFile option. The program receives the data in 128 byte chunks, sends the Xoff, then writes that page to eeprom, then sends Xon and so forth until it gets the EOF. All in Spin. Then to verify, it prints out the contents of the file from eeprom onto the terminal screen.
Caveat, I've only tried it on a Mac, not PC or Linux. I'm not sure how different FIFO hardware, such as Peter mentioned, might affect the performance.
Thanks. Right now I am well ahead on implementing a character-by-character scheme, which makes the total code really minimal, but the page-by-page is probably a more 'proper' way to do it, so I might do that as a next step.
Anyway, it is good to have this demo to look at as I engineer my own code. (I've found I need to (re-)write code myself in order to really learn.)
Performance is not really an issue. XON/XOF is attractive in that it is a really simple flow control, but my crude way of doing it does not require full duplex, so that makes the total code size small.
Erlend