Serial Port

[Charlied]

As a newbie I need a little help.
The issue I want to solve is to do with the serial port.
Consider incoming data stream a little like a dripping tap and the water being collected into a bucket. As the bucket fills I want to swap the bucket for a new and empty one whilst I work on the older full bucket.
So at some point in time I would like to swap the incoming serial buffer for an new empty buffer and then work on the data on the swapped out buffer. Is there any way of moving the new input buffer to a new memory location so that i can work on the old buffer? I would like to do this using pointers as I think that this is probably the quickest way of moving the data. The data in the buffer will be around 16Kb
BTW what is the max size for the individual serial port buffers?
Ideally I would want this to work both under Windows and linux.
Any constructive help or comments would be welcome.

[FihmpenRouk]

I would handle the serial buffer size as the convenient time slices to take care of the incoming data. Perhaps every 50 ms or so, depending on what the rest of the program should do.

Each time slice a routine empties that buffer to some work buffer for the handling you mention.

So, no need to change the buffers connected to the library. I guess that buffer is there not to demand intense watching for new data. Use your own buffer and copy to it with copymem().

So, in bucket terms. Give one bucket to the library to drip in. Have your own bucket to empty the other bucket in when convenient for you with consideration to the buckets sizes and data stream speed.

Oh, and I think the buffer size is only limited to memory size since I believe it's something used by the library, not the hardware.

[Rook Zimbabwe]

I would dump the buffer to a temp file and manipulate it therein... but it would depend on what data you were collecting as to how effective this would be or usseful...

Basically every 16k you wanna make a new buffer and play with the old one. With current speeds on most machines this is gonna fill up really fast!!! My old 286 handled 16k extremely fast so todays Athlon 64 6 CORE would be a picosecond!!! (gross exaggeration but it would be FAST!!!)

{{EDIT}}
The new PB4.5 is out!
There are improved array features like:

- Added: Support for Array, List, Map inside structures
- Added: CopyList(), CopyMap(), CopyArray()
- Added: FreeList(), FreeMap(), FreeArray()

So usse an array!!! I love arrays... then you can copy the arry to a new array and continue to recieve on the first one!

[Baldrick]

Maybe useful to you, maybe not. It should give you some idea of how to go about reading stuff from a serial port. At the end of the day, it all depends on exactly what it is you are trying to read, how the port functions with handshaking, etc. So a bit hard to answer without knowing these things.
http://88.191.63.41/english/viewtopic.php?f=13&t=33620

[Charlied]

Thank you for your replies.
A little more meat to the issue.
Serial port (real one not usb!) talking to up to 12 micros doing some data logging.
9600 baud, 8bit, no parity, 1 stop bit, no hand shake.
Interface is special double isolated half duplex current bus. (looking for 1kv isolation)
Pc sends out a 7 byte command (~7.3mS)
Turns round the bus (0.5mS)
waits for response from specific micro, Micro response time is (~1mS)
Micro returns up to 54 byte message (~56mS)
Allow 2mS for jitter and delay
Total loop time 67ms
12 micros to be scanned every 1 second.
Bus idle time is 196 mS total (~16mS X 12) per second

Processing of data has to be split up into small mini tasks as the PC commands have to be sent out on a regular basis (not relying on OS for accurate timing!)

System to record continuously (ie at least for 3 months)

PC to display "Digested" data on local screen.
All data recorded to local flash memory ( used as 1 month circulating buffer as the sites are "remote" and we need backup if the net connection goes down - and time to get to the site!)
PC to batch up data blocks, compress and deliver to FTP site every 10 mins.
Data is mainly limited text data ($ # ! & * % and hex ) so compression is good at least 5:1 say 80K every 10 mins.

We have a similar system working under DOS but have problems that it is not multi tasking and gets hung up on FTP delays and resends

[Baldrick]

Serial port (real one not usb!) talking to up to 12 micros doing some data logging.
9600 baud, 8bit, no parity, 1 stop bit, no hand shake.
Interface is special double isolated half duplex current bus. (looking for 1kv isolation)

So you have a multidropped serial set up, in effect, sort of like a poor mans Rs485 system.
My guess is you will have a dip switch on each unit to set an address. ( most probably a 4 way dip switch allowing up to 16 units)

Pc sends out a 7 byte command (~7.3mS)

Most liekly more a case of the pc sends out an ascii string command sequence something like
xxCpp, where xx will be the individual address, C will be the command & pp will be general parameters.

Micro returns up to 54 byte message (~56mS)

As the communication was initiated by your pc, you will already know which unit it has come from &
the reply will have some format which you should be able to narrow down quite easily.

12 micros to be scanned every 1 second

you will have around +80ms total for each call, so at 9600bps that is very easy
There will more than likely be some sort of end of message character sent from the unit anyway
so parsing will be no problem.

Processing of data has to be split up into small mini tasks as the PC commands have to be sent out on a regular basis (not relying on OS for accurate timing!
PC to display "Digested" data on local screen

See about parsing above, your messages can be processed & placed into say an editor gadget for display, while at the same time being split into individual items & placed into a flat file or database file.

PC to batch up data blocks, compress and deliver to FTP site every 10 mins.

Purebasic has native Ftp command set, so this can also be done on the fly while your rs232 is running

Data is mainly limited text data ($ # ! & * % and hex ) so compression is good at least 5:1 say 80K every 10 mins.

You are dealing with serial communications, so there is a pretty good chance you are dealing with standard ascii
(ansi) strings. - ( See the ascii table in the PB tools. )