Searching \ for 'LED mvong message.' 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/displays.htm?key=led
Search entire site for: 'LED mvong message.'.

Truncated match.
PICList Thread
'LED mvong message.'
1996\10\28@012257 by Werner Terreblanche

flavicon
face
Andres


>I'm working on a project that's quite long (about 10K lines of code)
>for a moving-message-LED-display controlled by a 16C73 that has a lot
>of features. It's working nicely and it's almost finished.

Hmm.... I found this quite interesting.  I also made a number of
moving message displays a couple of years ago based on the PIC16C57.
(On those days the fancier models like the 16C73 did not exist yet.)

Even though the moving message display worked very well and ran very
smoothly, at the end of that project I was sorry that I didn't rather
use a bigger micro like the 8051 or something that I could program in
a high level language like C.   The PIC16C57 that I used was filled
to the brim with code and there was no more room for future expansion
and that eventually killed the project as far as I was concerned.

But I suppose the 16C73 is a far better choice than the 16C57 and at
least you get some fancy C compilers for the PIC microcontrollers
these days.     Best of luck with your project!

Regards

Werner

--
Werner Terreblanche   Tel +27 21 7102251   Fax +27 21 721278
spam_OUTwterrebTakeThisOuTspamplessey.co.za (work) OR .....wernerKILLspamspam@spam@aztec.co.za  (home)

1996\10\30@012333 by Andres Djordjalian

flavicon
face
Hi Werner!

> Hmm.... I found this quite interesting.  I also made a number of
> moving message displays a couple of years ago based on the PIC16C57.
> (On those days the fancier models like the 16C73 did not exist yet.)
>....................
> But I suppose the 16C73 is a far better choice than the 16C57 and at
> least you get some fancy C compilers for the PIC microcontrollers
> these days.

I also started this project using a 16C57, but it soon proved too small
for what I had in mind. I could make it display text but it seemed
almost impossible to add the other features that where needed. If you were
able to complete a display controlled by a 16C57 I congratulate you!  The
16C73 is much more powerful, and now there is the 17C44 also, although it
could be cheaper!

I still can't say if it would had been better to use another micro. What I
like of PICs is their small package and speed. I needed speed for what I
had in mind, and I wanted to minimize costs and PCB complexity.

And also I guess the 4K-word ROM on the 16C73 is equivalent to almost 10K
bytes on another micro, and more if it's programmed with a HLL, so unless
there is a 16K or 32K ROM microcontroller that is cheap and fast I think
the 16C73 might be a good choice... But thanks for your comment!

>Best of luck with your project!

Thanks! Regards,
                                                       Andres

1996\10\31@040427 by Werner Terreblanche

flavicon
face
Andres Djordjalian <aajordjspamKILLspamALEPH.FI.UBA.AR> wrote:


>I also started this project using a 16C57, but it soon proved too
>small for what I had in mind. I could make it display text but it
>seemed almost impossible to add the other features that where needed.
>If you were able to complete a display controlled by a 16C57 I
>congratulate you!

Thank you.  I won't tell you how long it took me develop that. :(
I also had  to implement 9600 baud  serial communications all with
this one PIC1657.  And this was still in the dark ages before
Internet, so I didn't have any application notes or a Piclist to
consult.  <grin>

>I still can't say if it would had been better to use another micro.
>What I like of PICs is their small package and speed. I needed speed
>for what I had in mind, and I wanted to minimize costs and PCB
>complexity.

Well, you get the 8051 devices also in very high speed models.  I
know a guy here who makes gigantic big graphical LED displays, and he only
uses the fast 8051 devices.   So speed is not really a problem
anymore for these devices, but ROM considerations and development
tools and compilers certainly is.  If you feel that you are more
confident with the PIC microcontrollers then that is certainly the
right way to go.


>And also I guess the 4K-word ROM on the 16C73 is equivalent to almost
>10K bytes on another micro, and more if it's programmed with a HLL, so
>unless there is a 16K or 32K ROM microcontroller that is cheap and
>fast I think the 16C73 might be a good choice... But thanks for your
>comment!

The only problem is that they are all one time programmable.  (Except
for the PIC16C84, but that one is too small for your application.)   I really
like the
Atmel devices, because they are cheap, multi programmable and low on
power consumption.  However, that is just my personal opinion.  I
have gone through this same process once before and if I have to do
it all over again, I would rather use the Atmel 89CXX processors.

--
Werner Terreblanche   Tel +27 21 7102251   Fax +27 21 721278
.....wterrebKILLspamspam.....plessey.co.za (work) OR EraseMEwernerspam_OUTspamTakeThisOuTaztec.co.za  (home)


'LED mvong message.'
1996\11\02@101848 by Gerhard Fiedler
flavicon
face
At 02:22 30/10/96 GMT, Andres Djordjalian wrote:
>And also I guess the 4K-word ROM on the 16C73 is equivalent to almost 10K
>bytes on another micro, and more if it's programmed with a HLL, ...

What makes me wonder with such comparisons: 4k 16bit words already _equals_
8k with no added efficiency involved, so the 10k _bytes_ on another micro is
not too far off the 8k _bytes_ which is 4k words... Seems the microchip did
a good marketing trick to introduce 16bit _words_ as the base of their
codes: one of the big arguments is that all instructions are 1 word == 16bit
wide (on the bigger ones) -- but the average instruction in a typical 8031
code is way smaller than 2 bytes, as there usually are few with more than 2
bytes, but some with only 1. They just cannot claim that it is _one_ something.

1996\11\02@161937 by John Payson
picon face
> At 02:22 30/10/96 GMT, Andres Djordjalian wrote:
> >And also I guess the 4K-word ROM on the 16C73 is equivalent to almost 10K
> >bytes on another micro, and more if it's programmed with a HLL, ...
>
> What makes me wonder with such comparisons: 4k 16bit words already _equals_
> 8k with no added efficiency involved, so the 10k _bytes_ on another micro is
> not too far off the 8k _bytes_ which is 4k words...

Most PICs use 14-bit words; 4K words equals 7KBytes, not 8K.

>                                                      Seems the microchip did
> a good marketing trick to introduce 16bit _words_ as the base of their
> codes: one of the big arguments is that all instructions are 1 word == 16bit
> wide (on the bigger ones) -- but the average instruction in a typical 8031
> code is way smaller than 2 bytes, as there usually are few with more than 2
> bytes, but some with only 1. They just cannot claim that it is _one_
something.

Unless the author of the 8x51 code was space-concious, most opcodes used IN
PRACTICE are likely to be two bytes.  Further, let's look at some simple
code samples:

; Goal: add one variable to another (e.g. X=X+Y).  Assume both #'s are 8-bits
; PIC runs 4MHz; 8x51 runs at 12MHz

;PIC: 28 bits, 2us
       movf    Y,w
       addwf   X,f
;8x51 version 1: 24 bits, 3us [assuming X is in R1 and Y is in R2]
       mov     A,R1
       add     A,R2
       mov     R1,a
;8x51 version 2: 48 bits, 3us [assuming X and Y are in memory]
       mov     a,X
       add     a,Y
       mov     X,a

; Goal: as above, but 16-bit numbers.

;PIC: 84 bits, 6us
       movf    YL,w
       addwf   XL,f
       movf    YH,w
       btfsc   C
        incfsz YH,w
        addwf  XH,f
;8x51 version 1: 48 bits, 6us [assuming X is R1:R2 and Y is R3:R4]
       mov     A,R2
       add     A,R4
       mov     R2,A
       mov     A,R1
       addc    A,r3
       mov     R1,A
;8x51 version 2: 96 bits, 6us [assuming X and Y are in memory]
       mov     A,XL
       add     A,YL
       mov     A,XL
       mov     A,XH
       addc    A,YH
       mov     XH,A

;Goal: copy bit B1 to bit B2

;PIC version: 42 bits, 3us
       bcf     B2
       btfsc   B1
        bsf    B2
;8x51 version: 32 bits, 3us
       mov     C,B1
       mov     B2,C

;Goal: test a bit and branch

;PIC version: 28 bits, 2 or 3 us
       btfsc   Bit
        goto   Wherever
;8x51 version: 24 bits, 2us
       jb      Bit,Wherever

; Goal: test a bit and clear another memory location if it's set

;PIC version: 28 bits, 2us
       btfsc   Bit
       clrf    MemLoc
;8x51 version: 48 bits, 2 or 4 us
       jnb     Bit,Nope
       mov     MemLoc,#0
Nope:

;Goal: loop on a variable

;PIC version: 28 bits, 3us
       decfsz  Var,f
        goto   Loop
;8x51 version 1: 16 bits, 2us [loop control in R1]
       djnz    R1,Loop
;8x51 version 2: 24 bits, 2us [loop control in memory]
       djnz    Var,Loop

Most of these code samples represent things the 8x51 does quite well; as a
result, the PIC does not quite win out on a number-of-bits metric in many
cases, but comes very close.  In cases where it's often necessary to do
"simple" things in consequence of bits tests, the PIC may win out because
of it's "btfsx" instructions; in other cases, the 8x51 wins out.  On the
other hand, the PIC has an easy 5x speed boost available whereas the 8x51
generally does not.

1996\11\02@190333 by William Chops Westfield

face picon face
   ;8x51 version 1: 48 bits, 6us [assuming X is R1:R2 and Y is R3:R4]
           mov     A,R2
           add     A,R4
           mov     R2,A
           mov     A,R1
           addc    A,r3
           mov     R1,A
   ;8x51 version 2: 96 bits, 6us [assuming X and Y are in memory]
           mov     A,XL
           add     A,YL
           mov     A,XL
           mov     A,XH
           addc    A,YH
           mov     XH,A

Not to detract from your conclusions, but aren't you leaving out "effective
address fetch time" or something?  I have a hard time believing that any
processor can fetch twice as many bytes in its instruction stream and
maintain the same execution time...

BillW

1996\11\02@203553 by fastfwd

face
flavicon
face
William Chops Westfield <PICLISTspamspam_OUTMITVMA.MIT.EDU> wrote:

> I have a hard time believing that any processor can fetch twice as
> many bytes in its instruction stream and maintain the same
> execution time...

What you're missing, Bill, is that it's very easy to go the OTHER
way... That is, to fetch HALF as many bytes in the same time.

Look at it from that perspective, and remember that the 8051 has an
internal divide-by-12 on its clock, and you'll see that all that's
happening is that the short instructions are executing much slower
than they absolutely have to.

-Andy

Andrew Warren - @spam@fastfwdKILLspamspamix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1996\11\03@114836 by Gerhard Fiedler

flavicon
face
At 15:09 02/11/96 -0600, John Payson wrote:
>> At 02:22 30/10/96 GMT, Andres Djordjalian wrote:
>> >And also I guess the 4K-word ROM on the 16C73 is equivalent to almost 10K
>> >bytes on another micro, and more if it's programmed with a HLL, ...
>>
>> What makes me wonder with such comparisons: 4k 16bit words already _equals_
>> 8k with no added efficiency involved, so the 10k _bytes_ on another micro is
>> not too far off the 8k _bytes_ which is 4k words...
>
>Unless the author of the 8x51 code was space-concious, most opcodes used IN
>PRACTICE are likely to be two bytes.  Further, let's look at some simple
>code samples:

Thanks for the instructive samples. You're obviously right about the
possible speed boost, you'd have to use Dallas or some of the other newer
40MHz types to speed the 8031 up a bit. But they show also that the bit
count is not too far off, and the differences seem to be well within
differences of implementation (of the same solution by different
programmers...).

1996\11\03@114839 by Gerhard Fiedler

flavicon
face
At 16:02 02/11/96 PST, William Chops Westfield wrote:
>    ;8x51 version 1: 48 bits, 6us [assuming X is R1:R2 and Y is R3:R4]
>      ...
>    ;8x51 version 2: 96 bits, 6us [assuming X and Y are in memory]
>      ...
>
>Not to detract from your conclusions, but aren't you leaving out "effective
>address fetch time" or something?  I have a hard time believing that any
>processor can fetch twice as many bytes in its instruction stream and
>maintain the same execution time...

The examples were for a 8031 running @ 12MHz and a PIC running @ 4MHz. Does
this make your time less hard?

1996\11\03@164342 by John Payson

picon face
> At 16:02 02/11/96 PST, William Chops Westfield wrote:
> >    ;8x51 version 1: 48 bits, 6us [assuming X is R1:R2 and Y is R3:R4]
> >      ...
> >    ;8x51 version 2: 96 bits, 6us [assuming X and Y are in memory]
> >      ...
> >
> >Not to detract from your conclusions, but aren't you leaving out "effective
> >address fetch time" or something?  I have a hard time believing that any
> >processor can fetch twice as many bytes in its instruction stream and
> >maintain the same execution time...

One instruction cycle on the 8x51 is 12 clocks.  During this time, the MPU may
fetch
one or two bytes of code.  One of the reasons code density on the 8x51 is often
fairly
low is that many programmers don't bother to code for registers when
memory-based code

> The examples were for a 8031 running @ 12MHz and a PIC running @ 4MHz. Does
> this make your time less hard?

The most common speeds for an 8x51 are 12.0 and 11.0592MHz, though they are
available
in versions up to 40MHz.  The most common speeds for PICs are 4.0 and 3.579MHz
though
they are available up to 20MHz.  As a result, I thought the comparison
reasonable (I
personally prefer PICs, btw) even though 20MHz PICs are more common than 40MHz
8x51's.

1996\11\03@210816 by Dwayne Reid

flavicon
face
>At 02:22 30/10/96 GMT, Andres Djordjalian wrote:
>>And also I guess the 4K-word ROM on the 16C73 is equivalent to almost 10K
>>bytes on another micro, and more if it's programmed with a HLL, ...
>
>What makes me wonder with such comparisons: 4k 16bit words already _equals_
>8k with no added efficiency involved, so the 10k _bytes_ on another micro is
>not too far off the 8k _bytes_ which is 4k words... Seems the microchip did
>a good marketing trick to introduce 16bit _words_ as the base of their
>codes: one of the big arguments is that all instructions are 1 word == 16bit
>wide (on the bigger ones) -- but the average instruction in a typical 8031
>code is way smaller than 2 bytes, as there usually are few with more than 2
>bytes, but some with only 1. They just cannot claim that it is _one_ something.
>

Actually, the word size on a 16Cxx PIC is 14 bits.  But I think that you
miss the point about the word size.  Lets consider a 68hc11.  There are
three ways to address something, depending upon how far away that something
is from where you are right now.  Short jumps (+- 127 bytes) take a single
code space, longer jumps take two or three code spaces.  Since the PIC uses
a 13 bit address, these jumps usually (PCLATH problems notwithstanding) take
only ONE code space.

I have found that rewriting some of my old 'hc11 stuff into PIC format
really does result in a 2 to 3 times reduction in code size.  Part of that
is experience (I am a better programmer now than I was 5 years ago, part of
that is the PIC instruction set (it is possible to do certain things in a
much more elegant manner), and part is the inherent reduction possible
because of the longer word size.

Dwayne

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