Help needed with buffering serial data

[StevenO]

Hi all

I'm a student from the Technical University of Denmark, currently writing my bachelorproject about a x,y,z-foilwelder. I have to make the machine autonomous with 3-4 PIC's (18F2680) and a bunch of electronic devices (stepmotors, motordrivers, pneumatics, psu's).

I'm currently working on the user input interface which have to USB sticks. I've bought 2 embedded USB host controllers: Vinculum VDIP1 and GHI Electronics uALFAT-USB. I'm working with the VDIP1 right now.

My questions is how to buffer the input data. I'm dealing with .plt (plain ASCII text) files on a USB stick containing data in the following format:

PU15098 18141;
PD15098 18141;
PD15153 18137;
PD15207 18125;
PD15259 18106;
PD15308 18079;
PD15355 18046;
PD15400 18007;
PD15441 17962;
PD15480 17911;
PD15515 17856;
PD15546 17795;
PD15573 17731;
PD15596 17663;
PD15614 17591;
PD15627 17516;
PD15636 17439;
PD15638 17359;

These data follow the Hewlett Packard file protocol standard for plotters.

I've hooked up VDIP1 with a HyperTerminal on a PC through a RS232 level converter with UART, just for testing the included commands and getting to know the device. Everything works fine, and i'm reading the data to the monitor.

Now I have to make a PIC18F2680 recieve the data as written above. How is this done? I'm using CCS compiler PCH (newest) with MPLab 8.43 IDE and a PICKit 2 programmer.

Since the data are sent as chars over the UART, can i then use the fgets (i'm using streams)? I fear that i have to use an external eepromm to store the plotterdata?

Thanks on behalf - Great forum btw!

Best regards
Steven

[Ttelmah]

If you look at input.c, you will find the code for a slightly improved version of 'gets' (which prevents problems if the strings are longer than expected....). The code for this is pretty basic.
Now, ex_sisr.c, shows how to implement an interrupt driven serial buffer.
Put the two together, and you have the basis for a buffered gets, which will potentially allow your code to carry on doing other jobs, while waiting for the string to complete.

Best Wishes

[StevenO]

Thanks alot Ttelmah. I was actually aware of both input.c and ex_sisr.c (from another thread), but it's nice to confirm that they are the things I have to mess with.

Actually I've made a test program based on these 2 things, but I think I'm facing a problem with the amount of chars to be logged/buffered. I can only make a char or int8 array of about 3000 elements, before running out of RAM (since the plotter jobs are different, I can't tell the upper limit for the array).

Therefore I've ordered an external 256kbit i2c eeprom, to deal with this. My plan is to buffer/log on line at a time, analyse it and transfer the result into this eeprom.

Best regards
Steven

[Ttelmah]

If you can cancel/change the order, switch it to an FRAM instead.....

Problem with EEPROM, is that writes are slow. Typically 4mSec. Now it is possible partially to 'get round' this, by using block writes, but it increases complexity. FRAM, behaves just like EEPROM, except that it completes the write immediately. Faster than you can clock the data.

Best Wishes