Printable View
Hello,
Is there a simple way to send one file to a pic over a pc serial port?
Maybe using a Terminal?
I would like to store a binary file into a spi serial eeprom but i can't write a pc program to send the file. I don't need to re-invent the wheel. Such software brobably already exists.
No?
Thank you.
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,
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.
> 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.
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...?
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.
Quote:
Originally Posted by Darrel Taylor
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.
I've never seen a serial EEPROM with a 256 byte page buffer. Which one are you using?Quote:
Originally Posted by xnihilo
> 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>
About the serial EEPROM buffer, maybe I missed something.Quote:
Originally Posted by Darrel Taylor
It is a Microchip 25AA1024. Assume we use a 10MIPS PIC (=100ns inst cycle). From what I've read, you send the WRITE/PP instruction (8 bits = 8 clock cycles) then 24 bits address (=24 clock cycles) then up to 256 bytes (= 256*8 clock cycles) then you bring the CS_ pin high to enable the self-timed write cycle that can, in the worst case, be 10ms (that's why I will need to poll the WIP bit before starting the next page write).
So I beleive sending the page to the eeprom takes roughly ~ (1+3+256)*8*100 ns = 208Us then we can go back to storing the next 256 incoming bytes, one every 1ms (256ms to fill the 'buffer array' for the next page).
"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"
-> That's exactly how my 256 bytes buffer in PIC RAM is used.
"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"
-> What? We will get 1 byte every 1ms... no? Or you mean the speed at which the BITS arrive in the PIC? I consider the situation where the transfer is immediate (it should be at 115kb) and a 1ms interval between each byte. So it will take more thant 256ms to transfer 256bytes. Do you agree?
"But for sure it's less than 256 bytes."
-> Why so?
"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."
-> I'm sorry but I don't understand. Why would the program stop dead??? You mean the program will be idle while the HSERIN is getting its 8 bits of data? Right?
In this case, yes, I might check the bit so I gain the time during which HSERIN is getting the bits (it shoud logicaly take 8.7Us per bit at 115000 bps so about 70Us for 8 bits... not much you can do during such a short period)... I could lower the baud rate maybe.
DT>> I've never seen a serial EEPROM with a 256 byte page buffer.
Can't say that anymore ... 25AA1024 :o
> So I beleive sending the page to the eeprom takes roughly ~ (1+3+256)*8*100 ns = 208Us
Even using the MSSP module, you can't do SPI at full 10mhz. But I'm assuming you're using SHIFTOUT, which AT BEST (40mhz OSC) will run at about 500khz clk, which is 2us ea.
(1+3+256)*8*2us = 4160us
But don't count on that, because there's additional overhead involved too like retrieving bytes from the array.
With data as slow as 9600 baud, more than 4 bytes could be received during that time.
At 38400 baud it would be 16 bytes.
<br>
Quote:
Originally Posted by Darrel Taylor
What what what?
Shiftout??? I'm clocking out the write instruction then the address then the bytes. One bit at every instruction cycle (see 25AA1024 datasheet timing diagrams). One bit per clock cycle that is 10MHz. Maybe I'm not grasping something. Would you check that datasheet?
No need to look at that datasheet. It's simple math.
If you have a PIC with a 40mhz OSC, then the processor is running at FOSC/4, or 10mhz.
Now let's say you want to make a clk output that's as fast as possible. It will take a minimum of 4 instructions. One to turn the Pin ON, one to turn it off, and a GOTO (2 cycles) to create a loop.
Those 4 instructions, just cut that 10mhz down to 2.5mhz, and it's only creating a clock signal. Now start counting 8-bit's at a time so you know when to get a new byte, getting the new byte from memory, and rotating it so the bit's can be sent one at a time, and you should see that there's NO way to bit-bang a 10mhz SPI data rate.
Okay, I see but then I don't understand why in the datasheet they show a bit being sent at every rising edge of the clock cycle... What's the explanation for that?Quote:
Originally Posted by Darrel Taylor
Sure, from the EEPROM's point of view, it shifts in 1 bit of data for every rising edge of the clock signal. But that clock is derived from the PIC with either software or hardware.
The EEPROM's(SPI) clock is not the same as the Processors clock.
<br>
You say:Quote:
Originally Posted by Darrel Taylor
Now let's say you want to make a clk output that's as fast as possible. It will take a minimum of 4 instructions. One to turn the Pin ON, one to turn it off, and a GOTO (2 cycles) to create a loop."
-> Well, I also thought that the clock rising and falling was hardware controled (on the SCK pin of the pic), so there is no need to set the pin high then low by software to create a clock. Again, in the datasheet of the pic, at the section dedicated to MSSP, it is told that the clock can be as fast as 10MHz (FOSC/4) = 10Mpbs.
It seems the more I try to understand the less I do.
My problem is
1- to undestand the way things really work
2- make sure that with a 1ms delay I will have enough to transfer my 256 bytes array into the EEPROM page array if I'm using the HSPLL setting with a 10MHz xtal.
As with the send file from hyperterminal I have no flow control I unfortunately have a fixed inter-character delay of, let's say, 1ms, this is the time I have to transfer my array of 256 byte to the serial eeprom buffer and then initiate a page write that can take up to 10ms but then I don't care bescause while the 256 next bytes are received by the usart, I can wait for the write to be finished.
Norm did a project similar to mine (except he is using a 50MHz serial eeprom) and he is using flow control as he wrote a PC program to manage the character output.
My wish is to be able to transfer an pcm wave file to the eeprom then output is to a 16 bits dac. Timing seems somehow crucial in this project and this I need to understand.
Is there a way to know exactly how long it takes to transfer my 256 bytes array to the eeprom buffer?
You say:
"If you have a PIC with a 40mhz OSC, then the processor is running at FOSC/4, or 10mhz."
-> Then what is the PLL supposed to do. It should work as a clock multiplier so we get 40MHz out of a 10MHz xtal?
High sPC_FLOW_CTS ' Clear PC To Send
HSerIn 1000,EXIT_HSERIN_MEM_FAIL,[yBYTE_FROM_PC]
EXIT_HSERIN_MEM_FAIL:
Low sPC_FLOW_CTS
How does such code work exactly?
Does Hserin takes care of reading some control bit (something I would have to do if I were to write a bit-banging routine?), it handshakes with the PC at the rate defined in BAUDCON,RXSTA, TXSTA?
As I understand it, it will store data from PC in the 8,1 format (so the PC has to also send in this format... will it add the stop bit automaticaly??) when the byte has been received, it is stored in the variable yBYTE_FROM_PC. The 1000ms delay must be a the higher limit of a counter in a loop where Hserin checks periodicaly a flag bit to see if the transfer is complete, right?
How much time does such code use (if we consider there is no timeout)??
> It seems the more I try to understand the less I do.
And the more I try to explain the less I get across.
Look, I hate to say it this way but, ...
I find it hard to believe that someone who doesn't know how the USART works, would understand and be able to use the MSSP module. It's much more difficult. Perhaps you've cut&pasted someone else's code that does use it.
But I can't seem to get that kind of information out of you.
Please slow down and look at 1 thing at a time. And in this case, answer 1 question.
Are you using the MSSP module?
Keep in mind that there are NO PBP statements that use it.
You would have to be manually manipulating registers.
<br>
Quote:
Originally Posted by Darrel Taylor
I didn't cutnpaste code.
I've read the datasheet of the SPI serial memory (25aa1024, the info about the 16 bits SPI dac and the info about SPI in the PIC datasheet. It is very difficult but at least, from what I've read, using SPI is not that difficult, there are a few instructions.
Pull CD low, send WREN command to enable the writes, put CS High. Put CS low, check status register to see if the Write In Progress bit is cleared, put CS HIGH. Then put CS low, send the WRITE command followed by the 24 bits address and then the bytes to write and finish by putting the chip select pin high again.
You write to SSPBUF to transfer to the shiftin buffer and you read the data from the buffer and use it if relevant.
It does not seem so complicated once the setting to registers related to SPI have been properly set. I know there is no PBM commands to use SPI. But there are fot the USART. And using the usart seems more complicated to me.
Anyway, I have to learn. I read code from other people and try to figure it out.
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
Quote:
Originally Posted by Darrel Taylor
It's hard to say, but it sounds like parity is enabled in hyperterminal.
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/.
Quote:
Originally Posted by Darrel Taylor