Searching \ for 'Q&' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=
Search entire site for: 'Q&'.

No exact or substring matches. trying for part
PICList Thread
'[PIC]: A Q&D random number generator'
2003\05\31@161836 by John Nall

flavicon
face
I'm writing a small application which needs a quick and dirty random number
generator.  Since the number desired will be between 1 and 255, inclusive,
it seems to me that a nice way to do it would be just to start one of the
timers going (I'm using the 18F452) and read the 8-bit counter at the time
I need the random number.  Since it will be continually incrementing and
overflowing, this would seem to be pretty random.

But it seems so easy (really just one instruction) that there must be a
catch. :-)  Anyone see any?  (I'm using Timer0 for something else, but
since the F452 has four timers, that is no problem).

John

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu>

2003\05\31@172929 by Bob Axtell

face picon face
This application is similar to the Z80 free-running register; we used it as
a reasonable seed value. But if you read the "random number" repeatedly for
16K times, you will clearly see a repeating, non-random pattern.

In the PIC, the answer would be to access the WDT oscillator, since it has
its own RC oscillator that is not in sync with the PIC internal clock. But,
it is NOT available, alas.

But my choice for a Q&D is to feed the TMR1 Input from an external RC
oscillator running at 200Khz or slightly less (max speed for TMR1). Then
simply grab the LS timer which is incrementing through as fast as it can.

I like the single section of an 74HC14, with a resistor from input to
output, with a cap on the input to ground. Costs just pennies, and you have
5 more drivers to use somewhere else. You now have a degree of randomness
because this RC oscillator varies considerably with VCC, heat, component
aging, etc.

--Bob

At 04:18 PM 5/31/2003 -0400, you wrote:
{Quote hidden}

--------------------------

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu>

2003\05\31@193337 by Jinx

face picon face
> timers going (I'm using the 18F452) and read the 8-bit counter
> at the time I need the random number.  Since it will be continually
> incrementing and overflowing, this would seem to be pretty random

Unpredictability is the key to getting good random numbers. As the
PIC and everything it does is based on one clock source, it's unlikely
that in the long term a random sequence will be produced. If you look
around the web for examples of computer-based PRNGs you'll see
that most if not all have a caveat. Mr Axtell's suggestion of using a
conflicting frequency on Timer1 would be worth looking into. If using
standard crystals for OSC and Timer1, perhaps detune one to get
them as far out of synch as possible

> In the PIC, the answer would be to access the WDT oscillator,
> since it has its own RC oscillator that is not in sync with the PIC
> internal clock. But, it is NOT available, alas

It can reset the PIC though, and the RI, TO and PD bits in RCON
can be tested for this. I couldn't say for sure, but you may be able
to POP the PC off the stack to return to previous program position
after reading the timer registers (which are unaffected by reset)

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu>

2003\05\31@200511 by Tal

flavicon
face
> In the PIC, the answer would be to access the WDT oscillator,
> since it has its own RC oscillator that is not in sync with
> the PIC internal clock. But, it is NOT available, alas.
>

I think you can have an indirect access to the WDT counting speed. Reset
the WDT and enter an infinite loop that increments a register. When you
get a WDT reset, take the value (or last bit) from that register.

Does this make any sense ?

Tal

> {Original Message removed}

2003\05\31@205239 by Jinx

face picon face
After a little thought following a Q&D reply to a Q&D question,
POPping PC off the stack is of course pure BS. I was thinking
too many steps ahead, and not very clearly at that, and don't
believe there would be a way to save the PC so as to resume
program flow after a reset. It would be possible to do a computed
GOTO to get back into the same routine but not to the exact
instruction unless the program was specially written to do that.
The only other possible way to use WDT would be as a wake-up.
If you need the random numbers at specific points in the program
then SLEEP the PIC at that point and resume by reading the
timer. At other times dot some CLRWDTs around to prevent a
reset. Using WDT you'd get around 55 new numbers/sec

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu>

2003\05\31@211218 by Bob Axtell

face picon face
Thats the best Q&D solution yet! You could just read TMR0 in this case!

--Bob

At 12:51 PM 6/1/2003 +1200, you wrote:
{Quote hidden}

--------------------------

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu>

2003\05\31@214632 by William Chops Westfield

face picon face
   I'm writing a small application which needs a quick and dirty
   random number generator.  Since the number desired will be
   between 1 and 255, inclusive, it seems to me that a nice way to
   do it would be just to start one of the timers going (I'm using
   the 18F452) and read the 8-bit counter at the time I need the
   random number.  Since it will be continually incrementing and
   overflowing, this would seem to be pretty random.

Only if you read it significantly less often than it overflows, which is
probably a bit tough to do for an internal timer.  (an external counter or
LFSR clocked directly by OSCOUT would be better.)  You can improve this for
statistical/gaming purposes by clocking a PRNG N times each time you envoke
it (where N comes from the counter), but it's likely not to be very random
unless your program contains numerous loops that are depedent on actual
random (external) events.

OTOH, the most important thing about random numbers seems to be
understanding what sort of random number you actually NEED.  Security
and encryption applications need numbers that are very random indeed.
Simulations require only random numbers that are statistically well
behaved, and something like suffling that list of songs into 'random'
order doesn't need to be very random at all.

BillW

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu>

2003\05\31@214726 by Jinx

face picon face
> Thats the best Q&D solution yet!

"!" = Heath Robinson ? ;-)

> You could just read TMR0 in this case!

Yessum, that'd be the Q&D way if WDT or another uncontrollable
event is the trigger. The OP didn't say how many or how often he
needs them so maybe it's simple, maybe not

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu>


'[PIC]: A Q&D random number generator'
2003\06\01@084657 by John Nall
flavicon
face
At 11:33 AM 6/1/2003 +1200, Jinx wrote:

>Unpredictability is the key to getting good random numbers. As the
>PIC and everything it does is based on one clock source, it's unlikely
>that in the long term a random sequence will be produced.

Yes, I see that now.  It was a dumb idea.  I KNEW that it was too easy!!
:-)   Oh well.  Back to the drawing board.

John

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\06\01@085944 by John Nall

flavicon
face
At 01:44 PM 6/1/2003 +1200, Jinx wrote:

>The OP didn't say how many or how often he
>needs them so maybe it's simple, maybe not


The OP has realized at this point that it won't work as planned because, as
someone else pointed out, unless the possibility exists that it may
overflow one or more times in between hits, then all one would get would be
a hit which would be the previous hit plus an increment.  Probably proves
that a Q&D solution often is the result of a Q&D analysis of the situation. :-(

John

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\06\01@090356 by Jinx

face picon face
> :-)   Oh well.  Back to the drawing board.
>
> John

Just out of curiousity, how many and how often ?

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\06\01@100148 by John Nall

flavicon
face
At 01:06 AM 6/2/2003 +1200, Jinx wrote:

>Just out of curiousity, how many and how often ?

A large loop, grabbing a random number after about every 150 or so
instructions.  It was such a dumb idea!   But I will share how it came
about.  I was laboriously coding, assembly of course, one line at a
time.  Not sure what the industry standard is for how many lines a day
should be produced.  I think I read somewhere that 20 lines a day in
assembly is expected?  Anyway, I  thought:  "Hey, while I am doing this,
that little counter is sitting over there spinning away!   So I can just
grab a number out of it!"  And of course the fatal flaw in the logic is
that the little counter is "spinning" only at the rate the instructions are
being executed.  Oh well.    Not the first dumb idea I ever had, and will
not be the last.  Next time, though, I won't be so quick to share the idea
until I get a  good night's sleep. :-)

John

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\06\01@104836 by Olin Lathrop

face picon face
> I think I read somewhere that 20 lines a day in
> assembly is expected?

That is totally rediculous.  That means it would take 2 1/2 man-months to
write just 1000 lines!


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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\06\01@112025 by gtyler

flavicon
face
If you use a 18f1220 etc timer 1 has it's own oscillator.

Gtyler
----- Original Message -----
From: "John Nall" <spamBeGonejnall01spamBeGonespamALLTEL.NET>
To: <TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU>
Sent: Sunday, June 01, 2003 4:00 PM
Subject: Re: [PIC]: A Q&D random number generator


{Quote hidden}

are
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\06\01@112253 by Jack Smith

picon face
These productivity figures are generally cited in the context of very large,
complex systems.  For example, Brooks, in "The Mythical Man-Month" quotes
figures ranging from 10,000 instructions/man-year to 1,500
instructions/man-year. At the bottom end, 1,500/man-year, you wind up with
about 8 lines of code per day. The job that Brooks managed, the IBM360 OS,
clocked in at 600-800 debugged instructions per man-year.

But, the context is critical.  These figures are for projects with hundreds
to thousands of programmers and support staff, and code size measured in
hundreds of thousands to millions of lines of assembler code. Projects of
this scale involve huge interaction requirements and enormous documentation.

For a one-man job, Brooks cites a study--for programs averaging 3200
words--an average code-plus-debug time of 178 hours for a single programmer,
or about 35,800 instructions/man-year. This is around 150 instructions/day,
depending on your time-off assumptions.

Finally, Brooks compiled his figures in an era of batch programming, largely
without on-line debuggers or simulators. Indeed, IBM started developing the
360 OS before the hardware was functioning. I can remember getting about 100
pages of core dump back (the next day, of course) from FORTRAN jobs as an
"error report."  So, it was back to the punch for correction followed by
resubmitting the card deck for the next evening's run.  Compare that with an
interactive system that automatically displays the offending line and
highlights the erroneous instruction as we are the norm today for compilers.

Particularly for one-man jobs on a relatively simple platform such as PICs,
these modern tools improve productivity an order of magnitude or more.


Jack




{Original Message removed}

2003\06\01@112653 by John Nall

flavicon
face
At 10:48 AM 6/1/2003 -0400, Grumpy Olin wrote:

> > I think I read somewhere that 20 lines a day in
> > assembly is expected?
>
>That is totally rediculous.  That means it would take 2 1/2 man-months to
>write just 1000 lines!

The 20 was just a rough guess from what I remembered reading.  However, the
following article suggests that it is not too awfully far off the mark (a
bit low, I'll admit, but I doubt the study refers to only assembly language
code)

http://www.cnn.com/TECH/computing/9904/15/slacker.idg/

NEW YORK (IDG) -- U.S. programmers, their jobs protected by the labor
shortage, have become complacent and less productive than their
international peers, according to a study of 16,000 information technology
professionals in 28 nations.

The study, released here last week, was prepared by researcher Howard Rubin
for Meta Group Inc. in Stamford, Conn. Using a standard measure of IT
productivity based on the number of lines of code developed by a programmer
per year, the study pegged U.S. programmer productivity at an average of
7,700 lines of code.....

John

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\06\01@120013 by Spehro Pefhany

picon face
At 11:26 AM 6/1/2003 -0400, you wrote:


>The study, released here last week, was prepared by researcher Howard Rubin
>for Meta Group Inc. in Stamford, Conn. Using a standard measure of IT
>productivity based on the number of lines of code developed by a programmer
>per year, the study pegged U.S. programmer productivity at an average of
>7,700 lines of code.....
>
>John

There's a large difference in productivity between mediocre and very
good programmers.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
RemoveMEspeffspamTakeThisOuTinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\06\01@122515 by Dave Tweed

face
flavicon
face
Olin Lathrop <olin_piclistEraseMEspam.....EMBEDINC.COM> wrote:
> > I think I read somewhere that 20 lines a day in assembly is expected?
>
> That is totally rediculous.  That means it would take 2 1/2 man-months to
> write just 1000 lines!

Is it? Starting from a requirements document and an empty directory for
source code, and ending with debugged, dcoumented and releasable code, is
it really unreasonable to expect it to take 2.5 man-months to produce over
16 pages of new assembly code (i.e., not counting pre-existing libraries,
etc.)?

In my experience, this is actually not far off the mark.

In fact, I have heard LOC per man-month is pretty much independent of the
language being used. My experience does not contradict this.

-- Dave Tweed

P.S. Congrats on getting the email working again.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\06\01@154724 by William Chops Westfield

face picon face
NEW YORK (IDG) -- U.S. programmers, their jobs protected by the labor
   shortage, have become complacent and less productive than their
   international peers, according to a study of 16,000 information
   technology professionals in 28 nations.

"Labor shortage", eh?  How old IS that article, anyway?

Large US software producers are on something of a "quality kick" these
days, it appears to me.  It's really trivial for a large project to slow
down the overall software process 5 or 10x to get 2x "better quality."
That doesn't really mean that code writing speed has slowed down, it's
just that there is a lot of time spent sitting on your hands waiting for
your feature A to get tested, then tested again after the merge with
feature B, then tested again after the merge with features C+D, and so
on.  It's rather depressing...

At cisco, the time from "code working" to First production software shipment
is now over a year in most cases...

BillW

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\06\01@181038 by Tal

flavicon
face
Yes, I recall reading it somewhere, and the interesting point was that
the 20 lines/day is independent of the programming language used which
means that high language are more productive since you get more
functionality in 20 lines.

The 20 lines/day includes things like design, coding, documentation,
intra team communication, testing and debugging. Of course, if you don't
count the overhead or measuring a small scale, one person project, the
number will be higher.

Tal

> {Original Message removed}

2003\06\01@185400 by Jinx

face picon face
> 20 lines a day in assembly is expected?

If that's what it works out to on average it would be a rough
guide or starting place for quoting

And thanks for all the replies re Royalties. Some interesting
points brought up

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\06\02@035557 by Wouter van Ooijen

face picon face
> > I think I read somewhere that 20 lines a day in
> > assembly is expected?
>
> That is totally rediculous.  That means it would take 2 1/2
> man-months to write just 1000 lines!

It just depends on your definition or 'write'. It might include
everything from pre-sales consultancy to in-field troubleshooting. I can
krank out a few 1000's of lines in a day, but that is not the same thing
as making it into a product.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
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

2003\06\02@035603 by Wouter van Ooijen

face picon face
> But it seems so easy (really just one instruction) that there
> must be a
> catch. :-)  Anyone see any?

If your 'need' is periodical you might end up with not-so-random
numbers. If your need is not periodical (but essentially random placed
in time) that is the source of randomnedss you are using, and it might
work well, depending on how random it is.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
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

2003\06\05@202736 by Eric Bohlman

picon face
6/2/03 2:54:21 AM, Wouter van Ooijen <EraseMEwouterspamVOTI.NL> wrote:

>> > I think I read somewhere that 20 lines a day in
>> > assembly is expected?
>>
>> That is totally rediculous.  That means it would take 2 1/2
>> man-months to write just 1000 lines!
>
>It just depends on your definition or 'write'. It might include
>everything from pre-sales consultancy to in-field troubleshooting. I can
>krank out a few 1000's of lines in a day, but that is not the same thing
>as making it into a product.

Exactly.  The "20 lines per day" figure is based on dividing the number of lines of code *in the
final deliverable* by the number of days spent on *all aspects* of the program, *not* just the
coding phase.  So the numerator doesn't include things like test-harness code, or code that had to
be scrapped because of requirements changes, and the denominator includes a lot more things than
coding (testing, debugging, documenting, design, requirements analysis, administrative stuff,
progress reporting, etc).  It does *not* mean that someone can't code more than 20 lines in 24
hours, any more than "the average family has 1.5 children" means that any family has a child with a
partial body.

You'd get very similar figures, by the way, if you divided the number of words in a book by the
number of days it took the author to write it.  You have to account for all the time spent
outlining, writing first drafts, etc.

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamEraseMEmitvma.mit.edu>

2003\06\06@042139 by Alan B. Pearce

face picon face
>>It just depends on your definition or 'write'. It might include
>>everything from pre-sales consultancy to in-field troubleshooting. I can
>>krank out a few 1000's of lines in a day, but that is not the same thing
>>as making it into a product.
>
>Exactly.  The "20 lines per day" figure is based on dividing the number
>of lines of code *in the final deliverable* by the number of days spent
>on *all aspects* of the program, *not* just the

Been watching this discussion go past. IIRC the original definition years
back used to be "lines of debugged code", and was one of the measurement
methods to justify using HLL's as these produce more executable code per
line of source code. Hence one line of "debugged HLL code" was believed to
represent a larger amount of "executable code" than one line of "debugged
ASM code". The possibility that the larger amount of executable code may not
achieve any more useful operations than the line of assembler code did not
enter into the discussion.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

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