Send binary file to pic over pc serial port

[xnihilo]

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>

About the serial EEPROM buffer, maybe I missed something.
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.

[Darrel Taylor]

DT>> I've never seen a serial EEPROM with a 256 byte page buffer.
Can't say that anymore ... 25AA1024

> 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>

[xnihilo]

DT>> I've never seen a serial EEPROM with a 256 byte page buffer.
Can't say that anymore ... 25AA1024

> 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>

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?

[Darrel Taylor]

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.

[xnihilo]

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?

[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>

[xnihilo]

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:
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?