| View previous topic :: View next topic |
| Author |
Message |
JimB
Joined: 25 Aug 2005
Posts: 65
Location: Huntington Beach, CA
|
| No file creation - need to store and then transfer to a PC. |
 Posted: Sat Sep 24, 2005 5:47 pm |
 |
|
I purchased the CCS compiler about a month ago. The project that I am working on has just added the requirement to be able to store data in an onboard EEPROM. Then later transfer that data to either a PC or something like a USB thumbdrive. I was a little shocked to find that this compiler does not have the "fopen()" function which implies that I can only store raw data in local memory. Does this imply that the raw data would have to be transferred to a PC with custom software which could put this data in some sort of "file"?
What would be the best way to transfer the data to the PC?
Can the raw data be transferred to a USB thumbdrive without being in a file format?
Any suggestions for data storage and later transfer it to a PC. |
|
 |
kender
Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley
|
| Re: No file creation - need to store and then transfer to a |
| Posted: Sat Sep 24, 2005 6:08 pm |
|
|
| JimB wrote: | | Can the raw data be transferred to a USB thumbdrive without being in a file format? |
This is a very interesting question. I thought about it some time ago and came to a conclusion that a PIC can't communicate with a USB thumb drive directly in practice. The thumb drive is a USB slave, and in practice the PIC is a USB slave also. |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Sat Sep 24, 2005 6:42 pm |
|
|
| Quote: | | store data in an onboard EEPROM. |
What is your definition of this? Does it mean internal to the PIC or an eeprom on the board.
| Quote: | | I was a little shocked to find that this compiler does not have the "fopen()" function |
What would you expect the fopen() function to do? You do not need an fopen() function to store data in an eeprom. On a PC, it definitely make writing data to a HDD easy, but again, on a micro what would you expect it to do?
| Quote: | | store raw data in local memory |
What is your definition of local memory?
| Quote: | | Does this imply that the raw data would have to be transferred to a PC with custom software which could put this data in some sort of "file"? |
How else were you expecting to do it? Were you expecting to use a micro with fopen() write a file and then use something like xmodem to transfer the file to a PC?
| Quote: | | What would be the best way to transfer the data to the PC? |
What kind of data? The answer will most likely be RS232 though.
| Quote: | | Can the raw data be transferred to a USB thumbdrive without being in a file format? |
If you mean from a PIC, short answer is no. You would have to implement a host controller which would not be worth it.
| Quote: | | Any suggestions for data storage and later transfer it to a PC. |
How much data? What kind of data? How often? Details, Details, if you want valuable help, give good clear decisive details. |
|
|
JimB
Joined: 25 Aug 2005
Posts: 65
Location: Huntington Beach, CA
|
|
| Posted: Sat Sep 24, 2005 7:26 pm |
|
|
Excuse my ignorance. I'm a circuit designer by trade and have only had one C course some time ago. Programming the PIC became necessary for me since just having functional electronics these days won't do the whole job. Hence the silly questions.
The project I am working on is a hand held medical instrument that will take a measurement comprised of an average, min and max values plus some sort of index number, time, date. I am assuming that an external EEPROM will be used. At the end of the day I want to download this data (multiple sets of the data described) into a PC. |
|
|
kender
Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley
|
|
| Posted: Sat Sep 24, 2005 9:20 pm |
|
|
| JimB wrote: | | I am assuming that an external EEPROM will be used. |
You could use the PIC's internal EEPROM, if your data will fit it. For example that 18F452 has 256 bytes of EEPROM on the chip. Take a look at these functions:
| Code: | read_eeprom();
write_eeprom() |
On the other hand, if you want lots of storage, a media card (like the one used in the digital camera) can be used. Media cards support SPI bus, and there is code for them in this forum. |
|
|
dyeatman
Joined: 06 Sep 2003
Posts: 1933
Location: Norman, OK
|
|
| Posted: Sat Sep 24, 2005 9:44 pm |
|
|
| IMHO, one other excellent option for external storage would be some RAMTRON FM25256 256KB SPI FRAMs that generally use a lot less resouces than CF for example. In addition, the write cycle is much faster than external EPROM, SD, CF etc.... If you really want speed, use bytewide (at the expense of more pins)! |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1907
|
|
| Posted: Sat Sep 24, 2005 9:50 pm |
|
|
You can't really get away from the fact that you'll need some PC-side s/w to download & translate the data or at least just translate it. If you went with a simple RS-232 implementation, you can use hyperterminal to download the data, and then use a spreadsheet to import it. Not too convenient for the end user (imagine the user's manual!)
I really like the option of writing data to a compactflash or SD card, but there's one more option: incorporating a USB/RS-232 IC such as the products from FTDI.
If you want maximum user friendliness (for a medical device I'd assume so), then you'd be better off going with USB. Writing the PC side application could be the bottleneck, but it would be worth it to the user to have the convenience of USB, and having the data automatically download to the PC when the device is connected.
Just my $.02. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Sun Sep 25, 2005 6:26 am |
|
|
| JimB, one important question has not been answered yet: how much data are you expecting to be transferring? |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Sun Sep 25, 2005 9:43 am |
|
|
| Quote: | | If you want maximum user friendliness (for a medical device I'd assume so), then you'd be better off going with USB. Writing the PC side application could be the bottleneck, but it would be worth it to the user to have the convenience of USB, and having the data automatically download to the PC when the device is connected. |
In a windows environment, USB is fundermentally flawed for "ease of use" applications. If you reboot a PIC which is connected to a PC then when the PIC reboots, the device is given a differnt handle by windows. In most cases you must close and reopen the application to recover. If you plug the usb device in to a differnt USB connector on the PC then there is an excellant change the USB device will be seen as a different device and you may be required to reinstall the device driver. In the case of an FTDI USB controller with the virtual comm port driver then you may also have to hunt through windows device driver interface to find the "new" comm port associated with the device.
I know I should not generalise over such a broad category but...If you look at what is happening with medical instrumentation today you will notice that Ethernet is pretty much a standard interface wired and/or wireless. IP and sockets (TCP and/or UDP) provide a simple well defined interface for communicating between devices. If you want somethiing more exotic you can deploy HTTP or XML type interfaces.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
kender
Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley
|
|
| Posted: Sun Sep 25, 2005 4:47 pm |
|
|
| ckielstra wrote: | | JimB, one important question has not been answered yet: how much data are you expecting to be transferring? |
... and storing. |
|
|
JimB
Joined: 25 Aug 2005
Posts: 65
Location: Huntington Beach, CA
|
| Data size |
| Posted: Sun Sep 25, 2005 4:55 pm |
|
|
To answer the question regarding the amount of data saved and later transferred - quick calculation says around 10,000 bytes maximum.
I have observed that as a project like this goes on, discussions with the customer keep bringing up new thoughts and the project complexity keeps increasing until the capability of the designer is exceeded.
I really appreciate the help you folks are offering. Imbedded design and programming started off seeming very foreign, but as I move along and keep trying different approaches, things start sinking in. |
|
|
kender
Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley
|
|
| Posted: Sun Sep 25, 2005 5:50 pm |
|
|
| For 10kB you could use MicroChip's 24LC515, which has 512kb=64kB. It's an I2C EEPROM. It supports singe byte writes, which take 5ms, and 64B page-writes, which also take 5ms. CCS provides a driver for it. |
|
|
Joshua Lai
Joined: 19 Jul 2004
Posts: 42
Location: Malaysia, PJ
|
|
| Posted: Sun Sep 25, 2005 7:47 pm |
|
|
| How you know the write time is 5ms? I studied the code and found that the PIC will wait for the eeprom to complete. How about read time? |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Sun Sep 25, 2005 7:48 pm |
|
|
| Joshua Lai wrote: | | How you know the write time is 5ms? I studied the code and found that the PIC will wait for the eeprom to complete. How about read time? |
Cause he read the datasheet  |
|
|
Joshua Lai
Joined: 19 Jul 2004
Posts: 42
Location: Malaysia, PJ
|
|
| Posted: Sun Sep 25, 2005 8:31 pm |
|
|
Byte write: control, address, address, data
1/400kbps x 4 x 8bits = 80 us
How to calculate actually? At least tell me datasheet which part. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
