Searching \ for '[PIC:] Architecture for serial comms in C' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=serial
Search entire site for: 'Architecture for serial comms in C'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Architecture for serial comms in C'
2004\08\20@103910 by Lawrence Lile

flavicon
face
My question is not about how to do serial communications (using CCS C that is relatively trivial) but about the *architecture* used for serial communications, especially receiving characters.
Most of the time, I toss in a few printf's so that my program can tell me what it is doing.  Very rarely is this communication two-way.  
Generally, my C programs have a main loop that calls each subroutine in turn, a status variable that tells us what state the machine should be in, and some interrupts that mostly do timing.  Nothing unusual.  
Generally one of the subroutines is enabled every second or so, and printf's whatever I am interested at the time.  In the current project I am using a software serial port for various reasons, one of which is that CCS's software serial port can be invoked with an INVERT option that makes it squirt directly into a PC serial port without needing a MAX232.  That's handy.
Now if I understand correctly, there are two basic mechanisms for reading serial comms in CCS C.  kbhit() checks whether a start bit is happening now, and getc() waits for a start bit and then reads a character.
Using getc() seems problematic, because IIRC the processor will wait forever for input.  Maybe I am not ready to hit a key just now? Then the nice realtime embedded program is in a wait state instead of driving my robot.  
Using kbhit() seems problematic, because the processor needs to be polling it all the time, chewing up resources.  
So here is the architecture question:  To interrupt or poll?  Put the RX line and interrupt on PortB,0, and use the "external interrupt"? Move it all back to a hardware UART, and use that as an interrupt source?  Or poll it all the time with kbhit() ? How do other people approach this?


-- Lawrence Lile, P.E.
Electrical and Electronic Solutions
Project Solutions Companies
http://www.projsolco.com

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.735 / Virus Database: 489 - Release Date: 8/6/2004

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@104740 by hael Rigby-Jones

picon face
{Quote hidden}

Use interrupts and a circular buffer.  The ISR pulls each byte from the
USART as it arrives and stuffs it into the next location within the buffer.
You main loop code is now free to check the buffer for data when it's good
and ready, and suck the data out in one hit.  You need to size the buffer
according to the incomming data rate and how frequently the buffer will be
checked in you main loop.  You can also use circular buffers for
transmitting data, to free up the PIC after printf'ing something.

Once you have the circular buffer routines written, you can write
replacement getch and putch functions which will then be linked into ant
other I/O handling functions such as puts, gets, printf etc.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@111705 by Olin Lathrop

face picon face
Lawrence Lile wrote:
> So here is the architecture question:  To interrupt or poll?  Put the
> RX line and interrupt on PortB,0, and use the "external interrupt"?
> Move it all back to a hardware UART, and use that as an interrupt
> source?  Or poll it all the time with kbhit() ? How do other people
> approach this?

First, I don't use a compiler, so I don't have some of these problems.  Most
of the time I use interrupt driven UART I/O with software input and output
FIFOs.  The code has been used many times and automatically configures
itself to the target chip and oscillator frequency.  All I do is set the
FIFO sizes and baud rate.  This template code is QQQ_UART.ASPIC at
http://www.embedinc.com/pic.

Once a basic UART input routine exists, there are several options for
reading the input stream.  The code I referred to above sets a global flag
bit whenever something is in the input FIFO.  For simple input streams, I
poll this in the main loop and jump to the event handler only if there is an
input byte so that it is guaranteed not to wait.

The next level up, which is the most common case for 16 family PICs, is an
input stream processing module that implements a pseudo thread.  The event
handler gets envoked from the main event loop only when an input byte is
available.  The event handler reads the byte from the input FIFO and returns
from the GETBYTE macro of the pseudo thread code.  The next GETBYTE
invocation causes a return to the main event loop.  This structure can
greatly simplify parsing an input stream because from the thread's point of
view it goes and "gets" then next input byte when bytes are really coming at
it.  Once all the thread and event handling details have been written, the
input stream handling code is easy to write and clean.  A template for this
is also available in the QQQ_CMD.ASPIC module from the same web page.  You
shouldn't need to mess with the thread handling stuff, just fill in your own
stream parsing code.

The next level up is a pseudo thread that gets run for a timeslice every
time thru the main event loop.  This has a generic YIELD macro where the
return to the event loop is hidden from the pseudo thread.  GETBYTE is a
macro that checks the input FIFO flag and invokes YIELD in a loop until an
input byte is available.  This architecture is a little more complex, but
allows the thread to wait on other events than just an input byte available.

On the 18 family you can implement real threads that call a YIELD subroutine
as apposed to invoking a YIELD macro.  The main difference is that YIELD may
be called nested at a lower level from the top event routine since the stack
can be accessed and the appropriate save/restore performed when the thread
is switched in and out.  To minimize the stack storage space required, I
have a configuration constant that says how many nested levels down the
thread is allowed to call YIELD.  So far I haven't attempted to deal with
the data stack, so nothing may be left on the data stack when YIELD is
called.

On the 30 family full blown true threads (tasks) are easy since the stack is
in regular data memory and is used for both data and return addresses.  So
far all my PIC 30 projects that performed UART I/O have used tasks.  The
code for managing tasks and performing task switching is very simple, due to
the dsPIC's nice architecture.  It is available in QQQ_TASK.DSPIC under the
dsPIC Templates heading on the same web page.

This was probably a lot more than you wanted to hear, but you asked.  As you
can probably gather, I've been down this road dozens of times before.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@112912 by Eisermann, Phil [Ridg/CO]

flavicon
face
pic microcontroller discussion list wrote:
>> So here is the architecture question:  To interrupt or poll?
>> Put the RX line and interrupt on PortB,0, and use the
>> "external interrupt"? Move it all back to a hardware UART, and
>> use that as an interrupt source?  Or poll it all the time with
>> kbhit() ? How do other people approach this?
>
> Use interrupts and a circular buffer.  The ISR pulls each byte from
> the USART as it arrives and stuffs it into the next location within
> the buffer. You main loop code is now free to check the buffer for
> data when it's good and ready, and suck the data out in one hit.

My usual method is similar/nearly identical. I use the hardware RX
interrupt that stuffs the received byte into a buffer. Generally I
use "packets" that is, several bytes of data and a checksum. When
the packet is complete, a bit-flag is set that the main program
acts on when it is ready to do so.


--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@121431 by Jan-Erik Soderholm

face picon face
Hi !

Michael, Phil and Olin,
I think you missed this phrase in Lawrence original post :

"...In the current project I am using a software serial port
for various reasons..."

So the UART-RX interrupt will not work, if I'm not wrong...

Best Regards,
Jan-Erik.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@122000 by Alan B. Pearce

face picon face
>"...In the current project I am using a software
>serial port for various reasons..."
>
>So the UART-RX interrupt will not work, if I'm not wrong...

I hadn't picked up on it, because I skim read the original post.

Perhaps one way to deal with the problem is to have a look at the serial
uart code in the Microchip Pic-C18 compiler library. Even if using another
series of chip, this will give a template of how to do the code.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@122826 by Lawrence Lile

flavicon
face
It is looking like the software serial port presents it's own set of problems.  It might be better to move some pins around and use the hardware UART.  Max232's are not THAT expensive.......

-- Lawrence Lile, P.E.

> {Original Message removed}

2004\08\20@123656 by Carey Fisher - NCS

face picon face
"...In the current project I am using a software serial port
  > for various reasons..."
  >
  > So the UART-RX interrupt will not work, if I'm not wrong...
  >
  > Best Regards,
  > Jan-Erik.

Why not use an Interrupt-on-Change pin for the bit-banged serial input?
Then the serial comm could be interrupt-driven...

Carey Fisher, K8VZ
Chief Technical Officer
New Communications Solutions, LLC
website: http://www.ncsradio.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@140209 by Matt Pobursky

flavicon
face
On Fri, 20 Aug 2004 09:34:29 -0500, Lawrence Lile wrote:
> So here is the architecture question:  To interrupt or poll?  Put the
> RX line and interrupt on PortB,0, and use the "external interrupt"?
> Move it all back to a hardware UART, and use that as an interrupt
> source?  Or poll it all the time with kbhit() ? How do other people
> approach this?

Since you are out of the "squeeze every penny till it screams" consumer
world, make life easy on yourself and just use an interrupt driven
hardware serial port. I know it's a tough attitude to break (been there
and done that myself, having designed consumer gear in the past also).

Virtually all of my designs now have a hardware serial port whether
required or not that can be used for diagnostics and testing. The
difference in pin count and cost of a slightly more capable PIC is
usually a good tradeoff in development time and aggravation. You also
get very little performance hit on the interrupt driven hardware
method. One other thing I also like to do is make sure I've got an
upgrade path to a larger memory PIC of the same footprint/family type
if at all possible. You can develop with the larger part and move down
to a smaller one for production if cost is an issue. You can also move
UP in production if your client/boss etc. decides to add more software
"features" after the initial design. Bet that's never happened to
anyone, right? ;-)

Matt Pobursky
Maximum Performance Systems

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@140417 by Eisermann, Phil [Ridg/CO]

flavicon
face
pic microcontroller discussion list wrote:
> Hi !
>
> Michael, Phil and Olin,
> I think you missed this phrase in Lawrence original post :
>
> "...In the current project I am using a software serial port
> for various reasons..."
>
> So the UART-RX interrupt will not work, if I'm not wrong...
>

But he also asked

"...Move it all back to a hardware UART, and
use that as an interrupt source?..."

He was asking advice about how to best structure the serial
port, and that's what he got :)


--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@142833 by Lawrence Lile

flavicon
face
Yeah, the penny pinching attitude still sticks.  I remember there was some other reason I didn't use the hardware UART on this chip, but I can't remember what is was....  But there are plenty of pins, shouldn't be too tough to move them around.


-- Lawrence Lile, P.E.
Electrical and Electronic Solutions
Project Solutions Companies
http://www.projsolco.com
> {Original Message removed}

2004\08\20@143249 by Dave VanHorn

flavicon
face
At 01:25 PM 8/20/2004, Lawrence Lile wrote:

>Yeah, the penny pinching attitude still sticks.  I remember there was some other reason I didn't use the hardware UART on this chip, but I can't remember what is was....  But there are plenty of pins, shouldn't be too tough to move them around.

Yes.  It's a different kind of stinginess. Stingy with time!
If I'm going to make a million, then the SW cost of the soft uart makes sense.
If I'm going to make 100, then hardware is the only way to fly, unless have soft uart code on the shelf that I really trust.

Maybe that's a good segue into an OT topic, "What's in yer embedded toolbox?"

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@143701 by Marcel Duchamp

picon face
At 11:25 AM 8/20/04, Lawrence Lile wrote:

>Yeah, the penny pinching attitude still sticks.  I remember there was some
>other reason I didn't use the hardware UART on this chip, but I can't
>remember what is was....  But there are plenty of pins, shouldn't be too
>tough to move them around.

BTW, Lawrence, how has life been treating you now that you are "out of the
frying pan and into the fire"?  ;>

MD

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@152034 by Matt Pobursky

flavicon
face
On Fri, 20 Aug 2004 13:34:10 -0500, Dave VanHorn wrote:
> Yes.  It's a different kind of stinginess. Stingy with time! If I'm
> going to make a million, then the SW cost of the soft uart makes
> sense. If I'm going to make 100, then hardware is the only way to
> fly, unless have soft uart code on the shelf that I really trust.
>
> Maybe that's a good segue into an OT topic, "What's in yer embedded
> toolbox?"

A really excellent idea! Later tonight or this weekend when I get a
chance to think about it, I'll contribute to that message thread. As a
consultant where time truly IS money, it's a subject near and dear to
my heart (and pocketbook).

Also including a little information about your design philosophy in
general would be good -- it really does vary based on whether you're a
hobbyist, student, consultant, salaried engineer and which particular
industry you work.

Matt Pobursky
Maximum Performance Systems

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@191005 by William Chops Westfield

face picon face
On Aug 20, 2004, at 7:34 AM, Lawrence Lile wrote:

> So here is the architecture question:  To interrupt or poll?  Put the
> RX line and interrupt on PortB,0, and use the "external interrupt"?
> Move it all back to a hardware UART, and use that as an interrupt
> source?  Or poll it all the time with kbhit() ? How do other people
> approach this?
>
If you can't have actually interrupt-driven IO (which is ideal, but can
be a bit tricky to implement on a bit-banged serial port), what you
probably want is a getc_wait(timeout) function:
       getc_wait(int timeout)
    {
           int then = currenttime()+ timeout;
           while (currenttimer < then) {
                   if (kbhit()) {
                          return getc();
                       }
               }
       }

this is what parallax's basic-stamp "serin" does, isn't it?

BillW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\23@115744 by Lawrence Lile

flavicon
face
Well, the Fire is pretty warm and comfy these days.  
Project Solutions, as of today, is purely building systems design, and I run the electrical engineering department.  The cobwebs are starting to disappear on the NEC, which I could quote chapter and verse at one point in my life, and other electrical power stuff.  Just got done designing the feeder for a chiller that runs at 4160V  and consumes 1.3 megawatt.  Now I have to come up with an energy metering package for it.  
We are busy, but not too busy.  Most days I go home at 5:00 and forget this place existed for 14 hours or so.  
We are working our contacts and trying to find electronics and controls work.  We have a real good contact in the food processing industry who does custom controls and sensors for extreme environments (think "Ammonia exposure" "grease" "-40F" and "180F washdown duty" all in the same sensor!) which might turn into some work. Several other contacts have said "well we might have a project for you in XXX months".  So far this has not produced much, which is exactly what I expected so I am pleased.
My next assignment is to put together a web page detailing electronics capabilities.  I have been snooping other PIClister's pages for ideas and approaches, bad and good examples.  Hope y'all don't mind!  



-- Lawrence Lile, P.E.
Electrical and Electronic Solutions
Project Solutions Companies
http://www.projsolco.com
> {Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...