Searching \ for '[PIC]:hardware UART on the 16F877' 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/devices.htm?key=16F
Search entire site for: 'hardware UART on the 16F877'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:hardware UART on the 16F877'
2002\11\10@042932 by c Scheepers

flavicon
face
part 1 808 bytes content-type:text/plain; (decoded quoted-printable)

Hi all,

I got this code of the net so that I can explore using the hardware UART on the 16F877. I tried to compile this but the problem is I am getting
       Error 151 Operand contains unresolvable labels or is too complex.

on the following lines.
       
        aligned        SET     pow2&&((base&(size-1))==0)

               if      (aligned&&!(base&(1<<bit)))

and various others.

Why does it not moan on the following line :

       pow2    SET     !(size&(size-1))


I have looked up in help in the MPLAB help but it is not much help. I have included the full code as is. Maybe it can also help somebody else to get to the bottom of hardware UART after getting past this compiler problems.

Regards

Nic Scheepers


part 2 15186 bytes content-type:application/octet-stream; (decode)

part 3 131 bytes
--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\11\10@095004 by Dennis Crawley

flavicon
face
Hi Nic,
I have compiled your asm with put any problem unless I
haven't "membank.inc" file, but I assume it has bank
issues.

It seems you didn't respect the directive column
order. Also you forgot to declare that radix IS
decimal for that kind of macro code.... (Famous Eric
Smith uh?)

Insert this line after the processor definition:
radix dec

I hope that's all abt.

Regards,
Dennis Crawley
http://www.geocities.com/proyectosenpic



From: "Nic Scheepers"
<spam_OUTnic.scheepersTakeThisOuTspamLOGICALSOLUTIONS.CO.ZA>


Hi all,

I got this code of the net so that I can explore using
the hardware UART on the 16F877. I tried to compile
this but the problem is I am getting


on the following lines.

        aligned        SET
pow2&&((base&(size-1))==0)

               if      (aligned&&!(base&(1<<bit)))

and various others.

Why does it not moan on the following line :

       pow2    SET     !(size&(size-1))


I have looked up in help in the MPLAB help but it is
not much help. I have included the full code as is.
Maybe it can also help somebody else to get to the
bottom of hardware UART after getting past this
compiler problems.

Regards

Nic Scheepers


Cobertura especial de la Copa Mundial de la FIFA Corea-Japsn 2002, sslo en Yahoo! Deportes:
http://ar.sports.yahoo.com/fifaworldcup/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\11\10@110437 by Olin Lathrop

face picon face
> I got this code of the net ...

Looks like you got about what you paid for it.  I don't know who this Eric
Smith guy is that claims to have written it, but I would stay away from
anything else that has his name on it.  There are too many individual
things I don't like in that code to list here, so here are just a few
highlights:

> ; Copyright 1997 Eric Smith

Consider this a warning message.

{Quote hidden}

Good thing it's so well commented!

>
;-------------------------------------------------------------------------
----
> ; ram
>
;-------------------------------------------------------------------------
----
>
>   org rambase
>
> ; interrupt state save
> irqw:  res 1  ; must be in same loc in both banks

Actually it needs to be in all *4* banks, because that's how many the
16F877 has, which this code was apparently written for given the LIST
directive above.

> ramb2  equ ($ + 80h)

This is apparently an attempt to make sure the offset of IRQW is reserved
in all banks, although doing this without a comment is just plain
irresponsible.  Apparently his strategy is to start using other banks at
RAMB2, which will guarantee that the offset of IRQW is not used in the
other banks.  However, this assumes that the general registers start at
the same offset in all banks, which is not the case for many PICs.  On the
18F877 general registers start at offset 10h in banks 2 and 3 instead of
20h as in banks 0 and 1.  That will cause wasted space in this case.  On
other PICs, it could cause collision with special function registers.

The immediately following code defines his variables, although there is
not a single comment explaining what any of them are for.  I won't bother
repeat his mess here.

{Quote hidden}

This needlessly uses up an additional call stack location that will not be
available anywhere else an interrupt could occur.  It is a good idea to
keep stack useage within an interrupt to the minimum you can manage.

>  btfsc PIR1,TXIF
>  call txint

>
;-------------------------------------------------------------------------
----
> ; UART receive interrupt
>
;-------------------------------------------------------------------------
----
{Quote hidden}

Finally a few comments, although there is a lot more that could use
explaning.  This routine will only work if everything goes right.  If a
UART overrun ever occurs, it will never recover.  There is also no
handling of framing errors.

I could go on, but that would be pointless.  Just because something is on
the web doesn't make it correct.  If you want to see properly written
interrupt and UART routines, go to http://www.embedinc.com/pic and check
out the QQQ_INTR.ASPIC and QQQ_UART.ASPIC template modules in particular.
There are also a bunch of FIFO manipulation macros and lots of other stuff
in STD.INS.ASPIC.  And, the license is much less restrictive in that you
are allowed to use this code in a commercial product at no charge.


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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\11\10@134425 by Scott Dattalo

face
flavicon
face
On Sun, 10 Nov 2002, Olin Lathrop wrote:

> > I got this code of the net ...
>
> Looks like you got about what you paid for it.  I don't know who this Eric
> Smith guy is that claims to have written it, but I would stay away from
> anything else that has his name on it.  There are too many individual
> things I don't like in that code to list here, so here are just a few
> highlights:
>
> > ; Copyright 1997 Eric Smith
>
> Consider this a warning message.

Chuckle.

Eric Smith is a genius. He's done stuff with PICs that you and most others
can only dream about. I won't even try to defend this copy of code
you have criticized. Chances are, it was written 8+ years ago and last
touched 5 years ago (1997). It was probably written for the 16C64 at a
time the 16F84 was just becoming popular and the F877 was some Microchip
Engineer's fantasy.

Check out the OJ Muta-matic.

---

I can say one thing in agreement with you- I've yet to see a decent free
UART driver for the PIC on the web. Even Fr. Thomas McGahee's, which is
the best I've seen, has some problems when applied to real systems. His is
really intended as a Tutorial - and it is excellent in that regard. It
points out many of the pit falls associated with interfacing with PIC's
USART. But for a real system where serial data is coming in and going out
while the PIC is busy doing stuff, you need to be able to handle these
tasks simultaneously. There are many approaches to this problem, and
depending on the system requirements each has its merit. I tend to prefer
interrupt driven code with circular buffers for the transmit and the
receive processes. If memory is an issue, then polled drivers may be more
appropriate. Maybe someone one day will release a driver based on his
code...


Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\11\10@163011 by Olin Lathrop

face picon face
> I can say one thing in agreement with you- I've yet to see a decent free
> UART driver for the PIC on the web. Even Fr. Thomas McGahee's, which is
> the best I've seen, has some problems when applied to real systems. His is
> really intended as a Tutorial - and it is excellent in that regard. It
> points out many of the pit falls associated with interfacing with PIC's
> USART. But for a real system where serial data is coming in and going out
> while the PIC is busy doing stuff, you need to be able to handle these
> tasks simultaneously. There are many approaches to this problem, and
> depending on the system requirements each has its merit. I tend to prefer
> interrupt driven code with circular buffers for the transmit and the
> receive processes. If memory is an issue, then polled drivers may be more
> appropriate. Maybe someone one day will release a driver based on his
> code...

I have, as I said in the very message you responded to.  See the UART
template module at http://www.embedinc.com/pic.  I've used this code with
occasional customization in several commecial projects.


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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\11\10@164917 by Mike Singer

picon face
Salut PicList, c'est encore moi!
Salut, comment tu va?
.....................................................

Scott Dattalo wrote:
{Quote hidden}

Polling sure is a sometimes thing. I've come to this
in my recent project: PC controlling some hardware
through PIC by RS232.

My PIC's software consists of few dozens modules, which
are launched one after one continuously. Some register
holds "handle". When current module sees "its" active
handle, it transmits byte of his data to send, then deactivates
the handle. The handle is incremented and activated by
first module of the loop over some fixed number of polling
steps to ensure that bytes are not send "too often" to PC.

The second module of the loop monitors incoming bytes
checking RCIF of the PIR1. When byte has come, it
receives it into some register and places the handle into
another register, getting it from the incoming context. So
the module associated with this handle can process the
byte.

A fare amount of redundancy (continuous transmission,
context expenses) helps fault tolerance.
Regular transmission could easily be monitored by scope
and non-real-time MS Windows could be more predictable,
as for me in my particular case.

Mike. (Just my 2 uninterruptable coins :-)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\11\10@170613 by Mike Singer

picon face
Just adding to my previous posting:

PC is allowed to send bytes back to PIC only
at "on-event" events when receiving bytes
from the PIC.
This ensures all the bytes from PC can be
processed by PIC.

Mike.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\11\10@191150 by William Chops Westfield

face picon face
   > I got this code of the net ...

   Looks like you got about what you paid for it.  I don't know who this Eric
   Smith guy is that claims to have written it, but I would stay away from
   anything else that has his name on it.


   > ringadv macro ptr,base,size
   >  local pow2,aligned,bit,val
   > pow2 SET !(size&(size-1))
   > aligned SET pow2&&((base&(size-1))==0)
   >
   >  if aligned
   > val set size
   > bit set 0
   >  while val>1
   > bit set bit+1
   > val set val>>1
   >  endw
   >  endif
   >

   Good thing it's so well commented!

Indeed.  An interesting example of portability (or the lack thereof.)  In an
effort to make the code portable/usable on a wide variety of PICs (circa
1997) with assorted memory layouts, it has become all but incomprehensible
to anyone who couldn't have written their own code in the first place.
Obscure and powerful conditional assembly; Oh My!  Add five years an another
generation or two of PICs and it loses much of it's utility.  :-(

I'd blame this on assembler, except I see the same sort of thing ALL THE
TIME with C programs from a certain era.  Lovely incomprehensible make files
and preprocessor directives so that the code will compile under 4.2BSD, AT&T
SysV, SunOS 3.2, HP SysV, MSDOS using turbo-C, MSDOS using MS C, etc.  Try
to figure out what needs to be done in a modern Posix/windows environment,
and you're lost unless you're not only a unix wizard, but also a wizard in
at least one variety of obsolete unix :-(

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\11\10@235311 by c Scheepers

flavicon
face
Thanks guys,

I will go and look at the URL Olin send me, but your comments are appreciated very much.
Thanks again

Regards

Nic Scheepers



> {Original Message removed}

2002\11\11@002927 by c Scheepers

flavicon
face
Hi all,

I just realised that I made a big mistake with the email I sent out earlier asking for help on the uart program. I just realised I sent out the version that I dabbled with to get it working on the 16F877 where it was previously written for the 16C65.

I knew there will be bank problems with the conversion it was just these "$"'s he used in the program that caused the compiler to give errors. Can someone in short tell me how to use the macros giving the problems especially the "$" which has something to do with the program counter, but how does the linker know what the counter is going to be at link time.

Once again my appologies to you and Eric Smith for doing him wrong and let you believe it is his code that I sent out.

Regards

Nic Scheepers

> {Original Message removed}

2002\11\11@005048 by c Scheepers

flavicon
face
part 1 5019 bytes content-type:text/plain; (decoded quoted-printable)

Oh I forgot to send the right one, but here it is.

Regards

Nic Scheepers


> {Original Message removed}
part 2 14950 bytes content-type:application/octet-stream; (decode)

part 3 136 bytes
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2002\11\11@052110 by o-8859-1?Q?Tony_K=FCbek?=

flavicon
face
Hi,

Nic Scheepers wrote:
<snip>
>I knew there will be bank problems with the conversion
>it was just these "$"'s he used in the program that caused
>the compiler to give errors. Can someone in short tell
>me how to use the macros giving the problems especially the
>"$" which has something to do with the program counter, but
>how does the linker know what the counter is going to
>be at link time.

"$" evaluates to current adress at assembly time, for example:
(16x series)

       DECFSZ  Counter,F       ; adress 0xAAA0
       GOTO    $-1                     ; adress 0xAAA1, $=0xAAA1 - 1 =
0xAAA0 at assembly.

which can be written as :

TIMER_LOOP                              ; an label with adress 0xAAA0
       DECFSZ  Counter,F       ; adress 0xAAA0
       GOTO    TIMER_LOOP              ; adress 0xAAA1, $=0xAAA1 - 1 =
0xAAA0 at assembly.


On the other subject the buffer macro's,
I think you are using this 'macro' (or something similar):


;+++++
;       INC_BUFFER advance buffer pointers wrap if necessary ;
;       If buffer size is power of two, and buffer is aligned
;       on an multiple of twice it size, this macro generates
;       two instructions, Otherwise it generates six instructions.
;       Originator:  Eric Smith, ericspamKILLspambrouhaha.com for non-comercial
use.

INC_BUFFER MACRO        Pointer, Base, Size        
       LOCAL   POWER_OF2, ALIGNED,BIT,VALUE

POWER_OF2       SET     !(Size&(Size-1))
; calculate if power of 2
ALIGNED SET     POWER_OF2&&((Base&(Size-1))==0) ; calculate if powerof 2
and aligned

       IF      ALIGNED

       ; if code is aligned and power of 2, calculate which bit we need
to clear for wrap around 'feature'

VALUE   SET     Size
BIT     SET     0       ; set lowest bit

       WHILE   VALUE>1
BIT     SET     BIT+1    ; 'move' bit towards msb
VALUE   SET     VALUE>>1         ENDW

       ENDIF

       INCF    Pointer,F       ; increase pointer

       IF      ALIGNED&&!(Base&(1<<BIT)) ; if the buffer is aligned,
power of 2 then we can
                                     ; get wrap around feature by
clearing the size+1 bit of the pointer
       BCF     Pointer,BIT     ; yep clear bit
       ELSE
       ; the buffer is not suitable for 'fast' wrap around, we need to
check for buffer
     ; wrap around by xor'ing buffer max with current pointer and set
to start buffer if nessesary.
       MOVF    Pointer,W       ; nope
       XORLW   Base+Size
       MOVLW   Base
       BTFSC   STATUS,Z
       MOVWF   Pointer
       ENDIF

       ENDM

Now the reason for why this is not working is related to the assembler
and
not the actual 'code'. Let's analyze what this 'macro' does:
INC_BUFFER MACRO        Pointer, Base, Size        

At entry we have current pointer (offset in buffer), buffer base adress
( start of buffer in ram)
and the size of the buffer.

POWER_OF2       SET     !(Size&(Size-1))
; calculate if power of 2

This will evaluate to '1' (true) if the size of the buffer is power of
2,
else it will evaluate to '0'.


ALIGNED SET     POWER_OF2&&((Base&(Size-1))==0) ; calculate if powerof 2
and al

This will evaluate to '1' if:
- Buffer size if power of 2
- end buffer adress is power of 2
Else it will evaluate to '0'.


VALUE   SET     Size
BIT     SET     0       ; set lowest bit

       WHILE   VALUE>1
BIT     SET     BIT+1    ; 'move' bit towards msb
VALUE   SET     VALUE>>1         ENDW

This will calculate which bit number is 'overflow' for the buffer, i.e.
when we try to increase the buffer pointer, at some point we will reach
the end and overincrement.
As I said the assembler used to accept these calculations, however the
lastest
incarnations of it it have started to not accept these 'complex'
agruments,
I think it's a really bad practice by Microchip to change this
behaviour. There's nothing 'wrong' with above code, it used to work but for some
reason
the have ommited some functionality in the lastest assembler versions. Ok there was one thing lacking in the original code and that was
comments,
but that is not realted to your problems (directly anyway).
I've also had code there i did adress calulcations etc, which have
stopped working
just beaciuse of assembler 'upgrades' and it's really tedious work to
get them
accepted again.

Ponder these statements:

       CBLOCK  0x0C
       VariableStack:10
       ENDC

; macro to add an 16 bit literal to an 24 bit destination
; pointer to MSB of destination at entry.

ADD_16L_TO_24 MACRO     ARG_16_LITERAL,ARG_DEST_24
       
       MOVLW   LOW(ARG_16_LITERAL)
       ADDWF   ARG_DEST_24+2,F ; add lowest byte's                  
       MOVLW   LOW(ARG_16_LITERAL>>8)
       SKPNC                           ;  if overflow
          INCFSZ       WREG,F  ; increase source                 ADDWF   ARG_DEST_24+1,F ; and add to dest.
       SKPNC
       INCF    ARG_DEST_24,F ; handle 16 bit overflow

       ENDM

Now this works if used like:

       ADD_16L_TO_24 0xFF01,VariableStack

But not like:

       ADD_16L_TO_24 0xFF01,VariableStack+5

Beacuse it will evaluate to (example):

       ADDWF   (VariableStack+5)+2,F   ; add lowest byte's  
This is now 'to complex' for the assembler.

( the above code is not tested, it was just written to convey an
example of assembler quirks)

/Tony

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2002\11\11@053603 by c Scheepers

flavicon
face
Thanks a lot Tony,

I will go through this thoroughly and to use it as a sort of tutorial in macro coding:-)

Regards

Nic Scheepers


> {Original Message removed}

2002\11\11@055120 by Alan B. Pearce

face picon face
>I can say one thing in agreement with you- I've yet to see a decent
>free UART driver for the PIC on the web. Even Fr. Thomas McGahee's,
>which is the best I've seen, has some problems when applied to real
>systems. His is really intended as a Tutorial - and it is excellent
>in that regard. It points out many of the pit falls associated with
>interfacing with PIC's USART. But for a real system where serial data
>is coming in and going out while the PIC is busy doing stuff, you need
>to be able to handle these tasks simultaneously. There are many
>approaches to this problem, and depending on the system requirements
>each has its merit. I tend to prefer interrupt driven code with
>circular buffers for the transmit and the receive processes. If memory
>is an issue, then polled drivers may be more appropriate. Maybe someone
>one day will release a driver based on his code...


Hmm, converting the polled drivers to use the Fifo's and interrupts was
pretty simple. I had no trouble converting Fr. McGahee's code to interrupt
driven module, using Olin's macros. Has been working quite happily for me at
19.2kb, while the processor is simultaneously handling I2C and timer
interrupts. Perhaps it is because I was determined to stick within the
modular methods of Olin's development modules, that it worked out pretty
easily for me.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2002\11\11@084237 by Olin Lathrop

face picon face
> Can someone in short tell me how to use the macros giving
> the problems especially the "$" which has something to do
> with the program counter, but how does the linker know what
> the counter is going to be at link time.

"$" in the source code stands for the address of the current instruction.

The linker knows because it's doing the placing.  If anything, you might
wonder how the assembler knows.  The answer to that is that it doesn't, it
just passes the problem to the linker.

This is all very basic relocatable linker stuff, and not specific to PICs.
(In fact the PIC linker is on the dumb side of the spectrum.)  I'm sure
there have been volumes written about this subject.  Check out some
undergraduate computer science texts or maybe the documentation for a
relocatable binary format.


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

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2002\11\11@110924 by Thomas C. Sefranek

face picon face
> -----Original Message-----
> From: pic microcontroller discussion list
> [@spam@PICLISTKILLspamspamMITVMA.MIT.EDU]On Behalf Of Olin Lathrop
> Sent: Monday, November 11, 2002 8:42 AM
> To: KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
> Subject: Re: [PIC]:hardware UART on the 16F877
>
>
> > Can someone in short tell me how to use the macros giving
> > the problems especially the "$" which has something to do
> > with the program counter, but how does the linker know what
> > the counter is going to be at link time.
>
> "$" in the source code stands for the address of the current instruction.
>
> The linker knows because it's doing the placing.  If anything, you might
> wonder how the assembler knows.  The answer to that is that it doesn't, it
> just passes the problem to the linker.

Olin,

Can this be right?
The assembler resolves my $ just fine.
Are you saying the assembler call the linker even if I have not?
{Quote hidden}

 |  __O    Thomas C. Sefranek   spamBeGoneWA1RHPspamBeGonespamARRL.NET
 |_-\<,_   Amateur Radio Operator: WA1RHP
 (*)/ (*)  Bicycle mobile on 145.41, 448.625 MHz

hamradio.cmcorp.com/inventory/Inventory.html
http://www.harvardrepeater.org

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2002\11\11@113622 by Olin Lathrop

face picon face
> > "$" in the source code stands for the address of the current
instruction.
>
> Can this be right?
> The assembler resolves my $ just fine.
> Are you saying the assembler call the linker even if I have not?

The assembler doesn't automatically call the linker.  Any time the
assembler doesn't know the exact final address, it writes a relocatable
record to the object file.  This is the case with anything that isn't
wired to a hard address, which is any section where a fixed address wasn't
supplied in front of the UDATA, CODE, etc, directive.  The linker
eventually resolves the placement of each section, and can then compute
the absolute address for all the relocatable records written by the
assembler.  This is the essence of what a linker does.

Of course things are a bit different when the assembler is run in
"absolute" mode, but hopefully that isn't used much anymore these days.


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

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


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