Send binary file to pic over pc serial port

[Darrel Taylor]

Hyperterminal is all you need.

From the [Transfer | Send Text File] command, it actually sends a binary file. It just uses the default .TXT extension. But you can pick any file.

In the [File | Properties | Settings Tab | ASCII Setup Button] you can add the delays required to give the PIC time to write to the EEPROM, 10ms or more "Character Delay" depending on your EEPROM. Then you don't need any complex buffers or flow control.

It can be received on the PIC end with SERIN(2) or HSERIN, and stored to the EEPROM byte by byte.

hth,

[xnihilo]

You are great, thank you.

I have still a question. You are talking about flow control. When do I need it exactly?
Do I only need RX and GND? When interfacing PC and PIC using a max232, won't I need flow_CTS and DSR?

I've seen a code where the receive routine is something like:

FOR i = 1 to 15
HIGH pc_flow_cts
Hserin 1000,TIMEOUT_ROUTINE,[databyte_from_pc]
TIMEOUT_ROUTINE:
LOW pc_flow_cst
data_array[i] = databyte_from_pc
NEXT i

I beleive in the routine above, it request PC to send 8 bits, it stores it in the byte-sized databyte_from_pc variable, asks PC to pause transfer, stores the byte in the array then asks for the nex character and itt stops when 15 characters have been transfered, right?

In the Hyperterminal I'm ask what flow control to use:
Hardware, Xon/Xoff or none.
I beleive I will choose none in the case I'm not using the pc_flow_cts pin and choose 'hardware' if I'm using flow control pin...?
What is the advantage of not using flow control?
I might be using only RX and GND pins and add a pause after each byte so I won't need to use MAX232 chip and I don't need flow control, is this right?
(I think I've seen a schematic in the PBP manual (about SERIN) where only an inline 22K resistor is used on RX pin, so only 2 pins are used, I guess it also can be used with HSERIN...?).

You write:
"In the [File | Properties | Settings Tab | ASCII Setup Button] you can add the delays required to give the PIC time to write to the EEPROM, 10ms or more "Character Delay" depending on your EEPROM. Then you don't need any complex buffers or flow control."
-> I will have to send about 88KBytes of data into the serial EEPROM, if I add a 10ms after each byte, it will take years to tranfer all the file, no?


You also write:
"From the [Transfer | Send Text File] command, it actually sends a binary file. It just uses the default .TXT extension. But you can pick any file."
-> I'm asked for the protocol to use (1K xmodem, kermit, xmodem,ymodem,y modemg, zmodem, zmodem with crash recovery... Which one should I choose???

How does the PIC know that data is arriving on the RX pin if no interrupt is used?
I have to write a routine with a loop in which the user will be requested to send the file from PC to pic, right?

HSERIN only gets one byte? So I have to write a loop that will record all the bytes?

Sorry if I ask silly questions. I'm reading info about HSERIN and pic hardware serial port right now so I might find answers soon I guess.

[Darrel Taylor]

> I have still a question. You are talking about flow control. When do I need it exactly?
You don't "need" flow control for this.

> Do I only need RX and GND? When interfacing PC and PIC using a max232, won't I need flow_CTS and DSR?
Just RX and GND, but TX would be handy too. You need something to prompt when to send the file. Could be an LED or LCD prompt i guess.

> I've seen a code where the receive routine is something like: ...snip...
If you want to write your own program in Visual Basic or other language for the PC, you could do something like that. But it won't work with Hyperterminal.

> In the Hyperterminal I'm ask what flow control to use:
Hardware, Xon/Xoff or none.
I beleive I will choose none in the case I'm not using the pc_flow_cts pin and choose 'hardware' if I'm using flow control pin...?
What is the advantage of not using flow control?
Correct, NONE. Flow control on the PC doesn't work on a Byte by Byte basis like the PBP flow control does. So unless you have a large buffer on the PIC, it won't work.

>You write:
"In the [File | Properties | Settings Tab | ASCII Setup Button] you can add the delays required to give the PIC time to write to the EEPROM, 10ms or more "Character Delay" depending on your EEPROM. Then you don't need any complex buffers or flow control."
-> I will have to send about 88KBytes of data into the serial EEPROM, if I add a 10ms after each byte, it will take years to tranfer all the file, no?
14-1/2 minutes. Ouch! Big file.

Well, if you buffer the incoming data and use the Page Write feature of the EEPROM, you can drop that down to about 30 seconds.


>-> I'm asked for the protocol to use (1K xmodem, kermit, xmodem,ymodem,y modemg, zmodem, zmodem with crash recovery... Which one should I choose???
None, those are in the [Transfer | Send File] command.
I was talking about the [Transfer | Send Text File]

> How does the PIC know that data is arriving on the RX pin if no interrupt is used?
Poll the RCIF bit in PIR1.

[xnihilo]

Darrel,

Thank you for the answers but i'm lost now...
How does hyperterminal work when transfering a text file over com port? It simply sends all the file as a bytes stream and inserts a user defined delay between each of the bytes, until it reaches the eof? So that's why we don't need flow control?

Then i have to poll a bit that will tell me when the 8 bits of the transfered byte have filled the usart buffer? And if so i copy the buffered byte in an array for example?

Hserin takes care only of reading bits incoming on rx pin and setting the buf-full flag bit?

Did i get it well?

By the way, i remember from my old C programming days that there is a differece between Ascii and binary files (ascii may be interpreted for lf and cr characters... as this is no pc 'getch' handling we don't care if hyperterminal sends it as ascii, right?)

One last thing, i've checked the dataseet for 18f252 and 452, besides the memory size and psp and i/o pins count, i could as well use a cheaper 252 instead of 452 if it is to receive a file from pc into an spi eeprom and then send it to a 16bits dac. Both pics can run at 40mhz with 10mhz crystal and pll?

By the way... why would I need USART at all. Can't I poll an input pin connected to PC serial TX (out) and get bits one after another and build bites and transfer them to memory. I could even use an interrupt to know when a byte is incming...?

[Darrel Taylor]

Yeah, you've pretty much got it for the SLOW (14.5 minute) version. But I don't think you'll be happy with that. I'd forget about the 10ms per character option, with files that large.

To get any decent response time, you'll need to use the Page Write feature of the EEPROM, unless you are using FRAM, you haven't said.

If you are going to be buying new chips, look at the 18F2520/4520. The 252 and 452 are not recommended for new designs. The 2520/4520 have internal oscillators and several other enhancements. But the best part is that they are cheaper.

Why use the USART?
Cause if you don't, you will probably miss incoming data while trying to write to the EEPROM. With SERIN(2) and full-speed data, there's no time left to do anything else.

[xnihilo]

Yeah, you've pretty much got it for the SLOW (14.5 minute) version. But I don't think you'll be happy with that. I'd forget about the 10ms per character option, with files that large.

To get any decent response time, you'll need to use the Page Write feature of the EEPROM, unless you are using FRAM, you haven't said.

If you are going to be buying new chips, look at the 18F2520/4520. The 252 and 452 are not recommended for new designs. The 2520/4520 have internal oscillators and several other enhancements. But the best part is that they are cheaper.

Why use the USART?
Cause if you don't, you will probably miss incoming data while trying to write to the EEPROM. With SERIN(2) and full-speed data, there's no time left to do anything else.

I'm using page write, I'm collecting 256 bytes of data into an array then I write it into serial EEPROM. Even with the page feature I would need a ~10ms pause every 256 bytes to have the time to write the 256 bytes array into serial eeprom using the page write. That's why I have to keep the 10ms interval between character from hyperterminal. Any idea? Did I miss something?

I'm chosing 452 or 242 because Norm made an application based on this microcontroler (which costs about 8USD at futurlec.com). It has 28 (or 40) pins, an USART, SPI, 3 (or 5 ports) and can run at 40MHz with 10MHz xtal and PLL enabled. Otherwise if the PIC you are mentioning has the same features and are less expensive AND can be programed with ICSP, why not. I know 425 are supported by my pic programmer, I should check for other models.

About USART, do I need to poll a bit? The program executes the next instruction once the HSERIN is done, no??

I will post my code once I figure out everything about the registers settings.

[Darrel Taylor]

I'm using page write, I'm collecting 256 bytes of data into an array then I write it into serial EEPROM.

I've never seen a serial EEPROM with a 256 byte page buffer. Which one are you using?

> Even with the page feature I would need a ~10ms pause every 256 bytes to have the time to write the 256 bytes array into serial eeprom using the page write. That's why I have to keep the 10ms interval between character from hyperterminal. Any idea? Did I miss something?

Well, first off ... the Page Write Buffer is just that, A Buffer. Buffering the whole page in the PIC before writing it to the Page Write Buffer, isn't very efficient. The purpose of the buffer on the PIC should only be to collect incoming data during the time when it can't send it to the EEPROM's buffer because it's in a write cycle. How big that buffer needs to be, depends on the baud rate of the incoming data (also unknown at this point) and how long the EEPROM takes to write. But for sure it's less than 256 bytes.

> I'm chosing 452 or 242 because Norm made an application based on this microcontroler ...

The 2520/4520 will do everything the 252/452 can. And more.

> About USART, do I need to poll a bit? The program executes the next instruction once the HSERIN is done, no??

If you want the program to stop dead in it's tracks every time, sure, go for it.
Personally, I'd rather let the program continue on doing other things like buffer maintenance and figuring out how many bytes to write to the Page buffer at a time.
<br>

[eliotmayer]

Darrel,

I found this suggestion of yours on a web search, and it seems to fit a requirement we have, though not involving a PIC. It almost works, but it looks like every other byte has its MSB inverted when the data is sent out of the COM port. Do you have any idea why? Is there some HyperTerminal setting we are missing?

Thanks,

Eliot Mayer
Analogic Corporation
Peabody, MA, USA

Hyperterminal is all you need.

From the [Transfer | Send Text File] command, it actually sends a binary file. It just uses the default .TXT extension. But you can pick any file.

In the [File | Properties | Settings Tab | ASCII Setup Button] you can add the delays required to give the PIC time to write to the EEPROM, 10ms or more "Character Delay" depending on your EEPROM. Then you don't need any complex buffers or flow control.

It can be received on the PIC end with SERIN(2) or HSERIN, and stored to the EEPROM byte by byte.

hth,

[Darrel Taylor]

It's hard to say, but it sounds like parity is enabled in hyperterminal.

[eliotmayer]

Thanks, we thought that parity was disabled, but we'll double check that. Meanwhile, my colleague found a program that did the job of sending a binary file out the COM port with no problems. It's called Tera Term. I'm not sure, because he got it from another colleague, but it may be the free program posted at http://www.ayera.com/teraterm/.

It's hard to say, but it sounds like parity is enabled in hyperterminal.