Writing interrupt driven circular buffer

[Sven]

Can someone point out source code for a safe circular buffer receiver
transmitter? It's for sending and receiving bytes via RS232.

Thanks in advance.

 

[Sjouke Burry]

Can someone point out source code for a safe circular buffer receiver
transmitter? It's for sending and receiving bytes via RS232.

Thanks in advance.

http://home.planet.nl/~burry004/COMPORT.ZIP
Does not need an interrupt, does need port access, and you can
modify it to your harts desire.

 

[Peter Pichler]

Can someone point out source code for a safe circular buffer receiver
transmitter? It's for sending and receiving bytes via RS232.

Thanks in advance.

Sven,

What you ask for is off-topic on comp.lang.c. Things like interrupts,
receivers, transmitters and RS232 are platform dependent and hence not
covered by the ISO/ANSI C Standard. Your best bet is finding a newsgroup
that discusses your platform.

It is all covered in the FAQ, which can be found at http://c-faq.com/

Your question pertains to Qs 19.7 and 19.40b, but I recommend reading
the whole section 19.

<off-topic>
When I was doing something like that back in '96, I found great help in
a book "Serial Communication" by Peter W Gofton, SYBEX Inc., 1994. It
covers DOS and Windows (but see the publishing date). I am sure there
are better and more up-to-date books available now.
</off-topic>

Good luck,
Peter

 

[CBFalconer]

Can someone point out source code for a safe circular buffer
receiver transmitter? It's for sending and receiving bytes via
RS232.

All you need to do is disable interrupts (or their equivalents)
before altering the counters and flags.

 

[Flash Gordon]

Sjouke Burry wrote, On 28/10/07 00:53:

http://home.planet.nl/~burry004/COMPORT.ZIP
Does not need an interrupt, does need port access, and you can
modify it to your harts desire.

That code is highly DOS specific. Since it has function definitions
(rather than declarations) in a header file I would also suggest it is
badly written.

Sven would be best asking somewhere like comp.arch.embedded and
specifying what his target is and rather more about his requirements. I
know how I've implemented serial communications and it has been
radically different depending on what the processor was capable of and
what the requirements were.

 

[Ark Khasin]

All you need to do is disable interrupts (or their equivalents)
before altering the counters and flags.

In fact, you don't, if volatile (and of course atomic) read and write
indexes are modified exclusively by the read routine and the write
routine respectively. Good encapsulation saves messing with disabling
interrupts.

 

[CBFalconer]

In fact, you don't, if volatile (and of course atomic) read and
write indexes are modified exclusively by the read routine and
the write routine respectively. Good encapsulation saves messing
with disabling interrupts.

No it doesn't. Consider, for example, something with multiple
readers and one transmitter.

 

[Ark Khasin]

No it doesn't. Consider, for example, something with multiple
readers and one transmitter.

And... what those multiple readers would end up reading?

 

[CBFalconer]

And... what those multiple readers would end up reading?

For example, the keyboard. How else can the single keyboard be
attached to various processes?

 

[Peter Pichler]

For example, the keyboard. How else can the single keyboard be
attached to various processes?

This is deeply in the OT-land, but... I doubt the multiple processes
read a single keyboard simultaneously. Usually only one process at a
time has a keyboard focus. Even if they *do* all receive keystrokes,
they do so via some queueing mechanism. They do *not* access the
keyboard directly.

 

[Jack Klein]

In fact, you don't, if volatile (and of course atomic) read and write
indexes are modified exclusively by the read routine and the write
routine respectively. Good encapsulation saves messing with disabling
interrupts.

Actually, no, that's not always true. I've seen this done wrong many
times. In fact, I've had to fix other people's code that got this
wrong several times.

The biggest vulnerability, and easiest place to code an error, is when
an index needs to wrap around.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Ark Khasin]

Actually, no, that's not always true. I've seen this done wrong many
times. In fact, I've had to fix other people's code that got this
wrong several times.

The biggest vulnerability, and easiest place to code an error, is when
an index needs to wrap around.

Sure. Below is a sketch of an implementation that doesn't require
disabling interrupts, assuming one read agent and one write agent and
that unsigned is atomic.
Is there a problem with it?

//conventions:
//empty buffer: writex==readx
//full buffer: (writex+1)mod(buffer size) == readx
static volatile unsigned readx, writex; //indexes, init to 0
static unsigned char mybuf[MYSIZE];
static unsigned inx(unsigned x)
{
return (x+1)%MYSIZE;
}
int isempty(void) {unsigned r=readx, w=writex; return r==w;}
int isfull(void) {unsigned r=readx, w=writex; return r==inx(w);}
int readfrombuf(void)
{
if(isempty()) return BUFFER_EMPTY;
unsigned r = readx;
int ret =mybuf[r];
readx = inx(r);
return ret;
}
int writetobuf(unsigned char val)
{
if(isfull()) return BUFFER_FULL;
unsigned w = writex;
mybuf[w] = val;
writex = inx(w);
return BUFFER_OK;
}

 

[karthikbalaguru]

Can someone point out source code for a safecircularbufferreceiver
transmitter? It's for sending and receiving bytes via RS232.

But why would you use a circular buffer here ?
Any advantage ? What is your requirement here ?

Karthik Balaguru