>I have found that every once in a while our PICSTART refuses to program
>properly, but I put it down to the ZIF socket - devices placed centrally
>do not program properly but ones placed at the left side program OK.
Hmmm...
I've used the PICStart 16B since version 1.4 (keep getting upgrades, like
candy), and it's always been flakey. I have one at work and another at
home. Both the same.
I've never even tried shifting the part in the ZIF socket. Sometimes it
programs first time, usually it takes three attempts. Without shifting the
chip at all. I chalk it up to flakey timing and bad exception handling.
Which is also pure conjecture... My $0.02
I'm interested in that "Unix" code the other guy has.
Since I started this "introduction series" (again?) I will tell you a bit
about my interest in PIC:s.
I'm a student at Linkoping University (LiTH) in the middle-south-east of Sweden.
I study Applied Physics and Electrical Engineering (third year) and my
interest in electronics started when I was about 10-12 years old (I think).
As my studying occupies most of my time, I have only built two "major"
PIC-based gadgets, an RPM-counter for cars and a "magic wand"
(presented in Everyday with Practical Electronics recently) but MY wand is
better ...
>It seems to be a common problem to not provide sufficient bypassing on
>PIC's because they "use negligable current". There are two effects that
>happen when you under-bypass a part like the PIC because they are CMOS
> .... etc.
Don:
Do you think it's possible to make a full-time career out of advising
people to use bypass caps? You have a pretty good start...
> Cheapest Kit programmer such as David Taits
> Moderate Parallax "Hobby" programmer
> Moderate+ Microchip's PICSTART programmer
> Moderate++ Parallax's deluxe programmer (Clearview?)
> Expensive Microchip's PICMaster programmer
> Expensive EMP-20, etc.
> ....
> One kind (16C84) Kit programmer, no EEPROM parts have
> A/D yet
> Few kinds (16C5x, 16c7x) Microchips PICSTART (16B or 16C)
> Many kinds Parallax "hobby" programmer
> Many Kinds Both microchip PICSTART 16B and 16C
> Many Kinds PICMaster, EMP-20, etc.
> ....
> Few per day/week Kit programmer
> Few per day/week Parallax or Microchip "Hobby"
> programmers.
> 10+ per day/ 50+/week PICMaster, EMP-20, etc.
Chuck:
What you're saying, obviously, is that one gets what one pays for. I
have a couple of comments, though.
This is minor, but it bugs me every time I see someone make this
mistake:
Microchip's production-level programmer is called "Pro-Mate", not
"PIC-Master". The PIC-Master is, of course, Microchip's in-circuit
emulator. Microchip is partly to blame for your confusion; before they
realized that the name was already trademarked by DATA I/O, they called
their programmer a "Pro-Master".
I'm not at all familiar with Parallax's hardware, but I believe that
their "Clearview" products are emulators, too.
Ok... The main point:
Your third criterion (number of parts programmed) shouldn't really be an
issue. The difference in programming speed between the "hobby"
programmers (Microchip's PICSTART or Parallax's DOWNLOADER) and the
much-more-expensive Pro-Mate is fairly slight, and, in the case of the
PICSTART-to-Pro-Mate upgrade, the user interface is even the same.
A more important reason to choose the Pro-Mate is that it programs PICs
using Microchip's production-approved multiple-voltage verification
protocol. If the reliability of your programmed PICs over their full
voltage range is important to you, you pretty much have to use the
Pro-Mate.
>To save W, STATUS and FSR you can use:
>
> movwf SavedW
> swapf STATUS,W
> movwf SavedSTATUS
> movf FSR,W
> movwf SavedFSR
> .....
>
>To restore W, STATUS and FSR you can use:
>
> .....
> movf SavedFSR,W
> movwf FSR
> swapf SavedSTATUS,W
> movwf STATUS
> swapf SavedW,F
> swapf SavedW,W
> retfie
This works on the 16C71/61 (if you don't care about saving/restoring
PCLATH), but it will not work on any 16Cxx parts whose general-purpose
registers aren't accessible from all pages (e.g., all the other 16Cxx
devices). For those, save registers with:
I just paid 1.60 each for 10 HC705J1's (OTP)from FAI. I debated between the J1
and PIC
61's. After I thought out the pro's and con's of each, I stayed with the PIC e
ven
though it's three times as much. If I get into the thousands of units I will ha
ve to
re-evaluate.
how about amplifying,low-pass filtering ( 3rd order), and clipping
the guitar signal with a cheapo 324 quad-opa. Generate the desired
reference freq. with the RTCC. Make a software-PLL style frequency-
comparator ( edge-triggered RS-flip-flop )which is set by ref.-timing
and reset by input signal . Connect a 'sharp' LED to the Fin>Fref port and
a 'flat' LED to the Fref>Fin port. As the input freq. comes up/
down towards the ref.freq. the flat/sharp LED will dim.
Just a quick idea; don't know if it makes sense.
Another idea, not mine , saw it on Frankfurt Musik fair about 10yrs ago:
A guy fed a bright LED with a microcontroller generated reference
frequency and used the stroboscobe effect to visually tune the strings
without making noise - nice !
>It would be interesting to also pursue the generation of MIDI from a
>guitar signal ....
and from other real world events. In my free-time ( not much) I currently
work on such a project : a microphone is placed at each end of a 1m plastic
tube. If you hit the tube with e.g. a drum-stick the mikes generate pulses
with a runtime delay. A 16C54 along with a 324 opamp digitizes these pulses
( MIDI key velocity ) and calculates a MIDI-note-# from the trigger delays.
I 'll put schematics, layouts + code related to MIDI, musicelectronics, PICs
and other controllers on my ftp site as soon as possible ( late summer ?)
Will be announced here and on MIDI.boards
P.S.
I too have some code that sends MIDI. MIDI IN is tough.
a 20MHz PIC with HW-interrupt could do it. Somebody tried it ?
Anybody else doing MIDI with PICs ?
Uwe Sch"uler __\ /__ ein genie
Physiologie --\,,,/-- das sich nicht geniert
Gmelinstr.5 /" "\ ist wie ein rentier
D-72076 T"ubingen \_V_/ das sich nicht rentiert
Tel: (49) 70 71 29 - 30 72 Fax: - 30 73
> Another idea, not mine , saw it on Frankfurt Musik fair about 10yrs ago:
> A guy fed a bright LED with a microcontroller generated reference
> frequency and used the stroboscobe effect to visually tune the strings
> without making noise - nice !
> > Another idea, not mine , saw it on Frankfurt Musik fair about 10yrs ago:
> > A guy fed a bright LED with a microcontroller generated reference
> > frequency and used the stroboscobe effect to visually tune the strings
> > without making noise - nice !
>
> Oh man, I've gotta try it!
>
Must have to darken the room to tune?? Anyone have any ideas, helpful
hints to get this to work? Seems that it would be a rather stright
forward project!
Your suggestion for dealing with the harmonics is great. But my tuner
attempts to determine by itself which string is being tuned. I suppose
with expensive programmable filters you could detect the pitch, then dial
in the filter real quick to protect against the harmonics, which
intensify with time. But if you put in a filter sufficient to chop the
harmonics of the low E string (86 Hz or so) you'd never pick up the high
E two octaves up.
My hackbuddy and I have decided to return to this project and see if we
can get it to work. The idea will be: count on the fundamental being
strong for the first several cycles (seems to be safe), then start
ignoring any transitions that aren't close to the expected timings. For
example, if you're tuning the 110 Hz A string, you'd initially get a 110
cycle square wave. Then as the vibrations decay, you'd start seening
double, triple, or some oddball combination. If I remember right, the
second harmonic is the most prominent and can be isolated. But I'll have
to look again. Anyway, it might be as simple as ignoring every odd
pulse, once the expected pitch is established. Owell I'll try it and
post the results!
ps: about the code I've offered to put up... I was going to make it
available via ftp this morning but I forgot to move the files. I'll do
it tomorrow when I'm dialed in from home.
Lou> > A guy fed a bright LED with a microcontroller generated reference
Lou> > frequency and used the stroboscobe effect to visually tune the
Lou> > strings without making noise - nice !
Lou> Oh man, I've gotta try it!
Mike> Must have to darken the room to tune?? Anyone have any ideas,
Mike> helpful hints to get this to work?
David, here are a few suggestions for a solution to your problem with
harmonics:
1) Use a dual speed PLL to initially lock onto the strong fundamental
in 'fast' tracking mode and then automatically switch to 'slow' mode
to stay locked onto the decaying fundamental (decrease capture
range). The 'fast' speed would be optimized to lock onto the
fundamental quickly and the 'slow' speed would be fast enough to
track tuning variations but too slow to 'jump' over to a harmonic.
The fundamental could then be measured by coupling the vco to the
pic.
2) Use zero crossing detection. It has the unique property of allways
digitizing the lowest frequency, even if its not the strongest.
A well designed front end, and possibly threshold tracking to
maintain sensitivity could be used to extend its range.
3) Use a switched capacitor filter with external clock input configured
as a 'comb' filter. Lock on to the fundamental and feed it into the
filter's clock, thereby attenuating its harmonics. Something
creative would need to be done here to aquire the fundamental in the
first place.
4) Use the pic to implement an FIR or IIR filter.
5) Use the pic to integrate its measurement of frequency and then use
that to detect the rate-of-change. If the rate of change (slope)
exceeds a pre-set value then we know the detection circuitry has
switched from the fundamental to a harmonic. At that point in time
divide the new frequency measurement by the fundamental to calculate
the harmonic factor and use that factor in subsequent calculations.
This idea would work best if the signal were processed first by a
PLL to lock onto a single spectral component. In fact, you could use
the lock detection circuitry of the PLL to detect when the
switchover to a harminic occurs.
6) Can you tell if a note is sharp or flat from its harmonic as well as
from its fundamental? If so, then use a PLL front end to purify the
spectrum (one frequency at a time) and do your function on the VCO
signal.
7) Use an analog input and implement a PLL in pic firmware, using a
combination of the above ideas.
I really know absolutely nothing about music, but I hope these ideas are
usefull, or stimulate the formulation of new ones.
> 1) Use a dual speed PLL to initially lock onto the strong fundamental
Would it really stay locked to the weak fundamental?
> 2) Use zero crossing detection. It has the unique property of allways
> digitizing the lowest frequency, even if its not the strongest.
It can't be that easy, can it? I'm already amplifying and heavily clipping
the signal. Isn't that the same thing? Maybe I need to read up on zero
crossing detection.
> 3) Use a switched capacitor filter [...]
Impractical but clever.
> 4) Use the pic to implement an FIR or IIR filter.
What are these?
> 5) Use the pic to integrate its measurement of frequency and then use
> that to detect the rate-of-change.
What I was planning was simpler. Once the harmonic kicks in I'll be able
to recognize it because transitions will suddenly arrive way too early.
I can simply discard transitions that aren't within a few percent of
where I expect to find them.
> 6) Can you tell if a note is sharp or flat from its harmonic as well as
> from its fundamental? If so, then use a PLL front end to purify the
> spectrum (one frequency at a time) and do your function on the VCO
> signal.
How does one "purify a spectrum" with a PLL? What does that mean? But
yes of course it is possible to track changes in a harmonic as readily as
the fundamental.
> 7) Use an analog input and implement a PLL in pic firmware, using a
> combination of the above ideas.
I've done this for another project and it worked *very* well. However I
was able to isolate the fundamentals with analog filters ahead of time.
> From @uga.cc.uga.edu:TakeThisOuTowner-piclistEraseMEspam_OUTMITVMA.MIT.EDU Fri Jul 7 14:28:45 1995
> From: Uwe Schueler <RemoveMEuwe.schuelerTakeThisOuTUNI-TUEBINGEN.DE>
> Subject: Re: guitar tuner, PIC & MIDI (was:Freq.counter)
>
> >... David's guitar tuner project .....
>
> how about amplifying,low-pass filtering ( 3rd order), and clipping
> the guitar signal with a cheapo 324 quad-opa. Generate the desired
> reference freq. with the RTCC. Make a software-PLL style frequency-
> comparator ( edge-triggered RS-flip-flop )which is set by ref.-timing
> and reset by input signal . Connect a 'sharp' LED to the Fin>Fref port and
> a 'flat' LED to the Fref>Fin port. As the input freq. comes up/
> down towards the ref.freq. the flat/sharp LED will dim.
> Just a quick idea; don't know if it makes sense.
This has some possibilities. But you need to guess the reference freq.
from early edge crossings to get the correct string. Help me out now,
what would the algorithm look like in pseudo-code?
wait for an edge crossing.
start a timer.
next edge crossing is 1/2 period.
estimate string, get reference period, set up reference period in RTCC.
loop
wait for an edge or RTCC timeout.
if edge
set sharp LED. ;; you'd want to re-sync the RTCC?
if RTCC
set flat LED. ;; you'd have to re-sync the RTCC to the next edge?
if (too many RTCC's with no edge)
break, restart
So when you're close to 'in-tune', both LED's would be on?
> >It would be interesting to also pursue the generation of MIDI from a
> >guitar signal ....
>
> and from other real world events. In my free-time ( not much) I currently
> work on such a project : a microphone is placed at each end of a 1m plastic
> tube. If you hit the tube with e.g. a drum-stick the mikes generate pulses
> with a runtime delay. A 16C54 along with a 324 opamp digitizes these pulses
> ( MIDI key velocity ) and calculates a MIDI-note-# from the trigger delays.
This sounds like a really fun midi-trigger. I'd like to get a hold of
some of your results. Are you digitizing Mike output with RC discharge
time?
> I 'll put schematics, layouts + code related to MIDI, musicelectronics, PICs
> and other controllers on my ftp site as soon as possible ( late summer ?)
> Will be announced here and on MIDI.boards
I'll look forward to this.
> P.S.
> I too have some code that sends MIDI. MIDI IN is tough.
> a 20MHz PIC with HW-interrupt could do it. Somebody tried it ?
32 usecs/bit doesn't leave much time. Setting up an 'hc11 is quite
a bit easier.
> Anybody else doing MIDI with PICs ?
Not yet, but when my (non-existent) free time allows ..
> Uwe Sch"uler __\ /__ ein genie
Tim Braun |
Continental Healthcare Systems Canada | Voice: 204-942-2992 ext 228
1900-155 Carlton St | FAX: 204-942-3001
Winnipeg, Manitoba, Canada R3C 3H8 | Email: timEraseME.....chs.mb.ca
> This has some possibilities. But you need to guess the reference freq.
> from early edge crossings to get the correct string. Help me out now,
> what would the algorithm look like in pseudo-code?
>
> wait for an edge crossing.
> start a timer.
> next edge crossing is 1/2 period.
Are you sure you can assume 50% duty cycle? Depending on the DC level
when you clip, the 1/2 cycle transitions will hopefully be near the
middle but you can't count on the exact timing. I time from one
low-to-high transition to the next to unask this question.
The rest of your algorithm looks good. What I do is wait for the edge,
then peek at the RTCC and look up the count in a table. See http://www.rt66.com/dthomas/pic/pic.html if you want to see my tuner so
far.
> David, here are a few suggestions for a solution to your problem with
> harmonics:
>
> 1) Use a dual speed PLL to initially lock onto the strong fundamental
> in 'fast' tracking mode and then automatically switch to 'slow' mode
> to stay locked onto the decaying fundamental (decrease capture
> range). The 'fast' speed would be optimized to lock onto the
> fundamental quickly and the 'slow' speed would be fast enough to
> track tuning variations but too slow to 'jump' over to a harmonic.
> The fundamental could then be measured by coupling the vco to the
> pic.
>
> 2) Use zero crossing detection. It has the unique property of allways
> digitizing the lowest frequency, even if its not the strongest.
> A well designed front end, and possibly threshold tracking to
> maintain sensitivity could be used to extend its range.
>
> 3) Use a switched capacitor filter with external clock input configured
> as a 'comb' filter. Lock on to the fundamental and feed it into the
> filter's clock, thereby attenuating its harmonics. Something
> creative would need to be done here to aquire the fundamental in the
> first place.
>
> 4) Use the pic to implement an FIR or IIR filter.
>
> 5) Use the pic to integrate its measurement of frequency and then use
> that to detect the rate-of-change. If the rate of change (slope)
> exceeds a pre-set value then we know the detection circuitry has
> switched from the fundamental to a harmonic. At that point in time
> divide the new frequency measurement by the fundamental to calculate
> the harmonic factor and use that factor in subsequent calculations.
> This idea would work best if the signal were processed first by a
> PLL to lock onto a single spectral component. In fact, you could use
> the lock detection circuitry of the PLL to detect when the
> switchover to a harminic occurs.
>
> 6) Can you tell if a note is sharp or flat from its harmonic as well as
> from its fundamental? If so, then use a PLL front end to purify the
> spectrum (one frequency at a time) and do your function on the VCO
> signal.
>
> 7) Use an analog input and implement a PLL in pic firmware, using a
> combination of the above ideas.
>
> I really know absolutely nothing about music, but I hope these ideas are
> usefull, or stimulate the formulation of new ones.
>
> Regards, Dana Frank Raymond - Foxtrot Systems Ltd.
> Internet: EraseMEdana.raymondcanrem.com. Compuserve: 73362,3052
Please help my confusion - it seems to me that we are trying to over engineer
what could be an easy solution.
Wouldn't the normal tuning process be:
1. "Pluck" the string.
2. Listen for it being sharp or flat.
3. Tune the string.
4. Re-pluck the string.
If this is the case, why worry about decaying harmonics? Just count
the number of zero crossings in 100 msec & compair to a table of expected
values. If it is high or low out-of-range discard it & try again.
Even if you tune on the fly ( i.e. pluck-listen-tune as a single process); I
would think you could still get a good frequency sample after 2 sec. I could
be wrong here - I've never tried it.
I don't know much about guitars. But I think the difference between the
1st string (low E) and the 6th (high E) is 2 octaves. With a string way out-
of-tune, I think it is possible to tune to the frequency of another string.
Taking a string this far out-of-tune would be undetectable by your circuit.
You may want to consider using 8 LEDs: 1 per string, plus a high and low
indication. This would let you know which string the circuit thought you
were tuning.
On Mon, 10 Jul 1995, Jon Poland SE Sun St Louis wrote:
> Please help my confusion - it seems to me that we are trying to over engineer
> what could be an easy solution.
>
> Wouldn't the normal tuning process be:
> 1. "Pluck" the string.
> 2. Listen for it being sharp or flat.
> 3. Tune the string.
> 4. Re-pluck the string.
No. The way guitar players generally tune is to hit the string once,
good and hard, then adjust the peg as the string is decaying. That
way you can adjust a continuous pitch until it's right. If you try to
tune with only "that was too high" type information, it takes way too
many tries. Being off by even a few cents is enough to make the
instrument sound sour.
> Even if you tune on the fly ( i.e. pluck-listen-tune as a single process); I
> would think you could still get a good frequency sample after 2 sec. I could
> be wrong here - I've never tried it.
2 sec. is enough time to know if you're right or not, but it's not
enough time to bring the string in.
> I don't know much about guitars. But I think the difference between the
> 1st string (low E) and the 6th (high E) is 2 octaves.
<nod>
> With a string way out-
> of-tune, I think it is possible to tune to the frequency of another string.
Guitarists are smarter than this. Very few guitar players have any
trouble at all getting it close, even very close, by ear. The tuner
is just used for fine tuning. Also, guitars tend to drift some but
not a lot. A guitar that was packed up a month ago is unlikely to be
so far out of tune that an autodetect mechanism would identify the
wrong string. And most musicians wouldn't fall for it even then.
Still, your idea of providing a display that shows which string was
detected is a good one, provided you can afford to add it in your
particular application.
-> > 1) Use a dual speed PLL to initially lock onto the strong
-> Would it really stay locked to the weak fundamental?
Yes, I believe so. A PLL CAN track a signal outside its capture range if
it has been locked onto it in the first place and its loop
characteristic are such that it resists change that is too fast (a
change from the fundamental to a harmonic can be considered a fast
change). When the harmonic comes into the capture range (close enough in
frequency and strong enough compared to the fundamental) the PLL won't
move to it because its loop characteristics inhibit fast change.
-> It can't be that easy, can it? I'm already amplifying and heavily
No, you're right, I goofed. I'm still trying to find the reference in
"The Art of Electronics" that got me confused on that one (An excellent
reference BTW. I highly recommend it).
-> > 4) Use the pic to implement an FIR or IIR filter.
->
-> What are these?
Digital filters. You need a very fast CPU with an analog front end.
-> How does one "purify a spectrum" with a PLL? What does that mean?
-> But yes of course it is possible to track changes in a harmonic as
-> readily as the fundamental.
What I mean by that is that A PLL will lock onto one spectral component
(frequency) if it is coherent, stays within the tracking range, and
doesn't change too fast (slew rate). If you take a standard audio range
PLL and pluck a guitar string the PLL's oscillator will be one
frequency; The base note (terminology correct?), and the phase should be
shifted at around 90 degrees from the fundamental. The PLL will either
stay locked onto the fundamental or switch abruptly to a harmonic if
that harmonic is strong enough.
By measureing the PLL's oscillator frequency, you arn't getting a lot of
noise due to harmonics. Its only one frequency, changing over time.
> Yes, I believe so. A PLL CAN track a signal outside its capture range if
> it has been locked onto it in the first place and its loop
> characteristic are such that it resists change that is too fast (a
> change from the fundamental to a harmonic can be considered a fast
> change).
Okay yeah this makes sense. I just need to make the loop fast enough to
lock onto the fundamental before the harmonic gets too strong (500 ms
response is plenty good enough) but slow enough that the almost-instant
switch to the harmonic doesn't -- scuse the pun -- phase it.
I'd really like to try this approach. What would be some audio PLLs to
use? Perhaps a 565? 567? Or are there more modern, better ones? I've
worked extensively with RF type PLLs (gotta whole drawer full of motorola
chips) but never worked with audio PLLs.
Incidentally, for anybody wanting to use a PIC to tune an RF circuit, I
highly recommend the MC145170 chip. It's cheap (about $8), readily
available (Hamilton Hallmark, Newark), and miraculous. Programmed with 3
wire interface. Reference modulus can be any number from 4(?) to 32767.
Programmable divider from 40 to 65535. Can be programmed to be
single-ended or dual-ended. Ref. output available. Sign of loop can be
inverted by programming. Can directly synthesize up to 160 mc. XTAL ref.
osc. on-board. 16 pin package. I've used these with PICs and they work
great.
All one needs is an audible tone refference to tune the guitar. As the two
tones get closer they cause a 'RING' which allows a semi skilled musician
to tune-a-fish.
Doug Sellner
Beach Tech
4131 Vincent Avenue South
Minneapolis MN 55410
> All one needs is an audible tone refference to tune the guitar. As the two
> tones get closer they cause a 'RING' which allows a semi skilled musician
> to tune-a-fish.
Using 'beating' to tune a guitar is fine and good when you can hear the
guitar and reference ...
There are many commercial tuning devices on the market, any which
I've looked inside are based on microcontroller technology. This is
a great application for a PIC.
> All one needs is an audible tone refference to tune the guitar. As the two
> tones get closer they cause a 'RING' which allows a semi skilled musician
> to tune-a-fish.
Yeah that "ring" is called beating. It's the difference between the two
frequencies. And you are right that lots of musicians use this technique
all the time and it works great.
However, a lot of musicians prefer to use electronic tuners, at least in
some situations. Particularly, stage musicians like to have them.
You're playing and a string breaks -- you finish the song, then hit a
foot pedal and suddenly your tuner (with visual indicator) is in circuit
and your amp is not. You tune up without bothering the audience, then
you're back in business. Or, let's say another band is playing, and your
band is up next. You probably couldn't hear yourself to tune, perhaps even
with a headset.
I personally am very accustomed to relying on my ears, a lot more than
electronic measuring devices. I've never tried to play an instrument on
stage that I didn't first check with my ears. But a lot of pro musicians
do this sort of thing all the time.
> > David, here are a few suggestions for a solution to your problem with
> > harmonics:
> >
> > 1) Use a dual speed PLL to initially lock onto the strong fundamental
.
.
.
> > spectrum (one frequency at a time) and do your function on the VCO
> > signal.
> >
> > 7) Use an analog input and implement a PLL in pic firmware, using a
> > combination of the above ideas.
> >
> > I really know absolutely nothing about music, but I hope these ideas are
> > usefull, or stimulate the formulation of new ones.
> >
> > Regards, Dana Frank Raymond - Foxtrot Systems Ltd.
> > Internet: EraseMEdana.raymondEraseMEcanrem.com. Compuserve: 73362,3052
>
> Please help my confusion - it seems to me that we are trying to over engineer
> what could be an easy solution.
Being a guitarist, and having used a tuner, and having attempted to design
a tuner, once, I'll share a bit of my experience. I don't think we're over-
engineering yet.
> Wouldn't the normal tuning process be:
> 1. "Pluck" the string.
> 2. Listen for it being sharp or flat.
> 3. Tune the string.
> 4. Re-pluck the string.
Guitarists pluck the string and adjust the tuning while it sounds, and I for
one would not consider it useful to have to stop the string and re-pluck
to check the adjusted frequency.
> If this is the case, why worry about decaying harmonics? Just count
> the number of zero crossings in 100 msec & compair to a table of expected
> values. If it is high or low out-of-range discard it & try again.
The upper harmonics do decay quite quickly. The first and second harmonic
can be a problem.
> Even if you tune on the fly ( i.e. pluck-listen-tune as a single process); I
> would think you could still get a good frequency sample after 2 sec. I could
> be wrong here - I've never tried it.
I normally don't get a useful tuning measurement out of my commercial tuner
until about 1/2 second after the string is plucked. If you can't get a
good frequency sample for 2-5 seconds/pluck, it is really laborious to
tune.
> I don't know much about guitars. But I think the difference between the
> 1st string (low E) and the 6th (high E) is 2 octaves. With a string way out-
> of-tune, I think it is possible to tune to the frequency of another string.
> Taking a string this far out-of-tune would be undetectable by your circuit.
> You may want to consider using 8 LEDs: 1 per string, plus a high and low
> indication. This would let you know which string the circuit thought you
> were tuning.
>
>
> Jon Poland
> Sun Microsystems Inc.
> St. Louis, MO
> (314) 569-4716
> @spam@jon.poland@spam@spam_OUTcentral.sun.com
The two E strings are indeed 2 octaves apart. You can indeed tune a string
down to the next one, if you try. The harmonics on a given pluck on a string
won't let you simply count zero crossings, as you can pluck to generate
harmonics or not. The zero crossings should be harmonically related, though.
The low E is about 82.41 Hz, the A is about 110.0 Hz, the high B is
247.2 Hz, high E is 329.6 Hz. Referenced to A-440Hz. It's very useful
to be able to adjust the reference of a tuner. Acoustic pianos are out
most of the time in most places.
Tim Braun |
Continental Healthcare Systems Canada | Voice: 204-942-2992 ext 228
1900-155 Carlton St | FAX: 204-942-3001
Winnipeg, Manitoba, Canada R3C 3H8 | Email: spamBeGonetimKILLspamchs.mb.ca
In a message I posted here yesterday, I said that the 16C57's FSR is
cleared on reset. This is, of course, incorrect. However, the advice
I gave Dave Kingma ("Remove the CLRF FSR and use my Clear-RAM routine")
is still applicable, so long as no registers outside the range [00-0F]
are accessed before the Clear-RAM routine executes.
Sorry for any confusion my late-night misstatement might have caused.
> I am trying to interface your PIC programming hardware
> to a Sun SS20.
As I have no experience with doing this I'll copy my comments
to the PICLIST just in case anybody can help you with some more
concrete advice.
> The Sun has a centronix type parallel port.
> I'm running into a problem where I think my parallel port
> needs a data strobe in order to read/verify data from the
> PIC that is being programmed.
It just so happens that I am using a Sun to write this message but
it's one of the low end machines which doesn't have a parallel port
(apart from SCSI - which might be another approach to consider I
guess) so I can't try anything here and what follows is pure
speculation.
If you look at the programming spec of the 16C84 you'll see that data
is clocked in or out of the PIC on the negative edge of the RB6
signal. It might be an idea to feed this signal (possibly inverted)
back into the strobe pin. If you get no joy, then, perverse as it
sounds, and again exploiting the fact that you know that data will be
valid on the negative edge of RB6, you could generate the required
strobe signal on one of the data out pins and simply feed this signal
back into the strobe pin.
>>(Do not ask me about details regarding this code, as I _not_ am the
>> author of this code - Kavli)
>
> No kidding, Ronny... How about asking the authors of FIDE for
> permission before you go posting their copyrighted code to the
> world? Or at least acknowledging the copyright?
Since Andrew Warren has forced me :-) to investigate in this, the
author of the code I supplied is Raymod Carr. I don't know if he was
employed by Aptronix at the time the code was written or if the code
was bought by Aptronix at a later date or whatever.
In any case Raymond should be acknowledged for writing that code.
Newer versions of the code can be found by anonymous ftp at:
ftp.gre.ac.uk:/pub/robotics/motorola/mcu11/
Regards,
-------------------------------------------------------------------------------
Ronny H. Kavli This message was composed by 10,000 monkeys RemoveMEkavlispamBeGoneludd.luth.se keying on 10,000 computers. It was then
Lulea Academic Computer Soc.(Ludd) merged using COBOL. This was of course
Lulea University, Sweden all done under a government contract.
>I using the parallax simulator for a PIC16C84 part, and cant get
>the simulation to do a jump to an indirect address. A jump to 0
>redirects program flow to instruction 0 rather than the address
>in FSR. Anyone have a similar problem or am I missing something
>simple?
Greg:
You're missing something simple. To do an indirect jump, you must load
the destination address into the Program Counter, not the FSR.
Try something like this:
.... ;COMPUTE THE DESTINATION ADDRESS, AND
.... ;STORE IT IN "ADDRHI" AND "ADDRLO".
MOVF ADDRHI,W ;GRAB THE HI-BYTE OF THE ADDRESS.
MOVWF PCLATH ;STORE IT.
MOVF ADDRLO,W ;GRAB THE LO-BYTE OF THE ADDRESS.
MOVWF PCL ;STORE IT. PROGRAM EXECUTION CONTINUES AT
;THE ADDRESS IN "ADDRHI:ADDRLO".
Andy,
Actually, I needed to do an indirect jump so I could write a
vector interrupt table without wasting any extra RAM. I'm trying
something like:
Setup for particular interrupt routine:
Assign routine # 1..255
MOVLW #
MOVWF FSR
In Vector Interrupt Table
MOVF FSR
ADDWF PCL
MOVWF PCL
GOTO ADDR1 (addr of subroutine 1)
GOTO ADDR2 (addr of subroutine 2)
.........
It's a bit of a nonconventional use of FSR, and FSR can't be used
between the assignment to a subroutine and the interrupt.
Also only one type of interrupt can be used at a time.
Notice also that the routine # must be <=250 or PCL will
overflow. Lastly, flags must be cleared and ,if needed, status
must be saved in the body of the subroutine. All that aside, it
does allow for changing interrupts on the fly and saves those 2
bytes of RAM.
Anyone else have a favorite way of doing an interrupt table that
can by modified on the fly?
>Actually, I needed to do an indirect jump so I could write a
>vector interrupt table without wasting any extra RAM. I'm trying
>something like:
>
>Setup for particular interrupt routine:
>Assign routine # 1..255
>
>MOVLW #
>MOVWF FSR
>
>
>In Vector Interrupt Table
>
>MOVF FSR
>ADDWF PCL
>MOVWF PCL
>GOTO ADDR1 (addr of subroutine 1)
>GOTO ADDR2 (addr of subroutine 2)
>.........
>
The concept is OK, but the implementation is flawed. First, when getting
the *data* from an indirect location in RAM, you need to use INDF (register
0), which is a 'shadow' of the location pointed to by FSR. The MOVF FSR is
going to just get the constant routine number you loaded into it at first,
FSR is the *address pointer* for indirect data, not the data itself.
Secondly, the ADDWF PCL without specifying ,0 or ,w is going to leave the
result in PCL, i.e. execute the jump immediately. Thus, the MOVWF PCL is
not executed (unless 0 is added, then it causes real trouble), and the
entries in the table are one location off.
There is really no need to use a table of GOTOs, since you can vector
directly to routines by setting the vectors in RAM to the addresses of the
routines themselves (unless the routines are in the high part of the code
pages, but since you said this is an interrupt routine, a 14-bit PIC can
handle this OK by setting PCLATH accordingly).
So the vector part of the routine could be rewritten as:
MOVLW rtn#
MOVWF FSR
MOVFW INDF
MOVWF PC
Now, suppose that valid routines are located at addresses 030, 060 and 090
in program space. Further, a table in RAM beginning at address 18 contains
the addresses, 30, 60, and 90. If rtn# above is set to 19, then the routine
at address 60 will be executed. First FSR will be loaded with 19, which
makes INDF a 'shadow' of the RAM byte containing 60. Then the 60 is loaded
and transferred to PC. Later this same code can be made to execute another
routine by storing the address of that routine in RAM location 19.
Remember, when doing computed jumps of this nature, be sure the page select
bits or PCLATH register (depending on PIC type) are setup correctly, as the
computed part of the address is only the low 8 bits.
Mike,
Believe it or not, I am using FSR just as an extra byte of RAM,
not as it is normally used to indirectly address memory. That's
why I said my code was an unconventional use of FSR. Secondly, I
wrote my own assembler that has some different defaults...sorry
if the lack of arguments confused some people. It does produce
correct machine code with my software...I swear!
There are a couple of problems with your approach for my
application. (1) As you mentioned, vectoring directly to routines
instead of using a table is simpler but cannot access program
locations in high memory. I'm using the PIC16c84, so that means
almost 3/4 of the 1k program space cannot be accessed. As Andy
pointed out, and you implied, you can use an extra byte of RAM to
store access the PC through PLATH. As I said in my previous
post, I can't afford to lose two bytes of RAM and therefore need
the table of goto statements.
(2)So it would follow that your idea of a table in RAM would not
work for me, even more so if it had to store two bytes for every
routine address.
So I hope my use of FSR is clear here. I'm using it as a
temporary storage location for a routine # to be jumped to on
interrupt. The main interrupt routine uses the value to jump to a
table of goto statements in program memory. If you have plently
of RAM but program memory is at a premium, it might be wise to
used 2 bytes of ram as temp locations for the routine address.
Otherwise, a table of goto's can save those 2 bytes.
>Hmmm... Maybe take the MPSIM simulator and roll it underneath of the new fully
>windows version of PICMaster software to create an integrated design environmen
t
>where emulation and simulation were interchangeable. Would we do something lik
e
>that?
>tick tock tick tock .....
Quit teasing, Brian... You guys already showed MPLAB at the Embedded Systems
Conference.
For those people who weren't there, here's a quick overview of MPLAB:
It combines an integrated editor (based on PFE) with an enhanced PIC-Master
interface. Source-code level debugging is MUCH better than PICMASTR's, and
the
simulator is integrated, too (well... it will be soon; my pre-release copy
doesn't include it). It handles C source-code as easily as Assembly, AND...
(drumroll, please...) IT REMEMBERS THE CLOCK SPEED!
MPSIM has always been the most accurate, complete, and up-to-date PIC simula
tor
available, but it was hampered by an unbelievably bad user interface. Now t
hat
it has the same interface as PIC-Master, it blows all the third-party simula
tors
away. You guys without emulators are in for a treat.
> For those people who weren't there, here's a quick overview of MPLAB:
>
> It combines an integrated editor (based on PFE) with an enhanced
PIC-Master
> interface. Source-code level debugging is MUCH better than PICMASTR's,
and
> the
> simulator is integrated, too (well... it will be soon; my pre-release copy
> doesn't include it). It handles C source-code as easily as Assembly,
AND...
> (drumroll, please...) IT REMEMBERS THE CLOCK SPEED!
>
> MPSIM has always been the most accurate, complete, and up-to-date PIC
simula
> tor
> available, but it was hampered by an unbelievably bad user interface. Now
t
> hat
> it has the same interface as PIC-Master, it blows all the third-party
simula
> tors
> away. You guys without emulators are in for a treat.
>
> -Andy
I'm off. This is the tenth spam in two weeks time, and I'm not
going to take this anymore.
Frank
"Mutual respect, even if we disagree."
------------------------------------------------------------------------
Frank A. Vorstenbosch +31-(70)-355 5241 @spam@falstaffspam_OUT.....xs4all.nl
...
>Sure, but contrary to what that substandard simulator shows, it can't
....
BTW, is there somewhere a list of differences between the simulator and the
real part (w/ respect to the '84, mainly) ? I just noticed one other 'bug':
The sim won't preload the EEPROM memory - definitely a drawback if you want
to use this memory to initialize a few random numbers.
>I just got eprom eraser today, and I don't think is working.
>Should I be able to see the UV light source when it is on, I know tis
>is bad to look directly into? It has a dot that is supposed to glow
>when it is working, and is not. Does is sound like I got a bad unit?
>
>I have a:
>Dataerase II from JDR
>(no timer)
Ben:
Do not, do not, DO NOT look at the bulb. The fluorescent "dot" is
there for a reason.
As I recall, those Daterase II erasers have a safety-interlock switch
in the top cover to protect you from accidentally turning on the lamp
with the cover open. My guess is that that interlock is keeping the
thing from turning on.
Make sure that the cover's properly installed in the grooves, and that
it's closed COMPLETELY (you should hear a little click as the interlock
engages), then try it again.
Maurice (and all you guys who asked in private e-mail):
A year before I was born, J. E. Bresenham figured out a way to draw
lines on a bit-mapped display (well, ok... He was using a plotter, but
if he'd HAD a bit-mapped display, that's what he WOULDhave been using).
His algorithm uses only simple integer math -- no divides and (except
for a few multiply-by-2's outside the main loop) no multiplications.
I'm not going to give the mathematical derivation of the algorithm
here; anyone who wants it can send me private e-mail.
Here's the basic algorithm. In this form it only works for lines whose
slope is between 0 and 1 (that is, the angle of the line is between 0
and 45 degrees); it can be easily generalized for steeper or negative
slopes.
Enter with x1, y1 = starting endpoint; x2, y2 = ending endpoint.
dx = abs(x2-x1) [x-distance]
dy = abs(y2-y1) [y-distance]
switch = 2*dy - dx [initial value of the "do we just
increment x this time, or do we
increment x and y?" switch]
incx = 2*dy [when we just increment x, this value
gets added to the switch]
incxy = 2*(dy-dx) [when we increment both x and y, this
value gets added to the switch]
if x1 > x2 then [start the line at the smaller of the
x = x2 two endpoints' x-coordinates, and set
y = y2 the ending x-coordinate to the larger]
endx = x1
else
x = x1
y = y1
endx = x2
LOOP:
PLOT (x,y) [plot the current pixel]
if x < endx then [if we haven't finished the line....]
x = x + 1 [increment the current x-coordinate[
if switch < 0 then [see below]
switch = switch + incx [see below]
else [see below]
y = y + 1 [see below]
switch = switch + incxy [see below]
goto LOOP [loop back and plot this point]
end [x = xend, so we're done]
Ok...
The "switch" variable works as follows:
Imagine an "ideal" line from (x1,y1) to (x2,y2). It passes through an
infinite number of points, very few of which actually have integral
coordinates. Here's a really awful picture:
O O O O
(g)
.....
(c) (e) .....
O O O..... O
..... (f)
.....
.....
.....
O O O O
(a) (b) (d)
Each of the O's represent a point on our bit-mapped display, and the
"....." represents the "ideal" line starting at point (a), passing
between points (b) and (c), passing just below point (e), then
continuing between points (f) and (g).
Note that, because the text of this message is on a strict x/y grid
(unless you're reading this in a proportional font, in which case the
ASCII art above will look UNBELIEVABLY bad), my "ideal" line is just a
finer-scale version of the "bit-mapped" line that will approximate it.
Ironic, no?
So. We know that the line starts at point (a), so we make our x and y
equal to the coordinates of point (a) and plot it. So far, so good.
Now, we know that our slope is no more than 45 degrees (by definition),
so we know that our next pixel will be in the row to the right of the
one containing that first point, so we increment x.
Now we need to decide whether the line is closer to point (b) or to
point (c) [we know it must be one or the other, since, again, we know
that the line slopes in the positive direction, at an angle of no more
than 45 degrees]. The "switch" variable makes this decision for us; it
accumulates the error between the "ideal" line and the bit-mapped
approximation. If the error would be lessened by simply incrementing
x (that is, if the "switch" variable is less than 0), we leave the
y-coordinate alone and add a positive number ("incx") to the "switch"
variable. Otherwise, we increment the y-coordinate, too, and add a
negative number ("incxy") to the "switch" variable.
In this way, "switch" oscillates back and forth between negative and
positive values; since the values of "incx" and "incxy" are usually
different, "switch" is positive either more or less often than it's
negative. For instance, if "incx" = 2 and "incxy" = -6, "switch" will
be negative more often than it's positive, so we'll draw a "flatter"
line.
In this case, "switch" is positive, so we'll increment the
y-coordinate, add the negative number "incxy" to "switch", and plot
point (c). [Point (b) is actually closer, but the algorithm "gets off
on the wrong foot" when the slope is between 1/2 and 1. It doesn't
really matter.]
The next time through the loop, "switch" will be negative, so the
algorithm will choose point (e) over point (d).
The third time through the loop, "switch" will still be negative, so
the algorithm will choose point (f) over point (g), and so on...
The only real way to understand this algorithm is to try it; pick a
couple of endpoints and work through the pseudo-code above. It's
pretty cool.
Oh, yeah... I mentioned that this algorithm can be used to determine
PWM duty-cycles. Here's how:
Set x1 = 0 and x2 = 100.
Set y1 = 0 and y2 = 100 * desired percentage of full-scale voltage
Delete every line of the pseudo-code that references "x" or "y".
After "switch = switch + incx", add "turn off the output".
After "switch = switch + incxy", add "turn on the output".
This'll produce a PWM output with a resolution of 1/100 of full-scale.
What's really cool is that its output will be much easier to filter
than the output from the hardware PWM generators in the midrange and
high-end PICs, because it'll dynamically adjust the PWM frequency to
the maximum possible.
For example, let's say you want to produce a 1% duty-cycle PWM signal.
Using the 16C74's PWM generator, you'd set the frequency register to
100 and the duty-cycle register to 1 [I may be off by one here, or you
might have to set the duty-cycle register to 99 -- I don't have the
data book in front of me -- but you get the idea]. This will produce a
1-unit pulse, followed by a 99-unit gap: Exactly what you want.
The Bresenham algorithm will do the same.
Here's the important point:
Let's say that you now want to adjust the duty-cycle to 50%. Using the
PIC's hardware, you'd change the duty-cycle register to 50. This will
produce a 50% duty-cycle, all right, but it'll be running at a very
slow frequency: On for 50 units, then off for 50 units.
On the other hand, the Bresenham algorithm will produce 1-unit pulses
separated by 1-unit gaps, having automatically adjusted the PWM
frequency to 50 times the frequency of the 1% PWM signal.
Sorry this message turned out to be so long... Aren't you glad that I
didn't include the mathematical derivation, too?
-Andy
P.S. As though his previous accomplishment weren't enough, in 1977,
Bresenham discovered (and J. Michener later formalized) a
circle-drawing algorithm that's even simpler than his algorithm
for drawing lines. It requires nothing more complicated than
integer addition, subtraction, and multiplication by 4, and it
uses even fewer variables than the line-draw algorithm.
>
> Maurice Rabb <.....totemRemoveMEMCS.COM> wrote:
>
> >Ok Andy, what is the Bresenham algorithm?
>
>
> P.S. As though his previous accomplishment weren't enough, in 1977,
> Bresenham discovered (and J. Michener later formalized) a
> circle-drawing algorithm that's even simpler than his algorithm
> for drawing lines. It requires nothing more complicated than
> integer addition, subtraction, and multiplication by 4, and it
> uses even fewer variables than the line-draw algorithm.
>
> That Bresenham... What a guy!
>
I have used both routines in the past, and they work great. Often times
the brute force method is not the best.
--
John C. Perez <.....kajcp00STOPspam@spam@JCP.EN.TAIU.EDU> wrote:
>>
>> Maurice Rabb <totemEraseME@spam@MCS.COM> wrote:
>>
>> >Ok Andy, what is the Bresenham algorithm?
>>
>>
>> P.S. As though his previous accomplishment weren't enough, in 1977,
>> Bresenham discovered (and J. Michener later formalized) a
>> circle-drawing algorithm that's even simpler than his algorithm
>> for drawing lines. It requires nothing more complicated than
>> integer addition, subtraction, and multiplication by 4, and it
>> uses even fewer variables than the line-draw algorithm.
>>
>> That Bresenham... What a guy!
>>
>
>I have used both routines in the past, and they work great. Often times
>the brute force method is not the best.
Both sound a lot like Babbage's "Difference Engine", a mechanical computer
which added and subtracted to iteratively generate tables of complex
functions. For example, knowing that the sine and cosine are derivitives of
each other,
d(sin(x))/dx = cos(x)
d(cos(x))/dx = - sin(x)
a table of sines and cosines can be generated by a 'difference engine' using
two variables and adding them to each other. They will vary in sine/cosine
fashion.
Initialize
s=0, c=1
Iterate:
s = s + k*c
c = c - k*s
k is a constant less than 1. It determines the number of steps (I believe
something like number of steps = 2pi / k.)
Given some time, this produces a table of sines and cosines. It is not a
good way to find sin(x) for any x in a single step. But it is excellent for
drawing a circle on a raster display.
It is interesting how thinking goes in cycles. For a while it was "Hey, we
have a *real computer* now, no need to deal with the archaic difference
engine." Eventually many old ideas are re-discovered; only the names are
changed. Another example is the differential amplifier, (or feedback in
general), which went through a lull for quite a while until the op-amp hit
the market and designers *had* to use it.
Mike Keitz <RemoveMEmkeitzspamBeGoneBEV.NET> wrote:
>> Maurice Rabb <spamBeGonetotemKILLspam@spam@MCS.COM> wrote:
>>
>> >Ok Andy, what is the Bresenham algorithm?
>>
>> .....
>> P.S. As though his previous accomplishment weren't enough, in 1977,
>> Bresenham discovered (and J. Michener later formalized) a
>> circle-drawing algorithm that's even simpler than his algorithm
Both sound a lot like Babbage's "Difference Engine", a mechanical computer
which added and subtracted to iteratively generate tables of complex
functions. For example, knowing that the sine and cosine are derivitives of
each other,
d(sin(x))/dx = cos(x)
d(cos(x))/dx = - sin(x)
a table of sines and cosines can be generated by a 'difference engine' using
two variables and adding them to each other. They will vary in sine/cosine
fashion.
In general, this iterative method is generalized in CORDIC algorithms,
a popular method of calculating most elementary functions and even FP
multiply and division. It was first used, I believe, in HP
calculators, because it needs very little hardware to implement, and
later in some floating point hardware and libraries. Recently, it had
been somehow abandoned because of its inherently bit-serial
nature (it generates 1 bit per iteration).
A reasonably recent reference is :
Jarvis, P.: Implementing Cordic Algorithms.
Dr. Dobb's Journal, Vol. 15, No. 10, October 1990, pp. 152-158
przemek klosowski (przemekspam_OUT@spam@nist.gov)
Reactor Division (bldg. 235), E111
National Institute of Standards and Technology
Gaithersburg, MD 20899, USA
>simulator in http://www.ultranet.com/biz/mchip but i could not
>get them .because our INTERNET line in IRAN is very slow(9600 bps).
>so i have a new request.may you treat me kindly and send me these programs
>by e-mail? if you have in mind to do this kindness please use uuencode
>A.Marami
There are many computers around the world to do just that! They're called
FTP by Mail servers. One is at spamBeGoneftpmail@spam@SunSITE.Unc.EDU, but you should use
one that is close to you. You tell it (via email) where the file is and it
will get the file and email it to you. Easy to use. Some sites have long
waiting lists but others are very quick.
At 01:04 PM 10/23/95 -0600, you wrote:
>I don't know how to get this note to the list - It keeps getting bounced back
>because it is supposedly identical to a "previous" note. Maybe this sentence
>will help???
I believe it is because your message is 95% quoting! Unless the message is
very old (over 2 weeks) that you are replying to you don't need to quote
much for people to know what it is about. They likely read it and can
recall. If not they can always look it up. Try to only quote relevant
lines, not the whole message. It just bogs down the systems when you quote
to much.
> Could you tell us how much the PIC14000 is selling for?
This is the only line you needed. The rest is irrelevant.
Note that as a time/space tradeoff the algorithm may be improved by
observing that it will always [except at the two endpoints] go between
taking 'n' clicks per step and 'n+1' clicks per step [for some n].
Thus, rather than incrementing 'step' by dy for each x-click, it can
be incremented by [n*dy] for each n x-clicks; then, if needed, it can
be bumped another [dy] and another x-click added. For long, shallow,
lines this can substantially cut loop overhead.
Note too, [cute piece of recursion here] that if you're slope is such
that the line goes n steps, n, n, n+1, n, n, n, n+1, etc. that the number
of 'n's between 'n+1's will be either 'm' or 'm+1' for some m [or it may
happen that it goes n+1, n+1, n+1, n, n+1, n+1, n+1, n in which case the
number of 'n+1's between 'n's is either 'm' or 'm+1']. Etc.
> Oh, yeah... I mentioned that this algorithm can be used to determine
> PWM duty-cycles. Here's how:
> After "switch = switch + incx", add "turn off the output".
> After "switch = switch + incxy", add "turn on the output".
>
> This'll produce a PWM output with a resolution of 1/100 of full-scale.
> What's really cool is that its output will be much easier to filter
> than the output from the hardware PWM generators in the midrange and
> high-end PICs, because it'll dynamically adjust the PWM frequency to
> the maximum possible.
This approach to PWM'ing is even better if you simply code it as:
movfw value
addwf phase
rlf output
The one point to be careful of with this form of pwm'ing is that you will
have low-frequency components in the output if the 'value' has 1's in the
lower bits [if the LSB is 1, there will be a 1/256 sample rate component
in the output]. If an RC filter is used on the output, this component will
be strongest when value is near its minimum and maximum values. To avoid
odd audio properties, you may wish to zero out the last few bits of value
and force the next bit to be a '1'. This will trade off the number of bits
of precision for a reduction in lower-frequency noise.
>P.S. As though his previous accomplishment weren't enough, in 1977,
> Bresenham discovered (and J. Michener later formalized) a
> circle-drawing algorithm that's even simpler than his algorithm
> for drawing lines. It requires nothing more complicated than
> integer addition, subtraction, and multiplication by 4, and it
> uses even fewer variables than the line-draw algorithm.
>
> That Bresenham... What a guy!
>
>--
>Andrew Warren - .....fastfwdRemoveMEix.netcom.com
>Fast Forward Engineering, Vista, California
So, whats the circle-drawing algorithm? ;-) Seriously, you don't need to
make another long great post if you don't have time. I am mainly
interested in the reference you recommend for Bresenham's algorithms. As I
said to another person who also responded to my question,
>Ironically, the algorithm is not mentioned in my copy of "Introduction to
>Algorithms" by Cormen. It is one of my heaviest textbooks from college. It
>weighs in at 6.5 pounds!
Sincerely,
--Maurice
----------------------
Maurice Rabb
Totem Consulting
(312) 281-6003 totem@spam@mcs.com
----------------------
(I hope Microchip folks listen, and correct me if I'm wrong!) I have
heard the following reasons from Microchip reps:
1. Why not more EEPROM PICs: Microchip's EEPROM technology
requires a lot of silicon area. Other features are not worth trading
off for EEPROM.
2. Why not use more space efficient flash prom technology: Microchip
would have to license such technology from outside, which is not part
of their policy.
3. Micro chip believes few (big) customers are interested in EEPROM.
Allegedly, they use only OTP-versions for volume production. For
development, UV-EPROM are considered enough. The ability to reprogram
in-circuit is considered to be of marginal importance. (At several PIC
seminars I have visited, participants have stressed it would be useful
to be able to reprogram new versions, test programs etc., in
circuit, in particular for SMD PICs, but Microchip has not commented
on this.)
4. Actually, it has turned out that the 16C84 does sell very well, but
Microchip attributes this to the EE-programmable _data_ memory, not
_program_ memory. This interest is ascribed to students and hobbyists
(i.e. not much of a business).
I do hope that Microchip will rethink its strategy regarding
EEPROM. In particular, a 16C73 with EEPROM/Flash PROM would be close
to the ultimate microcontroller, in my opinion. Other companies, for
instance Intel, are now beginning to catch up here.
Martin Nilsson
Swedish Institute of Computer Science E-mail: EraseMEmnRemoveMESTOPspamsics.se
Box 1263, S-164 28 Kista Fax: +46-8-751-7230
Sweden Tel: +46-8-752-1574
> Date: Tue, 31 Oct 1995 17:50:09 -0500
> From: Chris Smolinski <RemoveMEcpsKILLspamTakeThisOuTACCESS.DIGEX.NET>
> Subject: Re: Bulk Buy of 16C84?
>
> > Is there interest in doing a bulk buy of PIC 16C84's, or perhaps
> >another PIC? I know this one is very popular due to eeprom, and I need
> >several for upcoming projects. I thought if there is interest, I would
> >try to put together a bulk purchase and save everyone some money.
> > I was thinking of the of the 10 Mhz, 18 pin Dip package. By
> >getting the faster speed everyone will be satisfied, even though it cost
> >a little more. If there is interest in 25 units, we can get a
> >decent discount over the 1 piece price. If there is interest in
> >100 or 1000 it is much cheaper, I like to be optimistic.
> > If your interested, email me directly with aproximate of how many
> >you might be interested in. I will put everyone who is intersted on a
> >email macro to keep you up to date. I wished I could publish prices, but
> >I want to see what kind of price break we can get first based on
> >the interest poll. (It should definately be <$10)
> >
>
> I'm planning on using the PIC16C84 in a project at work, and checked
> pricing. I need about 500 of 'em (two build two systems, each has 256 PICs,
> each PIC monitors a photodiode to check for a pulse of light at a certain
> time, and then processes the information and presents it on a common bus to
> be read by a 486. I wonder if this would be a record for the most PICs in a
> single product???)
>
> Anyway, I was quoted around $5 or so each. I'll have to check the pricing
> info at work tomorrow to make sure. If you can get the volume up, you
> certainly should get the price break.
>
> Any idea why Microchip doesn't make any other PICs with EE program memory?
> I need the ability to re-program the PICs in-circuit, so that left the
> 16C84 as the only possibility.
However, we are still a relatively small company and out of the
1,000,000 things we have to do, program memory EEPROM PIC's are about
number 736,492.
Also, when we ask our larger customers (who don't need to get together
to make bulk buys) what they will pay for a reprogrammable 16C73 as
opposed to a EPROM 16C73, the answer just isn't the one we want to
hear.
Everyone out there really needs to talk to a guy in Taiwan who will
give his mother and his left nut for a micro that costs 10 cents less.
The real world can be a scary place!
______________________________ Reply Separator _________________________________
Subject: Why not EEPROM PICs? (Was: Bulk Buy of 16C84)
Author: Martin Nilsson <RemoveMEmnspam_OUTSICS.SE> at Internet_Exchange
Date: 11/1/95 2:13 PM
(I hope Microchip folks listen, and correct me if I'm wrong!) I have
heard the following reasons from Microchip reps:
1. Why not more EEPROM PICs: Microchip's EEPROM technology
requires a lot of silicon area. Other features are not worth trading
off for EEPROM.
2. Why not use more space efficient flash prom technology: Microchip
would have to license such technology from outside, which is not part
of their policy.
3. Micro chip believes few (big) customers are interested in EEPROM.
Allegedly, they use only OTP-versions for volume production. For
development, UV-EPROM are considered enough. The ability to reprogram
in-circuit is considered to be of marginal importance. (At several PIC
seminars I have visited, participants have stressed it would be useful
to be able to reprogram new versions, test programs etc., in
circuit, in particular for SMD PICs, but Microchip has not commented
on this.)
4. Actually, it has turned out that the 16C84 does sell very well, but
Microchip attributes this to the EE-programmable _data_ memory, not
_program_ memory. This interest is ascribed to students and hobbyists
(i.e. not much of a business).
I do hope that Microchip will rethink its strategy regarding
EEPROM. In particular, a 16C73 with EEPROM/Flash PROM would be close
to the ultimate microcontroller, in my opinion. Other companies, for
instance Intel, are now beginning to catch up here.
Martin Nilsson
Swedish Institute of Computer Science E-mail: mnspamsics.se
Box 1263, S-164 28 Kista Fax: +46-8-751-7230
Sweden Tel: +46-8-752-1574
> Date: Tue, 31 Oct 1995 17:50:09 -0500
> From: Chris Smolinski <spam_OUTcpsspam_OUTspam_OUTACCESS.DIGEX.NET>
> Subject: Re: Bulk Buy of 16C84?
>
> > Is there interest in doing a bulk buy of PIC 16C84's, or perhaps
> >another PIC? I know this one is very popular due to eeprom, and I need
> >several for upcoming projects. I thought if there is interest, I would
> >try to put together a bulk purchase and save everyone some money.
> > I was thinking of the of the 10 Mhz, 18 pin Dip package. By
> >getting the faster speed everyone will be satisfied, even though it cost
> >a little more. If there is interest in 25 units, we can get a
> >decent discount over the 1 piece price. If there is interest in
> >100 or 1000 it is much cheaper, I like to be optimistic.
> > If your interested, email me directly with aproximate of how many
> >you might be interested in. I will put everyone who is intersted on a
> >email macro to keep you up to date. I wished I could publish prices, but
> >I want to see what kind of price break we can get first based on
> >the interest poll. (It should definately be <$10)
> >
>
> I'm planning on using the PIC16C84 in a project at work, and checked
> pricing. I need about 500 of 'em (two build two systems, each has 256 PICs,
> each PIC monitors a photodiode to check for a pulse of light at a certain
> time, and then processes the information and presents it on a common bus to
> be read by a 486. I wonder if this would be a record for the most PICs in a
> single product???)
>
> Anyway, I was quoted around $5 or so each. I'll have to check the pricing
> info at work tomorrow to make sure. If you can get the volume up, you
> certainly should get the price break.
>
> Any idea why Microchip doesn't make any other PICs with EE program memory?
> I need the ability to re-program the PICs in-circuit, so that left the
> 16C84 as the only possibility.
However, we are still a relatively small company and out of the
1,000,000 things we have to do, program memory EEPROM PIC's are about
number 736,492.
Also, when we ask our larger customers (who don't need to get together
to make bulk buys) what they will pay for a reprogrammable 16C73 as
opposed to a EPROM 16C73, the answer just isn't the one we want to
hear.
Everyone out there really needs to talk to a guy in Taiwan who will
give his mother and his left nut for a micro that costs 10 cents less.
The real world can be a scary place!
______________________________ Reply Separator _________________________________
Subject: Why not EEPROM PICs? (Was: Bulk Buy of 16C84)
Author: Martin Nilsson <RemoveMEmnKILLspam@spam@SICS.SE> at Internet_Exchange
Date: 11/1/95 2:13 PM
(I hope Microchip folks listen, and correct me if I'm wrong!) I have
heard the following reasons from Microchip reps:
1. Why not more EEPROM PICs: Microchip's EEPROM technology
requires a lot of silicon area. Other features are not worth trading
off for EEPROM.
2. Why not use more space efficient flash prom technology: Microchip
would have to license such technology from outside, which is not part
of their policy.
3. Micro chip believes few (big) customers are interested in EEPROM.
Allegedly, they use only OTP-versions for volume production. For
development, UV-EPROM are considered enough. The ability to reprogram
in-circuit is considered to be of marginal importance. (At several PIC
seminars I have visited, participants have stressed it would be useful
to be able to reprogram new versions, test programs etc., in
circuit, in particular for SMD PICs, but Microchip has not commented
on this.)
4. Actually, it has turned out that the 16C84 does sell very well, but
Microchip attributes this to the EE-programmable _data_ memory, not
_program_ memory. This interest is ascribed to students and hobbyists
(i.e. not much of a business).
I do hope that Microchip will rethink its strategy regarding
EEPROM. In particular, a 16C73 with EEPROM/Flash PROM would be close
to the ultimate microcontroller, in my opinion. Other companies, for
instance Intel, are now beginning to catch up here.
Martin Nilsson
Swedish Institute of Computer Science E-mail: mnspamBeGone.....sics.se
Box 1263, S-164 28 Kista Fax: +46-8-751-7230
Sweden Tel: +46-8-752-1574
> Date: Tue, 31 Oct 1995 17:50:09 -0500
> From: Chris Smolinski <KILLspamcps.....ACCESS.DIGEX.NET>
> Subject: Re: Bulk Buy of 16C84?
>
> > Is there interest in doing a bulk buy of PIC 16C84's, or perhaps
> >another PIC? I know this one is very popular due to eeprom, and I need
> >several for upcoming projects. I thought if there is interest, I would
> >try to put together a bulk purchase and save everyone some money.
> > I was thinking of the of the 10 Mhz, 18 pin Dip package. By
> >getting the faster speed everyone will be satisfied, even though it cost
> >a little more. If there is interest in 25 units, we can get a
> >decent discount over the 1 piece price. If there is interest in
> >100 or 1000 it is much cheaper, I like to be optimistic.
> > If your interested, email me directly with aproximate of how many
> >you might be interested in. I will put everyone who is intersted on a
> >email macro to keep you up to date. I wished I could publish prices, but
> >I want to see what kind of price break we can get first based on
> >the interest poll. (It should definately be <$10)
> >
>
> I'm planning on using the PIC16C84 in a project at work, and checked
> pricing. I need about 500 of 'em (two build two systems, each has 256 PICs,
> each PIC monitors a photodiode to check for a pulse of light at a certain
> time, and then processes the information and presents it on a common bus to
> be read by a 486. I wonder if this would be a record for the most PICs in a
> single product???)
>
> Anyway, I was quoted around $5 or so each. I'll have to check the pricing
> info at work tomorrow to make sure. If you can get the volume up, you
> certainly should get the price break.
>
> Any idea why Microchip doesn't make any other PICs with EE program memory?
> I need the ability to re-program the PICs in-circuit, so that left the
> 16C84 as the only possibility.
______________________________ Reply Separator _________________________________
Subject: Why not EEPROM PICs? (Was: Bulk Buy of 16C84)
Author: Martin Nilsson <spam_OUTmnKILLspamSICS.SE> at Internet_Exchange
Date: 11/1/95 2:13 PM
(I hope Microchip folks listen, and correct me if I'm wrong!) I have
heard the following reasons from Microchip reps:
1. Why not more EEPROM PICs: Microchip's EEPROM technology
requires a lot of silicon area. Other features are not worth trading
off for EEPROM.
2. Why not use more space efficient flash prom technology: Microchip
would have to license such technology from outside, which is not part
of their policy.
3. Micro chip believes few (big) customers are interested in EEPROM.
Allegedly, they use only OTP-versions for volume production. For
development, UV-EPROM are considered enough. The ability to reprogram
in-circuit is considered to be of marginal importance. (At several PIC
seminars I have visited, participants have stressed it would be useful
to be able to reprogram new versions, test programs etc., in
circuit, in particular for SMD PICs, but Microchip has not commented
on this.)
4. Actually, it has turned out that the 16C84 does sell very well, but
Microchip attributes this to the EE-programmable _data_ memory, not
_program_ memory. This interest is ascribed to students and hobbyists
(i.e. not much of a business).
I do hope that Microchip will rethink its strategy regarding
EEPROM. In particular, a 16C73 with EEPROM/Flash PROM would be close
to the ultimate microcontroller, in my opinion. Other companies, for
instance Intel, are now beginning to catch up here.
Martin Nilsson
Swedish Institute of Computer Science E-mail: RemoveMEmnRemoveMEEraseMEsics.se
Box 1263, S-164 28 Kista Fax: +46-8-751-7230
Sweden Tel: +46-8-752-1574
> Date: Tue, 31 Oct 1995 17:50:09 -0500
> From: Chris Smolinski <KILLspamcpsspamBeGoneACCESS.DIGEX.NET>
> Subject: Re: Bulk Buy of 16C84?
>
> > Is there interest in doing a bulk buy of PIC 16C84's, or perhaps
> >another PIC? I know this one is very popular due to eeprom, and I need
> >several for upcoming projects. I thought if there is interest, I would
> >try to put together a bulk purchase and save everyone some money.
> > I was thinking of the of the 10 Mhz, 18 pin Dip package. By
> >getting the faster speed everyone will be satisfied, even though it cost
> >a little more. If there is interest in 25 units, we can get a
> >decent discount over the 1 piece price. If there is interest in
> >100 or 1000 it is much cheaper, I like to be optimistic.
> > If your interested, email me directly with aproximate of how many
> >you might be interested in. I will put everyone who is intersted on a
> >email macro to keep you up to date. I wished I could publish prices, but
> >I want to see what kind of price break we can get first based on
> >the interest poll. (It should definately be <$10)
> >
>
> I'm planning on using the PIC16C84 in a project at work, and checked
> pricing. I need about 500 of 'em (two build two systems, each has 256 PICs,
> each PIC monitors a photodiode to check for a pulse of light at a certain
> time, and then processes the information and presents it on a common bus to
> be read by a 486. I wonder if this would be a record for the most PICs in a
> single product???)
>
> Anyway, I was quoted around $5 or so each. I'll have to check the pricing
> info at work tomorrow to make sure. If you can get the volume up, you
> certainly should get the price break.
>
> Any idea why Microchip doesn't make any other PICs with EE program memory?
> I need the ability to re-program the PICs in-circuit, so that left the
> 16C84 as the only possibility.
> Everyone out there really needs to talk to a guy in Taiwan who will
> give his mother and his left nut for a micro that costs 10 cents less.
> The real world can be a scary place!
What is the E-mail address of this guy in Taiwan, I can't get constant
prices or supplies in Australia, and MicroChip offer no alternatives for
me.
I look like chucking in with Ben and friends at this stage.
I could say more but will bite my lower lip for now!!!!!
> > Everyone out there really needs to talk to a guy in Taiwan who will
> > give his mother and his left nut for a micro that costs 10 cents less.
> > The real world can be a scary place!
>
> What is the E-mail address of this guy in Taiwan, I can't get constant
> prices or supplies in Australia, and MicroChip offer no alternatives for
> me.
I'm not trying to single out anyone in particular but I'm curious to know
whether the people who complain so much about price, etc. sell their own
products, services, labor at bargain basement prices just because the
people who buy from them don't want to pay very much?
When you see low prices like Mot 6805J1A's for <$2 you have to remember
that they're on allocation half the time, they're more difficult to buy
in one's and tens, etc. Considering the overhead involved I doubt if any
manufacturer of mcu's would be in business on the money they make (lose?)
selling one or two pieces to an individual.
I'm not affiliated with Microchip. They're just one of the many suppliers
I deal with in an effort to earn a living for my family.
>>> Everyone out there really needs to talk to a guy in Taiwan who will
>>> give his mother and his left nut for a micro that costs 10 cents
>>> less.
>>> The real world can be a scary place!
>> What is the E-mail address of this guy in Taiwan, I can't get constant
>> prices or supplies in Australia, and MicroChip offer no alternatives
>> for me.
> I'm not trying to single out anyone in particular but I'm curious to
> know whether the people who complain so much about price, etc. sell
> their own products, services, labor at bargain basement prices just
> because the people who buy from them don't want to pay very much?
> When you see low prices like Mot 6805J1A's for <$2 you have to remember
> that they're on allocation half the time, they're more difficult to buy
> in one's and tens, etc. Considering the overhead involved I doubt if
> any manufacturer of mcu's would be in business on the money they make
> (lose?) selling one or two pieces to an individual.
> I'm not affiliated with Microchip. They're just one of the many
> suppliers I deal with in an effort to earn a living for my family.
> Tim McDonough
WHAT!! Are you trying to say they are in it for the.... MONEY!?! Oooh! :)
>> > Everyone out there really needs to talk to a guy in Taiwan who will
>> > give his mother and his left nut for a micro that costs 10 cents less.
>> > The real world can be a scary place!
>>
>> What is the E-mail address of this guy in Taiwan, I can't get constant
>> prices or supplies in Australia, and MicroChip offer no alternatives for
>> me.
>
>I'm not trying to single out anyone in particular but I'm curious to know
>whether the people who complain so much about price, etc. sell their own
>products, services, labor at bargain basement prices just because the
>people who buy from them don't want to pay very much?
>
I worked for a company that made garage door openers radios, about 1.2
million units a year. We would let a 40k/year engineer work for three weeks
to eliminate one jumper on a single sided board. At .3 cents each it cost
many thousands of dollars to use that part.
In addition we would let work an extra two or three weeks on a layout just
to get the parts lined up so the head on the automatic insertion machine
did not have to turn. That turn takes about half a second but it works out
to several man-weeks per year of machine time in the quantities we were
doing.
I felt sorry, well sometimes, for the parts manufacturers. We used to beat
them mercilessly. I remember meeting 3 different EEPROM makers on the same
day to try to save a penny a part. Again, a penny is not much, but 1.2
million of them is something to write home about. And in this case we saved
7 of those shiny pennys on each EEPROM.
Our market was extreamly competitive. Eventually, someone was importing a
finished product for less than we could buy the parts for.
Now I am back in my own company doing custom stuff. Usually, it just
doesn't matter how much something costs. Nothing is more important than
time. I have used a MC68HC811E2 at $18.00 each to do a 485 bus keyswitch
box that interfaced a switch and two leds. It was cheaper, on 50 pcs, to
use the $900 worth of parts than it would have been to spend a week
re-writing the serial protocol for a 6805 or PIC.
And as far as allocation, it's part of life in the mass production game.
Saving some cost later is better than never saving it at all. Also, you
schedule say 50,000 pcs a month of something to keep the pipeline moving
and then take bigger sums when they are available.
John Payson wrote in an earlier message to the Piclist that he has a
3-wire communication protocol for connecting an arbitrary number of
devices that may be arbitrarily busy. However, to the best of my
knowledge, he has not given any further details of his protocol.
I think this idea is very interesting. Among the potential advantages
of such a protocol is that it wouldn't require guaranteed response
times from the bus nodes. It would run faster with faster technology,
without a redefinition of the protocol. No problems with skew. Less
problems with noise, cable capacitance, etc. I think most of you who
have experienced interfacing an I2C device to a PC have felt the need
for something like this,
Here is my version of the bit layer for such a self-timed serial bus
protocol (S2P?). I don't think it can be done in too many ways, and
several of you have probably come to the same conclusions. I'm
interested in your opinions and solutions.
The bus uses three wires A, B, and C, conceptually pulled-up
open-collector connected like I2C. (It could be an optical bus or
a combinatorial circuit, of course.) An idle state is when exactly
one of the bus lines is asserted, A, B, or C.
Suppose the current idle bus state is A. A bus master sends a one by
asserting B and releasing A. When the slaves see the transition A->AB
they also assert B and release A. The slaves play "follow the leader."
When A goes high, the master knows that everybody has received the
bit, and the bus is in the new idle state B. If the master had wanted
to send a zero, it asserts C and causes a bus transition sequence
A->AC->C. So far, everything is rather simple. Only two transitions is
necessary for sending one bit. The bandwidth is 1/3 bits/wire/time
unit, where a time unit is four times the propagation delay of the bus.
Suppose again that the current idle state is A. In order to transfer
control to a new master, the old master asserts B, releases A, and
converts to a slave. When the new master sees that B is asserted, it
asserts C and releases A. The new master waits until only C is asserted.
Then it asserts A and releases C. The sequence of bus states is
A->AB->ABC->BC->C->AC->A.
A slave will see one of the following subsequences:
A->AB->ABC->BC->C->AC->A.
A->AB->BC->C->AC->A.
A->ABC->BC->C->AC->A.
and it should assert B, C, and A in sequence. This control transfer
can't be done in many ways without risking deadlock. For instance,
a sequence
A->AC->ABC->BC->C->CA->A
could be seen by a slave as
A->AC->BC->...
and could be mistaken for the sequence
A->AC->C->BC->B...
which would cause deadlock.
The really tricky thing is arbitration in a multi-master system. This
is impossible in a pure self-timed system, so there are two
possibilities:
1) Require that a new master always receives control from an
old master, in a round-robin or similar manner (ie. no arbitration).
2) Allow a non-self-timed procedure for arbitration.
The disadvantage with the first alternative is that the procedure of
transfering control may take some time to find the node that wants to
become master. However, it isn't very easy to come up with a practical
procedure for the second alternative. For instance, the simple
arbitration procedure where each node tries to send a 1 first in John
Payson's 2-wire scheme will deadlock the bus if both nodes contend
simultaneously. Ideas?
Slaves can attract the attention of a master in an idle state A by
pretending to be masters, and letting the master resume control
with the control transfer procedure above.
[Nerd warning] A five-wire protocol can be constructed in the same way
as the three-wire scheme. Then we get 2/5 = 0.4 bits/wire/time unit. It can
be further generalized to n wires, of which k are asserted in an idle
state. I spent saturday night proving that the maximum bandwidth/wire
2
is log Phi bits/wire/time unit = 0.694, where Phi is the golden ratio =
1.618... . I hadn't expected this ratio to go over 0.5, but one can get
arbitrarily close to it for large n (it is a tight bound).
Some interesting pairs (n, bits) are
(3, 1), (5, 2), (7, 3), (9, 4), (15, 8), (62, 40).
For 3 < bits < 39, 2*n = 3*(bits+2). In practice, it is rather complicated
to decode the signals for large n, so a more practical way would be to use
the five-wire scheme replicated. This would produce (10, 4) and (20, 8)
solutions which are not all that bad.
Cheers,
Martin Nilsson
Swedish Institute of Computer Science E-mail: @spam@mnSTOPspam@spam@sics.se
Box 1263, S-164 28 Kista Fax: +46-8-751-7230
Sweden Tel: +46-8-752-1574
> John Payson wrote in an earlier message to the Piclist that he has a
> 3-wire communication protocol for connecting an arbitrary number of
> devices that may be arbitrarily busy. However, to the best of my
> knowledge, he has not given any further details of his protocol.
Sorry 'bout that. :-)
> I think this idea is very interesting. Among the potential advantages
> of such a protocol is that it wouldn't require guaranteed response
> times from the bus nodes. It would run faster with faster technology,
> without a redefinition of the protocol. No problems with skew. Less
> problems with noise, cable capacitance, etc. I think most of you who
> have experienced interfacing an I2C device to a PC have felt the need
> for something like this,
Well, there are skew and such requirements to be dealt with if cable lengths
are significant, but in most cases uniformity of signal arrival should not
be a problem; the biggest limitation on speed will likely come from the CPU
speeds since the protocol is intended for non-hardware-assisted applications.
> Here is my version of the bit layer for such a self-timed serial bus
> protocol (S2P?). I don't think it can be done in too many ways, and
> several of you have probably come to the same conclusions. I'm
> interested in your opinions and solutions.
>
> The bus uses three wires A, B, and C, conceptually pulled-up
> open-collector connected like I2C. (It could be an optical bus or
> a combinatorial circuit, of course.) An idle state is when exactly
> one of the bus lines is asserted, A, B, or C.
>
> Suppose the current idle bus state is A. A bus master sends a one by
> asserting B and releasing A. When the slaves see the transition A->AB
> they also assert B and release A. The slaves play "follow the leader."
> When A goes high, the master knows that everybody has received the
> bit, and the bus is in the new idle state B. If the master had wanted
> to send a zero, it asserts C and causes a bus transition sequence
> A->AC->C. So far, everything is rather simple. Only two transitions is
> necessary for sending one bit. The bandwidth is 1/3 bits/wire/time
> unit, where a time unit is four times the propagation delay of the bus.
Nice scheme. Unfortunately, I think it breaks if master sends a 1 followed
by a 0. Specifically: XYZ are the devices [X master]; for each state the
devices following the name in uppercase are those that are asserting the
line, those in lowercase are those that have last sampled the line as
asserted, and those in lowercase preceded by "!" are those that have last
sampled the line unasserted:
A=xYZ B=X
A=xyZ B=XY
A=y B=XYZ ; Z has released A; X and Z have polled it and seen it high; Y
hasn't polled it yet.
A=XZ B=Y ; B is still waiting for A to be de-asserted.
It looks like you account for this in your change-of-master handling (which
you IMHO overcomplicate) but you don't account for it in the bit-sending
protocol.
My protocol for three wires or four-wires low-overhead is as follows:
[wire names: "0", "1", "K", and "A" for zero, one, acK, and Attention;
the Attention wire is optional]
[in four-wire state description "-" means wire asserted by nobody; "M"
means asserted by master only; "S" by slave only; "X" by "everyone";
"*" by master and [maybe] slaves]
If a device is trying to send a "0" when clobber state occurs [either
XXXX or XX-X], it should forfeit to the device sending the "1". Similarly,
a "0" should not be registered by a receiver until the "--XX" state has been
reached. If a device doesn't think it will need any communication for a
while, [and other devices know this] it may go into hybernation [all lines
floating except "A", which is asserted] unless/until it sees all lines are
asserted. In this case, it should assert K and float A. If A rises before
"0" or "1" does, the device should assume an attention sequence and start
watching for possibly useful data. If "0" or "1" rises, the device should
float "K", assert "A", and go back to sleep.
> Suppose again that the current idle state is A. In order to transfer
> control to a new master, the old master asserts B, releases A, and
> converts to a slave.
With a protocol like the above, there is no such complex requirement for a
master/slave handoff. Since everyone [including the old and new master]
explicitly acknowleges everything they see, no one except the master needs
to know who's master.
> The really tricky thing is arbitration in a multi-master system. This
> is impossible in a pure self-timed system, so there are two
> possibilities:
Why is arbitration impossible in a self-timed system if devices have
unique addresses?
> [Nerd warning] A five-wire protocol can be constructed in the same way
> as the three-wire scheme. Then we get 2/5 = 0.4 bits/wire/time unit. It can
> be further generalized to n wires, of which k are asserted in an idle
> state. I spent saturday night proving that the maximum bandwidth/wire
> 2
> is log Phi bits/wire/time unit = 0.694, where Phi is the golden ratio =
> 1.618... . I hadn't expected this ratio to go over 0.5, but one can get
> arbitrarily close to it for large n (it is a tight bound).
> Some interesting pairs (n, bits) are
> (3, 1), (5, 2), (7, 3), (9, 4), (15, 8), (62, 40).
> For 3 < bits < 39, 2*n = 3*(bits+2). In practice, it is rather complicated
> to decode the signals for large n, so a more practical way would be to use
> the five-wire scheme replicated. This would produce (10, 4) and (20, 8)
> solutions which are not all that bad.
Well, I think for a 10/4 solution an easier approach is to have two control
wires and eight data wires. In the idle state, the wires are
X- lastbyte
To send two bytes of data, the transitions should be
SM -byte 1-
-X -byte 1-
MS -byte 2-
X- -byte 2-
Not as mathematically elegant as an arithmetic code, but easier I suspect.
BTW, does your formula consider deadlock avoidance as a requirement?
> John Payson wrote in an earlier message to the Piclist that he has a
> 3-wire communication protocol for connecting an arbitrary number of
> devices that may be arbitrarily busy. However, to the best of my
> knowledge, he has not given any further details of his protocol.
Sorry 'bout that. :-)
> I think this idea is very interesting. Among the potential advantages
> of such a protocol is that it wouldn't require guaranteed response
> times from the bus nodes. It would run faster with faster technology,
> without a redefinition of the protocol. No problems with skew. Less
> problems with noise, cable capacitance, etc. I think most of you who
> have experienced interfacing an I2C device to a PC have felt the need
> for something like this,
Well, there are skew and such requirements to be dealt with if cable lengths
are significant, but in most cases uniformity of signal arrival should not
be a problem; the biggest limitation on speed will likely come from the CPU
speeds since the protocol is intended for non-hardware-assisted applications.
> Here is my version of the bit layer for such a self-timed serial bus
> protocol (S2P?). I don't think it can be done in too many ways, and
> several of you have probably come to the same conclusions. I'm
> interested in your opinions and solutions.
>
> The bus uses three wires A, B, and C, conceptually pulled-up
> open-collector connected like I2C. (It could be an optical bus or
> a combinatorial circuit, of course.) An idle state is when exactly
> one of the bus lines is asserted, A, B, or C.
>
> Suppose the current idle bus state is A. A bus master sends a one by
> asserting B and releasing A. When the slaves see the transition A->AB
> they also assert B and release A. The slaves play "follow the leader."
> When A goes high, the master knows that everybody has received the
> bit, and the bus is in the new idle state B. If the master had wanted
> to send a zero, it asserts C and causes a bus transition sequence
> A->AC->C. So far, everything is rather simple. Only two transitions is
> necessary for sending one bit. The bandwidth is 1/3 bits/wire/time
> unit, where a time unit is four times the propagation delay of the bus.
Nice scheme. Unfortunately, I think it breaks if master sends a 1 followed
by a 0. Specifically: XYZ are the devices [X master]; for each state the
devices following the name in uppercase are those that are asserting the
line, those in lowercase are those that have last sampled the line as
asserted, and those in lowercase preceded by "!" are those that have last
sampled the line unasserted:
A=xYZ B=X
A=xyZ B=XY
A=y B=XYZ ; Z has released A; X and Z have polled it and seen it high; Y
hasn't polled it yet.
A=XZ B=Y ; B is still waiting for A to be de-asserted.
It looks like you account for this in your change-of-master handling (which
you IMHO overcomplicate) but you don't account for it in the bit-sending
protocol.
My protocol for three wires or four-wires low-overhead is as follows:
[wire names: "0", "1", "K", and "A" for zero, one, acK, and Attention;
the Attention wire is optional]
[in four-wire state description "-" means wire asserted by nobody; "M"
means asserted by master only; "S" by slave only; "X" by "everyone";
"*" by master and [maybe] slaves]
If a device is trying to send a "0" when clobber state occurs [either
XXXX or XX-X], it should forfeit to the device sending the "1". Similarly,
a "0" should not be registered by a receiver until the "--XX" state has been
reached. If a device doesn't think it will need any communication for a
while, [and other devices know this] it may go into hybernation [all lines
floating except "A", which is asserted] unless/until it sees all lines are
asserted. In this case, it should assert K and float A. If A rises before
"0" or "1" does, the device should assume an attention sequence and start
watching for possibly useful data. If "0" or "1" rises, the device should
float "K", assert "A", and go back to sleep.
> Suppose again that the current idle state is A. In order to transfer
> control to a new master, the old master asserts B, releases A, and
> converts to a slave.
With a protocol like the above, there is no such complex requirement for a
master/slave handoff. Since everyone [including the old and new master]
explicitly acknowleges everything they see, no one except the master needs
to know who's master.
> The really tricky thing is arbitration in a multi-master system. This
> is impossible in a pure self-timed system, so there are two
> possibilities:
Why is arbitration impossible in a self-timed system if devices have
unique addresses?
> [Nerd warning] A five-wire protocol can be constructed in the same way
> as the three-wire scheme. Then we get 2/5 = 0.4 bits/wire/time unit. It can
> be further generalized to n wires, of which k are asserted in an idle
> state. I spent saturday night proving that the maximum bandwidth/wire
> 2
> is log Phi bits/wire/time unit = 0.694, where Phi is the golden ratio =
> 1.618... . I hadn't expected this ratio to go over 0.5, but one can get
> arbitrarily close to it for large n (it is a tight bound).
> Some interesting pairs (n, bits) are
> (3, 1), (5, 2), (7, 3), (9, 4), (15, 8), (62, 40).
> For 3 < bits < 39, 2*n = 3*(bits+2). In practice, it is rather complicated
> to decode the signals for large n, so a more practical way would be to use
> the five-wire scheme replicated. This would produce (10, 4) and (20, 8)
> solutions which are not all that bad.
Well, I think for a 10/4 solution an easier approach is to have two control
wires and eight data wires. In the idle state, the wires are
X- lastbyte
To send two bytes of data, the transitions should be
SM -byte 1-
-X -byte 1-
MS -byte 2-
X- -byte 2-
Not as mathematically elegant as an arithmetic code, but easier I suspect.
BTW, does your formula consider deadlock avoidance as a requirement?
> What is the fastest floating point square root algorithm?
Stuart:
That's a lot like asking, "Who's the best-looking woman?" or "What's
the fastest car?"
The choice of an algorithm depends on your particular application
and how you define "fast"; a flip response to your question is, "A
lookup table," but constructing a large-enough one for all 24-bit
floating-point inputs is about as practical as (getting back to the
car analogy) building a car with top-fuel dragster acceleration,
Formula-1 handling, and Bonneville top speed... Not likely.
What's the range of inputs to your square-root function? What sort
of precision do the outputs need? How much code/data space are you
willing to trade for speed? Is it possible that you can solve your
problem without doing square roots at all?
At 04:36 PM 11/29/95 -0800, you wrote:
>Stuart Allman <spam_OUTstudioSTOPspamHALCYON.COM> wrote:
>
>> What is the fastest floating point square root algorithm?
>
>Stuart:
>What's the range of inputs to your square-root function? What sort
>of precision do the outputs need? How much code/data space are you
>willing to trade for speed? Is it possible that you can solve your
>problem without doing square roots at all?
I need it to take and receive a float (7-bit precision). I need it for
figuring out the magnitude of a frequency after an FFT. I remember someone,
like Newton, having an algorithm that gave closer and closer
approximatations. The Greeks also had an algorithm that was a little bit
simpler, but I can't remember it now.
> figuring out the magnitude of a frequency after an FFT. I remember someone,
> like Newton, having an algorithm that gave closer and closer
> approximatations.
Newton's method is embodied in this code: translate to your favourite language:
#include <math.h>
double
sqrt(double x)
{
double og, ng;
short niter;
int expon;
if(x <= 0.0)
return 0.0; /* sqrt(-ve) undefined */
og = x;
if(og < 1.0)
og = 1.0/og;
og = frexp(og, &expon);
og = ldexp(og, expon/2); /* make an educated guess - halv
e exponent */
if(x < 1.0)
og = 1.0/og;
for(niter = 0 ; niter < 20 ; niter++) { /* iterate until value converges
*/
ng = (x/og + og)/2.0; /* new guess calculated as the a
verage of
the old guess and the original
value
divided by the old guess */
if(ng == og) /* no change? finis! */
break;
og = ng;
}
return og;
}
--
Clyde Smith-Stubbs | HI-TECH Software, | Voice: +61 7 3300 5011 TakeThisOuTclydespamRemoveMEhitech.com.au | P.O. Box 103, Alderley, | Fax: +61 7 3300 5246 http://www.hitech.com.au | QLD, 4051, AUSTRALIA. | BBS: +61 7 3300 5235
----------------------------------------------------------------------------
FREE! Download our shareware (FREE for noncommercial use) MS-DOS C Compiler!
Point your Web browser at http://www.hitech.com.au/
> figuring out the magnitude of a frequency after an FFT. I remember someone,
> like Newton, having an algorithm that gave closer and closer
> approximatations.
Newton's method is embodied in this code: translate to your favourite language:
#include <math.h>
double
sqrt(double x)
{
double og, ng;
short niter;
int expon;
if(x <= 0.0)
return 0.0; /* sqrt(-ve) undefined */
og = x;
if(og < 1.0)
og = 1.0/og;
og = frexp(og, &expon);
og = ldexp(og, expon/2); /* make an educated guess -
halve exponent */
if(x < 1.0)
og = 1.0/og;
for(niter = 0 ; niter < 20 ; niter++) { /* iterate until value converges
*/
ng = (x/og + og)/2.0; /* new guess calculated as the
average of
the old guess and the original
value
divided by the old guess */
if(ng == og) /* no change? finis! */
break;
og = ng;
}
return og;
}
--
Clyde Smith-Stubbs | HI-TECH Software, | Voice: +61 7 3300 5011 KILLspamclydespamspam_OUThitech.com.au | P.O. Box 103, Alderley, | Fax: +61 7 3300 5246 http://www.hitech.com.au | QLD, 4051, AUSTRALIA. | BBS: +61 7 3300 5235
----------------------------------------------------------------------------
FREE! Download our shareware (FREE for noncommercial use) MS-DOS C Compiler!
Point your Web browser at http://www.hitech.com.au/
> This message is being 're-forwarded' - the list thinks I'm sending a
> duplicate. Dumb list.
So let me get this straight, Adam...
The list server tells you that you've already sent two copies of
the message, and your response is to send yet another copy and
call the LIST dumb? Hmm...
I've posted this message about three times so far... Here it is
again:
READ THIS IF YOU'RE GETTING "DUPLICATE MESSAGE" WARNINGS
FROM THE "PICLIST" LIST SERVER:
The list server software includes a helpful feature which
screens out duplicate messages. If your mailreader program
(or your brain) takes a vacation and you accidentally send a
hundred copies of a single message to the list, the list
server will bounce all the duplicates back to you with a
warning. This is a good thing.
However...
There's a bug in the PICLIST's list server software:
Occasionally, you'll get a "duplicate message" warning when
you've only posted one copy of your message.
IGNORE THIS WARNING. DO NOT RE-SEND YOUR MESSAGE!
Think for a second: Even if the warning WERE valid, it
would still mean that at least one copy of your message DID
make it to the list.
If you don't trust the list server to handle your mail properly,
send a message to the list server with the following body text:
SET PICLIST REPRO
This will make the list server send a copy of your messages
to you, as well as to everyone else on the PICLIST.
Ok...
> > > I may be a little off topic, but does anyone know how to get a
> > > floppy drive to spin at 750 rpm. I am using old 5.25 drives, the
> > > motor seems to have a comparator and bridge driver, but the
> > > adjusment pot makes little difference.
Most old 5.25 drives run at around 300 RPM, and the adjustment
pot only affects this speed by (maybe) 10 percent either way. I'm
not surprised that you can't get yours to adjust to 750.
If you're aware of this and trying to double the speed for a
reason (or if your drive is really supposed to run at 750 RPM)
you can certainly make it run at whatever speed you like.
If, on the other hand, you're just trying to get a broken drive
to work, perhaps you should try adjusting the speed to 300 RPM
and seeing whether that fixes it.
I've seen the list send me a 'duplicate message recieved' when I've
only sent one, defiantely a bug somewhere.
--
Ian Stirling. | http://web.students.stir.ac.uk/~is06
AKA Caeser, Bolonewbie. | Pretty sad at the moment, should get
| better tho.
Forwarded message:
> > This message is being 're-forwarded' - the list thinks I'm sending a
> > duplicate. Dumb list.
>
> So let me get this straight, Adam...
>
> The list server tells you that you've already sent two copies of
> the message, and your response is to send yet another copy and
> call the LIST dumb? Hmm...
No, the list is still dumb. The post which was supposedly a duplicate was
my first in months. I sent another copy because the list told me that my
first post was rejected. To accept and propagate the message while telling
me that it did the opposite is clearly and unequivocably dumb.
> Think for a second: Even if the warning WERE valid, it
> would still mean that at least one copy of your message DID
> make it to the list.
To the list server, not necessarily to the list.
Anyway, back to disk drives. I guess the original poster wants 750 rpm for
some reason? You're right, they are 300 rpm so the floppy drive probably
won't work. It might be a lot easier to take a hard disk (which will have a
higher speed) and try to find some multiple of 750 - if you found a 1500 or
3000 rpm drive you'd be laughing. Either add a sensor trigger to the platter or
wherever it's mounted, or delete some of the pulses coming from the speed
sensor.
Andrew Warren wrote:
> There's a bug in the PICLIST's list server software:
> Occasionally, you'll get a "duplicate message" warning when
> you've only posted one copy of your message.
Thanks, Andy. I was wondering why I was getting the duplicate message
warnings for messages that I could almost swear I only sent once. I
thought that maybe my mail software was doing something strange or that I
had perhaps set something up wrong.
> No, the list is still dumb. The post which was supposedly a duplicate was
> my first in months. I sent another copy because the list told me that my
> first post was rejected. To accept and propagate the message while telling
> me that it did the opposite is clearly and unequivocably dumb.
I have a very strong suspicion that there is an address subscribed to the
list which is improperly bouncing messages such that the server doesn't
recognize them as bounces. Thus, the sequence is:
Your message goes to server
It goes from there to everyone, including the failing address
The failed address bounces
The server sees the bounce and generates a "duplicate posting" message
which it then sends to you [apparently the machine at the bad address
munged the addresses in the message such that the server thought its
bounce came from you].
You see the "duplicate posting" message . . .
I think the best solution to this problem would probably be for the list
maintainer to send a message to all people on the list asking them NOT to
reply if they received the message, with the From: and Reply-to: set to
the list maintainer (not the list itself!). This would then allow the
person maintaining the list to identify any addresses which are bouncing
and unsubscribe them from the list.
> I think the best solution to this problem would probably be for the
> list maintainer to send a message to all people on the list ....
>
> Does anyone see any problems with this strategy?
Just one, John...
Jory Bell, the list maintainer, left the country a couple of
months ago and is apparently still abroad; he doesn't seem to
have checked in to the list since he left.
> The best solution would be to stop these spams getting in in the
> first place. I remember a while back there was a plan to do
> something about it, like only allow subscribed members to post or
> have a twit filter or something?
> ....
> Is there still a plan to fix this one day? I already unsubscribed
> once but came back when the list manager said he was going to get it
> fixed.
There's no problem with replying to any of those addresses (usually);
Netcom straightens everything out and routes all those replies to me.
However, Jory's anti-spam routine worked by comparing the "From:"
address to the list of subscribers. Since my Netcom-assigned domain
name only matches the address on the subscriber list about 5% of the
time, 95% of the messages I sent would be refused by the list server.
[Of course, this could actually be a GOOD thing for all of you...]
The solution which first came to mind was to subscribe me under all
possible domain names that Netcom might assign. This allowed me to
post messages to the list, but unfortunately resulted in my receiving
14 copies of every message that anyone else posted.
After a couple of days, Jory decided that the anti-spam software was
more trouble than it was worth and removed it. For now, the best
solution is simply to ignore the spam... After all, it comprises
less than 1% of all messages posted here.
Actually, the optimum solution would be mailing list software that allows
posting from a domain instead of just a single machine. That is supposed
to be available in the next release of Majordomo. If it looks good I'll
give the list a yell (I have to run mailing list software for a project
at work.)
If the anti-spam software has been removed, why do we continue to see people
double posting? I thought that this was caused by the message from the list
server that our message was rejected as a duplicate. I think it is better to
get an occasional duplicate than duplicates caused by an incorrect message
indicating a duplicate. The other reason we could be getting duplicates is
that the list doesn't send a copy to the sender. I know you can turn on this
option (I have) but why not make it the default as most new members (if not
most all members) would prefer it on anyway?
I agree with Andy (and many others) that the best anti-spam tactic is just to
ignore it.
Mark A. Corio
Rochester MicroSystems, Inc.
200 Buell Road, Suite 9
Rochester, NY 14624
Tel: (716) 328-5850
Fax: (716) 328-1144
e-mail: TakeThisOuTMcorioaol.com
***** Designing Electronics For Research & Industry *****
> Andy, can you tell us what PID is, or give a text reference?
Mike:
There are LOTS of books on PID... Look under "Process Control".
PID is an acronym for "Proprtional-Integral-Derivative". Like all
process-control algorithms, it takes an input (from whatever process
you're trying to control) and calculates the appropriate output to
keep the process doing what you want.
PID's real simple in concept... To understand how it came to be
invented, consider the simplest process-control algorithm: The
Proportional algorithm.
A Proportional controller looks at an input from your process,
compares it to the desired state, and sends an output to the process
to nudge it toward the desired state. In a simple system, like a
motor speed-control, a Proportional controler would just increase the
motor voltage when the motor speed was too low, and decrease it when
the motor speed was too fast.
The big problem with simple Proportional controllers is that they tend
to oscillate... With that motor speed control, the motor would rarely
be exactly at the setpoint; it'd tend to "hunt", fluctuating above
and below the setpoint.
A PID controller solves this problem (and a couple others that
appear when using Proportional controllers to control
more-complicated, non-linear processes) by adding a couple more
terms to the mix. It computes three terms:
The Proportional term is the same as before... It's the error,
or the difference (usually expressed as a ratio, to make the math
work out right) between the output and the input. It tells the
algorithm HOW FAR the input is from the setpoint.
The Integral term tells the algorithm HOW LONG the input has
been away from the setpoint.
The Derivative term tells the algorithm HOW FAST the input is
approaching the setpoint.
In a PID controller, the three terms are summed, and the result is
used as the output to the process.
Ok... I've sorta glossed over the details, but this should at least
give you a small idea of what the hell we're talking about.
> There are LOTS of books on PID... Look under "Process Control".
>
> PID is an acronym for "Proprtional-Integral-Derivative". Like all
> process-control algorithms, it takes an input (from whatever process
>......
The proportional term uses the error directly to generate the output, so
that if any output is needed to maintain the set point, there has to be
some error.
The integral term provides an adaptive offset to counteract the error
needed to generate an output. This allows the system to sit at the set
point.
The derivative term speeds up or slows down the changing system in such
a way as to try to get the system to settle as quickly as possible
without overshoot.
When Andy says "proportional to" he literally means that each term is
assigned a number that determines the proportion it contributes to the
final output, which is just a sum of the individual contributions. these
are the numbers that are tweaked when a controller is tuned.
There are several refinements to the basic algorithm that help with it's
behavior when the output isn't yet stable, as when the process is
started or the setpoint changed. Also, there are a bunch of historically
derived names for each term & proportionality constant that should be
learned you want to, say, have your controller tuned by the plants'
resident 'magic fingers' technician.
> Per Microchip's web site, there ARE going to be 8-pin devices.
John:
I just took a look at that press release. Guess the information
I have isn't secret anymore, so...
> By the sound of it, they're equivalent to the 16C54 except:
>
> No external clock generator (internal 4MHz)
>
> Code=512, Data=25, like the 54
TWO chips in the 12000 series have been announced... The other
one has 1024 words of code space, 41 registers.
> Watchdog unknown
Watchdog included.
> No external reset (or RTCC?) input
>
> Only 6 I/O pins [I don't know whether portB only or some portA some
> portB
PortB only. That is, the register is at the same address as the
PORTB register on the 16C5x. Whether Microchip's documentation
will refer to that port as "A" or "B", though, is anyone's guess.
> Price under $1.
In serious quantities, the smaller chip (the 12C508) will be WAY
under $1. I suppose that ANYONE could infer this from the fact
that Microchip's press release says, "pricing in 50,000-unit
quantities is less than $0.99 each for both the PIC12C508 and the
PIC12C509".
I'm surprised that Microchip has publicized the parts so
early... Perhaps the fact that they just started distributing
Picstart Plus programmers with silkscreened "8-pin devices go
here" markings had something to do with it.
> > [Quoting me:]
> > In serious quantities, the smaller chip (the 12C508) will be
> > WAY under $1.
>
> I assume though that this will be for masked devices. Will there be
> OTP devices too, and any idea what price?
Clyde:
When I wrote, "I guess the information I have isn't secret anymore,"
I didn't mean that ALL the information was no longer secret. For
pricing information beyond what can be inferred from the press
release, you'll have to talk to your Microchip sales rep.
>
>>I assume though that this will be for masked devices. Will there be OTP
>>devices too, and any idea what price?
>
The parts announced are OTP. As of now, there are no masked parts
announced. The pricing you see is for OTPs.
>
> > The "hello world" of the PIC is to blink an LED tied to a pin. I have
watched
> > several people implement this and have one warning:
> > If you can't see the LED blinking, check with a 'scope. PICs aren't very
good {Quote hidden}
> > at wasting time! The LED may be blinking faster than you can see it.
>
> I would suggest an easy remedy to this is to use a bipolar LED (one of
> the two-lead red/green types, available at Radio Shack or any mail-order
> electronics house) connected as shown:
>
> Gnd----[220ohm]---+---[220ohm]----+5
> |
> +---[LED]------- Port pin
>
> Although this circuit will waste 10 mils when idle [there are ways around
> that] it will provide a clear indication whether the port is solid high,
> solid low, tri-stated, or switching between two of those states. Note too
> that this can be a useful trick for driving more than one "independently-
> controlled" LED from a port pin.
Hmmm, I was having a discussion about bipolar LED's driven by PIC pins in
one of my classes I'm teaching this summer just this morning. The objective
was to drive 6 bi-polar LEDS (2 pin) using as few PIC port pins as possible.
Each LED should be able to show red,green,yellow, and off.
The design I hit upon after thinking a bit revolved around multiplexing
the 6 LEDs utilizing a common pin on one side. Something like:
Port pin---+-[220ohm]--+---[LED]------ Port pin
|
+-[220ohm]--+---[LED]------- Port pin
|
+-[220ohm]--+---[LED]------- Port pin
|
+-[220ohm]--+---[LED]------- Port pin
And so on. One led can be selected by tristating all but one port pin
on the right side. The selected LED's color can be picked by twiddling
with the left port pin and the one non-tristated port pin.
The question that popped into my mind during this design discussion was
the relevance of the position of the resistor. Does it matter if the resistor
is on the anode or the cathode side of an LED. Is putting the resistor on
the anode side simply a convention or is there some other reason that justifies
its placement. Should a bi-polar have resistance on both sides (I've done this
in previous designs)?
THe above configuration would be ideal because the left port pin could be
tied to the common terminal of a resistor pack somewhat simplifing the
wiring.
> From: Byron A Jeff <.....byron.....RemoveMECC.GATECH.EDU>
>
> The design I hit upon after thinking a bit revolved around multiplexing
> the 6 LEDs utilizing a common pin on one side. Something like:
>
> Port pin---+-[220ohm]--+---[LED]------ Port pin
> |
> +-[220ohm]--+---[LED]------- Port pin
> |
> +-[220ohm]--+---[LED]------- Port pin
> |
> +-[220ohm]--+---[LED]------- Port pin
>
> And so on. One led can be selected by tristating all but one port pin
> on the right side. The selected LED's color can be picked by twiddling
> with the left port pin and the one non-tristated port pin.
>
> The question that popped into my mind during this design discussion was
> the relevance of the position of the resistor. Does it matter if the resistor
> is on the anode or the cathode side of an LED. Is putting the resistor on
> the anode side simply a convention or is there some other reason that
justifies
> its placement. Should a bi-polar have resistance on both sides (I've done this
> in previous designs)?
>
It makes no electrical difference which side the R is on. Two 2-pin
devices in series may be used in any order.
BTW, the above circuit can also drive any 2 LEDs to arbitrary polarity
so long as consistent brightness isn't a problem. How about 3 or more?
Have to think about that...
It *DOES* make a difference where you put the resistor,
since programmers invariably make *mistakes*. With only
one resistor, it would be possible to burn out the left-hand
port pin if you were to drive too many of the right-hand
pins to the opposite polarity *simultaneously*. That's all.
If you're careful, *really* careful, not to do that, then
all is well with only one resistor. It makes absolutely
no difference which side of the LED you put the resistor
on, unless you want to use the roughly 1.3 V drop for some
sort of measurement purposes.
Use one "file" to hold bits to be driven during the "RED"
cycle and another to hold bits to be driven during the
"GREEN" cycle. Yellow gets a bit in both. Then cycle
through both files, one bit at a time. That way you
can be pretty certain you're not going to drive more than
one LED at a time.
How 'bout loading the flag file into the data output
latches and then rotating the TRIS file with one bit
cleared? :-) Now you know I'm going to have to build
this thing, just to see it run.
You might also wish to lower the value of the current-
limiting resistor to allow the full 20mA that the pins
can put through it. Since you're only going to be driving
the LEDs for very small duty cycles (1/12 at most) you
certainly won't have to worry about burning them out.
--
Rick Miller
<spam_OUTrdmillerTakeThisOuTEraseMEexecpc.com>
electronics house) connected as shown:
>>
>> Gnd----[220ohm]---+---[220ohm]----+5
>> |
>> +---[LED]------- Port pin
>>
This can also be used with separate red and green LEDs in inverse parallel,
e.g. a panel display to indicate TOO HIGH (red LED); TOO LOW (green LED);
or within range (tri-stated to open circuit - no LEDs).
> Port pin---+-[220ohm]--+---[LED]------ Port pin
> |
> +-[220ohm]--+---[LED]------- Port pin
> |
> +-[220ohm]--+---[LED]------- Port pin
> |
> +-[220ohm]--+---[LED]------- Port pin
>
>The question that popped into my mind during this design discussion was
>the relevance of the position of the resistor. Does it matter if the resistor
>is on the anode or the cathode side of an LED. Is putting the resistor on
>the anode side simply a convention or is there some other reason that justifies
>its placement. Should a bi-polar have resistance on both sides (I've done this
>in previous designs)?
>
In a series circuit, the same current flows through all elements, so it
makes no difference which side the resistor is on. Also, if you only need
to light one of the LEDs at a time, you can simplify this by using a single
resistor at the port pin.
.....................Reg Neale.....................
"Ignorance is a renewable resource" P.J. O'Rourke
> I am getting the impression there are actually a few problems [with
> the midrange PICs] other than the "baud rate generator=1" problem
> he mentioned above. Has anyone been keeping a list of the problems
> so we don't all learn the hard way?
Yes, Todd... Microchip keeps a list and distributes it in the form of
"errata" sheets. They're available from your Microchip rep; my rep,
in fact, telephones me whenever a new one comes out.
The eratta are on the BBS and the WWW site also. We aren't proud of
it, but we won't hide it from our customers either! (unlike some
other micro folks)
Rgds, Brian.
______________________________ Forward Header __________________________________
Subject: Silicon Bugs (was: "Re: Serial Port")
Author: Andrew Warren <@spam@fastfwdspamIX.NETCOM.COM> at Internet_Exchange
Date: 6/6/96 4:29 PM
> I am getting the impression there are actually a few problems [with
> the midrange PICs] other than the "baud rate generator=1" problem
> he mentioned above. Has anyone been keeping a list of the problems
> so we don't all learn the hard way?
Yes, Todd... Microchip keeps a list and distributes it in the form of
"errata" sheets. They're available from your Microchip rep; my rep,
in fact, telephones me whenever a new one comes out.
Brian, I want to retrieve the eratta for the 16C74, 16C74 and 16C65.
which files should I look for at the WWW ??????
thanks
juan
At 16:43 06/06/96 -0700, you wrote:
> The eratta are on the BBS and the WWW site also. We aren't proud of
> it, but we won't hide it from our customers either! (unlike some
> other micro folks)
>
> Rgds, Brian.
>
>
>______________________________ Forward Header
__________________________________ {Quote hidden}
>Subject: Silicon Bugs (was: "Re: Serial Port")
>Author: Andrew Warren <KILLspamfastfwdTakeThisOuTIX.NETCOM.COM> at Internet_Exchange
>Date: 6/6/96 4:29 PM
>
>
>Todd Peterson <TakeThisOuTPICLISTspam_OUTMITVMA.MIT.EDU> wrote:
>
>> I am getting the impression there are actually a few problems [with
>> the midrange PICs] other than the "baud rate generator=1" problem
>> he mentioned above. Has anyone been keeping a list of the problems
>> so we don't all learn the hard way?
>
>Yes, Todd... Microchip keeps a list and distributes it in the form of
>"errata" sheets. They're available from your Microchip rep; my rep,
>in fact, telephones me whenever a new one comes out.
>
>-Andy
>
>Andrew Warren - RemoveMEfastfwdspamSTOPspamix.netcom.com
>Fast Forward Engineering, Vista, California
>http://www.geocities.com/SiliconValley/2499
>
>
> Brian, I want to retrieve the eratta for the 16C74, 16C74 and 16C65.
>
> which files should I look for at the WWW ??????
They're under tech support. Since the files take awhile to download via
modem if you don't have a direct net connection, I'll summarize (this
summary is not complete, but indicates the ones I remember). First,
though, an editorial....
Some people, here and elsewhere, have sharply criticized Microchip for
releasing chips with "so many" bugs. Despite my like for the PIC, I
am inclined, depressedly, to agree with them that many of the high-end
PICs' peripherals are rendered largely useless by these bugs.
HOWEVER, despite the problems in the high-end chips I STILL intend to
support MicroChip to the extent I can. Despite the failings of the
PICs in the more "upscale" applications, the lower models such as the
16C5x or 16C62x are IMHO some of the best "little" micros there are:
cheap, fast, and great to program. Further, the PIC family is the ONLY
family of micros I know of where someone can buy an under-$10 micro from
Digi-Key, $10 or so in stuff from Radio Shack, and grab some free info
off the web, and have an in-circuit development system.
In addition, despite their shortcomings, Microchip has been reasonably
forward about their chips' problems. Perhaps this was their long-standing
intent; perhaps they're merely trying to avoid a "Pentium" fiasco. I
personally don't really care which--I just want them to survive and keep
producing great little micros [though a 28-pin EEPROM part would be nice]...
In closing, I would just like to offer my moral support to the folks at
Microchip who are probably sweating nervously as to how the market will
react to their "buggy" chips. It is only through their hard work and
effort that such wonderful chips as the 16C84 are available, and I hope
in future even more wonderful things will spring forth. If there is
anything I can do to help anyone at Microchip in their efforts to produce
better (hopefully bug-free) chips I would be happy to do what I can, and
I invite anyone at Microchip to write me personally (if needed, I'll sign
a reasonable non-disclosure agreement).
-- John
Anyway, here's what I remember offhand of the errata I've looked at. This
is not an exhaustive list, and my description of II is unlike any in the
errata but I think it describes the actual mechanics of the related prob-
lems. So here goes...
I. Serial Hardware Bugs
[A] UARTs will not receive reliably if BRGH is set for high baud rates.
[B] SPI mode has clocking problems
[C] I2C mode has problems in master mode [for I2C mastering, it's often
easier to ignore the I2C hardware].
[D] Suspected problem [not listed in errata, nor tested]: Writing a byte
to the outgoing serial buffer will clear any incoming byte that
happens to be there. [If this is not the case, it would see M'chip
added some logic to the CPU core to prevent read-before-write on
MOVWF.]
II. CPU Core Limitation/Quirk
[A] On 16Cxx, all instructions other than xxxLW will perform a read of
the address specified in the lower seven address bits. [On the
16C5x, the lower 5 bits, but no registers are affected by reads so
this is a non-issue].
- On all 16Cxx except the 5x parts, this affects MOVWF (does a read
before write), and depending upon where FSR is pointing, may also
affect NOP and the canonical form of CLRW (with an address of 0).
If one is courageous, one might be able to specify an address in
CLRW to simultaneously perform the read and clear W; this is most
likely not useful.
- On the 16C64, 16C74, and other parts with a parallel slave-port,
the LSB's of the RETURN instruction will cause the port to be read,
potentially causing a host CPU store there to be misregistered. A
possible workaround would be to use a different opcode for RETURN,
but I don't know if the hardware would accept any others.
III. Power/crosstalk problems
[A] Some PICs will not power-up reliably without an externally-imposed
reset [/MClr].
[B] Some PICs will not reliably assert the PO flag on power-up and this
flag should not be used for power-on detection.
[C] On the 16C71, the CPU oscillator can cause crosstalk with the ADC
input right next to it. In addition, use of an external RC main
oscillator may cause the internal RC for the ADC to fail if it is
used. Both of these problems may be somewhat mitigated by using
the CPU clock as the ADC source.
[D] On parts with an "external" crystal oscillator option (e.g. to use
a watch crystal for a timebase and something else for the main CPU
clock) this oscillator may pick of crosstalk from the main oscillator
if both are used simultaneously, and use of this other oscillator may
cause increased power draw as its digital input function is not dis-
abled by use as an oscillator.
[E] Some chips will behave badly in case of brownout and will have to
be power-cycled to recover.
IV. Other miscellaneous
[A] On the 16C74, the ADC may be inaccurate for measuring voltages over
3 volts.
[B] On some parts with extra timers, these timers will malfunction in
certain modes (see errata for more details).
[C] On the PIC16C84, it is possible to unblow the security fuse and read
out the chip contents. This is not believed possible on the other
chips.
[D] On many of the newer ceramic chips, there is no way to unblow the
security fuse--even UV erasure won't help. This is mentioned in the
data sheets, but should be repeated.
V. Documentation notes:
[A] The pinouts for the 28-pin surface mount parts are documented in-
correctly. See Errata for correct pinouts.
[B] On the 16C62x, the PORTB inputs operate as "normal" PIC inputs; only
the PORTA inputs operate as schmidt triggers.
[C] For some devices, the exact AC/DC tested parameters don't match the
data sheets.
AT> BTW, to my mind, chancging Vpp according Microchip's
AT> from 12 to 14v with 0.25v resolution is NOT nessesary!!!
AT> It seems to me than set Vpp=13.5v is enough for all chips.
AT> And Vdd must variate from 2v to 6v.
>
> Short form: in my considered opinion, as of the specs in the
> 95/96 databook, Microchip DOES NOT require any
> programmability for the Vpp supply in the sense that Vdd
> needs to be programmable as part of the specified
> program/verify procedure.
1.0 PROGRAMMING THE PIC 16C6X/7X (8X - the same)
1.1 Hardware Requirements
The PIC16C6X/7X requires two programmable power supplies,
one for Vdd (2.0v-6.5v recommended) and one for Vpp (12v-14v).
Both supplies should have a minimum resolution of 0.25v.
> What is this "applications handbook?" Could you please elaborate a
> little more about whait it is, what's in it, and where to get it?
Matthew:
It's called the "Embedded Control Handbook", published by Microchip.
It cotains a few dozen appnotes and is available from any Microchip
representative or distributor.
-
-> From: "W. Lee Vick, Jr." <RemoveMEwlvickRemoveMERemoveMEmicro.ti.com>
->
-> PIC.gurus,
->
-> I also have a little LED project and was looking for some help with
-> it. I'd like to build a box which determines the order of finish of a pine
-> box derby (small wooden cars about 7" by 3" which run down a slotted track)
-> race. [Details edited for brevity. ]
->
-Forget wire wrapping! Making a PCB is so easy these days. But first,
-prototype the circuit on a breadboard.
Well this is a religious argument. Each has their advantages and disadvantages:
Breadbording: Quick to throw together. Easy to change. Entirely too easy to
change.
Wirewrapping: Quick to throw together presuming you have the equipment. Sockets
cost more than PCB sockets. Too much extension from the bottom of the board.
Fairly stable and generally easy to modify.
PCB: Please tell me how to make an inexpensive, consistent PCB. While it
may be easy to do, many of us have not set up the design tools and equipment
to put it together. I'll gladly take a lesson in easy PCB making.
Pre-etched PCBs: Been experimenting with these lately. Shows promise. I'm
talking about the Rat Shack boards that are etched to look like breadboards.
Simply solder in the sockets, components, and wire.
Each has advantages and disadvantages. Generally while I'm designing and
testing I wire wrap. Easy to put together a semi-permanent board that can
be changed if necessary. I'm willing to examine PCBs but all I read in the
sci.electronics newsgroups is how difficult it is to get good boards....
By the way, what PCB package do you use, and have you seen WinBoard and
WinDraft? I talked with this company and you can get a 100 pad
vertion via the internet, and upgrade the pads by paying them (cheap). O'h I
also understand that the founder of this company is also the
founder of Orcad, and he is no longer with Orcad. Just thought I would mention
this seeing as a lot of people might want free software for
making small projects like LED-somethings... I will post the Inet address when I
get to work, got Jury service today! (drat)
Giles L. Honeycutt
Byron A Jeff wrote:
> Well this is a religious argument. Each has their advantages and
disadvantages:
>
> Breadbording: Quick to throw together. Easy to change. Entirely too easy to
> change.
>
> Wirewrapping: Quick to throw together presuming you have the equipment.
Sockets {Quote hidden}
> cost more than PCB sockets. Too much extension from the bottom of the board.
> Fairly stable and generally easy to modify.
>
> PCB: Please tell me how to make an inexpensive, consistent PCB. While it
> may be easy to do, many of us have not set up the design tools and equipment
> to put it together. I'll gladly take a lesson in easy PCB making.
>
> Pre-etched PCBs: Been experimenting with these lately. Shows promise. I'm
> talking about the Rat Shack boards that are etched to look like breadboards.
> Simply solder in the sockets, components, and wire.
>
> Each has advantages and disadvantages. Generally while I'm designing and
> testing I wire wrap. Easy to put together a semi-permanent board that can
> be changed if necessary. I'm willing to examine PCBs but all I read in the
> sci.electronics newsgroups is how difficult it is to get good boards....
Sorry for the off topic post but maybe this tip will help someone.
When I need a prototype I combine the Radio Shack breadboard and the
Radioshack "pre etched" board together.
Take the pre etched board secure it to the top of the breadboard the pattern
matches perfectly. Now build your stuff. I use wire wrap sockets for the I.C.s
due to the long pins. When your circuit is finished, flip the works over
and seperate the board from the breadboard, now solder using the breadboard
as a guide.
Joseph D. West
Electronics Lab. Supervisor
College of Mechanical Eng.
Ohio State University
At 07:46 AM 11/15/96 -0500, you wrote:
>
>PCB: Please tell me how to make an inexpensive, consistent PCB. While it
>may be easy to do, many of us have not set up the design tools and equipment
>to put it together. I'll gladly take a lesson in easy PCB making.
>
>
This may not be the best way to make PCBs, but for a hobbyist doing low
volume, it works for me.
1.) Use Window's Paintbrush to design your artwork. It is not difficult to
create a library
of reusable patterns that are easily cut-and-pasted. The hardest part
is making sure the
the hole spacings are accurately spaced when printed. A few printings
on paper make an easy
test of this.
2.) When satisfied with your work, print the artwork on a Laser printer
using clear acetate as
the paper. This is the stuff we use at work for creating overhead
projector transparencies.
3.) Get pre-sensitized PCB material from Circuit Specialists and sandwich
the clear acetate (with
printed artwork) between the PCB material and a piece of glass. Be
careful not to put the artwork
over the PCB material upside down or you will get a useless mirror image
of your work. Been there,
done that - oops.
4.) Expose the sandwich to a flourescent light for about 15-20 minutes.
5.) Develop and etch the board. (Developer and etchant are also available
from Circuit Specialists).
This makes very acceptable PCBs and you don't need any specialized software
or equipment (assuming you
have Windows or some other painting program, and running water). Cost is
minimal - about $10 per
board or less depending on board size. The true costs are in your time
spent developing the artwork.
Circuit Specialists can be found on-line, but I can't remember the address.
At 07:46 15/11/96 -0600, D. R. Chicotel wrote:
>1.) Use Window's Paintbrush to design your artwork. It is not difficult to
>create a library of reusable patterns that are easily cut-and-pasted.
As others pointed out, there are a couple of freeware PCB design programs
around, might be an alternative... ;-)
>By the way, what PCB package do you use, and have you seen WinBoard and
> WinDraft? I talked with this company and you can get a 100 pad
>vertion via the internet, and upgrade the pads by paying them (cheap). O'h I
> also understand that the founder of this company is also the
>founder of Orcad, and he is no longer with Orcad. Just thought I would mention
> this seeing as a lot of people might want free software for
>making small projects like LED-somethings... I will post the Inet address
when I
> get to work, got Jury service today! (drat)
> Giles L. Honeycutt
I tried out the IVEX (free) product and while they work very well on a small
test board I did, they upchucked something fierce on a 94 Pin board. (Lot's
of GPFs with the product).
I'm running Windows/95 on a brand-new AST Computer. I did call IVEX to ask
about it and they said they were aware of the problem under Windows/95.
I'm back on Easytrax (the free version you can get on the Net).
>Byron A Jeff wrote:
>> Well this is a religious argument. Each has their advantages and
> disadvantages:
>>
>> Breadbording: Quick to throw together. Easy to change. Entirely too easy to
>> change.
>>
>> Wirewrapping: Quick to throw together presuming you have the equipment.
> Sockets
>> cost more than PCB sockets. Too much extension from the bottom of the board.
>> Fairly stable and generally easy to modify.
>>
>> PCB: Please tell me how to make an inexpensive, consistent PCB. While it
>> may be easy to do, many of us have not set up the design tools and equipment
>> to put it together. I'll gladly take a lesson in easy PCB making.
I used to do it and finally gave up and got boards made. The problems I had
included: Getting top and bottom side layers to line up (or I would go with
one layer and lots of jumpers), Chemical storage and disposal (it's illegal
to put in the garbage here in Toronto AND you have to pay somebody to take
them), film manufacturing (although I got pretty good at it towards the end
with a laser printer that could do transparencies), board developing (Again
Chemicals and their disposal as well as making a lightbox to hold the film
against the card) and drilling (the drills cost a fortune and break so
easily). I once (note the "once") made a board using tape, stencils, and a
PCB marking pen.
For the past two years, I've done a number of Hobby boards using AP Circuits
in Calgary, Alberta, Canada. I've had excellent results each time with a
cost generally about $60 Canadian for two boards - the only problem I've had
is with a bad socket (not the raw card's fault). The cost is dependant on
the size of the card and the number of holes (good incentive to keep the
boards small), you can do multiple up panels which will drop the cost per
board significantly (last year, I did 8 "Frosty the Snowman" Boards at a
final cost of $12.00 Canadian each). The three day turnaround doesn't hurt
either.
>> Pre-etched PCBs: Been experimenting with these lately. Shows promise. I'm
>> talking about the Rat Shack boards that are etched to look like breadboards.
>> Simply solder in the sockets, components, and wire.
I think you're talking about "Vero"/"Vector" (I'm not sure of the right
term/manufacture) Boards (the boards with the long copper strips on the
backside), which is . They come out about 2x as large as the final,
embedded version, but at $5.00 for a 6x6 board (which I usually cut up into
smaller boards), the price is hard to beat.
One hint, I just got a Vector "Pad Cutter Tool" from Digi-Key (Digi-Key P/N
V1056-ND, Price $16.38). I know the price is a bit high, but it really make
working with the boards a joy, compared to cutting the traces with a drill
or an olfa knife and a soldering iron (like you do with a Surfboard).
Now, does anybody know of any layout tools for these boards?
>> Each has advantages and disadvantages. Generally while I'm designing and
>> testing I wire wrap. Easy to put together a semi-permanent board that can
>> be changed if necessary. I'm willing to examine PCBs but all I read in the
>> sci.electronics newsgroups is how difficult it is to get good boards....
Steve Ciarcia, when he was creating projects for Byte, used to create
semi-embedded cards for his projects. He would put on Connectors and such
and wire Vcc and Gnd and then Wire-Wrap the rest. Maybe if somebody's
energetic, they could do this for the PIC?
myke
Being a stealth pilot is one of the most labour intensive and time
constrained types of flying that I know. We have very strict time
constraints: to be where you are supposed to be all the time, exactly on
time, and that has to be monitored by the pilot. For example, during a bomb
competition in training in the U.S., I dropped a weapon that landed 0.02
seconds from the desired time, and finished third!
D. R. Chicotel wrote:
>
>PCB: Please tell me how to make an inexpensive, consistent PCB. While it
>may be easy to do, many of us have not set up the design tools and equipment
>to put it together. I'll gladly take a lesson in easy PCB making.
>
You can get a good but free PCB layout program called easytrax by
Protel. It is the little brother of there autotrax program. It runs
under MSDOS and is more than adequate for most boards. You should be
able to get a copy from Alberta Circuits at http://www.apcircuits.com/
If you have a laser printer, you may want to consider the toner transfer
systems. One is from a company called DynaArt Designs. You can access
their web page at http://www.dynaart.com. With this system you print the
artwork 1:1 to a laser printer, and then transfer the toner on to the
PCB using heat and pressure. The toner acts as a resist, so the board
can be directly etched. The advantage is the quick turn around. The
disadvantage is inconsistent results. I think this can be remedied if
you buy one of their 'SuperFuser' devices. Has anyone used a
'SuperFuser' ? If so what results did you get.
--
Randy Howe
Axiak Electronic Design Ltd.
Vancouver, B.C.
> >> Well this is a religious argument. Each has their advantages and
> > disadvantages:
> >>
> >> Breadbording: Quick to throw together. Easy to change. Entirely too easy to
> >> change.
> >>
> >> Wirewrapping: Quick to throw together presuming you have the equipment.
> > Sockets
> >> cost more than PCB sockets. Too much extension from the bottom of the
board.
> >> Fairly stable and generally easy to modify.
> >>
> >> PCB: Please tell me how to make an inexpensive, consistent PCB. While it
> >> may be easy to do, many of us have not set up the design tools and
equipment {Quote hidden}
> >> to put it together. I'll gladly take a lesson in easy PCB making.
>
> I used to do it and finally gave up and got boards made. The problems I had
> included: Getting top and bottom side layers to line up (or I would go with
> one layer and lots of jumpers), Chemical storage and disposal (it's illegal
> to put in the garbage here in Toronto AND you have to pay somebody to take
> them), film manufacturing (although I got pretty good at it towards the end
> with a laser printer that could do transparencies), board developing (Again
> Chemicals and their disposal as well as making a lightbox to hold the film
> against the card) and drilling (the drills cost a fortune and break so
> easily). I once (note the "once") made a board using tape, stencils, and a
> PCB marking pen.
This kind of testimony seems to debunk the original primise that making
PCB's are so easy that wire-wrapping is unnecssary.
> [ Canadian PCB manufacturer info deleted for brevity... ]
> [ Same for Vector boards... ]
>
> >> Each has advantages and disadvantages. Generally while I'm designing and
> >> testing I wire wrap. Easy to put together a semi-permanent board that can
> >> be changed if necessary. I'm willing to examine PCBs but all I read in the
> >> sci.electronics newsgroups is how difficult it is to get good boards....
>
> Steve Ciarcia, when he was creating projects for Byte, used to create
> semi-embedded cards for his projects. He would put on Connectors and such
> and wire Vcc and Gnd and then Wire-Wrap the rest. Maybe if somebody's
> energetic, they could do this for the PIC?
I'm still trying to find a good argument for using PCB's for development.
The statement that PCB's are trivally easy to do started this thread.
Breadboards are good if the project is extremely small. But their instability
and cost generally makes them unusable for anything other than fiddling.
PCB's are the way to go once the project is developed, tested, and working.
But for development? I don't think so.
So that leads me right back to wire wrap. Inexpensive (tool and wire for
less than $20), can be used in permanent situations, and simple modifications.
Gives nearly instant gratification like breadboards, but can be thrown in a
box and expect to work.
BTW I learned by hard experience that auto wire wrap tools like Slit-N-Wrap
and guns are generally bad news. Hand strip - Hand wrap is the way to go.
Every board I've ever had wrapped worked, can't say the same for the auto
tools.
myke predko wrote:
>
> >By the way, what PCB package do you use, and have you seen WinBoard and
> > WinDraft? I talked with this company and you can get a 100 pad
> >vertion via the internet, and upgrade the pads by paying them (cheap).
I've used WinBoard for 3 designs, mostly in the neighborhood of 180 pins
SMT. I had some problems early on that were fixed with the installation
of a newer driver for my PCI display adapter.....obviously not Ivex's
fault. I use the $29.95 version that gets you 220 pin limit.
The big issue with any board layout software is: How much work do you
have to do to get the library in shape for your work? WinBoard comes
with a fairly big library of modules, but most of them are for through
hole parts. Many of the SMT modules use pad geometries that don't match
up with the design rules preferred by my clients. So, I found myself
modifying or creating most needed modules in the early going.
Fortunately, their module creation stuff is easy to use.
Ivex documentation is pretty good. It's helpful to print it out in
color (at this price, you print it out yourself). My main complaint is
that you need to refer to 3 books to get the whole picture: Getting
Started, Tutorial, and Reference.
The WinDraft and WinBoard combination is amazing value.
--
Paul Mathews, consulting engineer
AEngineering Co. optoengKILLspamspamwhidbey.com
non-contact sensing and optoelectronics specialists
Been there. Done them all. Ruined all the T-shirts.
I use the breadboard thingies for development.
I use the Rat Shack boards for some things. Bit of a pain to work with,
but I found that if I use the chemical tin-plating solutions that you
can buy, and dip the board in that first, it solders better. You can get
rather obscene component density on these things, since you are using
insulated wire. You can more-or-less build multi-layer boards ... wires
can cross, etc.
I ONCE did wire wrap. Years ago, I had an evaluation kit for a Fairchild
F8 processor (meant to be used as an imbedded controller). I built 1K of
static RAM for it, with 256 bit RAM chips. It worked. But it was a long
job. Used manual wrap tool.
Just started building PCs the "easy" way. I've used the freeware
packages, and they work fine. I'm now using a package from Ultimate
Technologies in the Netherlands ... they have a 500 pin version for $79
US with schematic capture, autorouter, etc. Very nice.
If you use a package that lets you draw the schematic, then create the
board layout from that, you are guaranteed to have a board that works.
With the Rat Shack stuff, wiring it all by hand, you can (and will) make
mistakes on larger projects.
I use the Toner Transfer System (sold by digikey ... $15 for 5 81/2 x 11
sheets). I've only built a couple of boards so far, and they work fine.
You use a laser printer to put the pattern on the TTS paper (you can use
this for decals, etc as well). The you use the heat of an iron to
tramsfer the pattern to the board. Following their instructions,
everything has worked just fine for me.
Just don't make the traces or the pads too small, as this stuff is not
as precise as the photo methods.
You can make double sided boards ... I have not yet tried.
Drilling is a pain. Digikey sells special bits for this ... they have an
1/8 shank to make it easier to fit into a drill, and are tapered to the
proper bit size. They are designed for use on fibreglass (which will
destory normal bits rapidly, I gather). You only need a couple of sizes.
A bit that is just right for IC holes is also fine for most other
components. It may be a bit too big, but that isn't a problem. You can
use a normal electric drill ... a drill press accessory makes life
easier. I Dremel tool with it's accesory drill press stand is handy as
well. In fact, the Dremel tool (I just got one a month ago) has been
great for a lot of this stuff. It's "cut-off wheels" are great for
cutting up copper-clad boards into smaller pieces (I tend to make lttle
boards, not huge ones). Real handy tool.
Summary:
The Rat Shack boards with the copper patterns are cheap, easy to use,
and require no special tools, but are a pain to wire with lots of
components.
PC boards are not hard to make at home, with a modest investment. And
there is a certain amount of satisfaction at admiring your work. These I
put in frames and hang on my living room wall!. I can't say the same for
the Rat Shack boards. These I put in boxes and hide somewhere.
If you are building something just once and have analog or high speed
digital circuits, then use point to point wiring techniques and a
ground plane prototype board like Vector 8003.
If you have relativly low speed circuits (ie. digital less than 25
MHz) then by all means use wire wrap. It will get you there faster.
But, if you ever think that the device will be produced in any
quantity, then get a PCB/Schematic package (I use HIWIRE II). You may
make mistakes on your first Prototype run, but you can easily cut and
jumper your mistakes. And besides, you will be much closer to the
final design PCB.
Joe Dowlen
______________________________ Reply Separator _________________________________
Subject: Re: Board construction techniques (was: Yet another LED proj
Author: pic microcontroller discussion list <spam_OUTPICLIST@spam@MITVMA.MIT.EDU> at SMTP
Date: 11/15/96 11:24 AM
> >> Well this is a religious argument. Each has their advantages and
> > disadvantages:
> >>
> >> Breadbording: Quick to throw together. Easy to change. Entirely too easy to
> >> change.
> >>
> >> Wirewrapping: Quick to throw together presuming you have the equipment.
> > Sockets
> >> cost more than PCB sockets. Too much extension from the bottom of the
board.
> >> Fairly stable and generally easy to modify.
> >>
> >> PCB: Please tell me how to make an inexpensive, consistent PCB. While it
> >> may be easy to do, many of us have not set up the design tools and
equipment {Quote hidden}
> >> to put it together. I'll gladly take a lesson in easy PCB making.
>
> I used to do it and finally gave up and got boards made. The problems I had
> included: Getting top and bottom side layers to line up (or I would go with
> one layer and lots of jumpers), Chemical storage and disposal (it's illegal
> to put in the garbage here in Toronto AND you have to pay somebody to take
> them), film manufacturing (although I got pretty good at it towards the end
> with a laser printer that could do transparencies), board developing (Again
> Chemicals and their disposal as well as making a lightbox to hold the film
> against the card) and drilling (the drills cost a fortune and break so
> easily). I once (note the "once") made a board using tape, stencils, and a
> PCB marking pen.
This kind of testimony seems to debunk the original primise that making
PCB's are so easy that wire-wrapping is unnecssary.
> [ Canadian PCB manufacturer info deleted for brevity... ]
> [ Same for Vector boards... ]
>
> >> Each has advantages and disadvantages. Generally while I'm designing and
> >> testing I wire wrap. Easy to put together a semi-permanent board that can
> >> be changed if necessary. I'm willing to examine PCBs but all I read in the
> >> sci.electronics newsgroups is how difficult it is to get good boards....
>
> Steve Ciarcia, when he was creating projects for Byte, used to create
> semi-embedded cards for his projects. He would put on Connectors and such
> and wire Vcc and Gnd and then Wire-Wrap the rest. Maybe if somebody's
> energetic, they could do this for the PIC?
I'm still trying to find a good argument for using PCB's for development.
The statement that PCB's are trivally easy to do started this thread.
Breadboards are good if the project is extremely small. But their instability
and cost generally makes them unusable for anything other than fiddling.
PCB's are the way to go once the project is developed, tested, and working.
But for development? I don't think so.
So that leads me right back to wire wrap. Inexpensive (tool and wire for
less than $20), can be used in permanent situations, and simple modifications.
Gives nearly instant gratification like breadboards, but can be thrown in a
box and expect to work.
BTW I learned by hard experience that auto wire wrap tools like Slit-N-Wrap
and guns are generally bad news. Hand strip - Hand wrap is the way to go.
Every board I've ever had wrapped worked, can't say the same for the auto
tools.
I don't think anyone has yet mentioned the use of plain perfboard,
"vectorbord"(their spelling, not mine). It comes in a few different grades
and hole patterns, I usually get the 0.1" spacing epoxy glass. It's just
board with holes in it, no copper, like you'd use for wire-wrapping.
Use regular sockets, dab a little hot glue on them before putting them on
the board. Hand wire it, using small solid wire. You can use wire-wrap wire
if you like, but the insulation doesn't like the heat of a soldering iron.
Did I say soldering was involved?
If you want a reliable, durable project, put all the components and
connecting wires on the top side and do all the soldering on the bottom
side. You can make a relatively compact project that will last for years.
If there's a part of your circuit that will require a lot of trial and
error, do that part of the circuit on a solderless breadboard, and after
you've gotten everything figured out, unhook the breadboard and finish
building your perfboard circuit.
This is not a method for mass-production, just an alternative to wire-wrapping.
>Pre-etched PCBs: Been experimenting with these lately. Shows promise. I'm
>talking about the Rat Shack boards that are etched to look like breadboards.
>Simply solder in the sockets, components, and wire.
In the PCB / Prototype board section of the Digi-Key catalog, there's a
family of devices which essentially clamp a pre-etched breadboard PCB to the
top of a real breadboard. When you insert your parts and wires, they go
clear through the PCB and into the breadboard. You get your circuit working
and debugged to your satisfaction, then a piece of foam rubber hinges down
on top of the parts and wires and holds them in place. You can then remove
the breakboard to expose the foil side of the pre-etched PCB with the wires
and component leads sticking out, all ready to solder!
> PCB: Please tell me how to make an inexpensive, consistent PCB. While it
> may be easy to do, many of us have not set up the design tools and equipment
> to put it together. I'll gladly take a lesson in easy PCB making.
This is correct, there is a high initial investment. You can use EZTrax for free
(you can get it from ftp://oak.oakland.edu) but I discovered that having a PCB
layout program, doesn' t necessarily make for good PCBs. If you don't know
how big a hole to drill for a component, or how big a pad to use, then you are
liable to build a board that isn't very satisfactory. The good news is that you
can send you GERBER files to places like APCircuits and for about $100 they
will send you back a couple of double sided boards.
> Pre-etched PCBs: Been experimenting with these lately. Shows promise. I'm
> talking about the Rat Shack boards that are etched to look like breadboards.
> Simply solder in the sockets, components, and wire.
These are nicer, but I've sworn of the radio shack ones. The ones to get have
plated through holes and copper on both sides. You can even make "psuedo"
pcbs with these by laying wire down along the hole lines. The one RS board I
like is the one with the same drill pattern as a solderless breadboard. These,
while inefficient space wise, allow you to transfer a circuit easily.
Bob Blick wrote:
>
> I don't think anyone has yet mentioned the use of plain perfboard,
> "vectorbord"(their spelling, not mine). It comes in a few different grades
> and hole patterns, I usually get the 0.1" spacing epoxy glass. It's just
> board with holes in it, no copper, like you'd use for wire-wrapping.
>
> Use regular sockets, dab a little hot glue on them before putting them on
> the board. Hand wire it, using small solid wire. You can use wire-wrap wire
> if you like, but the insulation doesn't like the heat of a soldering iron.
<snip>
We have used this technique for years (more than 20) with one major
difference: we use machine pin soldertail sockets, and we drill the
board (I forget exactly what size, I think its #54; write if you want
details) so the socket will sit down into the hole tightly. Usually
there's no glue needed. We hand wire using wire-wrap wire, but get the
good Kynar insulated stuff; the heat wont bother it. We use 20 or 24 ga.
bus bar with Teflon tubing for insulation to distribute power; put the
power grid in first, with all the bypass caps, then wire the signals.
You can daisy-chain by using a standard wire-wrap stripper at the
desired intermediate point and stretching enough of a gap in the
insulation to get a wrap around the pin. Solder as you go.
You can be surprisingly close to the final pc layout, and you can work
over a ground plane for fairly high speed stuff. We've also used a
hybrid approach, with power and ground and critical signals on a simple
etched or mechanically prepared board with sockets and hand wiring for
the rest. Done a lot of 16 & 32 bit stuff this way; PIC stuff is a
breeze.
At 10:33 15/11/96 EST, myke predko wrote:
>I think you're talking about "Vero"/"Vector" (I'm not sure of the right
>term/manufacture) Boards (the boards with the long copper strips on the
>backside), which is . They come out about 2x as large as the final,
>embedded version, but at $5.00 for a 6x6 board (which I usually cut up into
>smaller boards), the price is hard to beat.
>[...]
>Now, does anybody know of any layout tools for these boards?
An autorouter for these boards, that would be a challenge! :-)
>Steve Ciarcia, when he was creating projects for Byte, used to create
>semi-embedded cards for his projects. He would put on Connectors and such
>and wire Vcc and Gnd and then Wire-Wrap the rest. Maybe if somebody's
>energetic, they could do this for the PIC?
Wouldn't that be a great idea: make boards for every PIC (or even every
popular micro), with the basic standard circuitry and connectors, and a
field for custom stuff like those boards mentioned above? Once designed,
that's a cheap thing, and many small (hobby) projects could use them. Or is
there something similar already for sale?
It seems to me that one problem is with current packaging technology. Wire
wrap works nicely with DIPS and even PGAs, but as soon as you start dealing
with PLCC packages, WW sockets seem to get prohibitively expensive, and if
you're using SIOC, VSOP, or other explicitly surface mount technology, the
sockets are hard to find and use in ADDITION to being very expensive. In
these cases, using a PCB becomes nearly a necessity (especially if you NEED
the small size features of soic/etc in the first place.)
I've heard that the computer-operated mechanical milling (routing?) machines
designed for making PCBs can be had for as little as $3-5K (used.) It'd be
cool if someone would set one up for doing "hobbyist" PCBs, but it's hard to
imagine that you could make money doing so (The advantages would include
small setup charges and teh ability to do small boards very easilly.)
> BTW I learned by hard experience that auto wire wrap tools like Slit-N-Wrap
> and guns are generally bad news. Hand strip - Hand wrap is the way to go.
Agreed, except do yourself a favour and buy some pre-stripped wire. It saves a
lot
of work. It comes in various lengths and colours.
Having said that, after many years of wire-wrapping one-off boards, I have
now gone to getting PCBs made - it costs a little more, but with the right
software it's less work. The right software in my case is Protel Advanced
Schematic/PCB/Route. The software cost some significant money, but the
Advanced Route 3 in particular is brilliant. It can fully route boards I
have trouble completing, and can do in 5 minutes what would take me 8
hours or more.
> wrap works nicely with DIPS and even PGAs, but as soon as you start dealing
> with PLCC packages, WW sockets seem to get prohibitively expensive, and if
To get around this, make up a PGA socket from wire-wrap socket strips, then
plug a solder-tail PLCC socket into that. Works fine, just takes a few
minutes trimming the socket strips.
Has anyone tried the "PICproto" boards from microEngineering Labs? They have
4 different models. I thing a little expensive, but maybe not when bought
in quantity?
According to Gerhard Fiedler:
>
> Wouldn't that be a great idea: make boards for every PIC (or even every
> popular micro), with the basic standard circuitry and connectors, and a
> field for custom stuff like those boards mentioned above? Once designed,
> that's a cheap thing, and many small (hobby) projects could use them. Or is
> there something similar already for sale?
>
> Gerhard
>
MicroEngineering Labs sells proto boards specifically for pics. There
are 4 different flavors 18pin, 18/28pin, 28pin, and 40pin cost $10-17.
Jameco& JDR carry them.
--
Les Troyer
Sr. Analyst
Siemens Power Corp
2101 Horn Rapids Rd.
Richland, Wa. 99352-0130
These boards are GREAT! Instant PIC circuits, the PICProto18 (for 18 pin pics)
uses any kind of PIC, brings all pins out to a line of connectors, and has a
plated through breadboard area to boot. For one larger project I soldered a
wirewrap sip connector through the "PICbus" (the line of connectors) and then
simply inserted it through a larger perfboard to "mount" the PIC circuit to the
rest of the circuit.
--Chuck
----------
From: Gonzalo Palarea[SMTP:spam_OUTchalospamBeGoneTIKAL.NET.GT]
Sent: Friday, November 15, 1996 3:04 PM
To: Multiple recipients of list PICLIST
Subject: Re: Board construction techniques (was: Yet another LED project)
Has anyone tried the "PICproto" boards from microEngineering Labs? They have
4 different models. I thing a little expensive, but maybe not when bought
in quantity?
> Wouldn't that be a great idea: make boards for every PIC (or even
> every popular micro), with the basic standard circuitry and
> connectors, and a field for custom stuff like those boards mentioned
> above? Once designed, that's a cheap thing, and many small (hobby)
> projects could use them. Or is there something similar already for
> sale?
Gerhard:
MicroEngineering Labs already make exactly what you want... They have
versions for all the PICs (except maybe the 8-pin devices). You can
reach them at 719 520-5323 (fax: 719 520-1867) or on the web at:
>components. It may be a bit too big, but that isn't a problem. You can
>use a normal electric drill ... a drill press accessory makes life
>easier. I Dremel tool with it's accesory drill press stand is handy as
>well. In fact, the Dremel tool (I just got one a month ago) has been
>great for a lot of this stuff.
Where did you get your Dremel drill press accessory? And, how much did it
cost?
At 15:35 15/11/96 -0800, Andrew Warren wrote:
>MicroEngineering Labs already make exactly what you want... They have
>versions for all the PICs (except maybe the 8-pin devices). You can
>reach them at 719 520-5323 (fax: 719 520-1867) or on the web at:
>
> http://www.melabs.com
I _knew_ it -- it's too obvious. I wonder why in the previous discussions
nobody mentioned this solution (which might work for many cases where space
is not critical, and only one or two devices are needed). Thanks a lot!
>Just started building PCs the "easy" way. I've used the freeware
>packages, and they work fine. I'm now using a package from Ultimate
>Technologies in the Netherlands ... they have a 500 pin version for $79
>US with schematic capture, autorouter, etc. Very nice.
Larry,
How 'bout sharing a little more info about this gem with the rest of us?
I've downloaded WinDraft and WinBoard, but WinDraft locks my system, and
WinBoard is seemingly unstable-- if you click on a part in the module loader
that *would* bring your board over the (100) pin limit, *if* it were placed
on the board, but instead click on cancel, WinBoard thinks that there are
more than 100 pins and won't let you save your file. Same thing if you go
over the limit then delete a module which brings you back under the limit--
won't let me save or print my board. This has caused me to get into the
habit of saving my file after placing EACH module.
Anyway, I'd like to know more about this program that you're using. Sounds
like a good deal.
Matthew Mucker wrote:
>
> >Just started building PCs the "easy" way. I've used the freeware
> >packages, and they work fine. I'm now using a package from Ultimate
> >Technologies in the Netherlands ... they have a 500 pin version for $79
> >US with schematic capture, autorouter, etc. Very nice.
>
> Larry,
>
> How 'bout sharing a little more info about this gem with the rest of us?
I'm using this software too. Ulticap (schematic capture) has some nice
feature's that even orcad (386+) can't give you. It's very easy to make new
components, easy to make connections (it works like an autorouter) etc.
Since i am using this package for a very short time now i can't tell much
about the ultiboard part right now. But it looks allright to me.
In ultiboard it's also easy to make your own shape. For placement of the
shape's you get help from a force vector, traces, and a histograms which
shows the routing density. Pin and gate swapping is supported and so is
forward/back annotation.
I like it a lot...
The package includes an tutorial manual and a cd-rom.
Bert Koerts wrote:
>
> Matthew Mucker wrote:
> >
> > >Just started building PCs the "easy" way. I've used the freeware
> > >packages, and they work fine. I'm now using a package from Ultimate
> > >Technologies in the Netherlands ... they have a 500 pin version for $79
> > >US with schematic capture, autorouter, etc. Very nice.
> >
> > Larry,
> >
> > How 'bout sharing a little more info about this gem with the rest of us?
At 01:44 PM 11/15/96 PST, William Chops Westfield wrote:
>I've heard that the computer-operated mechanical milling (routing?) machines
>designed for making PCBs can be had for as little as $3-5K (used.) It'd be
>cool if someone would set one up for doing "hobbyist" PCBs, but it's hard to
>imagine that you could make money doing so (The advantages would include
>small setup charges and teh ability to do small boards very easilly.)
>
>BillW
>
>
The problem with these is the tooling cost. The drills are OK but the
special mills that outlinre the traces are expensive. They do last quite a
while. The tools with a short life are if you want to do a board rubout of
unused copper or another "outline" with the end mill to make a wider
isolation path. The end mills in that size are expensive and wear out fast.
I hesitate to stoke the off-topic boiler, but seeing as I started this
off with a contentious point please indulge me...
> From: Byron A Jeff <@spam@byronEraseMEspamCC.GATECH.EDU>
>
> [SJH wrote:]
> -Forget wire wrapping! Making a PCB is so easy these days. But first,
> -prototype the circuit on a breadboard.
> Well this is a religious argument. Each has their advantages and
disadvantages:
>
> Breadbording: Quick to throw together. Easy to change. Entirely too easy to
> change.
>
> Wirewrapping: Quick to throw together presuming you have the equipment.
Sockets
> cost more than PCB sockets. Too much extension from the bottom of the board.
> Fairly stable and generally easy to modify.
>
> PCB: Please tell me how to make an inexpensive, consistent PCB. While it
> may be easy to do, many of us have not set up the design tools and equipment
> to put it together. I'll gladly take a lesson in easy PCB making.
Yes, consistency is a good point. After much weeping and gnashing of teeth
I have found a routine which works for me. I recommend anyone considering
making PCBs to spend a whole day working out a good routine then sticking
to it.
I use precoated positive photo board. Saves worrying about the zillions
of variables which can affect the process of making your own (thickness,
baking temp, dust, hairs, dust, resist-eating moths, dust etc. etc.)
1. Draw the board on white bond paper. Use a laser printer or use
a 0.5mm drafting pen. Print/draw mirror image so that the pattern will be
correct when the ink side is pressed against the board. I use Protel
but have also used drafting techniques. To draw nice pads, I drilled
a DIP pattern into my square so that running the pen around each of the
holes results in a nice round pad complete with drill guide hole. (Relieve
the underside of the template to prevent ink smears).
2. Sandwich board and pattern between 2 sheets of glass with ink side
against the board. Expose to white fluorescent lights (4 x 20W tubes
about 200mm from board) for about 1 hour. Yes, this is slow but it gives
time for the finer things in life such as preparing the developer and
etchant.
3. Develop in commercial developer (or NaOH in a pinch). Etch in hot
ammonium persulphate, preferred for its transparency and non-staining
which is always an advantage when sharing the kitchen with the boss of
the house. Don't leave developer in glassware - I etched a good erlenmeyer
flask by not rinsing immediately. Throw away developer after use.
4. Drill then solder. I find that removal of the resist is not
required before soldering and in fact forms a nice barrier against
my sweaty little fingers. (Be nice if it was actually flux, wouldn't
it?)
Note on using laser printers: since the paper is not gripped by punched holes
etc. don't expect the laser to produce perfectly dimensioned artwork. This
is especially a problem when doing long edge connectors or trying to
register two patterns for double-sided work. 75mm boards are about the
upper limit for my HP laserjet. 15mil traces and clearances are the limit
for a 300DPI printer and 10mil for a 600DPI.
If you know a little PostScript (TM) then post-processing of the artwork
can be quite easy. A favourite of mine is to change the output from
Protel so that it a) sets a black page, b) outputs the pattern in white
with everything oversize by 30mils and c) outputs the original pattern
in black. This gives a pseudo ground plane for SS boards. Optionally,
you can connect all the copper islands left by this process using the
drafting pen.
If cutting the board to size using an angle grinder, leave a 10mm zone
around the edge where no copper will be required. The heat of grinding
ruins the resist for about 6mm either side of the cut.
Fluoro lights should be mounted to give a perfectly even illumination
over the board. If the board is tilted slightly to the tube axis or
at one end of the tube, you will be surprised how unevenly the resist
will develop. If in doubt, move the board to twice the original distance
and quadruple the exposure.
Heating the etchant is recommended unless you like watching paint dry.
I used to heat up ferric chloride in the microwave oven. Since ammonium
persulphate is made up as required then discarded, just use boiling
water when making it. Don't use at over 80 deg C otherwise the resist
can get damaged.
Hairline breaks in the traces are a severe annoyance. They can be
minimised by ensuring that the printer toner is in good condition, and
examining the backlit pattern for breaks. Such breaks are repaired
with the drafting pen. Filled-in drill guide holes are another pest.
Cured by ensuring the resist is fully developed!
Many a good DS board has been damaged by using blunt drills. When the
drill breaks through the other side it lifts the pad there. Tungsten
carbide drill bits last more than 10 times as long as HSS but must be
used in a drill press. They also cost ten times as much. It's a pity,
but I've never seen nitride coated HSS in PCB sizes.
>
> Pre-etched PCBs: Been experimenting with these lately. Shows promise. I'm
> talking about the Rat Shack boards that are etched to look like breadboards.
> Simply solder in the sockets, components, and wire.
>
> Each has advantages and disadvantages. Generally while I'm designing and
> testing I wire wrap. Easy to put together a semi-permanent board that can
> be changed if necessary. I'm willing to examine PCBs but all I read in the
> sci.electronics newsgroups is how difficult it is to get good boards....
>
Single sided with min. 20mil traces is easy. Double sided and/or 12mil
is a pain. However, by dint of much practise my boards are turning
out so well that I wouldn't consider wire wrapping or solder tags (remember
them in the days when components were big enough to see?).
>How 'bout sharing a little more info about this gem with the rest of us?
>I've downloaded WinDraft and WinBoard, but WinDraft locks my system,
If you're running Win 3.1, you have to download and install the 32 bit
Windows software support program and install it first. It's on the same web
page as WinDraft.
When I started making PCBs I found that using a normal electric drill in a
drill stand to be too cumbersome, resulting in many off-centre holes.
I personally find that the best tool to use is a modelmakers archimedian
screw drill. These can take up to a 1mm drill shank size, although it's so
precise I drill 0.6mm holes for most components. Cost about 6 UK pounds.
Geoff
> >You can use a normal electric drill ... a drill press accessory makes life
> >easier. I Dremel tool with it's accesory drill press stand is handy as
> >well. In fact, the Dremel tool (I just got one a month ago) has been
> >great for a lot of this stuff.
>
> Where did you get your Dremel drill press accessory? And, how much did it
> cost?
>
> -- Hank
>
When I build an electronic device, I have two considerations:
If I don't want the circuit later, how much of the stuff can be recycled?
How easy is it to modify, (improve, fix, etc?)
I have tried everything from "ugly construction" to printed circuit
boards and wire wrap. As one who was born blind, I can't read or write
schematics, but IC's provide a convenient graph-like reference for circuit
design as in:
1 +input
2 -input
3 NC
4 v-
etc
I tried making PC boards in the early seventies and found the
experience interesting, but frustrating. I would use tape and decalls to lay
out a circuit on a piece of un-etched board and then dunk it in ferric
chloride. I then discovered two awful truths. First, I couldn't feel the
traces on the board after stripping off the tape and second, the liquid
has a nasty habit of flowing under any little bubble or break in the tape
and etching where it shouldn't. Sometimes, dirt or other contamination
would act as random resist and leave a little copper fly speck where there
should have been nothing. I found out about wire-wrapping and that technology
solved enough of my problems that I have been content with that for almost
20 years.
What works for me is to do a usual wire-wrap on any square pins such
as IC sockets or any other devices that don't have round leads. I wrap the
wire on the round leads and then solder it since it will slowly unwrap
if not secured.
I am looking forward to using PIC's for the same reasons everybody
else likes them plus one more. If I come up with a good application that
either might have a market value or is simply good and I would like another
one like it, documentation will be much easier since most of the circuit is
the program itself. The source file shows what pins should be what in the
circuit. After all, there are many different ways to connect digital logic
and linear devices that accomplish the same purpose so it is nice to be able
to keep track of what one did so that it can be revisited years later without
having to just start over again because the documentation is too poor to
follow.
I am dreading the day when the only components will be surface mount
devices and we must all build our circuits under a microscope.
Martin McCormick WB5AGZ Stillwater, OK 36.7N97.4W
OSU Center for Computing and Information Services Data Communications Group
I didn't buy the press accessory, (I have an very old tiny drill press
designed just for PC boards that I picked up in a surplus place), but
they are a standard Dremel accessory and I've seen them at several
places where Dremel tools are sold (such as Canadian Tire up here in
Canada ... a large chain store). The cost is about $60 CDN ($1.29 US :)
)
>----------
>From: Hank Gupton[SMTP:guptonTakeThisOuTKILLspamSTARLINK.COM]
>Sent: Saturday, November 16, 1996 8:40 AM
>To: Multiple recipients of list PICLIST
>Subject: Re: Board construction techniques (was: Yet another LED project)
>
>
> Where did you get your Dremel drill press accessory? And, how much did it
>cost?
>
>
The package is called Challenger Lite, from Ultimate Technologies in the
Netherlands. They have a Web site at http://www/ultiboard.com/offer.html.
It used to be $79 US, incl shipping but now is $94.
The package has a schematic capture module, a PCB layout module, with an
autorouter built in, plus a separate fancier autorouter. It is a DOS
package (the separate autorouter is Windows ... I've not even fired it
up), but comes with a reasonable set of video drivers. But the standard
SuperVGA ones work fine for me.
It's biggest flaw comes from the documentation. They send a tutorial
manual, and a getting started manual, but no user manual. And no on-line
help. But with some experimenting, you can figure out what a lot of the
things do.
For example, since I use the laser printer/iron-on method, I like traces
and pads that are a bit larger than normal. It was relatively easy to
figureout how to change the default trace and pad sizes.
It has an impressive library of components (no PICs, but building a
library component is quite easy). One caution ... being a European
package, it uses Eurpoean schematic symbols by default. HOWEVER, there
is an American symbol library set as well ... you just have to make sure
that you select from the proper library.
The schematic package is easy to use, and produces high-quality
drawings. Same with the PCB package. If you want to do anything other
than what is in the tutorial manual, be prepared to experiment.
The printing subsystem supports laser printers, plotter, and Gerber
photoplotter stuff. The printing can be customized (again, via
experimentation) to your needs. For example, I don't make two-sided
boards, but I use the ability of the PCB package to put traces on the
top side to place wire jumpers. I modified the printing of the top-side
silk screen (which I use a component layout guide) to print the
top-side traces as well, then I just install jumpers where those traces
show up.
I'm very impressed. I too played around with Winboard, and this is much
better. It is a professional package with a 500 pin limit.
They said that when they ship version 5, the Windows 95 version,
purchasers of Challenger Lite will get an upgrade to that version free.
I'm anxiously awaiting it.
>----------
>From: Matthew Mucker[SMTP:RemoveMEmmuckerTakeThisOuTAIRMAIL.NET]
>Sent: Saturday, November 16, 1996 5:14 PM
>To: Multiple recipients of list PICLIST
>Subject: Re: Board construction techniques (was: Yet another LED project)
>
>Larry,
>
>How 'bout sharing a little more info about this gem with the rest of us?
>I've downloaded WinDraft and WinBoard, but WinDraft locks my system, and
>
> The problem with these is the tooling cost. The drills are OK but the
> special mills that outlinre the traces are expensive. They do last quite a
> while. The tools with a short life are if you want to do a board rubout of
> unused copper or another "outline" with the end mill to make a wider
> isolation path. The end mills in that size are expensive and wear out fast.
Actually, what you need to do is learn to sharpen the things. I used a
diamond hone and a "vision aid" to see the edge. Most of the machines
I've seen use a pointed bit, and the tip geometry is so simple that
sharpening is pretty easy.
At 11:21 AM 11/18/96 -0500, terogers wrote:
>Larry G. Nelson Sr. wrote:
>
>> The problem with these is the tooling cost. The drills are OK but the
>> special mills that outlinre the traces are expensive. They do last quite a
>> while. The tools with a short life are if you want to do a board rubout of
>> unused copper or another "outline" with the end mill to make a wider
>> isolation path. The end mills in that size are expensive and wear out fast.
>
>Actually, what you need to do is learn to sharpen the things. I used a
>diamond hone and a "vision aid" to see the edge. Most of the machines
>I've seen use a pointed bit, and the tip geometry is so simple that
>sharpening is pretty easy.
>
>-- Tom Rogers Time Tech Inc.
>
>
This is true for the main mill from T-Tech for example but the end mills are
too tiny.
Larry G. Nelson Sr. TakeThisOuTL.NelsonTakeThisOuTRemoveMEieee.org http://www.ultranet.com/~nr
> The only drawback to NT is that some equipment, especially that
> which has custom bus interface cards like the PICMAster, will not
> run under NT.
Just a quick clarification:
That should read "....will not run under NT until new device drivers
are written". There's nothing in the PICMaster HARDWARE that keeps
it from running under NT.
Antti, if you are going to produce a BASIC compiler, I suggest that you
look at using BS 2 syntax, not BS1. In particular, the BS-2 way of
defining/using variables is much better. And it would be nice to have
the BS2 features ... in particular, SHIFTIN/SHIFTOUT.
I'd be happy to help you beat the devil out of the beast, if you do a
BS-2 version. I have the Micro Engineering Labs Picbasic (BS-1) and it
works well, but a freeware or shareware BS-2 would be a lot better.
>----------
>From: Antti Lukats[SMTP:spamBeGoneanttispam_OUTSISTUDIO.COM]
>Sent: Monday, December 02, 1996 5:07 AM
>To: Multiple recipients of list PICLIST
>Subject: Christmas lights with PIC Basic anyone?
>
>(snip)
>In the meantime I am making experiments with our tiny basic compiler
>which is today very very alfa, but already produces some useable code.
>
>I am wondering if there is anyone around who would be interested to
>test it in this early stage?
>
>currently supported features are
>
>Basic Stamp I syntax
>byte vars
>for next
>goto gosub
>+ - and or xor /2
>pause and some more tokens,
>eeprom, read/write
>
>
>Antti, if you are going to produce a BASIC compiler, I suggest that you
>look at using BS 2 syntax, not BS1. In particular, the BS-2 way of
>defining/using variables is much better. And it would be nice to have
>the BS2 features ... in particular, SHIFTIN/SHIFTOUT.
Actually, why don't you use uSoft's GWBASIC with some PIC Specific
extensions? This would mean that you are creating something a bit more
standard and recognizable by people other than STAMP users. (Although this
may be the point of your compiler.)
>
>I'd be happy to help you beat the devil out of the beast, if you do a
>BS-2 version. I have the Micro Engineering Labs Picbasic (BS-1) and it
>works well, but a freeware or shareware BS-2 would be a lot better.
>
>Larry
>
>>----------
>>From: Antti Lukats[SMTP:EraseMEantti.....SISTUDIO.COM]
>>Sent: Monday, December 02, 1996 5:07 AM
>>To: Multiple recipients of list PICLIST
>>Subject: Christmas lights with PIC Basic anyone?
>>
>>(snip)
>>In the meantime I am making experiments with our tiny basic compiler
>>which is today very very alfa, but already produces some useable code.
>>
>>I am wondering if there is anyone around who would be interested to
>>test it in this early stage?
>>
>>currently supported features are
>>
>>Basic Stamp I syntax
>>byte vars
>>for next
>>goto gosub
>>+ - and or xor /2
>>pause and some more tokens,
>>eeprom, read/write
>>
>>
>
>
Today, the commercial sector is advancing computer and communication
technology at a breakneck pace. In 1992, optical fiber was being installed
within the continental U.S. at rates approaching the speed of sound (if
computed as total miles of fiber divided by the number of seconds in the year).
Aviation Week and Space Technology, October 28, 1996
> > movf (bbb), w
> > skpnc
> > incfsz (bbb), w
> > addwf (aaa), f
>
> And as Bob F. and I were recently discussing, this comes from
> Microchip's AN617. The author is Frank Testa.
Scott & Bob:
I'd also be inclined to believe that Frank Testa was the first to use
that implementation... His use is the earliest reference I've seen.
Of course, others among us have discovered it independently.
Testa also pointed out -- and I only learned about this in 1994, so
he knew about it earlier -- that, with a minor modification, the
code works for valid-carry two-byte SUBTRACTION, too:
> I am looking at doing a project using Philips I2C Bus and, through
> a series of phone calls, happened to end up talking with the
> Philips in-house patent attorney about it. He told me some news
> that disturbed me: he said, and I paraphrase fairly close to the
> original - ' I won't say thay Microchip is breaking the law using
> I2C YET, but they do not have a valid license.' .... I, of course,
> contacted MCHIP and they told me they DID have a license.
> ....
> Anyone know for sure why I was told by Philips that Microchip was on
> their bad list?
Todd:
No, don't get your hopes up... I don't know what's going on, either.
Here's everything I DO know about Microchip, Philips, and the I2C
license. I've divided it into "good" and "bad" categories, but
beyond that, it's completely disoganized... I'm too tired to try to
put these points into any meaningful order:
BAD:
1. When Microchip first started making I2C EEPROMs, the term
"I2C" was conspicuously absent from all of their documentation,
as was any acknowledgement that the protocol was owned by
Philips.
2. I don't know how the I2C licenses are written; if they
differentiate between "dumb" devices like EEPROMs and "smart"
devices like microcontrollers, Microchip may have stepped on
their toes by incorporating I2C (even though it's only Slave
Mode) into the PICs.
3. Microchip's microcontrollers don't implement Master Mode in
hardware, but Microchip advertises them as containing a
Synchronous Serial Port "with I2C". Maybe Philips doesn't like
that.
4. Microchip has traditionally taken a too-casual approach to
trademarks; the "Pro Master" programmer had to be renamed "Pro
Mate" when it was discovered that the name was already taken,
and even the word "PIC" can't be used in any of Microchip's
development tools, since it's trademarked by a European company.
Maybe they used the I2C trademark inappropriately, too... I
don't know.
GOOD:
1. In general, Philips seems willing to license the I2C
protocol to just about ANYONE... As you mentioned, there are AT
LEAST 15-20 licensees.
2. Microchip Technology is a member of the ACCESS.bus Industry
Group, and ACCESS.bus uses the I2C protocol. By supporting
AbIG, Microchip is supporting Philips.
3. All the current literature acknowledges that I2C is a
Philips trademark, and the Microchip databooks even reference
the Philips "I2C and how to use it" spec.
4. Microchip is now #2 worldwide in serial-EEPROM sales
(behind -- WAY behind, by the way -- SGS-Thomson).
Ok... That's it. Sorry I didn't have any specific information for
you.
As Piotr Piatek has patiently explained to me in private e-mail, the
Gray-code algorithm I gave is equivalent to the one Warren Davis
showed... I misread Warren's description and didn't realize that his
"b(i)" notation referred to individual bits in n-bit words; instead,
I thought each b(i) represented an entire n-bit word.
> This problem is hardly unique to microcontrollers, and can
> frequently occur when people from different disciplines are
> exchanging information. For example, someone not familiar with
> dietary measures might assume that a Life Savers(r) candy with 10
> calories would have approximately enough energy to heat one gram of
> water ten degrees C; in fact, the candy has 1,000 times that much
> energy because the real dietary unit is the "kilocalorie" except
> that people shorten it to "calorie".
Of course, the MOST unfortunate consequence of the
"calorie/Calorie" misunderstanding is that it makes impossible
the "gin-and-tonic diet", in which you drink a liter of your
favorite cold beverage and burn 25,000 calories simply by
bringing the cold liquid up to body temperature in your stomach.
The discussion "Placing blame on IBM (RA4 inversion)" inspired me to do
a little investigation, since the parallel port control pins is my primary
means of interfacing PCs and PICs.
Question is: What ARE the pullups, usually?
According to the Parallel port-FAQ, the control ports are supposedly
pulled up by 4.7k resistors, if I remember right. I decided to
check this out on three PCs I had in my vicinity. This can be easily done
with the following procedure:
1. In DOS, run DEBUG and give the following command:
o 37a 4
This sets the four control pins 1, 14, 16, and 17 high. The address
37a (hex) is the standard parallel port address. Replace with whatever
is the address for your system.
2. Use an ammeter to measure the current between GND (any pin 18-25)
and pins 1, 14, 16, and 17, respectively.
3. For a 4.7k pullup, this current should be about 1mA (=5V/4.7kOhm).
The result was interesting. For each single computer, the current
was the same over the pins, but there was an order of magnitude
difference between computers:
Old Toshiba notebook (5 years): 0.44 mA
Medium old Taiwanese desktop (3 years): 6.1 mA
New Taiwanese notebook (1 year): 1.0 mA
I would be interested in knowing the results for anybody else. It seems
the pullups vary generally in the range 1k-10k.
I tested two PCs that I had handy here in my office. Using an ohmmeter
between 5 volts
and the control lines with the PC off:
a: Compaq 486SX has 4.7K pullups.
b: Clone 486 DX has 2.2 Meg resistance ( VLB I/O card). Obviously in
this machine
the "pullups" are actually MOSFET current sources internal to the I/O
chip.
In my experience, all PC standards are non-standard. Last summer we
designed a device that interfaced
with the PC keyboard port which is also an open collector port. We found
pullup resistors as small as
470 ohms in one machine. Most typical was 2.2K, several 1K pullups were
found.
--- Steve
>Question is: What ARE the pullups, usually?
>According to the Parallel port-FAQ, the control ports are supposedly
>pulled up by 4.7k resistors, if I remember right. I decided to
>check this out on three PCs I had in my vicinity. This can be easily
done
>with the following procedure:
>1. In DOS, run DEBUG and give the following command:
>This sets the four control pins 1, 14, 16, and 17 high. The address
>37a (hex) is the standard parallel port address. Replace with whatever
>is the address for your system.
>2. Use an ammeter to measure the current between GND (any pin 18-25)
>and pins 1, 14, 16, and 17, respectively.
>3. For a 4.7k pullup, this current should be about 1mA (=5V/4.7kOhm).
>The result was interesting. For each single computer, the current
>was the same over the pins, but there was an order of magnitude
>difference between computers:
> Old Toshiba notebook (5 years): 0.44 mA
> Medium old Taiwanese desktop (3 years): 6.1 mA
> New Taiwanese notebook (1 year): 1.0 mA
Martin Nilsson wrote:
.........
> 1. In DOS, run DEBUG and give the following command:
>
> o 37a 4
>
.........
> 2. Use an ammeter to measure the current between GND (any pin 18-25)
> and pins 1, 14, 16, and 17, respectively.
>
> 3. For a 4.7k pullup, this current should be about 1mA (=5V/4.7kOhm).
Martin:
Be carfull, most DMMs when measuring current have a voltage drop
(burden) that causes them to understate the current. You can check
this by manually increasing the range to the Amps range, or use a
shunt resistor and measure the voltage drop before and after it is
installed.
>Be carfull, most DMMs when measuring current have a voltage drop
>(burden) that causes them to understate the current. You can check
>this by manually increasing the range to the Amps range, or use a
>shunt resistor and measure the voltage drop before and after it is
>installed.
If the voltage drop over my meter is anywhere near the order
of 5V, I will surely return it to factory for service :-). The
internal resistance for my DMM in the 20mA range is 10 Ohm => about 1%
voltage drop => not service time yet...
By the way, I measured the second parallel port on my desktop
(27a). This port sits on a cheap I/O card of recent date. Result: 2.2mA. X-@
The newsgroup-versus-maillist thread pops up here about once every
six months... Each time, the OVERWHELMING concensus is that no one
wants to "convert" the list to a newsgroup.
Moreover, there are strong arguments even against forming an
automated "gateway" connection between the list and a newsgroup...
Automatically copying to the list all the crap that'll appear on the
newsgroup will give us the worst of both worlds, and copying in the
other direction will put all the list-members' e-mail addresses out
in the open where they can be added to junk-mail mailing lists.
If anyone wants to start a PIC-centric newsgroup, that's fine... Just
go to news.announce.newsgroups and start the process. But don't
expect to find a lot of support here for any connection between the
existing list and that newsgroup.
Oh... And whatever you do, please don't ever ask for a "vote" here
on the list (on this or any other topic) without an explicit
instruction -- repeated a couple of times in all caps, preferably --
that all votes are to be sent to you in PRIVATE e-mail rather than to
the list at large. There are over 1200 members of the PICLIST; no
one wants to read "I agree" or "I vote no" messages from each of
them.
A "birthday attack" against a cryptographic one-way hash function
(which is what I assume John Payson was talking about when he
mentioned a hypothetical "improved" code-protection scheme for the
PICs) is an attack that takes advantage of a statistical property
usually demonstrated by the "Birthday Problem":
Assuming random distribution, how many people must be in a room
for there to be a greater than 50% chance that at least two of
them share the same birthday?
The answer is lower than you might think: Only 23 people.
In the case of a one-way hash function that produces an 8-bit
output, 129 random attempts would be required before you had a
greater-than-even chance of finding an input message that hashed to
a SPECIFIC output, but if you only needed to find two inputs that
hashed to the SAME arbitrary output, you'd need to try just 20
inputs.
To see this for yourself, run the following BASIC program:
Z = [number of days in a year]
K = [number of people in the room]
> Oh wait, the Rockwell assembler (Apple ][) did use "$" I think.
>
> $ would then be context sensitive, because it's the standard to denote
> "current PC" as in
> goto $-1
>
> for an infinite loop. I never liked making compilers with context-sensitive
> tokens myself.
It's not context-sensitive as the term is normally used. If you regard
that as context-sensitive, then so is 0 - on its own it's a number - when
it comes after a letter e.g. M0 then it's part of a symbol. Context
sensitivity refers to stuff like the IntelSoft 8086 assembler syntax,
where the instruction
mov ax,fred
could mean either direct addressing, or immediate addressing, i.e. either
move the contents of the location 'fred', or move the address of the
location 'fred'. The distinction depends on the previous type of declaration
of the symbol 'fred'. This, in an assembler, is a Bad Thing, in my view. But
the notion of context-sensitivity is not usually applied at the lexical
level, where individual characters are grouped into tokens.
There is, regrettably, a veritable plethora of different syntaxes (should that
be syntaces, I wonder?) for number-base specification. As Andy suggested, the
only sensible solution is to support all of them.
Clyde
--
Clyde Smith-Stubbs | HI-TECH Software, | Voice: +61 7 3354 2411 spamBeGoneclydeKILLspamKILLspamhtsoft.com | P.O. Box 103, Alderley, | Fax: +61 7 3354 2422 http://www.htsoft.com | QLD, 4051, AUSTRALIA. |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/
At 08:35 PM 2/20/97 +1000, you wrote:
>Thus spake Andy Kunz (TakeThisOuTmontanaspamFAST.NET):
>
>> Oh wait, the Rockwell assembler (Apple ][) did use "$" I think.
>>
>> $ would then be context sensitive, because it's the standard to denote
>> "current PC" as in
>> goto $-1
>>
>> for an infinite loop. I never liked making compilers with context-sensitive
>> tokens myself.
>
>It's not context-sensitive as the term is normally used. If you regard
>that as context-sensitive, then so is 0 - on its own it's a number - when
>it comes after a letter e.g. M0 then it's part of a symbol. Context
>sensitivity refers to stuff like the IntelSoft 8086 assembler syntax,
>where the instruction
I was approaching "context sensitive" from the point of the
compiler/assembler writer.
In compiler design, one frequently is able to consider alpha characters as
starting identifiers, math operators as such, etc. Numerics are "alpha" if
they are immediately following an alpha. THis is usually very easily
handled by the tokenizer in the first pass of the compiler.
It's when the tokenizer can't figure out what a character is as soon as it
sees it that things get touchy. For example, if we were to support "$" as
both denoting a hex value and the PC, we have to "look ahead" to see the
next character before we know what to do.
movlw $0c
goto $-1
If the language you are writing your compiler in supports look-ahead
functionality (some do not!) for file I/O, it isn't a problem. You can GET
and UNGET.
What's funny is that when reading post notation on types, you need to read
the value as a string and then parse it when you reach the type. That's a
pain, too. That's one thing where C is much better than many other languages.
Your 8086 assembler example is a perfect reason why people should use C. <G>
Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
Hardware & Software for Industry & R/C Hobbies
"Go fast, turn right, and keep the wet side down!"
==================================================================
> It's when the tokenizer can't figure out what a character is as soon as it
> sees it that things get touchy. For example, if we were to support "$" as
> both denoting a hex value and the PC, we have to "look ahead" to see the
> next character before we know what to do.
>
> movlw $0c
> goto $-1
Yes, but single-character lookahead is required anyway - otherwise you would
not even be able to parse 1+1. It's best to
implement your own level of get and unget rather than relying on ungetc()
or equivalent. Apart from anything else, it makes life much easier if
you read a whole line of input at one time.
Lexical analysis can be tricky at times; consider the following
fragment of C code:
char a[] = {
0x0E+1,
0x0D+2,
};
One of these is a legal expression in ANSI C, the other is not.
Cheers, Clyde
--
Clyde Smith-Stubbs | HI-TECH Software, | Voice: +61 7 3354 2411 EraseMEclydeEraseMEhtsoft.com | P.O. Box 103, Alderley, | Fax: +61 7 3354 2422 http://www.htsoft.com | QLD, 4051, AUSTRALIA. |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/
> The PIC16C74 has two banks of registers. As it happens the TRIS
> registers are located in the upper bank. I don't think the TRIS
> PORTC command in your example will work.
>
> I was under the impression something more like this is required...
>
> [example using RP0 and MOVWF TRISC snipped]
>
> If anyone knows this is not required, I would be interested to hear
> about it...
Bob:
The TRIS PORTx instructions work (and will always work) on all the
current PIC16Cxx processors... For ports A, B, and C, there's no
real need to go through the machinations specified in the Microchip
data books.
That said, I should mention that I personally never use the TRISx
instructions on those parts with accessible TRIS registers, unless
I'm REALLY pressed for space or time.
-Andy
=== Andrew Warren - spamfastfwdix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Did the information in this post help you? Consider
=== contributing to the PICLIST Fund. Details are at:
=== www.geocities.com/SiliconValley/2499/fund.html
> > Isn't an infinite loop done with: goto $
>
> No, because PC has been incremented to point to the next
> instruction. Standard notation is to do it: goto $-1
>
> ....
>
> Here's a hint. If you have to a waste time, and you would normally
> write it as
> NOP
> NOP
> NOP
> NOP
>
> try using the following instead.
>
> goto $+1
> goto $+1
Um, Andy?
How do you reconcile your "$-1" infinite loop with your "$+1"
two-cycle NOP?
The PIC's program counter is incremented before the current
instruction is executed, but the ASSEMBLER's "program counter"
isn't. Perhaps you've confused the two?
> When I make comments about the MPLAB-C I try my best to qualify them
> with Version numbers. So many of the compiler writers are trying
> their best to repair their products and version numbers are the way
> to keep score.
Good point. By the way, CCS is a prime offender in this regard;
the "Compiler Comparison" page on their web site compares their
compiler to a VERY old version of MPC.
A number of people have asked them to update that page, but CCS
apparently believe that it wouldn't serve their interests to do
so, since (at least, the last time I checked) they haven't yet
gotten around to it.
> Lexical analysis can be tricky at times; consider the following
> fragment of C code:
>
> char a[] = {
> 0x0E+1,
> 0x0D+2,
> };
>
> One of these is a legal expression in ANSI C, the other is not.
What is the problem here? The only thing I can see which is questionable is
the extra comma after the second expression; I believe, however, that the ANSI
standard requires that compilers accept (and ignore) a comma following the
last item in an initializer. Is there something else which I should be notic-
ing?
> How do you reconcile your "$-1" infinite loop with your "$+1"
> two-cycle NOP?
>
> The PIC's program counter is incremented before the current
> instruction is executed, but the ASSEMBLER's "program counter"
> isn't. Perhaps you've confused the two?
I stand corrected.
"goto $-1" will jump to the instruction preceding the goto
"goto $" will be an endless loop
"goto $+1" will jump to the next address (I was right about this one, anyway).
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
Hardware & Software for Industry & R/C Hobbies
"Go fast, turn right, and keep the wet side down!"
==================================================================
> The opcode for NOP on the 68000 is decidedly NOT the same as the opcode for
> a jump-short to the next instruction. On the 68000, a jump instruction has
> an eight bit relative address. If this field is non-zero, it will be added
> to the address of the following instruction and loaded into the PC. If this
> field is zero, then the 68000 will fetch the next 16 bits and use those as a
> relative address.
Yup, that's what I said in my previous message. I did not say that a NOP has the
same opcode as a jump, I said (in an oblique manner) that some assemblers will
output a NOP when jmp $+2 is requested.
> [1] Output some useless one-word instruction [e.g. NOP]. This will be compact
> but it will produce slightly skewed timings.
>
> [2] Output a short jump ahead 2, followed by a NOP. The NOP will put the tar-
> get of the jump in an acceptable place, while giving execution timings
> comparable to just using a short jump (if such a thing were possible).
The
> extra NOP may mess up cache timings, however.
>
> [3] Output a long jump to next instruction. This may be slower to execute
than
> method #2, and probably doesn't have any particular advantage, but it is
> the only output which is "literally" correct.
Neither [1] nor [2] is correct, since they implement jmp $+4. Other than the
effect on the pipeline (which on a 68000 is only one word deep anyway) a NOP
has precisely the same effect as a short jmp $+2 would if it existed. But some
people have trouble with the assembler choosing a bit pattern for an instruction
that is not what they expect.
In the same vein, there are processors with skip instructions, including SKIPA
(skip always) and SKIPN (skip never), and on at least one (can't remember which
one now) the SKIPN is used as a NOP.
The PIC is an interesting case - have a look at the encoding for NOP - it
happens to be equivalent to
movwf 0,w
NOP even gets listed in the opcode table with the other instructions that
reference memory. Go figure.
--
Clyde Smith-Stubbs | HI-TECH Software, | Voice: +61 7 3354 2411 spamBeGoneclyde.....htsoft.com | P.O. Box 103, Alderley, | Fax: +61 7 3354 2422 http://www.htsoft.com | QLD, 4051, AUSTRALIA. |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/
> > Lexical analysis can be tricky at times; consider the following
> > fragment of C code:
> >
> > char a[] = {
> > 0x0E+1,
> > 0x0D+2,
> > };
> >
> > One of these is a legal expression in ANSI C, the other is not.
>
> What is the problem here? The only thing I can see which is questionable is
> the extra comma after the second expression; I believe, however, that the ANSI
> standard requires that compilers accept (and ignore) a comma following the
> last item in an initializer. Is there something else which I should be notic-
> ing?
Yes, there is (but it requires a careful reading of the ANSI standard
to figure it out).
Now first up, since sometimes I seem to be a little too obtuse in my postings,
let me make it clear that I don't like what the ANSI standard says about
this, i.e. I think the standard is broken in this regard. So there's no point
in arguing with me about it - I just happen to have been caught by a compiler
(gcc) that is very literal in its interpretation of the standard. But it
IS the standard so it's neither wrong nor right, it just is.
The ANSI standard for C separates the lexical analysis and parsing of a C
program in several stages; the first happens at the pre-processor level,
and it is at this stage that all tokenization occurs, i.e. once a program
has been converted to a stream of tokens, those tokens are indivisible by
later stages. The tokenization is specified by a grammar, and one of the
grammar elements is a non-terminal called a 'pp-number', which is meant
to represent anything in C that will later be interpreted as a number.
Incidentally, it is not required by the standard that a compiler actually
implement things in these stages, but it must behave as if it does (this
is known as the "as-if" rule).
Basically a pp-number is anything that starts with a digit, followed by
any sequence of digits, upper and lower case letters a-f and x, or
a decimal point, then optionally followed by a plus or minus sign
and one or more decimal digits. I may have the exact details wrong,
but that's the gist of it. This caters for decimal numbers (123),
hex numbers (0x123) and real numbers (0.123, 123e+10).
But the way the grammar is written, 0x0E+1 is a pp-number! So
at the lexical level, the sequence 0x0E+1 becomes a single token,
whereas 0x0D+2 is split into a pp-number (0x0D), a plus sign, and another
pp-number (2). Now when you get to the next stage, where numbers are
actually parsed into hex, decimal or whatever, this token (0x0E+1)
is not a legal number. So your program will not compile.
Now being a subjective, illogical human being, I can look at 0x0E+1
and know perfectly well what the programmer meant. But a strictly-
conforming ANSI compiler is not allowed to be that clever.
So if you want to add a constant to 0x0E, leave a space before the +
sign, i.e.
0x0E +1
is fine.
--
Clyde Smith-Stubbs | HI-TECH Software, | Voice: +61 7 3354 2411 @spam@clydehtsoft.com | P.O. Box 103, Alderley, | Fax: +61 7 3354 2422 http://www.htsoft.com | QLD, 4051, AUSTRALIA. |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/
> The PIC is an interesting case - have a look at the encoding for NOP - it
> happens to be equivalent to
>
> movwf 0,w
>
> NOP even gets listed in the opcode table with the other instructions that
> reference memory. Go figure.
Right. What happens if FSR happens to be pointing at a register which would
be affected by the read?
On the 16C5x, at least, NOP is 0x000, while movf 0,w would be 0x200
and movwf 0 would be 0x020. The only thing that NOP might code to
would be tris 0, which is of course a nonsense operation.
______________________________ Reply Separator _________________________________
Subject: Re: Instruction encodings (was: Code error)
Author: John Payson <supercatRemoveMEMCS.NET> at Internet
Date: 2/21/97 9:07 AM
> The PIC is an interesting case - have a look at the encoding for NOP - it
> happens to be equivalent to
>
> movwf 0,w
>
> NOP even gets listed in the opcode table with the other instructions that
> reference memory. Go figure.
Right. What happens if FSR happens to be pointing at a register which would
be affected by the read?
> Right. What happens if FSR happens to be pointing at a register which would
> be affected by the read?
Even though movwf 0,w would be the obvious interpretation of opcode 0x0000
surely it would never be executed as such so we never have to worry about
where FSR points. Or have I got that wrong?
Andrew Warren wrote:
>
> John Dammeyer <spamPICLISTMITVMA.MIT.EDU> wrote:
>
> > When I make comments about the MPLAB-C I try my best to qualify them
> > with Version numbers. So many of the compiler writers are trying
> > their best to repair their products and version numbers are the way
> > to keep score.
>
> Good point. By the way, CCS is a prime offender in this regard;
> the "Compiler Comparison" page on their web site compares their
> compiler to a VERY old version of MPC.
>
> A number of people have asked them to update that page, but CCS
> apparently believe that it wouldn't serve their interests to do
> so, since (at least, the last time I checked) they haven't yet
> gotten around to it.
We are quite aware of the age of our comparison. We do have
several customers working on that comparison so it will be current.
anybody that asks me about the page I tell me that it is comparing
the older version of the compiler. You can also note that it does not
cover Microchip's compiler, just the ByteCraft compiler. This also will
soon be changed.
I will change our web page today to reflect that this is an old
version of the comparison and to look for a new one soon.
> John Payson wrote:
>
> > Right. What happens if FSR happens to be pointing at a register which would
> > be affected by the read?
>
> Even though movwf 0,w would be the obvious interpretation of opcode 0x0000
> surely it would never be executed as such so we never have to worry about
> where FSR points. Or have I got that wrong?
Well, on the 16C74, a RETURN instruction (0x000D) does a read to port D (at
address 0x000D) which will clear the incoming byte flag if that port is used
in parallel-slave mode. Draw your own conclusions (I would not rely on that
behavior, because Microchip may fix it, but AFAIK current silicon works that
way. Fortunately, on the PIC very few things are affected by reads.
Consider as well, by the way, that CLRW may behave similarly; even if Mchip
adds logic to ensure that 000000x xxxxxxx instructions don't read memory, the
CLR instruction probably will continue to do so.
At 02:57 PM 2/21/97 -0000, you wrote:
>Hi to all.
>
>First, does anyone know where i can get a freeware/shareware 6502 assembler
>for use on the pc?
>
There are two that I know of, and you ought to be able to find them at any
of the "good" ftp sites(is Simtel-20 still operational?). These two
cross-assemblers I see are on a couple of shareware cd-roms that I have.
If you can search the internet, look for "tasm" or "table-driven assembler"
or "pseudosam".
Hi.
I have found tasm, but not for the 6502.
I can seem to get it ok for the pc, but not the 6502. I have a differnt
assembler, but not this one. If you would like to mail it to me, if it is
not too big, then please do.
Thanx,
Daniel.
----------
> From: Bob Blick <@spam@bblickspam_OUTTELIS.ORG>
> To: .....PICLIST.....MITVMA.MIT.EDU
> Subject: Re: 6502 x-asm(was: interfacing the 93c66)
> Date: 22 February 1997 02:02
>
> At 02:57 PM 2/21/97 -0000, you wrote:
> >Hi to all.
> >
> >First, does anyone know where i can get a freeware/shareware 6502
assembler
> >for use on the pc?
> >
> There are two that I know of, and you ought to be able to find them at
any
> of the "good" ftp sites(is Simtel-20 still operational?). These two
> cross-assemblers I see are on a couple of shareware cd-roms that I have.
>
> If you can search the internet, look for "tasm" or "table-driven
assembler"
> or "pseudosam".
>
> -Bob
>
> http://www.bobblick.com/
At 18:42 21.02.97 -0600, you wrote:
>> > Right. What happens if FSR happens to be pointing at a register which
would
>> > be affected by the read?
>>
>> Even though movwf 0,w would be the obvious interpretation of opcode 0x0000
>> surely it would never be executed as such so we never have to worry about
>> where FSR points. Or have I got that wrong?
>
>Well, on the 16C74, a RETURN instruction (0x000D) does a read to port D (at
>address 0x000D) which will clear the incoming byte flag if that port is used
>in parallel-slave mode. Draw your own conclusions (I would not rely on that
>behavior, because Microchip may fix it, but AFAIK current silicon works that
>way. Fortunately, on the PIC very few things are affected by reads.
>
I can't believe, that PICs behave the way you say.
It should be easy, to decode special instructions in a way that they don't
have theses side effects you mentioned.
The data sheets _SHOULD_ also mention them?!?
> One of the timers is preloaded / prescaled such that it will
> generate an interrupt every <n> ms. (input = OSC) This is your
> system's heartbeat.
>
> Then to measure the number of revolutions, you start a counter that
> counts the pulses read from the shaft (e.g. TMR1 in a 'C64).
>
> Depending on the pulse frequency and the accuracy, you let it count
> for a certain time and read it out. The time is of course a multiple
> of the <n> ms heartbeat.
>
> The <n> ms depends on your OSC frequency. To give you an example,
> using a 2.4576 MHz Xtal and some presacling, I get a 5 ms heartbeat.
> The interrupt routine counts the heartbeats and every 200 beats (1
> sec), it stops + reads the 16 bit TMR1, writes it to some variable
> and clears the TMR1 and starts it again.
Jeroen:
Good suggestion, but I'm afraid your method will only be
accurate if the shaft is rotating VERY rapidly relative to the
gate time.
In this case (measuring the speed of an anemometer with a
1-second gate time), your method will be accurate to within 1%
only when the anemometer is spinning at 6000 RPM or faster...
Not very likely.
Of course, if Richard doesn't mind opening up the gate time to
10 seconds, he can get 1% accuracy at speeds of only 600 RPM.
He can accomplish the same goal by putting 10 magnets (or
reflective stripes, or gear teeth, or whatever he's using to
count revolutions) on the shaft, too.
If he doesn't want to do either of those things, measuring the
time required for each rotation is the most accurate way. He
can even use TMR1 in the Capture Mode to get the same sort of
background operation that your method provides.
-Andy
=== Andrew Warren - KILLspamfastfwd.....KILLspamix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html
In message <3.0.32.19970224100413.009057b0@mira> PICLISTspam_OUTspam_OUTMITVMA.MIT.EDU writes:
> At 18:42 21.02.97 -0600, you wrote:
> >> > Right. What happens if FSR happens to be pointing at a register which
> would
> >> > be affected by the read?
> >>
> >> Even though movwf 0,w would be the obvious interpretation of opcode>
0x0000
> >> surely it would never be executed as such so we never have to worry about
> >> where FSR points. Or have I got that wrong?
> >
> >Well, on the 16C74, a RETURN instruction (0x000D) does a read to port D (at
> >address 0x000D) which will clear the incoming byte flag if that port is>
used
> >in parallel-slave mode. Draw your own conclusions (I would not rely on>
that
> >behavior, because Microchip may fix it, but AFAIK current silicon works>
that
> >way. Fortunately, on the PIC very few things are affected by reads.
> >
>
> I can't believe, that PICs behave the way you say.
> It should be easy, to decode special instructions in a way that they don't
> have theses side effects you mentioned.
> The data sheets _SHOULD_ also mention them?!?
>
It sure seems to be worrying.
Can we have some comment from Microchip on this please? Brian?
The first 16C5X PIC devices would generally do an extraneous read of
the memory at whatever address the least significant 5 bits pointed
to. This saved transistors and on devices without a lot of
peripherals was safe to do.
On the '74, as peripherals were added, this became more involved and
location 000D was overlooked.
On all new devices such as '74A, the instruction decoder PLA treats
literal and control instructions as special cases and shuts off the
read logic.
BTW, the NOP reading the FSR was never a problem as the PLA always
accounted for that. The NOP is actually MOVWF 0,W which will only
move W to W and a read of FSR is disabled. That PLA term that
disables the read is now generalized to disable all inadvertent reads.
At 18:42 21.02.97 -0600, you wrote:
>> > Right. What happens if FSR happens to be pointing at a register which
would {Quote hidden}
>> > be affected by the read?
>>
>> Even though movwf 0,w would be the obvious interpretation of opcode 0x0000
>> surely it would never be executed as such so we never have to worry about
>> where FSR points. Or have I got that wrong?
>
>Well, on the 16C74, a RETURN instruction (0x000D) does a read to port D (at
>address 0x000D) which will clear the incoming byte flag if that port is used
>in parallel-slave mode. Draw your own conclusions (I would not rely on that
>behavior, because Microchip may fix it, but AFAIK current silicon works that
>way. Fortunately, on the PIC very few things are affected by reads.
>
I can't believe, that PICs behave the way you say.
It should be easy, to decode special instructions in a way that they don't
have theses side effects you mentioned.
The data sheets _SHOULD_ also mention them?!?
regards
Wolfram
+-----------------------------------------------------+
| Wolfram Liebchen |
| Forschungsinstitut für Optik, Tübingen, Deutschland |
| @spam@liebchenRemoveMEffo.fgan.de |
+-----------------------------------------------------+
> Awesome post Edward. Many thanks! I've included the whole original
> as I added comp.arch.embedded and sci.electronics.design to the
> newsgroups. I'm also sending it to the pic mailing list. The more
> neurons the merrier.
Andrew:
Awesome though Edward's post may be, crossposting it to multiple
newsgroups, let alone to the PICLIST, is not likely to make many
people "merry".
In the future, perhaps it would be best to just post a short note
saying something like:
"Edward and I are having a really fascinating discussion of X-10
wall switches. If you're interested in joining us, come on over
to the comp.arch.embedded newsgroup."
> Aaahhrgh!!!
>
> Please get rid of this mail program of yours that sends HTML mail.
> Or configure it to not send messages as HTML. IMO it is horrible.
... and sent his message with a MIME-encoded Base64 attachment that's
just as horrible as HTML, if not more so.
Dries:
Please configure YOUR mailer so it doesn't send BASE64 copies of
your messages. "Aaahhrgh!!!", indeed.
> From: Andrew Warren <fastfwdTakeThisOuTIX.NETCOM.COM>
>
> Dries Kuperus <.....PICLISTTakeThisOuTMITVMA.MIT.EDU> wrote:
>
> > Aaahhrgh!!!
> >
> > Please get rid of this mail program of yours that sends HTML mail.
> > Or configure it to not send messages as HTML. IMO it is horrible.
>
> ... and sent his message with a MIME-encoded Base64 attachment that's
> just as horrible as HTML, if not more so.
>
> Dries:
>
> Please configure YOUR mailer so it doesn't send BASE64 copies of
> your messages. "Aaahhrgh!!!", indeed.
>
> -Andy
Hear hear! Let's stick to good ol' 7-bit ASCII. Go into your
mailer NOW and switch off the junk!
John Payson <EraseMEsupercatKILLspamMCS.NET> wrote:
> Right. What happens if FSR happens to be pointing at a register which
> would be affected by the read?
and later added:
> Well, on the 16C74, a RETURN instruction (0x000D) does a read to port D (at
> address 0x000D) which will clear the incoming byte flag if that port is
> used in parallel-slave mode.
Wolfram Liebchen <liebchenEraseMEFFO.FGAN.DE> wrote:
> I can't believe, that PICs behave the way you say.
> It should be easy, to decode special instructions in a way that they don't
> have theses side effects you mentioned.
> The data sheets _SHOULD_ also mention them?!?
Yes, they should. But they don't.
Another example of this is the CLRW instructions, which is described in the
data sheets as having the bit pattern 00 0001 0xxx xxxx, where the "x"s are
"don't care".
Originally the Microchip assemblers set all of the don't care bits to 0,
but if the FSR points to a register which has a side effect when read,
this coding will cause problems. This is understandable since CLRW is really
just a ",W" variant of the CLRF instruction.
Recent versions of MPASM now use 00 0001 0000 0011 for CLRW, so the
superfluous read is to the PCL register, and has no side effect. As far as I
know, the PIC data sheets have not been updated to reflect this.
It would appear that all the instructions in the range 0000h..0fffh hex
do a read, even the "special" instructions from 0000h..007fh:
NOP 00 0000 0xx0 0000 (it appears that they have
special-cased 0000h to not read IND,
but I'm not sure about 0020h, 0040h,
and 0060h)
RETURN 00 0000 0000 1000 reads PORTD, TRISD, PORTG, TRISG,
ADCON0, ADCON1, EEDATA, EECON1, or
unimplemented, depending on the part
and the RP0/RP1 bank switch bits
RETFIE 00 0000 0000 1001 reads PORTE, TRISE, ADRES, EEADDR,
EECON2, or unimplemented
The following instructions no doubt do an extraneous read also, but of
locations from 62h to 67h that are likely to always either be RAM or
unimplemented:
OPTION 00 0000 0110 0010 (obsolete)
SLEEP 00 0000 0110 0011
CLRWDT 00 0000 0110 0100
TRIS PORTA 00 0000 0110 0101 (obsolete)
TRIS PORTB 00 0000 0110 0110 (obsolete)
TRIS PORTC 00 0000 0110 0111 (obsolete)
>Awesome though Edward's post may be, crossposting it to multiple
>newsgroups, let alone to the PICLIST, is not likely to make many
>people "merry".
I'll have to stand by the newsgroup crosspost. That's exactly
what is crossposting is for, some subjects span multiple groups.
Three newsgroups isn't excessive IMHO.
Regarding piclist, I _am_ sorry to start another thread about what
is an appropriate thread :-/
>Just my opinion; I could be wrong.
Well, what about the content of the article as opposed to the source.
Interesting? Appropriate?
I thought it applicable. I'll bow to the majority opinion...
I apologise for the article to those who feel as Andrew does.
Andy
> NOP 00 0000 0xx0 0000 (it appears that they have
> special-cased 0000h to not read IND,
> but I'm not sure about 0020h, 0040h,
> and 0060h)
Hmm... perhaps they have special-cased NOP. From what I can tell, at least
on 16C84's in 1995, MOVWF always does a read (which means there's no way to
change any bits on port B without clearing the port-changed latch). I don't
know whether the UART on the 16C74 has this problem (it would be rather a
pain if trying to output a character to the UART would clear any character
that had 'just' come in)
> RETURN 00 0000 0000 1000 reads PORTD, TRISD, PORTG, TRISG,
> ADCON0, ADCON1, EEDATA, EECON1, or
> unimplemented, depending on the part
> and the RP0/RP1 bank switch bits
I think PORD is the only one of these where a read has any effect, however.
Does a read of any of these addresses do anything on any 16Cxx device? If
not, the superfluous read is a non-issue.
> The following instructions no doubt do an extraneous read also, but of
> locations from 62h to 67h that are likely to always either be RAM or
> unimplemented:
> BTW, the NOP reading the FSR was never a problem as the PLA always
> accounted for that. The NOP is actually MOVWF 0,W which will only
> move W to W and a read of FSR is disabled. That PLA term that
> disables the read is now generalized to disable all inadvertent reads.
Hmm... methinks perhaps my code to test that case must have been broken. Most
sorry about that... I wouldn't want to give Microchip any undeserved bad rep-
utation. If I might ask though...
[1] Does the generalized PLA term correctly screen out the MOVWF and CLRW
instructions as well?
[2] Are there any 16C74's out there where writing a character to the serial
port would risk "reading" one? If so, but this quirk has been changed,
when did this change come about?
John Payson <supercatspam_OUTMCS.NET> wrote:
> [2] Are there any 16C74's out there where writing a character to the serial
> port would risk "reading" one? If so, but this quirk has been changed,
> when did this change come about?
The UART has separate Rx and Tx regs, probably because they discovered the
MOVWF problem very early on. Too bad they didn't think to do the same for
the parallel host port. Although that still would have left the RETURN
problem.
> John Payson <spamsupercat@spam@MCS.NET> wrote:
> > [2] Are there any 16C74's out there where writing a character to the serial
> > port would risk "reading" one? If so, but this quirk has been changed,
> > when did this change come about?
>
> The UART has separate Rx and Tx regs, probably because they discovered the
> MOVWF problem very early on. Too bad they didn't think to do the same for
> the parallel host port. Although that still would have left the RETURN
> problem.
True, though Microchip has indicated that they've fixed that too in new
silicon. IMHO, the host port as Microchip implements it is still somewhat
limitted, however, since there is no good way to distinguish commands from
data without adding more external logic. Think what you like about the
8042's instruction set, but having two read addresses and two write addresses
from the host's point of view can really improve things a lot.
> BTW, the NOP reading the FSR was never a problem as the PLA always
> accounted for that. The NOP is actually MOVWF 0,W which will only
> move W to W and a read of FSR is disabled. That PLA term that
> disables the read is now generalized to disable all inadvertent reads.
Hmm... methinks perhaps my code to test that case must have been broken. Most
sorry about that... I wouldn't want to give Microchip any undeserved bad rep-
utation. If I might ask though...
[1] Does the generalized PLA term correctly screen out the MOVWF and CLRW
instructions as well?
[2] Are there any 16C74's out there where writing a character to the serial
port would risk "reading" one? If so, but this quirk has been changed,
when did this change come about?
John Payson <RemoveMEsupercat@spam@spamMCS.NET> wrote:
> IMHO, the host port as Microchip implements it is still somewhat
> limitted, however, since there is no good way to distinguish commands from
> data without adding more external logic. Think what you like about the
> 8042's instruction set, but having two read addresses and two write addresses
> from the host's point of view can really improve things a lot.
Agreed. When I first saw the specs, I thought, "Wow, finally a decent
8041/8042 replacement" (since Intel's never done a decent one since).
Given how ubiquitous the 804x are, you'd think someone at Microchip would
have bothered to actually look at it for ideas as to how to make a *usable*
host port. :-( Mitsubishi, who I usually don't credit for being
exceptionally clueful, managed to get that right on their 3745x parts.
I'd really like to see three separate registers for data and commands written
by the host to the PIC, but even a single register for both would be OK if
they'd save a 9th bit like to 804x.
Sigh. Maybe someday some semi company will accidentally stumble onto the
combination of great engineering *and* low prices. I haven't yet become
convinced that it's impossible.
Maybe we could convince Microchip to send a few of us very early
(pre-tapeout) engineering specs to look over to try to avoid silly design
flaws and limitations like this.
Well, I won't take this personally since I hired into Microchip after
the slave port was defined. The guy who designed it is an Intel-Ex
and was very familiar with the 804X. The port is primarily
constrained by the pin availability. There wasn't a good place to put
an address pin.
BTW, we do customer surveys frequently when defining a new device. If
some of you would like to participate, respond to me directly and
include your address, as we visit the country/world by region.
Rgds, Brian.
______________________________ Reply Separator _________________________________
Subject: Re: Re[2]: Instruction encodings (was: Code error)
Author: Eric Smith <RemoveMEericRemoveMETakeThisOuTBROUHAHA.COM> at Internet_Exchange
Date: 2/25/97 5:01 PM
John Payson <supercatTakeThisOuT@spam@MCS.NET> wrote:
> IMHO, the host port as Microchip implements it is still somewhat
> limitted, however, since there is no good way to distinguish commands from
> data without adding more external logic. Think what you like about the
> 8042's instruction set, but having two read addresses and two write addresses
> from the host's point of view can really improve things a lot.
Agreed. When I first saw the specs, I thought, "Wow, finally a decent
8041/8042 replacement" (since Intel's never done a decent one since).
Given how ubiquitous the 804x are, you'd think someone at Microchip would
have bothered to actually look at it for ideas as to how to make a *usable*
host port. :-( Mitsubishi, who I usually don't credit for being
exceptionally clueful, managed to get that right on their 3745x parts.
I'd really like to see three separate registers for data and commands written
by the host to the PIC, but even a single register for both would be OK if
they'd save a 9th bit like to 804x.
Sigh. Maybe someday some semi company will accidentally stumble onto the
combination of great engineering *and* low prices. I haven't yet become
convinced that it's impossible.
Maybe we could convince Microchip to send a few of us very early
(pre-tapeout) engineering specs to look over to try to avoid silly design
flaws and limitations like this.
At 20:19 25.02.97 +0200, you wrote:
>I had a look in my links and could not find the pointer to the PIC core
>on the net though I saw it there a month ago or so.
>Does anyone out there want to convert the c into whatever the smart cards
>use. I was told that the sky cards were basicly pics????
Original SKY cards are not based on PIC and they certainly can't be easily
reprogrammed - however, almost all pirate cards for the Eurocrypt are based
on PIC16c84. Most people today use the PIC16c84 smartcard made by the major
smartcard manufacturers for hacker supply stores. The software is available
everywhere on Internet, with a built-in feature for the user to update the
encryption key in the card, using the D2MAC/Eurocrypt on-screen menus and
the satellite receiver's remote control.
There is also PIC software freely available to decode 9 Videocrypt2
channels and 2 Videocrypt1-channels. No Sky channels though. The Sky pirate
cards are expensive and based on processors with higher security than
PIC16c84, so that no competing hackers can steal the code and make their
own.
> Yes, the perennial phase error.
> ....
> I encountered this sort of problem when writing a Z80 assembler.
> The Z80 has two different flavours of branch: JR and JP. JR only
> had a short range (and takes 2 bytes) whereas JP could jump anywhere
> (3 byte instruction). I wanted to implement a pseudo-op called 'J'
> which used the shortest possible opcode JR or JP. It turned out
> that to optimally implement this, the assembler would potentially
> have to make a large number of passes, refining its estimate of the
> value of each label each time. It is also conceivable that the
> assembler could get stuck in an infinite loop.
Steve:
This is slightly off-topic, but there's a really simple algorithm
that solves the "branch/jump optimization" problem in linear time:
1. Start with all branches set to the shortest size.
2. Put all the branches on a stack.
3. Pull a branch off the stack; if it's out of range, increase
it to the next-larger size (some processors have 3 or more
branch sizes) and put all the branches that SPAN the
just-increased branch on the stack.
4. Repeat step 3 until everything's stable.
This algorithm was first shown to me by Dr. Cliff Click, who works in
Motorola's PowerPC compiler group. As I said, it runs in linear time
and is guaranteed not to get stuck in an infinite loop.
I can send you the rigorous mathematical proof if you're
interested... It depends on the fact that monotonic functions over
complete lattices have a unique minimal fixed point.
-Andy
=== Andrew Warren - .....fastfwdspamBeGoneix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html
> This is slightly off-topic, but there's a really simple algorithm
> that solves the "branch/jump optimization" problem in linear time:
>
> 1. Start with all branches set to the shortest size.
>
> 2. Put all the branches on a stack.
>
> 3. Pull a branch off the stack; if it's out of range, increase
> it to the next-larger size (some processors have 3 or more
> branch sizes) and put all the branches that SPAN the
> just-increased branch on the stack.
>
> 4. Repeat step 3 until everything's stable.
>
> This algorithm was first shown to me by Dr. Cliff Click, who works in
> Motorola's PowerPC compiler group. As I said, it runs in linear time
> and is guaranteed not to get stuck in an infinite loop.
That's not a bad algorithm, though most assemblers I've seen use the following
instead:
[1] Pass I: Assemble the code assuming all forward references, and all back-
ward references that aren't known to be short, are long.
[2] Pass II: Assemble the code, using the information gained from [1] to make
branches short when possible. REMEMBER which branches/accesses were long.
[3] Pass III: Assemble the code for real. Make branches/accesses short or
long so as to match pass II.
Simpler, and in practice essentially as good. Note that it's possible to in
pass II not record which branches are long/short but just 'hope' pass III has
them all the same length as in pass II. Usually this will work, and if it
fails (easy to detect) a pass IV would usually resolve it. Naturally there
cases where this algorithm--no matter how many passes it's run--will yield a
sub-optimal result (e.g. a pair of branches which are out of short-branch
range BECAUSE they are long). Nonetheless, such cases are usually rare and
such assemblers are just fine in practice.
> I feel that one should suffer a little bit in the beginning to
> develop a way of thinking. Copying other's code teaches nothing.
Tjaart:
I understand your point, but I'm not sure that you can make such a
blanket declaration about copying others' code.
For instance, how long do you suppose it would take a beginner to
come up with the following extremely-useful code fragments without
ever having seen them used in someone else's code?
ADDLW 256-HIVAL ;THIS IS ERIC SMITH'S CODE TO TEST FOR
ADDLW (HIVAL-LOVAL)+1 ;"LOVAL <= W <= HIVAL".
BC INRANGE ;
#3:
ADDWF PCL ;CALCULATE 2^W, WHERE W IS IN THE
ADDLW 0 ;RANGE [0-7].
ADDLW -1 ;
ADDLW -3 ;
ADDLW -7 ;
ADDLW -15 ;
ADDLW -31 ;
ADDLW -63 ;
ADDLW 121 ;
#4:
MOVF BLO,W ;DO A 16-BIT SUBTRACTION (A = A - B),
SUBWF ALO ;WITH THE CARRY FLAG PROPERLY SET ON
MOVF BHI,W ;COMPLETION.
SKPC ;
INCFSZ BHI,W ;
SUBWF AHI ;
-Andy
=== Andrew Warren - RemoveMEfastfwdspamKILLspamix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html
>I understand your point, but I'm not sure that you can make such a
>blanket declaration about copying others' code.
Very useful fragments, Andy. Think I'll have to steal some of them!
I agree with you 100%. Some of the neatest things in my code were thought
up by somebody else!
Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
Hardware & Software for Industry & R/C Hobbies
"Go fast, turn right, and keep the wet side down!"
==================================================================
Andy Kunz wrote:
>
> >I understand your point, but I'm not sure that you can make such a
> >blanket declaration about copying others' code.
>
> Very useful fragments, Andy. Think I'll have to steal some of them!
>
> I agree with you 100%. Some of the neatest things in my code were thought
> up by somebody else!
Sure... But do you reach for the ol' PIC archives if you want to do
some keyboard debouncing, or if you want to drive a LCD? (How many times
have I seen *that* line?)
I concede that one can learn a lot of 'tricks' by looking at what other
folks came up with, but if you are starting out, the hard way makes you
use that grey stuff upstairs.
I may be biased because that was the way I started out, but I feel one
has to adopt an inventive way of thinking when faced with the
restrictions
(ROM, RAM and I/O) of a small micro.
--
Friendly Regards
Tjaart van der Walt STOPspamtjaartEraseMEwasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
| WASP International http://wasp.co.za |
| GSM and GPS value-added applications |
| Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8686 |
|_____________________________________________________________|
> But do you reach for the ol' PIC archives if you want to do some
> keyboard debouncing, or if you want to drive a LCD? (How many times
> have I seen *that* line?)
Yeah... My favorite posts are the ones that go something like:
"Does anyone have code to read numbers entered on a keypad,
perform floating-point calculations on them, display text on
an LCD, and drive 4 stepper motors according to what was
entered?
"I'd write it myself, but I don't want to re-invent the
wheel...
"[signed]
John Doe
Custom Industrial Controls, Inc."
> I concede that one can learn a lot of 'tricks' by looking at what
> other folks came up with, but if you are starting out, the hard way
> makes you use that grey stuff upstairs.
You're right; as I said, I can see your point. I was only saying
that those "tricks" can open the eyes of beginning programmers
(and even experienced ones like Andy Kunz) to entirely new
techniques that they might be unlikely to discover themselves.
For a COMPLETE beginner, of course, tricks like the examples I
posted won't help at all... But for a slightly more advanced
programmer, understanding them is the key to becoming a MUCH
more advanced programmer.
As you know, I do a fair amount of "pure" consulting in addition
to the contract design that occupies most of my time... Most of
that consulting is for companies with small (one- to
three-person) software-engineering departments.
You'd be amazed -- I was, initially -- at the lack of quality in
the code produced by most of these teams... I usually ask to see
examples of both their most-recently- and LEAST-recently-written
code, and there's often no real improvement between the two
examples, even in cases where the guys have been writing PIC
code for YEARS.
It's not their fault, really; it's just that they've usually been
working in isolation and just don't realize that there ARE better
ways. Also, many of the "software engineers" in the
embedded-control industry have little or no formal software
training... Lots of them are electrical engineers who just fell
into writing software out of necessity.
No matter what the reason for their poor skills, though, most of
the clients to whom I show those programming "tricks" INSTANTLY
see the light and are able to make HUGE leaps forward.
More importantly, though, the realization that "there are more
things in assembly-language software than are dreamt of in their
philosophy" seems to rekindle their interest in programming...
The same guys who were content to let their skills stagnate for
years suddenly start telephoning to tell me about the exciting
new programming techniques they've "discovered", and when I make
a followup visit six months after the initial one, I usually find
that their newest code is SIGNIFICANTLY improved over the crap
they used to write.
So, to get back to my point...
Programming languages are just like all human languages; it's
possible (and maybe even desirable) to learn the vocabulary and
grammar on your own, but in order to become FLUENT, you need to
have a strong grasp on the language's idioms, dialects, and
subtle nuances... And to accomplish that, you need to actually
interact with people who already SPEAK the language.
Just my opinion; I could be wrong.
-Andy
=== Andrew Warren - fastfwd@spam@ix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html
> For instance, how long do you suppose it would take a beginner to
> come up with the following extremely-useful code fragments without
> ever having seen them used in someone else's code?
How about this one [figure out what it does yourself :-)]
> How about this one [figure out what it does yourself :-)]
>
> movf Num1,w
> movwf Result
>
> movf Num2,w
> subwf Result,w
> btfss C
> subwf Result,f
>
> movf Num3,w
> subwf Result,w
> btfss C
> subwf Result,f
>
> Anyone know of any smaller way?
John:
Does this work?
MOVF NUM1,W
SUBWF NUM2,W
MOVF NUM1,W
SKPC
MOVF NUM2,W
MOVWF RESULT
SUBWF NUM3,W
SKPC
ADDWF RESULT
-Andy
=== Andrew Warren - fastfwdspam_OUTRemoveMEix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html
> Andy said in response to John:
> > Does this work?
> >
> > MOVF NUM1,W
> > SUBWF NUM2,W
> > MOVF NUM1,W
> ...
>
> Perhaps I just don't understand. But wouldn't the third instruction
> destroy all of the work of the first two?
Alan:
Glad you asked. Here... I'll explain.
First, though, a warning:
IF YOU WANT TO FIGURE OUT ON YOUR OWN WHAT JOHN PAYSON'S CODE
DOES, PLEASE READ NO FURTHER.
> Andy said in response to John:
> > Does this work?
> >
> > MOVF NUM1,W
> > SUBWF NUM2,W
> > MOVF NUM1,W
> ...
>
> Perhaps I just don't understand. But wouldn't the third instruction
> destroy all of the work of the first two?
Alan:
Glad you asked. Here... I'll explain.
First, though, a warning:
IF YOU WANT TO FIGURE OUT ON YOUR OWN WHAT JOHN PAYSON'S CODE
DOES, PLEASE READ NO FURTHER.
Ok... Given three values stored in registers NUM1, NUM2, and NUM3, the
routine finds the minimum value and stores it in RESULT, leaving
NUM1-3 unchanged.
Here's the commented version of my code; this should make it clear:
;NOTE: In the comments below, "min(A,B)" means "the lesser of A
; and B".
MOVF NUM1,W ;Set the Carry flag if NUM1 is less than
SUBWF NUM2,W ;NUM2.
MOVF NUM1,W ;Assume that NUM1 was less than NUM2. This
;instruction does NOT affect the Carry flag.
SKPC ;If NUM1 really was less than NUM2, skip
;ahead with W = NUM1.
MOVF NUM2,W ;Otherwise, W = NUM2.
;At this point, W contains min(NUM1,NUM2).
MOVWF RESULT ;Store it in RESULT.
;At this point, both W and RESULT contain min(NUM1,NUM2).
SUBWF NUM3,W ;Set the Carry flag if W [which contains
;min(NUM1,NUM2), remember] is less then NUM3.
;At this point, RESULT still holds min(NUM1,NUM2), but W now
;contains NUM3 - min(NUM1,NUM2).
SKPC ;If W really was less than NUM3, skip ahead.
ADDWF RESULT ;Otherwise,
;RESULT = RESULT + W
; = min(N1,N2) + W
; = min(N1,N2) + [NUM3 - min(N1,N2)]
; = NUM3.
;
;Note that I typed "min(N1,N2)" instead of
;"min(NUM1,NUM2)". Sorry... I ran out of
;space and had to do that to keep the
;formatting ;pretty.
;At this point, RESULT holds min(NUM3,min(NUM1,NUM2)), which is
;of course equivalent to min(NUM1,NUM2,NUM3).
Did that help?
-Andy
P.S. I hope this also explains why I said in an earlier message that
assembly-language programmers need to understand the basic
arithmetic axioms of association, commutation, and
distribution.
>
> Tjaart van der Walt <spamBeGonetjaartspamspamBeGonewasp.co.za> wrote:
>
> As you know, I do a fair amount of "pure" consulting in addition
> to the contract design that occupies most of my time... Most of
> that consulting is for companies with small (one- to
> three-person) software-engineering departments.
>
> You'd be amazed -- I was, initially -- at the lack of quality in
> the code produced by most of these teams... I usually ask to see
> examples of both their most-recently- and LEAST-recently-written
> code, and there's often no real improvement between the two
> examples, even in cases where the guys have been writing PIC
> code for YEARS.
>
> It's not their fault, really; it's just that they've usually been
> working in isolation and just don't realize that there ARE better
> ways. Also, many of the "software engineers" in the
> embedded-control industry have little or no formal software
> training... Lots of them are electrical engineers who just fell
> into writing software out of necessity.
>
> No matter what the reason for their poor skills, though, most of
> the clients to whom I show those programming "tricks" INSTANTLY
> see the light and are able to make HUGE leaps forward.
>
> More importantly, though, the realization that "there are more
> things in assembly-language software than are dreamt of in their
> philosophy" seems to rekindle their interest in programming...
> The same guys who were content to let their skills stagnate for
> years suddenly start telephoning to tell me about the exciting
> new programming techniques they've "discovered", and when I make
> a followup visit six months after the initial one, I usually find
> that their newest code is SIGNIFICANTLY improved over the crap
> they used to write.
Touche! I visited a major local company some time ago and discovered
that they use a compiler that I personally found *many* bugs in.
(Even more than MPLABC <G>)
>
> So, to get back to my point...
>
> Programming languages are just like all human languages; it's
> possible (and maybe even desirable) to learn the vocabulary and
> grammar on your own, but in order to become FLUENT, you need to
> have a strong grasp on the language's idioms, dialects, and
> subtle nuances... And to accomplish that, you need to actually
> interact with people who already SPEAK the language.
> Just my opinion; I could be wrong.
I agree - as long as you know the basics before you start making
speeches. Otherwise you'd be asking people for a pre-written speech
because you don't want to reinvent the wheel.... Geez, how *that* one
really grates me!
--
Friendly Regards
Tjaart van der Walt @spam@tjaartspamspam_OUTwasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
| WASP International http://wasp.co.za |
| GSM and GPS value-added applications |
| Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8686 |
|_____________________________________________________________|
> From: Andrew Warren <KILLspamfastfwdKILLspamIX.NETCOM.COM>
>
> John Payson <KILLspamPICLISTspamspamMITVMA.MIT.EDU> wrote:
>
> > How about this one [figure out what it does yourself :-)]
> >
> > movf Num1,w w = n1
> > movwf Result r = n1
> >
> > movf Num2,w w = n2
> > subwf Result,w w = n1 - n2
> > btfss C
> > subwf Result,f if (n2 > n1) r = n1 - (n1 - n2) = n2
> >
> > movf Num3,w w = n3
> > subwf Result,w r = r - n3 = max(n1,n2) - n3
> > btfss C
> > subwf Result,f if (n3 > max(n1,n2)) r = n3
> >
> > Anyone know of any smaller way?
>
> John:
>
> Does this work?
>
> MOVF NUM1,W w = n1
> SUBWF NUM2,W w = n2 - n1
>
> MOVF NUM1,W w = n1
> SKPC
> MOVF NUM2,W if (n1 > n2) w = n2
>
> MOVWF RESULT r = min(n2, n1)
>
> SUBWF NUM3,W w = n3 - min(n2, n1)
> SKPC
> ADDWF RESULT if (min(n2,n1) > n3)
r = min(n2,n1) + n3 - min(n2,n1) = n3
thus result = min(n1, n2, n3). Not exactly the same, Andy, but we
assume you meant SKPNC instead of SKPC. I know I forget this
wierd Microchip convention all the time -- I'm so used to carry
meaning the answer was negative after a subtraction.
This is reminiscent of the XOR technique of swapping 2 or more bytes.
It basically works because there are operations (op) such that given
Z = X op Y, then if you know any two of X, Y or Z, then the third
value can be reconstructed. ADD, SUB and XOR are such op's. AND
and OR, on the other hand, fundamentally destroy information.
Regards,
SJH
Canberra, Australia
PS: I missed your subsequent post with 'the answer' so forgive me
if I'm correcting an already corrected oversight.
> [and Andy Warren's ugly-yet-shorter code produces] min(n1, n2, n3).
> Not exactly the same, Andy, but we assume you meant SKPNC instead
> of SKPC.
No, I meant SKPC... I must have misread John's code; I thought
it found the minimum.
My apologies to anyone who was misled by my message; as Steve
points out, you can make my code find the maximum, or make
John's code find the minimum, by simply changing his BTFSSs to
BTFSC or my SKPCs to SKPNCs.
-Andy
=== Andrew Warren - fastfwdspamBeGoneix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html
> Want to give a few more details on the Virus you mentioned, I have
> used [the Microchip Technical Library] CDROM on my computer and
> would hate to think there is a Nasty waiting to strike.
Ben:
The 1996 Microchip Technical Library, Second Edition, contains a
Microsoft Word for Windows file ("register.doc", maybe? I forget)
that's been infected with the "Concept" virus.
This virus isn't particularly malicious; it just prevents you from
saving Word documents as ".doc" files (instead, you have to save
them as Word "template" files, by giving them the extension ".dot").
Microsoft has a set of programs and Word macros (available on their
web site) that protect against the Concept virus; if you use
Microsoft Word, you should probably download them.
Note that ONLY the "1996 Second Edition" CDROM has the virus; it
does NOT exist in the Third Edition. Even if you use the Second
Edition CDROM, you can only be affected by the virus if you open
the "register.doc" (or whatever) file in Microsoft Word.
Third Edition CDROMs are available from your Microchip rep.
-Andy
=== Andrew Warren - .....fastfwdRemoveMEKILLspamix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html
Peter (and anyone else who's thinking of doing something
similar):
Please, please, PLEASE don't attach encoded binary files (like
pictures, etc.) to messages that you send to the PICLIST.
Sending those attachments is a BAD idea for a number of reasons:
1. Many people here aren't interested in the pictures.
2. Even if they WANT to see them, a lot of folks can't
decode the attachments.
3. Anyone who receives the digest version of the list will
have a VERY difficult time with the attachments,
even if his mail reader DOES support auto-decoding
of attachments.
Instead of sending attacments to the list, either publish them on a
web page somewhere and just post the URL here, or post a brief
description of the files and offer to send them in PRIVATE e-mail to
anyone who's interested.
Thanks.
-Andy
=== Andrew Warren - fastfwdspam_OUTspamBeGoneix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html
In a message dated 97-03-28 16:00:12 EST, you write:
>Instead of sending attacments to the list, either publish them on a
>web page somewhere and just post the URL here, or post a brief
>description of the files and offer to send them in PRIVATE e-mail to
>anyone who's interested.
I agree. I personally do not open any mail with attachments unless I am VERY
interested in the topic (e.g. responses to one of my questions).
Mark A. Corio
Rochester MicroSystems, Inc.
200 Buell Road, Suite 9
Rochester, NY 14624
Tel: (716) 328-5850 --- Fax: (716) 328-1144 http://www.frontiernet.net/~rmi/
***** Designing Electronics For Research & Industry *****
I appreciate the binary attachment. I wish I had a place to post my own
URL...but I don't. And I wish I had time to respond to hundreds of
interested people.... but I don't. Therefore, in the future I will also
post a binary attachment to communicate concepts when its
appropriate...which yours was. Thank you, Peter. {Quote hidden}
>
> Sending those attachments is a BAD idea for a number of reasons:
>
> 1. Many people here aren't interested in the pictures.
> 2. Even if they WANT to see them, a lot of folks can't
> decode the attachments.
> 3. Anyone who receives the digest version of the list will
> have a VERY difficult time with the attachments,
> even if his mail reader DOES support auto-decoding
> of attachments.
>
>Instead of sending attacments to the list, either publish them on a
>web page somewhere and just post the URL here, or post a brief
>description of the files and offer to send them in PRIVATE e-mail to
>anyone who's interested.
>
>Thanks.
>
>-Andy
>
>=== Andrew Warren - fastfwd.....@spam@ix.netcom.com
>=== Fast Forward Engineering - Vista, California
>===
>=== Custodian of the PICLIST Fund -- For more info, see:
>=== http://www.geocities.com/SiliconValley/2499/fund.html
>
>
> Peter Cousens <@spam@peterspamcousens.her.forthnet.gr> wrote:
>
> > Take a look at this circuit....
>
> and attached a 56K BMP picture to his message.
>
> Peter (and anyone else who's thinking of doing something
> similar):
>
> Please, please, PLEASE don't attach encoded binary files (like
> pictures, etc.) to messages that you send to the PICLIST.
>
> Sending those attachments is a BAD idea for a number of reasons:
>
> 1. Many people here aren't interested in the pictures.
> 2. Even if they WANT to see them, a lot of folks can't
> decode the attachments.
> 3. Anyone who receives the digest version of the list will
> have a VERY difficult time with the attachments,
> even if his mail reader DOES support auto-decoding
> of attachments.
>
> Instead of sending attacments to the list, either publish them on a
> web page somewhere and just post the URL here, or post a brief
> description of the files and offer to send them in PRIVATE e-mail to
> anyone who's interested.
Andy did you look at the ( pictures )circuit ?
How about sugesting a better way to put this guy on the
right track
I posted a practical circuit that can be used to control resistive
inductive or capacitive loads, use one PIC pin, very simple to
control, the circuit requires no calibration, is easily repeatable,
is not timing sensitive and requires no syncronization
would it not be more productive to correct the less viable/
workable sugestions
As for not being able to read attachments
windows bitmap is probably the easiest for most people
As for not wanting to, well if they don't want to learn
then why are the on the list ??
part 0 305 bytes 3. Anyone who receives the digest version of the list will
have a VERY difficult time with the attachments,
even if his mail reader DOES support auto-decoding
of attachments.
There is a digest version of this list? How do I subscribe to it?
>There is a digest version of this list? How do I subscribe to it?
>
>Kieran Sullivan
>
>Attachment Converted: D:\WAN\MAIL\INCOMING\ReSendin
>
Hey Kieran can you turn off the attachments please, the body of the message is
enough...
Rgds
Mike
Some say there is no magic but, all things begin with thought then it becomes
academic, then some poor slob works out a practical way to implement all that
theory, this is called Engineering - for most people another form of magic.
Massen
newcastle.ac.uk (Simon Harrison) writes:
