CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Serial algorithm with interrupts

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
theteaman



Joined: 04 Aug 2006
Posts: 98

View user's profile Send private message

Serial algorithm with interrupts
PostPosted: Sat Aug 26, 2006 7:02 pm     Reply with quote

Hello

I need to be able to read a large amount of data from a PC, over UART, to the PIC. Now I have the UART all set up and it works. But my problem relates to the algorithm itself. Basically, the amount of data that will be transferred will be greater than the total RAM the PIC has, and I was hoping to transfer the data into a Flash memory IC as the data is received to overcome this problem.

If I have an interrupt handler that simply sets a global variable to the value returned by getc(), this wont work because the handler will be called faster than the main code has time to deal with it, and this will result in lost data.

If I have an interrupt handler that stores to a buffer, then in my case, wont I still lose data eventually (it will just take longer for the buffer to overflow)?

Does anyone have any ideas of what I can do? The only thing I can think of is to send the data from the PC in fixed sized chunks (and wait for each chunk to complete before sending the next one), but surely there is another way?
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Sat Aug 26, 2006 10:21 pm     Reply with quote

Use a FRAM device for storage. The write time is pretty much instant. Receive the data into a ring buffer. Anytime data is in the ring buffer, store to the FRAM device. Implement flow control, RTS, CTS.
theteaman



Joined: 04 Aug 2006
Posts: 98

View user's profile Send private message

PostPosted: Sat Aug 26, 2006 11:27 pm     Reply with quote

Mark wrote:
Use a FRAM device for storage. The write time is pretty much instant. Receive the data into a ring buffer. Anytime data is in the ring buffer, store to the FRAM device. Implement flow control, RTS, CTS.

Well I'm using a flash memory at the moment (M25P) is that the same thing as FRAM? it has page program cycle tim of between 1.4 and 5ms, is this fast enough for me to do what you are saying?
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Sun Aug 27, 2006 8:05 am     Reply with quote

theteaman wrote:
Mark wrote:
Use a FRAM device for storage. The write time is pretty much instant. Receive the data into a ring buffer. Anytime data is in the ring buffer, store to the FRAM device. Implement flow control, RTS, CTS.

Well I'm using a flash memory at the moment (M25P) is that the same thing as FRAM? it has page program cycle tim of between 1.4 and 5ms, is this fast enough for me to do what you are saying?


Nope, it is not the same. A FRAM has a program cycle time of 0ms. You don't give any specifics about the communication so no one can possibly answer your question. If it takes less than 5ms to receive a "block" of data then the answer is no.
Guest








PostPosted: Sun Aug 27, 2006 8:12 pm     Reply with quote

[quote="Mark"]
theteaman wrote:

Nope, it is not the same. A FRAM has a program cycle time of 0ms. You don't give any specifics about the communication so no one can possibly answer your question. If it takes less than 5ms to receive a "block" of data then the answer is no.

Well, you havent given me any specifics about what I should be specific about......

anyway, the solution is to send the data in chunks. I cannot find FRAM at digikey, and I cant imagine it being a serial interface, but rather parallel which I do not have enough pins for nor the space to add circuitry to share them, so the answer is simply to be more 'cooperative' on the PC sender end.
specialk



Joined: 12 Nov 2005
Posts: 27

View user's profile Send private message

PostPosted: Sun Aug 27, 2006 8:15 pm     Reply with quote

Mark wrote:
Nope, it is not the same. A FRAM has a program cycle time of 0ms.

There is no such thing as a program cycle time of 0ms. Looking at a popular manufacturer (Ramtron), their parallel FRAM modules have an access time as low as 60ns and as high as 120ns (http://www.ramtron.com/doc/Products/Nonvolatile/Nonvolatile_list.asp?ID=6). Their serial modules are even slower (because of the serial overhead). While fast (by relatively slow PIC standards), it is not instantaneous.

-special [k]
kender



Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley

View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger

PostPosted: Sun Aug 27, 2006 8:19 pm     Reply with quote

specialk wrote:
Mark wrote:
Nope, it is not the same. A FRAM has a program cycle time of 0ms.

There is no such thing as a program cycle time of 0ms.

I think, Mark wanted to say that writing cycle of FRAM is under 1ms. Most types of nonvolatile memory have write times one the order of few ms. C'mon, 120ns is almost zer0 compared to 1ms.
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Sun Aug 27, 2006 9:16 pm     Reply with quote

specialk wrote:
Mark wrote:
Nope, it is not the same. A FRAM has a program cycle time of 0ms.

There is no such thing as a program cycle time of 0ms. Looking at a popular manufacturer (Ramtron), their parallel FRAM modules have an access time as low as 60ns and as high as 120ns (http://www.ramtron.com/doc/Products/Nonvolatile/Nonvolatile_list.asp?ID=6). Their serial modules are even slower (because of the serial overhead). While fast (by relatively slow PIC standards), it is not instantaneous.

-special [k]


Obviously there is no 0ms write time but to the application there would be. The part writes at the bus speed so you can in essence write the data as fast as the bus speed without any need to delay. In essence, 0ms. While we are at in Cornflake, no one said anything about access times. The orginal poster referred to page program cycle time of 1.4ms-5ms. The device will be unable to be accessed during this time. The FRAM has no such waiting period. It is 0ms which is what I was referring to.


Cheerios
treitmey



Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA

View user's profile Send private message Visit poster's website

PostPosted: Mon Aug 28, 2006 8:07 am     Reply with quote

mouser has the ramtron devices.. Here is the search for FM24C256

[url]http://www.mouser.com/search/Refine.aspx?Ne=1447464+254016&Ntt=*FM24C256*&Msb=0&Mkw=FM24C256&N=1323038[/url]


Last edited by treitmey on Tue Dec 26, 2006 4:56 pm; edited 1 time in total
specialk



Joined: 12 Nov 2005
Posts: 27

View user's profile Send private message

PostPosted: Mon Aug 28, 2006 2:19 pm     Reply with quote

Quote:
Obviously there is no 0ms write time but to the application there would be. The part writes at the bus speed so you can in essence write the data as fast as the bus speed without any need to delay. In essence, 0ms. While we are at in Cornflake, no one said anything about access times. The orginal poster referred to page program cycle time of 1.4ms-5ms. The device will be unable to be accessed during this time. The FRAM has no such waiting period. It is 0ms which is what I was referring to.


Cheerios

I'm sorry if my reply seemed rude or hurtful, I did not intend to offend you (or anyone else). However, while you may think that 120ns isn't a long time (as I said before, by relatively slow PIC standards), data access speeds (which in the case of Ramtron FRAM refer to reading OR writing) have been a serious issue for a number of colleagues who had to abandon the Microchip PICs in favor of much more robust (and faster) ARM microprocessors with DMA.

Theteaman may want to consider an FRAM device or possibly an SRAM. I'm not discouraging its use. I have had a lot of success with Maxim's NV SRAM; however, they are parallel modules (~70ns access time), so given his requirements, I agree with you that Ramtron's serial FRAM modules would be more appropriate. FRAM modules are, as you said, more than adaquite for Microchip PIC applications.

Again, I apologize for my curt reply and for offending you.

-special [k]
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group