>
> Hi all.
>
> I've been interested in 8051s for ages - but someone recently introduced
> me to the ridiculously cheap DIY PIC16C84 programmers, and Im now a
> total convert...
Most of us are.
>
> Some questions:
>
> The PIC mnemonics, IMHO, are terrible. Is there a 'standard' better
> mnemonic set?
Well parallax has a set of mnemonics that are 8051 based. The two problems
are that you no longer know exactly how long each instruction is and that
you need the parallax assembler.
Personally I find the PIC instruction set very clean and concise. Very good
for compiler writing. A PIC compiler of a language somewhere between C and
BASIC is one of my summer projects.
>
> Are there any example PIC sources available?
Call Microchip or a local rep and ask for the applications notes for the
PIC series. It has dozens of example programs for you to look at. And all
of them are in the original PIC instruction set so you can see how the
set operates.
> Is the serial programming algorithm of the 16C84 the same or similar to
> that of the other two recent PICs (I forget the names - the 33 IO pin
> one, and the one with internal ADC) -
There are two 40 pin chips (17C42 and 16C64). The internal ADC is a 16C71.
> Can I use a similar modified serial programmer to blow these?
The 16C84 and the 16C71 use almost the same serial algorithm.
A good idea is to get the Microchip Microcontroller data book. It has not
only the data sheets for all the parts but the programming algorithms too.
Michchip is just too cool with the way they interact with us hobby
enthusiasts!
> It is always better to get used to the manufacturer's mnemonics as any code
> examples or help you get from others is likely to be in that form. A good
> macro assembler will allow you to generalize your code to make it more
> portable.
I take your point as a general idea, but come on - ADDWF f,d where d is
*direction*!!! Whats wrong with ADD f,W / ADD W,f?
Ive programmed Z80, 6502, 8051, 77C82, ARM2, 68000 - and I have to say
that the PIC has the least user friendly mnemonics of the lot.
Still - Im sure I'll get used to them in time...
Peter
-
Peter Knight Email: spam_OUTp.j.knightTakeThisOuTuk.ac.bradford Mono: Cathedrow
_ _ _ _
Who says you can't display letters on a 7 | _| |_ |_ |_| _| _ _ _|
segment display? OK, so you can't do a W..|_ |_| |_ | | |_ |_| | |_| _|
Tom,
Thanks for the question:
> Tell me more about ASPIC ?
I will try to avoid making it sound like an ad <smile>...
ASPIC is a shareware assembler (reg = $100 CDN ($69 US)) which has been in
use since late 1991 for PIC and since 1986 for other processors (NEC
78c10, Mitsubishi MELPS 8 and 16 bit). It is **DESIGNED** for embedded
controler design, so it has som unusual features like character set
translation (eg. for LED, LCD, and On Screen Displays), bit labels,
environment labels, etc.
It is very stable (only 3 bugs reported and fixed in the last 2 years), and
it integrates well with other developement tools. A short list of features
reads something like:
- One assembler for 16c5X, 16c7X, 16c8X, 17c42
- Compatable with PICSIM (MPSIM)
- Compatable with MAKE, and with auto-error tracking editors
- Many times faster than PICALC (MPALC)
- Standard base notation (Intel & Motorola format)
- CODE and FUNCTION macros
- Auto register bank management
- Text/data translation
- Automaticly generates RETLW tables for text and data tables
- Built-in version management and assembly control functions
- user command-line switches
- many other features
(hope that didn't sound too much like an ad, but the shareware license has
an unusual clause absolving those who don't register but only use it for
non-commercial purposes)
I can't ftp from compuserve, but it is available around. Try microchips
bbs (3rdparty file area) or my BBS @(604) 597-3479.
On 18 May 1994, Peter Knight <.....P.J.KnightKILLspam@spam@bradford.ac.uk> wrote:
> I take your point as a general idea, but come on - ADDWF f,d where d is
> *direction*!!! Whats wrong with ADD f,W / ADD W,f?
I agree with your comments about Microchip's syntax being suboptimal, but
I should point out that the ",d" doesn't specify the direction, it specifies
the destination. While this may seem like a minor point, consider the
SUBWF instruction:
SUBWF FOO,W ; W := FOO - W
SUBWF FOO,F ; F := FOO - W
While discussing subtract instructions, I should point out that the SUBLW
instruction subtracts the contents of W *FROM* the literal, which is not what
people generally expect.
At first this seemed brain-damaged but then I discovered that it is useful.
If you want to take the two's complement of W, for instance, you can use
SUBLW 0 ; W := 0 - W
If you want to subtract a literal from W, you can use the ADDLW
instruction with the two's complement of the literal:
ADDLW 0feh ; W := W - 2
Some assemblers will let you write this in a natural form:
> On 18 May 1994, Peter Knight <P.J.KnightKILLspambradford.ac.uk> wrote:
> > I take your point as a general idea, but come on - ADDWF f,d where d is
> > *direction*!!! Whats wrong with ADD f,W / ADD W,f?
>
> I agree with your comments about Microchip's syntax being suboptimal, but
> I should point out that the ",d" doesn't specify the direction, it specifies
> the destination. While this may seem like a minor point, consider the
> SUBWF instruction:
OK - my mistake - I did mean destination...
Thanks for the hint on SUBLW - I missed that subtle point!
Peter
-
Peter Knight Email: .....p.j.knightKILLspam.....uk.ac.bradford Mono: Cathedrow
_ _ _ _
Who says you can't display letters on a 7 | _| |_ |_ |_| _| _ _ _|
segment display? OK, so you can't do a W..|_ |_| |_ | | |_ |_| | |_| _|
I've just started working on a project based around the 17C42. I assumed
that I'd be able to use the same development tools as I've used in the
past for 16C71 projects but I've just realised that MPSIM doesn't
support the 17C42. Is there another similar tool that I've overlooked
and if not, what is the development process for the 17C42 ?
Your help would be appreciated.
>
> I've just started working on a project based around the 17C42. I assumed
> that I'd be able to use the same development tools as I've used in the
> past for 16C71 projects but I've just realised that MPSIM doesn't
> support the 17C42. Is there another similar tool that I've overlooked
> and if not, what is the development process for the 17C42 ?
> Your help would be appreciated.
>
> Alasdair
>
The microchip tools for the 17C42 are on sics.se in /pub/mchipsoft/asm17
A special programmer will be needed if you need to program the internal
eprom, but I believe the factory default mode for the chip is "microprocessor"
so the code can go into two external eproms.
Hope this helps
=%-)
Ian
p.s. if you need a copy I could e-mail it to you (if your mailer supports "big" messages)
>
> >
> > I've just started working on a project based around the 17C42. I assumed
> > that I'd be able to use the same development tools as I've used in the
> > past for 16C71 projects but I've just realised that MPSIM doesn't
> > support the 17C42. Is there another similar tool that I've overlooked
> > and if not, what is the development process for the 17C42 ?
> > Your help would be appreciated.
> >
> > Alasdair
> >
>
> The microchip tools for the 17C42 are on sics.se in /pub/mchipsoft/asm17
> A special programmer will be needed if you need to program the internal
> eprom, but I believe the factory default mode for the chip is "microprocessor"
> so the code can go into two external eproms.
Just one caveat for you folks working with the 17C42 in microprocessor mode.
I haven't done it yet (but planning to) but from what I was reading of the
data sheet, in an erased state the watchdog timer is enabled with no
prescaler on the 17C42. That means that in 18ms or so that the chip will reset
if you do not execute CLRWDT command.
I have to admit that I am getting very curious about the PIC series of
chips. I am becoming increasingly frustrated by the availability problems
that daunt Motorola products. The idea of being able to order chips from
Digi-Key really sounds nice....
Sorry if this is an FAQ, but what's available to support us Mac users
who want to use the PIC? What else do I need to get started?
Mike Harpe
University of Louisville
--
Michael Harpe, Communications Analyst III Information Technology
Internet: EraseMEmikespam_OUTTakeThisOuThermes.louisville.edu University of Louisville
(502) 852-5542 (Voice) (502) 852-1400 (FAX) Louisville, Ky. 40292
"He's not a man, he's a remorseless eating machine!" - The Simpsons
Here are a couple of MPALC macros I found useful for storage
allocation on PICs. They're for when you wat a register allocated
but don't care which; you can choose whether to allocate from the
top or bottom end of the register set. The parameters given here
do for 16C71 and 16C84 PICs, for others change RAM_Start and MAX_RAM.
If you like these, I also have some code for implementing timed finite
state machine dispatch (a machine is a set of states; the current state
is executed after a delay specified as a number of calls of the dispatcher;
states can set the next state and next delay to dispatch to; for N instances
of machines, it uses 2N+2 registers, 2N of them permanently and 2 as temps
for dispatch). I also have a master transmitter and slave receiver I^2 C
implementation for PICs (16C84 or 16C71) running at > 6MHz that supports
multimaster operation (in theory). If you are interested, say so, and I'll
post the code.
John Hallam, AI Dept., Edinburgh University.
-------------------cut here for MPALC code---------------------------
;******************************** Register File Store Allocation
;
; These macros allocate store from the register file. If there is
; enough store they succeed, defining the specified label. If not,
; they fail, leaving the label undefined and so inducing errors.
RAM_Start equ 0Ch ; First GP Register
MAX_RAM equ 30h ; Last GP Register + 1
RAM_Lo set RAM_Start ; Current low water mark
RAM_Hi set MAX_RAM ; Current high water mark
AllocHi macro label,amount ; Allocate store called <label>
if RAM_Lo+amount > RAM_Hi ; Not enough registers
exitm ; ERROR EXIT
else
RAM_Hi set RAM_Hi-amount ; Adjust mark
label equ RAM_Hi ; Allocate at high end
endif
endm
AllocLo macro label,amount ; Allocate store called <label>
if RAM_Lo+amount > RAM_Hi ; Not enough registers
exitm ; ERROR EXIT
else
label equ RAM_Lo ; Allocate at low end
RAM_Lo set RAM_Lo+amount ; Adjust mark
endif
endm
Is there an easy way to connect a PIC to a 68000? Preferably memory mapped.
The only way I can think of is putting a PIA like a 6820/68230 or a UART
like 6850/68901 in between. The serial solution is probably too slow, as I
need at least 20 KB/s data transfer.
Easy. Even without having to use PIA or UART. Use the asynchronous bus feature of 68k.
Have 2 PIC pins configured to sample the state of /CS (from decoder) and R/W (from 68k)
Have 1 PIC pin to drive the /DTACK (with OC driver). And have the PIC to place/read the data on
the bus at appropriate times. Note that your 68k will wait until it detects /DTACK asserted. The
danger is of course that if the PIC is not programmed properly in its response to 68k requests, so
that /DTACK never gets asserted in this bus cycle, then the system dies.
On Wed, 13 Jul 1994, Ben Stuyts wrote:
> Is there an easy way to connect a PIC to a 68000? Preferably memory mapped.
> The only way I can think of is putting a PIA like a 6820/68230 or a UART
> like 6850/68901 in between. The serial solution is probably too slow, as I
> need at least 20 KB/s data transfer.
>
What about a simple 2 line modified serial interface. Use one line to clock
data and one line for the data bit. I use that to commuicate on all of
my PICs. In short it hauls ass. but I have never had an application
where i had to get 20KB/s of data and send it. If any place thats where
you will loose your performace.
later
John
_____________________________________________________________________________
John Johnson |If it's not OS/2.|johnsonjspam_OUTccwf.cc.utexas.edu
|It's crap! |@spam@johnsonjKILLspamghostwheel.bga.com
OOOO SSSS /2222 2222 11 | |
O O S / 2 2 1 |"We need breath- |"Bite me." Tom Servo
O O SSSS / 2222 2222 1 |-ing room!" |
O O S / 2 2 .. 1 | Bill Gates |"I want to decide who lives
OOOO SSSS/ 2222 2222 .. 111| |and who dies" Crow T. Robot
-----------------------------------------------------------------------------
I'm a rookie at this microcontroller programming stuff, but I am very interested
in finding the answers to your questions. Since, I have to write the same
routines for the pic16c64.
I wonder what clock speed you are using for the chip. This may have
an effect on the number of program steps that the chip must wait for the
next bit. You could calculate this value and set a loop parameter, so
you could generalize the code for any speed.
Also if the chip is wasting time waiting to send the next bit, you could use
that time to check for an xon (h'11') or xoff (h'13') byte to see if you should
stop sending bits.
You probably already thought of this, and remember I'm a rookie.
Anybody here got one of these? Have you used other ICEs that compete
with it? It seems like a pretty good price ($699) if it works as
advertised, and I've used the front end software when it was just
a simulator. At least, it *looks* the same.....
Has anyone got some code or ideas on how to sense the baud rate
of an Asynchronous Serial I/O automatically. Ideally this should be
done continuously allowing a RC clocked PIC to adjust calibration
as its operating freq changes.
I have considered using the start bit to give the timing of the link
(baud rate) which as you say will only work for 50% of characters.
I was also thinking in terms of timing edge transitions and dividing
this time by the bit time to give number of bits at same level (mark or
space). Has anyone else considered this rather than the more conventional
measure the link at bit rate aftre delay of bit rate/2 from start ??
I have seen several systems where it was required to press
the space bar as the first character. In serial communications,
the least significant bit is transmitted first. For a space, the
bit pattern would look like the following:
This conforms to 1 start bit, 8 data bits, no parity and two stop bits.
The processor then has six bits that are low in which to increment a
counter and calculate the serial data rate relative to it's own clock
frequency. The longer time for measurement makes for a more accurate
determination of the serial data rate.
Another example would be to use a ( , 8 , H , X , h or an x. These
characters will allow a measurement for four bits long. Althogh a
little less accurate, you only need to right shift your counter
twice ( divide by four ) in order to calculate your reload data
for your bit counter.
The BASIC interpreter in the 8051AH-BASIC chips requires you to press
the space bar to log on, and then for the real time clock to work,
you give the command xtal = xx.xxxxxx to match the crystal connected
to the micrcontroller.
You can get topic-0.1.zip from ftp.funet.fi in the directory
/pub/microprocs/pic/topic. (If your filing system doesn't support
multiple dots in the filename, enter a command like "get topic-0.1.zip
topic01.zip" to store it with a different local filename).
Below I've included the short README file.
Enjoy!
-- vinsci
README:
This README file describes Topic release 0.1, an assembler for the PIC
microcontroller series. The PIC is manufactured by Microchip Technlogy
Inc.
This assembler is published under the GNU General Public License in
the hope that others will use and benefit from this program as well as
contribute their own improvements and extensions for all of us to
share.
What it doesn't do (yet):
While I believe Topic does things the right way, it currently lacks
features that will hopefully be available in later versions. Such as
pseudo instructions (easily added), macros (the code to insert macros
already exist and works), optional ",0" or ",1" as a second argument
(easiliy added), real expressions and operators (this is the biggest
drawback in this first release), conditional assembly (we need to see
if GASP, the Gnu ASsembler Preprocessor, suits our needs) etc.
What it does:
It does support symbols (any length symbol name), file inclusion, good
warning and error message capability (some of the messages in this
release are on the lighter side -- see the source in case you don't
understand a message). It also supports a variety of ways to write
constants. It writes a simple symbol table, reporting which symbols
were really used and which were not. It writes an object file in the
same format as Microchip's MPALC assembler if the assembly was
successful, or none if not. Topic doesn't crash your machine when it
doesn't see what it expected (unlike MPALC).
This software is pretty much experimental so far (it's less than a
week old, what do you expect?), but it is cleanly written. There are
even a few comments.
Currently, it only supports the 12 bit variants of the PIC, but I've
designed the assembler so that it is very easy to extend it to the 14
bit core as well and make the choice while the assembler is running
(ie. using an assembler directive). Some constants in the source now
make the assembler believe the memory size is 2048 instruction words
as for the PIC 16C57, which I work with, hmmm ;-), but all this is
very easily changed.
OK, how do I improve it and recompile it?
First get a standard C compiler. I used the GNU C compiler GCC which
is available for free on the net and is a very good compiler and has
everything you need.
For MSDOS systems, get the variant of GCC called DJGPP:
If you have a make utility, just CD into the Topic subdirectory and
type MAKE. To compile by hand, give the command "gcc -o topic
topic.c". Easy! (If you're using DJGPP, you can now run the file
topic, which is still in unix format, with the command "go32 topic
source.asm" to assemble source.asm and produce source.obj. You can
also create a normal executable with DJGPP, after that the command
would be "topic source.asm", as on a unix system.)
Spots that could use some improvement are marked by the word fixme.
Are you improving the assembler?
Any improvements and/or bug fixes that are clean and well thought out
are welcome by e-mail at the address below. Please use the DIFF
command "diff -c2 topic.c newtopic.c >diffs" to produce the diffs
file, and e-mail me that along with a description of the diff in
question. Make separate diffs for changes/improvements that aren't
related and send them in separate e-mails. All changes should follow
the GNU coding standards to reasonable extent to maintain readability.
>
> You can get topic-0.1.zip from ftp.funet.fi in the directory
> /pub/microprocs/pic/topic. (If your filing system doesn't support
> multiple dots in the filename, enter a command like "get topic-0.1.zip
> topic01.zip" to store it with a different local filename).
>
> Below I've included the short README file.
>
> Enjoy!
>
> -- vinsci
>
Good! I'm glad to see someone starting this! I'm presently using the gnu
c compiler, and I'm pleased to see some software development for the pic's
following the same route.
What about a simulator? It sure would be nice to have some control over
what a simulator can do.
I have also just finished an assembler for pics, just the
documentation and a bit more testing left to do before its released.
Compared to topic is has:
pros: macros, real expressions, conditional assembly, local variables
and labels, 12 and 14bit pics, a simple disassembler.
cons: own object file format (with conversion tools to and from
intel hex.) C format numbers (i.e. 0xff etc), and error handling
is "simplistic" and finally no clever name (topic, aspic) thought
up yet ;-)
I will try to get the docs done this weekend and put it up for ftp
next week. It has been built under linux and gcc, but should work under
any unix or even dos (using djgpp).
=%-)
Ian
p.s. votes for next tool being taken, simulator or picstart code downloader.
p.p.s. does anyone know the format of the picstart download protocol or
e-mail address for someone at microchip who might know.
Concerning Autobaud, I started down the path of using RC PIC's for low cost. Cr
ystals
and ceramic resonators were over $1.00 where RC circuits were $.10-.15. Then I
found
ceramic resonators from FAI at $.26 each. Its hard not to take the .3% frequen
cy
stability over an RC for $.15. Also very good prices on PIC's. Call Chris or N
ancy at
1-800-303-5701 or 303-237-1400. This is not a recommendation for FAI, just a co
st
effective place to buy some items.
PS Anyone had experiance with PIC running stright off 115VAC power, no xformer?
> Damn, beaten by a couple of days... ;-)
> I have also just finished an assembler for pics, just the
> documentation and a bit more testing left to do before its released.
Heh ;-) I skipped the docs part altogether, which probably saved a
couple of days...
> Compared to topic is has:
>
> pros: macros, real expressions, conditional assembly, local variables
> and labels, 12 and 14bit pics, a simple disassembler.
Sounds great!
> cons: own object file format (with conversion tools to and from
> intel hex.)
This is not necessarily a con; running those conversion tools
is anyway easiliy automated as needed.
> C format numbers (i.e. 0xff etc), and error handling
> is "simplistic" and finally no clever name (topic, aspic) thought
> up yet ;-)
Well, it seems a bit hotter than Topic, so maybe Tropic would be nice? ;-)
> Ian
>
> p.s. votes for next tool being taken, simulator or picstart code downloader.
> p.p.s. does anyone know the format of the picstart download protocol or
> e-mail address for someone at microchip who might know.
A picstart code downloader should be pretty easy and very desirable to
get out of the MSDOG/Windows dependance (I just hate to have to boot
my PC ten times a day whenever the system crashes; not that booting
takes such a long time but it interrupts my flow of thoughts).
For the simulator which I'm sure we'll build sooner or later, I've
been thinking of using the combination of C and Tcl/Tk (see
comp.lang.tcl). Tcl is a rather nice library that would give the
simulator great scripting capabilities, while Tk is a GUI toolkit for
Tcl with the look and feel of Motif. Tcl/Tk interfaces very well with
C allowing the simulator to be written partly in Tcl (faster to
edit/test/fix) and partly in C (faster final code); thus one can start
most of it off in Tcl and then code the timecritical parts in C
routines as needed. Tk provides some nice features that are ideal for
a CPU simulator, or any program that needs to update screen data as
variables change.
Tcl/Tk come with an X11 or BSD type public license and are available
under both Unix/X11 (Linux, for example) and MSDOS/Windows (for those
unfortunate of you ;-), so the simulator could be used by a large
number of people.
>
> I am building a prototyping board for the 16C84 . What is the recomented
> resistor value for a crystal at 10MHz ?. I am talking for the resistor
> connected at the OSC2 pin.
>
The Rs value is dependent on your X-tal; you'll need it only if yor
X-tal gets overdriven. Look at the signal with an oscilloscope and if
it's distorted try 100R (or higher) until you get an nice sinewave.
Then decrease the resistor value until you get back the distortion.
The correct Rs value should be somewhere in the middle.
>
> Derrick (et al),
>
> Do they have a 20MHz 16c84? I thought the c84 was limited to 10MHz
> (presumably due to EEPROM write limitations).
>
> I am a little behind on uChip produt announcements ;) Anyone know of any
> plans for any other EEPROM parts? Maybe with more I/O pins and/or A/D/A?
>
> -jory bell
> IBM Almaden Research Center
>
Oops, I meant to say that I was looking for the resistor value for a 20MHz
crystal for my 16c64.
Nope, I haven't heard of any other EEPROM products, but it sure would be nice
if they produced one with more memory.
In article: <RemoveME9409270615.aa27079TakeThisOuTpost.demon.co.uk> joryEraseME.....figment.mit.edu writes:
>
> Derrick (et al),
>
> Do they have a 20MHz 16c84? I thought the c84 was limited to 10MHz
> (presumably due to EEPROM write limitations).
>
> I am a little behind on uChip produt announcements ;) Anyone know of any
> plans for any other EEPROM parts? Maybe with more I/O pins and/or A/D/A?
>
Such things are being discussed, but nothing's out yet (any or all of
the options above) - what do you want (and how many?)?
Best regards
Alex R. Baker - Field Apps Engineer Ph: +44 628 851077 Car: +44 831 494921
Arizona Microchip Technology Fx: +44 628 850259 Email: EraseMEalexmicrochp.dem
on.co.uk
ANY VIEWS EXPRESSED HERE ARE MINE AND DO NOT NECESSARILY REPRESENT THOSE OF MY E
MPLOYER
> Do they have a 20MHz 16c84? I thought the c84 was limited to 10MHz
> (presumably due to EEPROM write limitations).
1) No, or at least not yet. Eventual progression of the 16C84 to
0.9u/6" wafer process will allow this, but not before mid 1995.
2) It is
Rgds
Alex R. Baker - Field Apps Engineer Ph: +44 628 851077 Car: +44 831 494921
Arizona Microchip Technology Fx: +44 628 850259 Email: RemoveMEalexTakeThisOuTspammicrochp.dem
on.co.uk
ANY VIEWS EXPRESSED HERE ARE MINE AND DO NOT NECESSARILY REPRESENT THOSE OF MY E
MPLOYER
> Never tried it myself, but the 16C74(?) has an A-D built in, which will
> solve the problem on a single 24(?) pin chip!
>
> Maybe someone else who knows more than me can continue this point....
>
> Bryan
>
> --
> ---------------------------------
> BRYAN CROTAZ - RemoveMEb.crotazKILLspamic.ac.uk
> ---------------------------------
There is also the PIC 16C71. It has an ADC and has something like 14 or
16 pins. Very nice and small. It comes in the PICSTART as well.
I have a question about assemblers and simulators. I had heard many
positive things about the Macro+ assembler (ASPIC) and have been trying
to learn how to use it. I have written a few simple programs for the '84
and run them OK on the chip. Now as I begin to write more complex
programs, I would like to incorporate a simulator into the development
cycle. So I have downloaded MPSIM (v4.2 -- whatever the latest is) and
gone through the tutorial. It seems pretty useful.
Here's my question: When I tried to single step through a simple program
written in ASPIC, I would lose all symbols, and single step through
"source code" generated by the disassembler I think. When I did a "LO
test" MPSIM complained about not finding a .COD file. The sample.COD
file that came with MPSIM looked like it was not ASCII. I could not find
any info in the ASPIC manual about generating this file, so I am at a
loss. Should I abandod ASPIC and use MPASM? Am I using the wrong
simulator?
>Jory,
>
>May I suggest that somebody (you?? or some automated mechanism) post a
>how-to-post type article.
>
>While I read what flies past, I never seem to be able to find the how-to-post
>info when I need it.
in case this detail is keeping people from jumping into the fray:
there are basically two ways to post to the pic list:
2. you can "reply" with your mailer software to a message which was sent to
thepic list.
note that if you simply reply to a message someone sent to the pic list,
your response will go to the list, and not to the individual who sent the
message.
in order to send to the original poster, you must manually supply their
email address (which is notes in their original mail to the list).
also note that adding or deliting yourself from the list is done by sending
email to EraseMElistservEraseMEmitvma.mit.edu, not to the list address itself.
MPSIM works fine with MPSIM, but the latest version needs a command line
switch to tell it you are using MPALC, as they have changed the defaults.
Since MPSIM expects all of your program to be in a single file, compile
your program with the command line switch -L,T (for terse output) into a
file *.LST, where * MUST be the same as the name of your .obj file.
The file DEMO.ZIP contains an example makefile to run MPSIM (you will need
to add the -C option for the new version of MPSIM). Registered users of
ASPIC get SIMVIEW, a parser that turns the output of mpsim into a parsable
data file indicating the register values at all times, so that the
waveforms can be plotted, or the output may be parsed into an STI file for
multi-PIC simulations.
I suggest that you compile your program twice, once with listing off, to
trap errors so your editor can goto the error lines for you. The second
time will compile with listing on, so the simulator will have a listing
file to work from (only if you will be simulating). This may seem like it
will be slow, but ASPIC compiles my typical full 16c84 design (about 12000
lines) in about 4 seconds on a relatively slow DX2-66 running under
Windows, so you're only talking about a 4 or 5 second delay.
I am working on a new extension to the .OBJFIL directive... .OBJFIL FISH,
to output .COD files. The problem is that the .COD file format stinks <g>.
With it, you cannot have data randomly distributed throughout the memory
space, and it still needs more work to make it reliable. It also imposes
label and code structure restrictions that I am having trouble reconciling
with the power and flexibility of ASPIC.
I've written a PIC16C84 simulator that runs under X Windows. It's in
C++ and has been compiled & run with gcc-2.5.8 on Linux and
SunOS4.1.3. It accepts output from Ian King's PicTools assembler. It
still needs a lot of work (e.g. it's hard-coded to read the program
from "test.pt") but I thought I'd tell you all about it in case
somebody wants to play with it / help develop it. I've kept the other
PIC processors in mind while writing it, and I think it will be easy
to add support for the other chips.
If you want a copy, let me know (*DON'T* send the request to the PIC
list!). I'll be away on business for the next two weeks, but I'll be
checking my email and will be able to respond to requests. (I just
may not be able to fix bugs until I get back.) If I get deluged with
requests, I'll try to find an FTP site somewhere to post it.
(Suggestions for such a site are welcome.)
>PSIM has lots of trouble under os/2. It almost always crashes for some
>reason. Is this only me? Hope it is.
I dunno: I haven't gotten far enough to crash yet ;-)
I'm really surprised to see this kind of flakiness, though: it's clear that
there's a lot of thought and talent behind the Parallax designs, and they put a
lot of work into things like documentation and the "app notes" that most of
their competition does poorly, if at all. You just don't expect to see a produ
ct
with that kind of support have diagnostics that simply say "ERROR", beep,
and give up.
I went through the Parallax BBS last night, and found little help or
encouragement. I found someone who'd had problems with another product
(the Stamp downloader) who'd solved them by enabling access to the hardware
timer, but that didn't help.
Worse, I downloaded a "diagnostic" routine for the ClearView that says it
failed verifying that memory had been cleared. No indication of where, alas:
it just said "ERROR" instead of "OK". It runs the tiny sample programs I've
tried okay, but I'm worried that there's a bad RAM chip or something that'll
screw up a schedule that's already impossibly tight.
Interestingly, I put my serial line monitor on the CV to see if I could spot th
e
problem, and it complained incessantly about framing errors at every baud
rate I tried. I wonder if they're running a non-standard rate...
>>
>> Please remove my name from the mailing list.
>> spamBeGonejim.knoxKILLspamum.cc.umich.edu Thanks.
>Me too. This list is far to productive. What about a news conference..?
>
>
>--
>Roger (Sysop RaumaMBBS #1 +47 712 54774 (300-21600+HST))
> ( #2 +47 712 56759 (300-9600 +HST))
>PolarNet: Roger Storvik@RBS --- Internet Email: .....Roger.Storvikspam_OUThiMolde.no
While I generally ignore administrative matters sent directly to the list
(negative reinforcement) I'd like to make a little clarification.
You must send the email from the account from which you originally subscribed.
Please note that it is considered rude to post unsubscribe requests
directly to the list (this holds true for most mailing lists!). In addition
to being rude, it does not tend to get you unsubscribed from the list.
In the *unusual* circumstance that you genuinely need assistance getting
off the list (not just because you don't feel like dealing with a listserv)
you can send me email directly (TakeThisOuTjoryKILLspamspammit.edu), and we can discuss your
problems. I try to deal with real issues in a helpful manner.
In terms of going over to usenet (the contentful part of the quoted
post)... I am alway open to new ideas. Are people desirous of such a move?
Another possible solution I could see would be to split the group between
hardware and software (or some such thing).
To put things in perspective (mine that is):
I filter all the PIC list mail with Eudora into appropriate mailboxes... so
I don't yet have a problem with the volume (even my net access is
presently: TCP/IP via SLIP via TIA via Telnet via Dialup ;)
I like the PIC list BECAUSE it is a mailing list. Newsgroups tend to get too
cluttered with off-topic discussion.
* Douglas Martin * Design Engr/Elec. Technician * RemoveMEdmartinspamBeGonebgsuvax.bgsu.edu *
* BGSU Department of Chemistry - Bowling Green, Ohio - USA *
* 'Ticking away the moments that make up a dull day . . .' - Pink Floyd *
***** *****
> > Jory asked:
> >
> > >In terms of going over to usenet (the contentful part of the quoted
> > >post)... I am alway open to new ideas. Are people desirous of such a move?
>
Allow me to introduce myself. I am Russ Casey.
(who)? A student of the Dept. Of Computing, Imperial College, London.
(why)? I will be writing a PIC emulator/assembler in Visual Basic as
a final year project. I think you ought to know, I don't actually know
very much about PICs, but I know Bryan Crotaz, who does, and I need
your help. I want to know about any special features you would like
it to do.
So far, I have this in mind:
The emulator will run under windows, and be very nice and usery.
It will support all current microchip PICs, and hopefully it will
be simple to upgrade as new PICs come onto the market.
The I/O pins will have : LED and Waveform Monitors.
Inputs can be defined as logic functions of outputs and input stimuli.
Once a single-chip emulator is working, the system will be expanded to
support multiple interacting PICs, including line delays for simulating
networks.
My strategy is to simulate the operation of a PIC at it's lowest level
(Bryan tells me each PIC assembler instruction is split into four
primitives. The data sheet only shows some of these reductions, but I
believe I will need the full set (Does anyone have this?). I understand
there is a great variety of project work being done by readers of this list,
and I would value any ideas (I need to have a spec ready for this Wednesday!)
Thanks In Advance,
Russ.
--
----------------------------------------------------------------------------
Network Controller Now is the time...
STOIC,
The Student Television Of Imperial College, ...to procrastinate
Imperial College Union,
London,
SW7 2BB. spamBeGonerdc@spam@spam_OUTdoc.ic.ac.ukTakeThisOuTstoicspamic.ac.uk
----------------------------------------------------------------------------
Well I have finally uploaded the latest version of
pictools onto ftp.funet.fi. It is currently in
/pub/microprocs/incoming, but will (hopefully) soon
be moved into /pub/microprocs/pic/pictools
In case you don't know it is a macro assembler and disassembler
for unix (or any system that can run gcc, bison and flex) All
source code is supplied.
The file is: pictools08.tar.gz (29180 bytes long)
If anyone needs a copy urgently I will mail them with it. If there
is a flood of interest I could post it to the whole list but I would
rather not bung up everyones in-tray ;-)
0.5 to 0.8 are complete re-writes of the original code and this is the
first public release of this new code.
The readme.1st follows.
pictools0.8
-----------
*Important* these pictools are released under the GNU licence (included in
COPYING)
Please read this carefully if you want to do anything but use these tools.
These programs are designed to allow a unix like system (linux in my
case) act as a development system for the Microchip PIC range of processors
They port to any system that is capable of running GNU gcc.
The assembler picasm is able to compile code for 12, 14 and 16 bit pics.
The disassembler picdis is able to disassemble code from 12 and 14 bit pics.
If anyone needs a 16bit disassembler they had better ask really nicely, or wait
until I need to use one ;-)
See the test and example directorys for example code showing the syntax of the
source assembler code. In the include directory are the instruction sets for the
three architectures of PIC, giving an idea of how macros are defined. This
directory
needs to be pointed at by the picasm script, so edit picasm appropriatly.
Code is output in intel hex 16 format, together with a config file which
may detail the fuse, id and oscillator options a pic may use.
A program to decode the .cfg file is also be provided and may be used to produce
loaders
for downloading software. The format of the config file is close to the
previous PT
format used by this assembler.
Some code for reading intel hex 16 (for downloader code writers) is provided
in the disassembler directory src/disasm/intel16.c
A "concise" manual is provided, as well as an "real" piece of example code.
Next project is a high(er) level language based on either C, BASIC or FORTH
(haven't decided which yet!) aimed at PICs and other low resource
microcontrollers
(IBP's) all/any suggestions welcome..... Currently a tiny FORTH environment is
looking good to me (STOP PRESS - this has now been started provisionally called
third ;-)
Acknowledgements.
-----------------
Thanks to
vinsci <RemoveMEvinsciEraseMEspam_OUTfi.funet.nic> For many suggestions on how to make the thing
better
and for actually using the assembler while it wa
s barely
operating.
Jory Bell <EraseMEjory@spam@EDU.MIT> For setting up and running the Pic mailing list.
and
Linus Torvalds <> For creating Linux, by far the best OS on a PC (
IMHO!!)
Yesterday, I tried to connect my pc to the ssp port of the 16c64 that I have on
the bench. The code running on the chip writes a value to the sspbuf with the
ssp in slave mode. I was hoping to read this value using a C program that
accesses the parallel port, but nothing appeared to be sent over the data out
pin. Since I have a 33MHz machine, I think that I may be reading the data
faster than the ssp port can send.
Has any one else written this before? Am I reinventing the wheel?
Have you verified your serial code on the PC is working properly? I
once fought a comm problem for several hours before I realized that
the bioscomm routines _had_ to have the hardware handshaking lines
on the serial port properly tied before the bios routines would
pass data using only TX, RX, and GND. When connected to a modem that
supplied the handshaking everything worked great. When I connected it
to the device I was building... nothing!
Thank you for the reply Tim. I'm sort of cheating. I'm using the
parallel port for the communications. As a result, I can control
each of the pins directly. I borrowed this idea from the pic serial
programmer code that David Taite wrote.
I think that my problem is that I'm clocking too fast, but I haven't
verified that this is true. My pc runs at 33MHz, and the pic is running
at 20MHz. In the past, I did some timing runs on the parallel port, and
I think that I could only sample in the 100 kHz range. So, I still
may have some other problem.
Would it be possible for me to get the pic serial programmer code David
Taite wrote? I have a parallax programmer and am interested in building
a new one, to program all the microchip series.
Thanks,
Scott Stephens
>Thank you for the reply Tim. I'm sort of cheating. I'm using the
>parallel port for the communications. As a result, I can control
>each of the pins directly. I borrowed this idea from the pic serial
>programmer code that David Taite wrote.
>
>I think that my problem is that I'm clocking too fast, but I haven't
>verified that this is true. My pc runs at 33MHz, and the pic is running
>at 20MHz. In the past, I did some timing runs on the parallel port, and
>I think that I could only sample in the 100 kHz range. So, I still
>may have some other problem.
>
>Cheers,
>
>Derrick Early
I finally got the SPI port to work in the master mode on my 16c64; however,
it looks like the slave mode doesn't work.
I've been trying to capture the data using the parallel port, but I'm
having trouble synchronizing the reception of the signal.
Would I be better off trying to read the SPI port with my com: port on
my pc? Has anyone tried this? Do you have any source code that I could
start with? Does a SPI to RS232 chip exist?
I finally got the SPI port to work in the master mode on my 16c64; however,
it looks like the slave mode doesn't work.
I've been trying to capture the data using the parallel port, but I'm
having trouble synchronizing the reception of the signal.
Would I be better off trying to read the SPI port with my com: port on
my pc? Has anyone tried this? Do you have any source code that I could
start with? Does a SPI to RS232 chip exist?
RS232 is a connector and voltage level spec for
serial comm. Async in ASCII using RS232C is the
standard serial comm method for PC's etc. (Binary
for non text data). Do you want do go from SPI
to RS232 levels or, as I would guess, go from
SPI (Sync) to Async & RS232, to talk to a PC.
I am not aware of a Sync to Async conversion
chip (doesn't mean there ain't one out there.)
Black Box et al. sell boxes that do it, $$$$$
RS232 is a connector and voltage level spec for
serial comm. Async in ASCII using RS232C is the
standard serial comm method for PC's etc. (Binary
for non text data). Do you want do go from SPI
to RS232 levels or, as I would guess, go from
SPI (Sync) to Async & RS232, to talk to a PC.
I am not aware of a Sync to Async conversion
chip (doesn't mean there ain't one out there.)
Black Box et al. sell boxes that do it, $$$$$
>Subject: PIC switching A/C
>
>Fellow PIC users,
>
> I am using a 16C57 in a project driving nitinol "muscle wires"
>which contract when heated. I believe that I will use alternating
>current to heat the wires so that I don't have to regulate the all that
>power just for heating wires.
>
> 1) Would someone suggest an efficient way to switch A/C power using
>PIC outputs.
>
> 2) I have been looking into using a triac but I have little
>experience with them and I am not sure just how they work. Does a triac
>switch on and off with it's control or does it stay triggered as long as
>the A/C power is applied?
>
>Thanks all,
>
>Martin Kirk
>Arizona State University
>spamBeGonemlkEraseMEasu.edu
>(602) 263-9270
>
>------------------------------
Martin,
if you're not familiar with TRIACs, SCRs and AC-phase control circuits,
I guess you'd be better off with a so called Solid State Relay (already
mentioned here before). But be aware that it can only switch on and off at
the zero crossings of the AC. And like all SCRs and derivatives it is a lossy
device as it has a voltage loss of about 1.5 volts. I still don't know about
your power requirements but for high currents this can be point of
consideration. A Power MOSFET, will perform much better and it can switch on
and off any time which predestines it for pulse width control applications.
For AC control you can simply insert it into a bridge of Schottky diodes
but it can even handle AC itself since the MOSFET is a nothing but a voltage
controlled resistor.
hpe dz hlpz
Kind regards, Volkmar
Volkmar Gross, Softwork Telematica, Bremen, Germany (Fone&Phax: +49 421 74434)
>>>-----------------------------------------------------------------------------
>
Planck's quantum is the calorimetric equivalent of a Baud (Max Demon)
>>>-----------------------------------------------------------------------------
>
=*= Error: Keyboard not connected - Press F1 to continue =*=
I'm trying to get SPI output into my PC, and I'd like
to do it with the least effort. So, I'm open to
suggestions. Right now, I'm reading the SPI output
through the parallel port on the pc, but I'm having
trouble synchronizing with the synchronized signal.
If I slow the SPI port down enough, I should be able
to solve capturing each bit, but I haven't figured
out a clever way to detect the beginning of the byte.
>I finally got the SPI port to work in the master mode on my 16c64; however,
>it looks like the slave mode doesn't work.
Have you verified that you have both in the same mode, same clock polarity, et
c.?
If you're doing multi-byte transfers, are you giving the slave enough time to
hadle the interrupt before starting a new byte?
>Would I be better off trying to read the SPI port with my com: port on
>my pc?
Nope: the PC wants to see async data.
>Does a SPI to RS232 chip exist?
Maybe: depending on how you're using the SPI, it could be possible to do
SPI-to-async with a 68HC11.
> 1) Does anyone know of a good single chip solution to convert PIC
>outputs to RS232? I am using a PIC for the diagnostics in my "Muscle
>Wire" design and I will send diagnostics data to my PC serial port.
>
> 2) I notice that Parallax calls for a MAX232 chip in their app notes
>but they don't say who makes it. Does anyone know who makes the MAX232?
Martin, the MAX232 requires 4 caps, someone said the MAX231 requires 2 caps,
but you should really check out the MAX233. It requires _no_ capacitors and
generates the voltages internally.
Just checked my Digi-Key catalog [(800) DIGI-KEY]:
Then there are others that are just xmitters, etc. So, with the 231 it
looks like you have to supply the +12v (but no -12...), with the 232 you
just supply the +5 and more caps, and with the 233 (at a price) just the +5
and no external components.
I'm a total novice when it comes to analog circuitry, so this probably isn't
the most elegant of solutions.
I needed a simple, robust, low-power RS232 connection for my data logger. I
minimised the components on the logger by using an "active" plug. It works
like this:
The logger itself has only two connections: GROUND and DATA. DATA goes
straight to a PORT-B pin on the PIC through a resistor.
The plug contains an op-amp (eg 741) powered from the DTR and RTS pins via
diodes (for protection). One input of the 741 sees a voltage of around 0.6
volts (actually, one diode-drop above ground). The other input is connected
to DATA. Receive (from the host) is connected to DATA via a resistor. Transmit
(to the host) is connected to the ouput of the OP-AMP. You can fit the whole
arrangement (OP-AMP + a few diodes) in a 9-pin backshell.
Advantages are:
(1) No active components on the PIC board. All power is drawn from the host.
(2) The output of the OP-AMP swings to the supply voltages, so you get whatever
output voltage range the host uses (+-5v, +-12v, etc.) minus about 0.6v.
(3) Only 2 wires connect to the PIC. For a logger like mine this is a definite
plus. You can put the PIC inside a canister and communicate through the casing
(arranged like a lithium cell) - no sockets required.
Disadvantages are:
(1) The link is half-duplex. Every character sent by the host is echoed by
the interface.
(2) You need to be able to control the handshaking lines to some extent. On a
PC this is no problem.
(3) Its a little wierd, but sometimes wierd is the only way to go.
I no longer seem to be receiving the PIC mail. The automatic response
from the listserver tells me that I am still registered on the PIC list.
Can anyone tell me how to go about getting the flow of mail turned on
again?
I have used a 74HC14 with a 10K resistor on the input as a RS-232 receiver
transmitter. Although it is a little bigger than a 741, it uses less power
(essentially zero except when data transfers). The only problem I know of
with this scheme is if the serial receiver at the other end needs to see a
negative voltage for a mark condition. The 1489 receiver doesn't, the TI
receiver chip that's used for RS-232 does. I don't know about MAX chips,
etc. It does work quite nicely though and I still have 4 inverters left
over.
A while ago someone posted a source for low cost ceramic resonators.
I lost my mail database a few days ago and I can't remember the name of
the company.
I believe it was something like JAI or RAI.
I need quantity and low cost so Digi-Key is out of the question.
I suppose I could track down a Murata or Panasonic distibutor,
but this other outfit sounded cheaper.
Thanks in advance.
carl
Henry Carl Ott N2RVQ .....carl@spam@EraseMEpipeline.com
------------------------------------------------
No wife, no horse, no spell checker.
------------------------------------------------
We built a transmission analyzer earlier this year that measured the
current in some solenoids. As you suggested we measured the voltage
across a small series resistor. The value in our application was
0.5 ohms I believe.
> Hi everyone.
>
> Does anyone have any experience making current measurements using a
> PIC16C71?
> I want to be able to measure the current being produced by an automotive
> alternator. What would be the best approach? Just measure the voltage
> drop across a small series-resistor? Or is there a better way? I vaguely
> recall hearing of an IC made for just such a purpose, but I didn't pay much
> attention to it at the time :^( Has anyone else heard of this?
>
> Any info or ideas will be greatly appreciated.
>
> Thanks, and...
>
> M E R R Y C H R I S T M A S !
> -------------------------------
>
> --
>
>
> - Richard Friesen Little Timmy took a drink,
> (.....Richard_FriesenSTOPspam@spam@mindlink.bc.ca) But now he'll drink no more,
> For what he thought was H2O
> Was H2SO4
> ------------------------------------------------------------------------------
> --
>
>
>We built a transmission analyzer earlier this year that measured the
>current in some solenoids. As you suggested we measured the voltage
>across a small series resistor. The value in our application was
>0.5 ohms I believe.
I've done similar things in test fixtures, too. But, if you look at the circu
it
you used, it probably had a bipolar power supply, or at least one greater
than the voltage of the UUT, for the op amp that amplified that differential
voltage. Even expensive op amps tend to lose it a bit as you get close to the
supply rails, and cheap ones can't accurately handle signals there at all.
Especially at the upper rail.
This might be a good application for the "toroid pickup" trick that someone
mentioned either here, or on the Stamp list, the other day for measuring
AC appliance power consumption. You run one leg of the circuit through a
toroid with a "sense coil" wrapped around it, and measure the induced
voltage. I *think* this still works, even though it would be dealing with the
rectified current, instead of AC, but I'm not sure.
Microswitch makes some nice little Hall Effect current
monitors. Run one lead of your circuit through the hole
(multiple turns for greater senstivity) and get a voltage
out proportional to current in the lead.
Microswitch's part numbers are CSLAXXX where the XXX is
style and current range codes.
If I remember right, the original poster stated he did
not want Hall effect type sensors. I wonder why, cause
that sure limits options for DC.
> Actually, I have no objections to using a Hall effect sensor. In fact, it
> may be better than the series-resistor method, since that would require an
> op-amp, and therefore a negative power supply. (Or is there another way?)
Op-amps don't REQUIRE a "negative" power supply if done right -- it's all
relative!!! If you use 5V for Vdd and Gnd for the negative side, you can
sense most any voltage in between (with the exception of the low extremes).
Check out the Forest M. Mimms op-amp book that Radio Shack sells. Look for
comparator circuits.
The CSLA1XX family runs on 8-16VDC 12VDC nominal.
Output is in mV/NI where N is number of turns & I is current.
Lowest current part is 49.6 mV/NI max current 57 Amps
Higest current part is 5.6 mV?NI max current 625 Amps
Hole ranges from .43" to 1.06" depending on I range.
The CSLA2XX family runs on 6-12VDC 8VDC nominal.
Output is 32.7mV/NI for the 72 A max part
The 950 A max part is 2.3mV/NI.
Hole sizes are the same.
Sorry I don't have prices.
A Seattle phone number is 206-453-7591
Microswitch/Honeywell Canada, Scarborough, Ontario 416-293-8111
You want to ask for the current (no pun intended) version of
Catalog 20.
>James Kelly wrote:
>
>>Whats the best way to convert Parallax Instruction codes into
>>MicroChips?
>
>Andy Warren wrote back:
>
>The best way is just to learn the Microchip instruction set. The PIC16s
>only have... what? 30-odd instructions? Sit down with a cup of coffee
>and a Microchip databook, and you can probably learn the instructions in
>one sitting.
>
>If you have a learning disability or just don't feel like taking
>the time, there are a couple of Parallax-to-Microchip converters
>available. Parallax probably have one on their ftp site
>(ftp.parallaxinc.com) -- Lance Walley can verify this -- and I think
>one's been posted on Microchip's BBS.
Actually, we have no knowledge of any real convertors, either at Parallax
or Microchip. Consequently, we are talking to two PIC list members about
writing a robust convertor to convert in both directions. Once we decide
upon someone to do it, it will of course take some time. For now,
therefore, Andy is right: you essentially must to learn the Microchip code.
------------------------ Lance Walley ---------------------------
Parallax, Inc.
There's been some recent talk about converting Microchip code to Parallax
code and vice versa. We'd like to know how much interest there is in this.
Over the past two years, several Parallax customers have uploaded various
utilities to our BBS. However, none of these has been complete or
maintained. Recently, two members of this list contacted me about writing
such a utility. We would establish a format relationship with the author,
which should guarantee some form of maintenance.
Would a two-way convertor be useful? It would allow you to implement
useful Microchip and Parallax code samples, with minimal effort. Please
let us know what you think.
------------------------ Lance Walley ---------------------------
Parallax, Inc.
As a result of MIT's coordination of previously separate computing systems,
it has become necessary to rename this discussion list. Beginning with
Tuesday 17 January 1995, please use the name PICLIST in place of PIC for all
commands to and communication with this list. We shall try to insure that
messages specifying the former name, during a suitable grace period, will
receive a notice of the name change.
We regret that we have found such a change necessary for the benefit of our
local clients, but trust that it should not cause any great disruption for
you. Please let us know immediately if it does not behave properly for you.
I have one of the PICProto Boards that Parallax sells and have lost the
sheet of paper that give the recomenned caps. specifically I need the
caps for C6 adn C5 for an XT osc. If anyone has these I would appreciate the
info.
later
John
-----------------------------------------------------------------------------
John Johnson Team OS/2 member | RemoveMEjohnsonjspamBeGonebga.com | spamBeGonejohnsonjKILLspam@spam@utdallas.edu
C&H Technologies VXI Plug N' Play member
-----------------------------------------------------------------------------
And the Seventh version of OS/2 raised into the air its bow of blue steel and
cried," It. Is. Done." Around him lay Bill Gates and Microsoft apps. Their
evil in this world at an end.
Revelations of InfoWorld, Oct 11 1994
>I have one of the PICProto Boards that Parallax sells and have lost the
>sheet of paper that give the recomenned caps. specifically I need the
>caps for C6 adn C5 for an XT osc. If anyone has these I would appreciate the
>info.
John,
The paper from MicroEngineering Labs (the PICProto maker) recommends a
value of 5-22 pF. The Microchip data sheet (for 5x parts) recommends
values of 15-30 pF for C1 (connected to OSC1) and 15-300 pF for C2
(connected to OSC2). If you're running at 1 MHz, they recommend 15-30 pF
for both. At 4 MHz, they recommend 15 pF for both.
Hope it helps...
------------------------ Lance Walley ---------------------------
Parallax, Inc.
> John,
>
> The paper from MicroEngineering Labs (the PICProto maker) recommends a
> value of 5-22 pF. The Microchip data sheet (for 5x parts) recommends
> values of 15-30 pF for C1 (connected to OSC1) and 15-300 pF for C2
> (connected to OSC2). If you're running at 1 MHz, they recommend 15-30 pF
> for both. At 4 MHz, they recommend 15 pF for both.
I acutally took those for granted to be the same as the data book so i
have those. What I was looking for is the electrolytic ones for the
regulator. C5 looks like a noise cap for the incoming V into the 7805 and
C6 maybe one off the reg. I remeber seeing it in a little box on the
sheet that came with in that was on the left side just below the
schematic of the board.
later
John
-----------------------------------------------------------------------------
John Johnson Team OS/2 member | johnsonjspam_OUT@spam@bga.com | spamBeGonejohnsonj@spam@utdallas.edu
C&H Technologies VXI Plug N' Play member
-----------------------------------------------------------------------------
And the Seventh version of OS/2 raised into the air its bow of blue steel and
cried," It. Is. Done." Around him lay Bill Gates and Microsoft apps. Their
evil in this world at an end.
Revelations of InfoWorld, Oct 11 1994
>On Wed, 25 Jan 1995, Lance Walley wrote:
>
>> John,
>>
>> The paper from MicroEngineering Labs (the PICProto maker) recommends a
>> value of 5-22 pF. The Microchip data sheet (for 5x parts) recommends
>> values of 15-30 pF for C1 (connected to OSC1) and 15-300 pF for C2
>> (connected to OSC2). If you're running at 1 MHz, they recommend 15-30 pF
>> for both. At 4 MHz, they recommend 15 pF for both.
>I acutally took those for granted to be the same as the data book so i
>have those. What I was looking for is the electrolytic ones for the
>regulator. C5 looks like a noise cap for the incoming V into the 7805 and
>C6 maybe one off the reg. I remeber seeing it in a little box on the
>sheet that came with in that was on the left side just below the
>schematic of the board.
>
>later
> John
Sorry about that; that was pretty stupid. The info sheet recommends the
following caps when using a TO-220 7805:
C5: 0.01 - 0.1 uF
C6: 0.1 - 10 uF
------------------------ Lance Walley ---------------------------
Parallax, Inc.
Over the past year or two, we've developed several PIC development tools.
Most of these have been mid-range downloaders, I/O simulators, etc. Late
in 1994, we introduced some in-circuit emulators, which are now taking
sales from the earlier tools.
Which brings us to this: we have several products that we'd like to clear
out. They're good products, but they're just not in much demand, anymore.
Rather than trash them, we'd like to donate them to schools and
universities. If you're interested, please let us know.
Hope I haven't ruffled too many feathers.
------------------------ Lance Walley ---------------------------
Parallax, Inc.
> Pablo,
>
> Home automation? What kinds of things are you thinking of doing?
>
> Any particulars yet?
>
> ... JC
Well, first of all, I have 3 things already done and I'm actually trying to
sell them -- look for an add in the back of Circuit Cellar's Feb. issue.
First of all, some buddies and I created a communications protocol (VERY
SIMPLE and EASY to use). We call this RS232-BUS. It's simply RS232 wired
multi-drop with addressing. Then, we created a temperature taking device,
expanded that to a thermostat, and we also made an 8-bit I/O device for
interfacing to relays, alarm systems, or just about anything else. If you
want detailed information, mail a letter to RemoveMEchaseEraseMEKILLspambga.com and someone will
send you detailed information.
In the future, I hope to do some infra-red transmitting/receiving devices,
some "control panels", motion sensors, etc... We have a pretty good list
of useful things we hope to do. Right now though, it's mostly for our own
use but once we develop something and test it - why not sell it?
I saw that you're interested in robotics - write me if you need any help - I
have some interest in this area and I'd be willing to help you get started.
Oh god yes. My univ has almost nothing in the way of pic tools. except
the programmer i have. We would love stuff like that. Actually we dont
have a lot of hardware at all. We have crappy scopes and really shitty
HP LA(yech). Well if i am not number 2K in line and we are worthy let me
know :) btw my address says it all. University of Texas at Dallas.
> I hope this isn't too commercial...
>
> Over the past year or two, we've developed several PIC development tools.
> Most of these have been mid-range downloaders, I/O simulators, etc. Late
> in 1994, we introduced some in-circuit emulators, which are now taking
> sales from the earlier tools.
>
> Which brings us to this: we have several products that we'd like to clear
> out. They're good products, but they're just not in much demand, anymore.
> Rather than trash them, we'd like to donate them to schools and
> universities. If you're interested, please let us know.
>
> Hope I haven't ruffled too many feathers.
>
>
> ------------------------ Lance Walley ---------------------------
> Parallax, Inc.
>
later
John
-----------------------------------------------------------------------------
John Johnson Team OS/2 member | .....johnsonjRemoveMEbga.com | johnsonj@spam@utdallas.edu
C&H Technologies VXI Plug N' Play member
-----------------------------------------------------------------------------
And the Seventh version of OS/2 raised into the air its bow of blue steel and
cried," It. Is. Done." Around him lay Bill Gates and Microsoft apps. Their
evil in this world at an end.
Revelations of InfoWorld, Oct 11 1994
Here is, as promised, the info I have on the TO flag bug.
Note that the following is based on my experience only, so it may
be that I've misunderstood something. Therefore I would like to
here from anyone who can confirm or deny that this problem exists.
The story: In July 1994 I was working on a project that involved
PIC16C57. The electro-magnetic working environment for the PIC's
was pretty nasty -- to say at least, so I used the Watch dog to
catch any program run-aways.
The PIC's (8 of them) were controlled from a PC through a serial
connection. If one of the PIC's didn't respond to a request from
the PC, then the PC would reset the PIC's via the MCLR pin -- an
extra safety precaution.
The initialization code in the PIC's used the TO (TimeOut) bit in
the Status register to determine if a reset was caused by Watch dog
time-out or by a MCLR/power-up reset.
I use the CLRWDT instruction in the program, this instruction sets
the TO bit to "1", so after a MCLR reset the TO bit should be "1",
since a MCLR doesn't affect the TO bit (according to the manual).
However, I noticed that when the PC did a MCLR reset of the PIC's,
some of them would execute the power-up reset routine (as
expected), while others executed the watch-dog time out reset
routine. When I repeated the MCLR pulse, the pattern seemed to be
random, that is, at one time a PIC would do a power-up reset, the
next time a time-out reset...
The power-up/time-out ratio appeared to be around 50/50.
Very strange I thought -- must be a software bug... So I wrote a
short program that simply copied the TO bit to an output port
connected to a LED. When the PIC's were reset by MCLR, some of the
LED's turned on and some off - in other words: the same problem.
Well, maybe it's a hardware problem then ? I took a small PCB, put
on a PIC, a crystal, 8 LED's and a MCLR reset key. Wrote a program
that shifted the TO bit into a register, then copied the register to
the port, so that the LED's would show the status of the TO flag
after the last 8 resets.
After power up, the pattern on the LED's shifted one position each
time I did a MCLR reset or provoked a WDT time-out by stopping the
oscillator. The value shifted in after a WDT time-out was always
"0" (as expected) and the first TO bit shifted in after power-up
was always "1" (also as documented in the manual).
But after a MCLR reset the TO bit had an apparently random value :((
I discovered that the problem ONLY occurres when the prescaler is
assigned to the RTCC. When assigned to the WDT (even if set to 1:1)
then the TO bit isn't affected by MCLR reset.
I tried using different oscillator configurations and speeds -
didn't affect the problem.
Next I tried different supply voltages - no influence.
Then I disabled the Watch dog by blowing the WDT fuse - and I still
got random 1's and 0's in the TO bit !!!
Note that when the watch dog timer is disabled, then the TO bit
should *NEVER* be "0", since a watch dog time-out is the only event
that can set the TO bit to "0" (according to the manual).
I tested different devices. No difference between the EPROM / OTP
parts I tested.
Besides the 16C57's, the 16C55's also have the bug. 16C54 and 16C56
probably also, since they have the same core as 16C57, but I haven't
tested.
The 16C58A did not have the bug (Strange - since it's the same
core as the other 16C5X's ? - or maybe not ? ).
The PIC16C71 does not have the bug. My guess is that 16C84, 16C64
and 16C74 work fine, since their core is based on '71, but I
haven't tested.
Well, what did I do ?
After discussing the problem with the local distributor (exatec),
I send the source code to them and later the hardware too. They
didn't come up with anything, so they passed the code/hardware to
Microchip and told me that "They (Microchip) are looking into my
problem".
I guess they look very carefully, because they have been looking for
more than 6 months now.
As stated in the beginning, I'm very interested in hearing from
anyone that have had the same or similar problems -- and perhaps
solved them ?
For the time being, my solution is simply not to use PIC16C54-57
in any new designs, where I need to determine the cause of reset.
This is not what I would call a satisfactory solution to the problem.
To summarize: The TO bug affects an application when:
* The TO flag is checked after reset and
* The reset may be caused by MCLR and
* The prescaler is assigned to RTCC and
* PIC16C54-57 is used
I hope that someone on the PICLIST can help me with this problem
- or, at least, that this information can help you from running
into a similar problem in future designs.
>For the time being, my solution is simply not to use PIC16C54-57
>in any new designs, where I need to determine the cause of reset.
>This is not what I would call a satisfactory solution to the problem.
Michael:
If you have the registers to spare, you may want to try simply loading a
few (four of them, perhaps) with known values. Check the contents of
those registers on reset. If they contain the proper values, you can
assume that the PIC was reset via MCLR. If they don't, assume that the
PIC was just powered up.
>Does anyone know if the STAMP list has died or moved during the last couple
>of months? I haven't reveived anything this year. I have PIC's & some
>STAMPS & would like to keep current on both.
>
>Regards,
>
>Dave
I haven't received anything but I think the STAMP list is alive even
if the mail volume isn't like on this list :-)...
You wrote:
> If you have the registers to spare, you may want to try simply loading a
> few (four of them, perhaps) with known values. Check the contents of
> those registers on reset. If they contain the proper values, you can
> assume that the PIC was reset via MCLR. If they don't, assume that the
> PIC was just powered up.
Yes, useful tip for checking if reset was caused by power-up or
by MCLR reset.
However the subject were Watch Dog Timeout reset vs. MCLR reset.
According to the manual, the TO bit should indicate whether a
Watch dog timeout has occurred. But under some circumstances the
TO bit does NOT have the correct value. That is the problem.
Someone wrote me and indicated a problem with my WWW interface to the
Circuit Cellar Ink FTPmail server.
It appears that in Mosaic (at least the X version), the submit button was
rendered as a field rather than a button, so there was no way to submit
the form with your email address. I have fixed that problem.
I am mentioning this here in case anyone tried it and gave up because it
didn't work. If that is the case, you probably threw the URL away. It is: http://tfnet.ils.unc.edu/cgi-bin/CCBBS
Oh, by the way; Once you have entered your email address and gotten the
list of file areas, save that document as a bookmark. It contains your
email address so you won't have to "log in" again. The same is true of any of
the file area listings.
I have encountered a problem I didn't expect - couldn't find a consistent
set of tools for the '71 chip!
I have a program written for the 16c54, that I wanted to "port" to a '61
and then enhance. Supposedly the '71 mode of assemblers should produce
correct code. Since my original program was written in Microchip mnemonics
and was using macros, I decided to try the Microchip assembler. It does
assemble the code, but no simulator would handle it!
1. I try the new MPASM that Microchip recommends. It generates a .hex
file, not .obj and no .sym file. The Parallax's PSIM won't recognize the
.lst format, the Windows version generates a General Protection Error, and
the Microchip's own MPSIM wants the .obj file. Renaming .hex to .obj
doesn't help much.
2. I try the MPALC assembler. It does produce both the .sym and the .obj
files. The object is supposedly in the INHX8M format. I start the MPSIM.
It doesn't complain, but doesn't interpret the object file right either -
even the first instruction looks bad and hex file's checksums are
interpreted as code! And the doc claims that the default format is INHX8M.
So the questions part:
1. How to use the tools correctly for the '71 PIC? Which assembler and
what options.
2. Is there an automated or semi-automated way to translate the Microchip
mnemonics source into Parallax source. I know that PASM is supposed to
handle the Microchip mnemonics, but it sure doesn't like macros in my file.
I would hand edit it as a last resourt, if I new the Parallax tools will work.
> Having seen that there are numerous problems that crop up that could
> be due to un-initialised registers the simulators should be engineered
> to point this out. It is very difficult to decide what will happen
> to program flow at compile time especially with computed GOTOs so the
> only place to detect the use of registers that have not been set up would be
> in a simulator.
Our simulator, PSIM, allows you to randomize the contents of the register
space any time during program execution. This feature was put in to ferret
out this exact problem.
Your idea is excellent! There would need to be a lot of information about
what registers this rule should apply to as some non-ram registers, such
as RTCC on the PIC, would not qualify for this treatment.
-- Tom Mornini ----------------------------------------------------------
-- Parallax, Inc. ------------------------------------------------------
-- Makers of really cool PIC development tools & the BASIC Stamps ------
-- http://www.parallaxinc.com ftp://ftp.parallaxinc.com/pub --
In message <spam_OUTm0ruGcw-000DCnCspam_OUTspam_OUTdopey.me.iastate.edu>, you write:
>This may be PIC related...
>
>I went to the MegaZone in Morecambe last night, it is a laser gun game
>arena, like QZar and Laser Quest. Normally you are known as 'Player 1'
>etc., but if you purchase club membership you get your own name stored on
>the computer to identify you. To activate this feature you are given a tag
>which looks exactly like a button cell (or lithium battery). You press the
>cell against two contacts (centre and edge, like + and - contacts for a
>power cell) and somehow the cell returns a unique code. One of the cells
>was manufactured by Dallas. How do they work?
>
The Dallas part is probably one of their "Silicon Serial Numbers" (basically a
serial ROM), which uses Dallas' one-wire bus. This is a novel bus which uses a
single wire for power, clock and data. Interesting devices, these. While we're
on the subject, does anyone have PIC code for talking to this bus? The
protocol looks to be a bit on the complicated side. :-)
> I had trouble with a capital T when trying to program in-circuit with
> the oscillator running. The program would intermittently load starting
> at the wrong place.
One of my students found exactly this behaviour recently (he was using
an Xtal oscillator if it makes any difference). He was using O/C
buffers to drive RB6/7 and had a sort of wire-OR arrangement of two
transistor switches to set VPP/MCLR to one of 0, 5V or 13V. The program
seemed to be loaded a few bytes displaced from where it should have been.
Nothing was repeatable though. The cure was a 10K//100pF network from
MCLR to GND. The MCLR line is incredibly sensitive.
>The Dallas part is probably one of their "Silicon Serial Numbers"
> ....
>does anyone have PIC code for talking to this bus? The protocol looks
>to be a bit on the complicated side. :-)
Monty:
It's not complicated at all, although you probably want your PIC to be
running at some real clock speed (like 4 MHz -- I've done it at 32 KHz,
but it wasn't fun). You should get a copy of the Touch Memory Databook
from Dallas if you're interested in these parts.
The programmer in question has correctly programmed about 80% of the units
so far (around 200 pieces or so.) We have narrowed it to the programmer.
We pre-programmed some 16C84s before inserting them and all of that test
run worked correctly except that they are not properly "branded" with
the desired serial numbers.
> Timothy McDonough wrote:
>
> > In our particular case only the first byte of program memory is being
> > programmed. The other locations read 3FFFH when read by a PICSTART.
>
> Has this programmer ever worked with or without an oscillator connected?
> Is this scenario familiar: the device is first bulk erased then the
> programmer tried to program the first location but failed to verify it
> and then stopped with an error message?
>
> David
> --
> KILLspamdavid.taitspamBeGoneman.ac.uk
>
Here's the general information for the list you've
subscribed to, in case you don't already have it:
[Last updated on: Sun Apr 2 12:21:43 EDT 1995]
MINDS ONLINE
Minds Online, is a non-profit, non-commercial, independent service
providing applications assistance to working engineers developing designs
destined for volume production.
Minds Online--a work in progress--has four phases. Phase One, Two, and
Three are on line now. Phase Four, a WWW home table, is still in the works.
Phase One is the ftp site, ftp.std.com -->
/customers2/nonprofits/minds-online. Posted on this ftp site's
subdirectories under /minds-online are handy electronics engineering
programs. Contributions welcome. Public domain and shareware only,
please. Dig through your files and upload those programs you have written
or have found to be handy. Also posted under /minds-on/stories is
computer-readable material related to trade-magazine design articles and
ideas for design. Under /biblio you will find bibliographies of
trade-magazine articles.
Phase Two is the mailing list, spam_OUTnew-at-molSTOPspamworld.std.com. Anyone who is
interested in new developments and postings at Minds Online, engineer or
not, can join this mailing list. Expect no more than one message per two
weeks.
Phase Three is the mailing list, RemoveMEminds-onlinespamworld.std.com. Engineers
can post requests for applications help to this mailing list. The
applications engineers, consultants, and altruistic engineers who are on TakeThisOuTminds-onlinespamRemoveMEworld.std.com's mailing list may--or may not--reply to these
requests. These recipients may reply for free or they may negotiate a
consulting fee. After all, you get what you pay for and he who expects
something for nothing is often disappointed.
Minds Online thinks that virtual consulting over the Internet will become
an important way for companies to accomplish specialized design tasks and
for engineers to make some money working part-time at home. Minds Online
sees its role as that of a matchmaker, not a justice of the peace. In
other words, once Minds Online introduces two parties, they will then
have to work out their own relationship.
The KILLspamminds-onlinespamspam_OUTstd.world.com mailing list will be particularly helpful
when you do not know which specific design path to take or which specific
suppliers to deal with. Minds-onlineRemoveMEstd.world.com will present your
problem to engineers familiar with many disciplines and many ways of
solving a given problem.
The EraseMEminds-onlineSTOPspamRemoveMEstd.world.com mailing list will accept requests only
from working engineers. Only the moderator of Minds Online can approve a
request for transmittal to the list's recipients. The requests will go
out by private e-mail and will not apprear on any public fourm. The names
of the list's recipients are strictly protected. Only the moderator of
Minds Online can access the recipients' names.
To be added to Minds Online's mailing lists, send a message containing
In addition, to have your request posted to the recipients of spamminds-online.....spamworld.std.com applications-help requests, or to join the
list of recipients of applications-help requests, supply enough
information so that the Minds Online moderator can judge if you are
eligible or not.
If your job title is some form of junior engineer, engineer, project
engineer, senior engineer, engineering manager, or electronics
technician, just your name, title, company, address, and e-mail address
will do. If you do not bear such a title, submit a brief circulum vitae,
detailing your design experience. For example, some companies, for no
known reason, dub senior engineers "staff scientists." If you have such a
title, please explain what you really do.
Specifically excluded from minds-onlinespam_OUT@spam@world.std.com, from either
posting requests or receiving requests, are hobbyists, the
something-for-nothing crowd, tire-kickers, inexperienced students, and
the totally lost. Requests from these folks will be politely steered to
the sci.electronics newsgroup.
Several days ago, the Pic Microcontroller mailing list received a post
(included below) which indicated that "we" (apparently the list in its
entirely) had been added to some commercial mailing list you apparently
maintain (although you failed to gicve your own email address).
Such blatantly commercial junk mail directed at the PIC microcontroller
mailing list is way out of line (according to my records, you are not even
a member of the list). Furthermore, the PIC microcontroller list only
accepts postings from individuals, not from other mailing lists. Your kind
of abusive spamming is outrageous, and I would urge your service provider
to revoke your net privileges immediately.
I am now informing you that every member of the PIC list is a paid internet
consultant. As such, they command fees of US$100/hour or US$100/message
(whichever is greater) in order to review unsolicited email. As list owner,
I am defining all mail from you, Bat Falcon or your busines associates or
any email list you or your associates maintain or moderate, as "unsolicited
email" for the business purpose outlined above. Any furter email from you
or your associates to the PICLIST email list (.....piclistspam.....mitvma.mit.edu) will
be billed accordingly. There are apprximately 500 members on the list at
this time (although the list has been consistently growing, so keep that in
mind if you plan further spammage). Individual members of the list may
choose to waive their consulting fees of they so desire (although I doubt
many will).
The best advice I can offer, Bat, is for you to remove anyone on the
PICLIST (and/or the PICLIST itself) from your spamming "new-at-mol" list,
and send me an apology, personally (joryKILLspamEraseMEmit.edu), which I will be glad to
forward to the list at no charge. I would also suggest that in the future
you refrain from adding people to a mailing list without an explicit
request on their part to do so.
Sincerely,
Jory Bell
owner: PIC microcontroller email list
ps: If you intend to keep the PICLIST on your spam-list, please send me
your mailing address, as it will help in any necessary collection efforts.
==========================================================================
begin included spammage:
========================================================================== {Quote hidden}
>--
>
>Welcome to the new-at-mol mailing list!
>
>If you ever want to remove yourself from this mailing list,
>send the following command in email to
>"EraseMEnew-at-mol-request@spam@@spam@world.std.com":
>
> unsubscribe
>
>Or you can send mail to "@spam@MajordomospamKILLspamworld.std.com" with the following command
>in the body of your email message:
>
> unsubscribe new-at-mol spamBeGonePICRemoveMEEraseMEmitvma.mit.edu
>
>Here's the general information for the list you've
>subscribed to, in case you don't already have it:
>
>[Last updated on: Sun Apr 2 12:21:43 EDT 1995]
> MINDS ONLINE
>
>Minds Online, is a non-profit, non-commercial, independent service
>providing applications assistance to working engineers developing designs
>destined for volume production.
>
>Minds Online--a work in progress--has four phases. Phase One, Two, and
>Three are on line now. Phase Four, a WWW home table, is still in the works.
>
>Phase One is the ftp site, ftp.std.com -->
>/customers2/nonprofits/minds-online. Posted on this ftp site's
>subdirectories under /minds-online are handy electronics engineering
>programs. Contributions welcome. Public domain and shareware only,
>please. Dig through your files and upload those programs you have written
>or have found to be handy. Also posted under /minds-on/stories is
>computer-readable material related to trade-magazine design articles and
>ideas for design. Under /biblio you will find bibliographies of
>trade-magazine articles.
>
>Phase Two is the mailing list, RemoveMEnew-at-molKILLspamRemoveMEworld.std.com. Anyone who is
>interested in new developments and postings at Minds Online, engineer or
>not, can join this mailing list. Expect no more than one message per two
>weeks.
>
>Phase Three is the mailing list, TakeThisOuTminds-onlineworld.std.com. Engineers
>can post requests for applications help to this mailing list. The
>applications engineers, consultants, and altruistic engineers who are on
>spamBeGoneminds-onlineKILLspamTakeThisOuTworld.std.com's mailing list may--or may not--reply to these
>requests. These recipients may reply for free or they may negotiate a
>consulting fee. After all, you get what you pay for and he who expects
>something for nothing is often disappointed.
>
>Minds Online thinks that virtual consulting over the Internet will become
>an important way for companies to accomplish specialized design tasks and
>for engineers to make some money working part-time at home. Minds Online
>sees its role as that of a matchmaker, not a justice of the peace. In
>other words, once Minds Online introduces two parties, they will then
>have to work out their own relationship.
>
>The EraseMEminds-online.....KILLspamstd.world.com mailing list will be particularly helpful
>when you do not know which specific design path to take or which specific
>suppliers to deal with. spamMinds-onlinestd.world.com will present your
>problem to engineers familiar with many disciplines and many ways of
>solving a given problem.
>
>The minds-onlineSTOPspamstd.world.com mailing list will accept requests only
>from working engineers. Only the moderator of Minds Online can approve a
>request for transmittal to the list's recipients. The requests will go
>out by private e-mail and will not apprear on any public fourm. The names
>of the list's recipients are strictly protected. Only the moderator of
>Minds Online can access the recipients' names.
>
>To be added to Minds Online's mailing lists, send a message containing
>
> subscribe minds-online
>
> or
>
> subscribe new-at-mol
>
> to
>
> majordomoSTOPspamKILLspamworld.std.com.
>
>Or send
>
> subscribe
>
> to either
>
> @spam@new-at-mol-request.....spamworld.std.com
>
> or
>
> spamminds-online-request..........world.std.com.
>
>In addition, to have your request posted to the recipients of
>minds-online.....world.std.com applications-help requests, or to join the
>list of recipients of applications-help requests, supply enough
>information so that the Minds Online moderator can judge if you are
>eligible or not.
>
>If your job title is some form of junior engineer, engineer, project
>engineer, senior engineer, engineering manager, or electronics
>technician, just your name, title, company, address, and e-mail address
>will do. If you do not bear such a title, submit a brief circulum vitae,
>detailing your design experience. For example, some companies, for no
>known reason, dub senior engineers "staff scientists." If you have such a
>title, please explain what you really do.
>
>Specifically excluded from KILLspamminds-onlinespam_OUTworld.std.com, from either
>posting requests or receiving requests, are hobbyists, the
>something-for-nothing crowd, tire-kickers, inexperienced students, and
>the totally lost. Requests from these folks will be politely steered to
>the sci.electronics newsgroup.
>
>Bat Falcon
>Minds Online Moderator
>EOL
Hello from Microchip! As the commercial vendor of the stuff this
list concerns, I would like to ask your permission to make some
postings to this list. Please respond to spam_OUTbbolesTakeThisOuTmicrochip.com
Since this is not a moderated list, sure, you are welcome to post.
As in all unmoderated lists, we do want to know what is comming
and is happening ast microchip, but if it smacks of being too
commercial, someone will no doubt let you know :)
Greetings everyone! I am new to this list so
pardon me if this is repetitive.
Is anyone aware of any UNIX based development tools
for the PIC parts. SUN workstations are the prefered
target platform, but any info would be helpful.
Thanks,
John
Field Apps Eng
Bell Industries
T: (408) 734-8570
F: (408) 734-8588
From: John T <.....72712.2347.....RemoveMECOMPUSERVE.COM>
Is anyone aware of any UNIX based development tools
for the PIC parts. SUN workstations are the prefered
target platform, but any info would be helpful.
I also prefer to use Linux rather than DOS/Windows, because
of its inherent capabilites (e.g. I expect to be able to
download program to the PIC while still having the machine
available for other use). At present, I plan to run
assembler and simulator in a DOS emulator uner Linux,
while running David Tait downloader.
In the long term, I plan to pull out the PIC emulator that someone
wrote for Unix/X, and work on it some. I plan to convert it to
use Tcl/Tk.
> Greetings everyone! I am new to this list so
> pardon me if this is repetitive.
> Is anyone aware of any UNIX based development tools
> for the PIC parts. SUN workstations are the prefered
> target platform, but any info would be helpful.
Here's an announcement that appeared on this list some time ago .. is
it possible to add this to the FAQ ?
Well I have finally uploaded the latest version of
pictools onto ftp.funet.fi. It is currently in
/pub/microprocs/incoming, but will (hopefully) soon
be moved into /pub/microprocs/pic/pictools
In case you don't know it is a macro assembler and disassembler
for unix (or any system that can run gcc, bison and flex) All
source code is supplied.
The file is: pictools08.tar.gz (29180 bytes long)
If anyone needs a copy urgently I will mail them with it. If there
is a flood of interest I could post it to the whole list but I would
rather not bung up everyones in-tray ;-)
0.5 to 0.8 are complete re-writes of the original code and this is the
first public release of this new code.
The readme.1st follows.
pictools0.8
-----------
*Important* these pictools are released under the GNU licence (included in
COPYING)
Please read this carefully if you want to do anything but use these tools.
These programs are designed to allow a unix like system (linux in my
case) act as a development system for the Microchip PIC range of processors
They port to any system that is capable of running GNU gcc.
The assembler picasm is able to compile code for 12, 14 and 16 bit pics.
The disassembler picdis is able to disassemble code from 12 and 14 bit pics.
If anyone needs a 16bit disassembler they had better ask really nicely, or wait
until I need to use one ;-)
See the test and example directorys for example code showing the syntax of the
source assembler code. In the include directory are the instruction sets for the
three architectures of PIC, giving an idea of how macros are defined. This
directory
needs to be pointed at by the picasm script, so edit picasm appropriatly.
Code is output in intel hex 16 format, together with a config file which
may detail the fuse, id and oscillator options a pic may use.
A program to decode the .cfg file is also be provided and may be used to produce
loaders
for downloading software. The format of the config file is close to the
previous PT
format used by this assembler.
Some code for reading intel hex 16 (for downloader code writers) is provided
in the disassembler directory src/disasm/intel16.c
A "concise" manual is provided, as well as an "real" piece of example code.
Next project is a high(er) level language based on either C, BASIC or FORTH
(haven't decided which yet!) aimed at PICs and other low resource
microcontrollers
(IBP's) all/any suggestions welcome..... Currently a tiny FORTH environment is
looking good to me (STOP PRESS - this has now been started provisionally called
third ;-)
Acknowledgements.
-----------------
Thanks to
vinsci <KILLspamvinsciTakeThisOuTfi.funet.nic> For many suggestions on how to make the thing
better
and for actually using the assembler while it wa
s barely
operating.
Jory Bell <RemoveMEjoryspamSTOPspamEDU.MIT> For setting up and running the Pic mailing list.
and
Linus Torvalds <> For creating Linux, by far the best OS on a PC (
IMHO!!)
>
> JT <.....72712.2347EraseMECOMPUSERVE.COM> wrote :
>
> > Greetings everyone! I am new to this list so
> > pardon me if this is repetitive.
> > Is anyone aware of any UNIX based development tools
> > for the PIC parts. SUN workstations are the prefered
> > target platform, but any info would be helpful.
>
> Here's an announcement that appeared on this list some time ago .. is
> it possible to add this to the FAQ ?
>
> -adrian
>
>
>
<Long announcement about pictools08 removed>
I've taken this and gotten it to compile on my Sun 3/260. I did have to make
one major adjustment, in one location. If anyone is interested, let me know
(particularly the author, if he's listening, I haven't had time to make up
real diff's) I've also added some new lines to the code to get it to be
more compatible with MPASM (I think :). The changes haven't been thoroughly
checked as I haven't had time....
It's quite interesting, as I NFS mount the development directory on my PC.
It can then read the object files created by the assembler, so that I can
use my programmer to program the parts. All this because, I have a really
slow PC, and I like using X windows (my PC won't run MS-Windows...)
> I am hoping to find an MSc student to convert an existing simulator
> into a PIC simulator. Our tool is based on the Tcl/Tk ``wish'' Window
> Shell, and lets you simulate multiple (interconnected) controllers, use
> Tcl/Tk to build graphical I/O simulations and control panels, and use Tcl/Tk
> as a ``macroassembler'' for your applications code. However, the microcontrol
ler
> that it currently simulates isn't a PIC, so someone has to convert the
> interpreter part. Naturally, if we get this done, I'll let everyone know!
>
> Bob G
There's another Unix simulator around, too - it was posted to this group
by Dave Madden <spamBeGonedhmRemoveMEVHEISSU.NET.DCL.CO.JP> last november, and should be
on ftp.sics.se as well (though I can't see it there). It needs C++ and X,
and I still have a copy, though it would probably be better to look to
Dave for any updates first.
I haven't tested it, since I don't have C++ up.
=>There's another Unix simulator around, too - it was posted to this group
=>by Dave Madden <.....dhmEraseMEVHEISSU.NET.DCL.CO.JP> last november, and should be
=>on ftp.sics.se as well (though I can't see it there). It needs C++ and X,
=>and I still have a copy, though it would probably be better to look to
=>Dave for any updates first.
Hi. I'm still here, but haven't had much time to do PIC-related stuff
recently. I've put the simulator Adrian mentioned up for anon ftp
from:
iii.net:/pub/pub-site/dhm/picsim.tar.gz
I compiled it today with g++-2.6.2 and X11R6 and it still worked; I
think I was using g++-2.5.4 and X11R5 back in November when I was last
working actively on it. Several people took copies back then, but I
only heard from one or two people, and only that they were having
trouble compiling it (with older versions of g++ or AT&T c++).
I haven't done any more on it because I'm trying to think of elegant
ways to handle some tough issues; it's not specifically PIC-related,
so I won't waste your time with it, but if anyone wants to discuss
simulator design, I'd be glad to hear from you.
If I was hard pressed to make a minimal suggestion, I'd suggest making a
c84 with a 12 bit A/D. As you would probably use successive
approximation to perform the A/D, you could also get a D/A converter out
of the PIC as well.
By making TRISTATE sample and hold circuits as the outputs of your 8 I/O
pins, you could hook in an internal analogue multiplexor and thus offer
A/D and D/A on any of the output pins. (naturally, these could not drive
any mega level of load, but on the c84 those pins can't anyway)
That would make the c84, stumped for better words, *AWESOME*. It would
make the c84 the obvious choice for experimenters and
low intensity applications people. You could imagine the number of CRO'S
and function generators, sound effects units etc etc that would fill the
magazines if such a beasty existed.
Hey, an alternate way to do the A/D is have in input Analogue input
connected to a simple VCO, in turn fed into a counter. Hey, that's how
I did it once, and it gave me the 8khz 8 bit sample rate I needed.
But yeah, c84 with A/D and D/A all the same...
Thanks,
Regards,
Mick Kunstelj.
-------------------------------------------------------------------
Greetings and Salutations from Mick Kunstelj |If MS do make a global spamu913596spam_OUT@spam@student.canberra.edu.au |network, you should be more
|worried about a satellite
I accept no care or responsibility for anything,|landing on you than them
anywhere or anytime.... So NYAH!!!! |taking things over...
-------------------------------------------------------------------
>I'll second (or third?) that. There are a few hundred million of us
>here in Asia that can't get onto your BBS as it would cost far too
>much, but we can get onto Internet for US$120/year. I would be very
>interested in some method of gaining more information on your
>products, so some sort of Internet link or archive for your BBS
>postings would be very helpful.
>(I can't get to your BBS via Compuserve either for you eagle-eyed
Hi, folks, I am the Microchip BBS Sysop, and I have been following
this thread about Internet and BBS for some time. Let me add a few
comments here:
1. Many of you may not be aware of it, but the Microchip Boston Sales
office does sponsor a Microchip Web and ftp site.
You should be able to get latest Development software (like MPASM,
MPSIM, etc.) from these sites.
2. The term COMPUSERVE connotes an impression that Microchip customers
must belong to the Compuserve Information Service (CIS) membership to
participate in the Microchip BBS. It ain't so! Compuserve, in order
to support its CIS customers, installs a global network and offers to
make it available for lease, not unlike AT&T offering its
long-distance service. Most Microchip customers, especially overseas
like Europe and Asia, should be able to take advantage of this global
network and dial into Microchip BBS with a local phone call. The
connection procedure for overseas varies with geographical areas. If
you have problem, send me an e-mail and I'll see if I can help you
out. Remember: you don't need Compuserve membership to participate in
the Microchip BBS.
Since H&R Block, America's biggest tax preparation firm, owns
Compuserve, maybe we should suggest they change the name to H&R Block
network to eliminate the confusion :-)
3. You want internet connection, and we hear you!! :-)
>I'm designing a cheap consumer product and need to find a 500K HZ (.5 MHZ)
>timing source accurate to within 2-5%.
>
>Can anyone recommend a cheap crystal or ceramic resinator?
>
>I'd like to keep the cost under $.50 ea / 1000.
If you can go down to 455 kHz, there are cheap ceramic resonators usually
used for superhet AM radios (what's a ZF in English ?).
Otherwise - no Idea. Crystals in that range tend to be somewhat expensive,
you might perhaps use a higher freq. crystal (e.g. 4 MHz, they drop in
price at around there according to my catalogue) and a couple of flipflops
(three in that case).
>
>I'm designing a cheap consumer product and need to find a 500K HZ (.5 MHZ)
>timing source accurate to within 2-5%.
>
>Can anyone recommend a cheap crystal or ceramic resinator?
>
>I'd like to keep the cost under $.50 ea / 1000.
Digi-Key seems to be having stocking problems with the
Panasonic resonators, but they do expect to get them back
in "someday".
We just got some samples from Integrity Technology, and
haven't started testing them yet, but Scott Edwards mentioned
on comp.robotics the other day that he's been using them in
his PIC products. They're cheaper than the Panasonics by
quite a bit, but the packaging isn't quite as nice-looking
(they look kinda like a dipped cap, while the Panasonics
are molded into a more-compact block). I have their phone
# at work, but you should be able to get it from information
in the 408 area code.
> 1. Many of you may not be aware of it, but the Microchip Boston Sales
> office does sponsor a Microchip Web and ftp site.
>
> The Web site is: http://www.ultranet.com/microchip
> and ftp site is: ftp.ultranet.com/microchip.
Yes, I've looked there (I think it's ftp.ultranet.com/biz/mchip) -
unfortunately, updating the site doesn't seem to be a high priority at
the moment : the pointers to device info sheets on the web page don't
work, and the application notes in the ftp directories are incomplete
(I think the popular AN589 is still missing).
This could just reflect the state of the BBS - I haven't checked these
files on there - but I get the impression that the BBS is kept rather
more current.
On the BBS, there's an improvement that could probably be made quite
easily : the implementation of Kermit that's in use seems to be the
old-fashioned one often included in BBS file transfer suites. It's
way out of date by current standards, and upgrading to a modern version
would improve transfer speeds considerably while losing none of the
reliability for which Kermit is famous. Kermit 3.14 includes a
'kermit lite' version especially configured to provide only the functions
needed for a BBS external protocol while minimising memory usage.
>
> 3. You want internet connection, and we hear you!! :-)
>
> > I'm developing a consumer product that needs to sense the status of the
> > phone line, I.E. determine - ring, offhook, onhook.
> >
> > Anyone have a low cost solution?
> >
>
> Do you plan to get it FCC part-68 certified and do you know how
> much that certification cost? I am also planning to build a device
> to interface to the phone lines and was wondering about all the
> legalities in doing so. If anyone knows any specifics about the
> requirements, we would like to know.
Yes, we would like to know. So far I have imported 2 telephone monitors
using PIC chips from the USA to Malaysia and tried to get them
type-approved. Both of them have failed. This is a big problem because I
have friends that want similar units but I can't legally import them in
quantities if they fail the tests. Therefore I am trying to make my own &
would like to conform to International standards.
Dave
--
-------------------------------------------------------------------------
| David Baker | Internet ID (home) - RemoveMEdavidRemoveMERemoveMEbaker.pc.my |
| Electronics Engineer | Internet ID (work) - davidKILLspamspamgmetra.po.my |
| | Fax - 60-3-2612870 |
| Kuala Lumpur, Malaysia | Compuserve ID - 70461,2360 |
-------------------------------------------------------------------------
> Apparently Parallax and Microchip downloaders are very timing-sensitive in
> their operation. This list had many reports about them breaking even under
> DOS, e.g. on faster machines.
After 1.7 the MicroChip downloader stuff has been pretty solid. One advantage
of the Microchip stuff is that they use the serial port which is generally
better supported in various "Soft" PCs.
Well the 1.4 release wouldn't work at all on my ThinkPad lap top, and
the update fixed that. On the BBS they claimed they had changed the
serial support to be more generic. I know they worked under Linux
now but I've not tried them on a mac (sorry but I'm Macintosh challenged :-)
--Chuck
> problem as each pair of supply pins has 100n across them. The supply
> comes from a 78L05 and the timing is courtesy of a three terminal (4MHz)
> ceramic resonator.
> I don't know if this is relevant, but recently I ran into this:
> I have been building a PIC programmer, and I used a 7812 with
> a voltage divisor to boost the voltage slightly (to 14 V).
> _____ The voltage measured with a voltmeter
> _______| |________ looked fine, but when I looked at it
> | | | with the scope, it was 14VDC plus a 10MHz
> --+--- < oscillation with 1 Vpp amplitude. Kind of
> | > shook my confidence in 78xx parts. I suggest
> | < you look carefully for a parasitic oscillation
> | > (of course hooking scope probes could influence
> +------| what you are looking for---welcome to the
> > wonderful world of analog).
> > BTW, I ended up using LM317---works like a charm.
Hi,
You must make sure that the current in the resistor string in high enough
as well as putting decoupling capacitance on both sides of the regulator.
The oly time I had the problem you describe was with a LM723 regulator
working at 3 volts (near its limit of 2.7V) and driving a simple LED.
An LED has a funny VI characteristic and can cause funny effects in
regulators, the regulator would get very hot as well, putting the LED
before the regulator cured the problem.
--
Kalle Pihlajasaari spam_OUTkalle@spam@data.co.za
Interface Products Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750 Fax: +27 (11) 402-7751
Would you like to specify the next generation of microcontroller
development tools? Do you know emulators? Do you know programmers?
Do you know assemblers, c-compilers, fuzzy logic? Do you know how
much Microchip stock has risen in the past years?!
Does anyone know of a viable commercial system that will do speech to
text on a PC platform? Single user, connected speech, etc. i.e.
electronic dictation.
The application is to enter specifications for new PIC's incorporating
all of the ideas presented on this list!!! Thanks for the bounce
back.
______________________________ Reply Separator _________________________________
Subject: Re: Speech to Text
Author: jory bell <TakeThisOuTjoryEraseMERemoveMEMIT.EDU> at Internet_Exchange
Date: 6/3/ 0 11:02 AM
> Does anyone know of a viable commercial system that will do speech to
> text on a PC platform? Single user, connected speech, etc. i.e.
> electronic dictation.
>
> Rgds, Brian Boles. spam_OUTbbolesRemoveME.....microchip.com
What is the application? There are several of which I am aware including
Dragon Dictate, Kurzweil, IBM Power Secretary, et.
* This message contains the file 'hbridge.tif', which has been
* uuencoded. If you are using Pegasus Mail, then you can use
* the browser's eXtract function to lift the original contents
* out to a file, otherwise you will have to extract the message
* and uudecode it manually.
______________________________ Forward Header __________________________________
Subject: PWM control of 90-volt, 2.4-amp DC motor
Author: "BOWDEN; ANDREW V JR" <spamABOWDENspam_OUTSCANA.COM> at Internet_Exchange
Date: 6/16/95 11:25 AM
Hi, all.
I'm interested in controlling a 90-volt, 2.4 amp DC motor with a PIC
using PWM. This is not a servo application, just simple but precise
speed control in one direction with braking.
Unfortunately, all of the books I have seen on power supplies seem to
assume that any application over about 24 volts only requires current
in the milliamps range. Can anyone suggest a good AC to DC conversion
circuit, preferably without a transformer?
Second, can anyone suggest a proper interface circuit that will allow
the PIC to perform PWM. In other words, perhaps control of a MOSFET
that does the switching with proper protection for the PIC.
Any assistance would be eagerly and gratefully received. BTW, I have
the capability to handle attached graphics files if anyone wants to
include a schematic. :)
> I'm interested in controlling a 90-volt, 2.4 amp DC motor with a PIC
> using PWM. This is not a servo application, just simple but precise
> speed control in one direction with braking.
>
> Second, can anyone suggest a proper interface circuit that will allow
> the PIC to perform PWM. In other words, perhaps control of a MOSFET
> that does the switching with proper protection for the PIC.
I have already work on a project like that (controlling a 110V/2.8A DC
motor using PWM, but i used a PC instead of the PIC).
For the interface circuit of the H-Bridge, i used a high voltage
bridge driver from International Rectifier IR2110 (a monolithic high
voltage and high speed dual driver with independent floating rail high
side and fixed rail low side referenced output chanels). And instead of
MOSFETs I used four IGBTs (Insulated Gate Bipolar Transistors) again from
International Rectifier the IRGBC20S (600V/19A).
ARISTOTLE UNIVERSITY OF THESSALONIKI
SCHOOL OF ENGINEERING
Department of Electrical Engineering
Electronics and Computing Section
Thessaloniki Greece
------------------------------------------------------------------------------
>I'm interested in controlling a 90-volt, 2.4 amp DC motor with a PIC
>using PWM. This is not a servo application, just simple but precise
>speed control in one direction with braking.
>Unfortunately, all of the books I have seen on power supplies seem to
>assume that any application over about 24 volts only requires current
>in the milliamps range. Can anyone suggest a good AC to DC conversion
>circuit, preferably without a transformer?
I'm working on something similar, but at 12 volts. *However*, the
technique may still be applicable.
I'm using an audio power op-amp, made by SGS Thomson. TDA2040....I think.
It's a 5-lead TO-220 package, grounded tab, good for about 3 amps
continuous. They sell these things in a variety of current and voltage
ratings. Hang an RC integrator on the front end and you've got a
PWM-to-DC driver. It sources, it sinks, it's bulletproof and it's cheap!
90 volts is a little higher than I'd go with the 2040, but you might
add a couple of power transistors on the output to beef up the voltage
capability. Or, they make higher-voltage parts, though I'm not sure
how *much* higher. Or, call Apex Microtechnology...they make POWER opamps
up to kilovolts/kilowatts. Serious oomph, serious dollars.
You may want to actively drive both leads, even though you want only
one-direction rotation. Ya know how fast you can *stop* a motor by
reversing the drive current? Yow! I've got sheared keys to prove it. STOPspamforbesmspam_OUTspamBeGonepeak.org
Mark G. Forbes
"Never ascribe to malice that which can be blamed on the engineer."
> in the milliamps range. Can anyone suggest a good AC to DC conversion
> circuit, preferably without a transformer?
>
Sorry ? Could you plese explain what for (Input/Output parameters) ? At
least I didn't understand the connection of that problem with a DC motor
control (unless it's related to getting the 90 Volts DC from a 115/230 V AC
net).
> Second, can anyone suggest a proper interface circuit that will allow
> the PIC to perform PWM. In other words, perhaps control of a MOSFET
> that does the switching with proper protection for the PIC.
If you want to do breaking, you'll need some possibility of electronically
short-circuiting the motor. With a full bridge it's easy, but that requires
4 power transistor vs. 1 for a simple speed control.
For the power part: at that current/voltage I'd use a bipolar transistor.
High voltage mosfets tend to be more difficult to organize. Anyway, the
power part of this circuit (without breaking) could be: optocoupler for PIC
protection, pull-up resistor and a pnp (perhaps darlington) between motor
and positive supply. Should work, but try it beforehand.
>
> Any assistance would be eagerly and gratefully received. BTW, I have
> the capability to handle attached graphics files if anyone wants to
> include a schematic. :)
If you need one, drop me a line - I don't think we should handle schematics
on the list, but in case I talk complete gibberish, the other people here
are bound to provide some corrective feedback.
Has anyone connected any of the MAXIM serial A/D and D/A's to any
PIC, especially the 16C71. This may be a simple question but for some
reason or other I cannot get the sample code in the Embedded
Controller Handbook, the one relating to interfacing to 93Cxx series
serial EEPROM's to work. I have tried to modify the code so that I
get 12 bit data as two 8 bit bytes into memory on the PIC. I
use the code in 4 wire mode and have checked that I am using
the correct clock phase. Data output is via a 1200 bps serial
line to a PC, this works as I issue a 'G' command to start
conversion of the A/D. When completed the 16 bit value should
be returned as two 8 bit bytes. Nothing happens. I have data
and clocking on the DO and CLK lines but nary a sign of life.
I also provide an 'O xxxx' which allows me to send a 12 bit value to
a D/A, same result, NOTHING. I know the 1200 bps
serial line works as it operates in FULL DUPLEX mode. Either the
format is incorrect or I have done something gravely wrong. Any
clues would be most appreciated
Nino Benci
Monash University - Physics
Wellington Rd, Clayton.
VICTORIA. AUSTRALIA. 3168
tel - 61 3 9905 3649 fax - 61 3 9905 3637
email - spam_OUTnino.bencispamBeGonesci.monash.edu.au
************************************************************************
* Nino Benci - Chief Technical Officer * *
* Monash University - Physics * Profound message *
* Wellington Rd, Clayton. 3168 * to be inserted *
* Victoria, Australia. * in the near *
* TEL - 61 3 9905 3649, FAX - 61 3 9905 3637 * future *
* EMAIL - EraseMEnino.benciKILLspamsci.monash.edu.au * *
************************************************************************
>Hi
>
>I'm trying to design a digital noise generator. Horowitz and Hill have one
>based on a MM5437 which seems to be no longer available. However, I seem to
>recollect that someone has produced a solution based on a PIC. Can anyone
>enlighten me ??
>
>TIA
>
>Nick
>
>
There was an application note on the Parallax site that did just this.
Seems like overkill to use a pic just as a pseudo white noise generator, but
if you can't find the MM5437 then I guess it migh be the most economical.
I'm going to email you the source to keep the list traffic down.
Hope this helps.
later....carl
>Hi
>
>I'm trying to design a digital noise generator. Horowitz and Hill have one
>based on a MM5437 which seems to be no longer available. However, I seem to
>recollect that someone has produced a solution based on a PIC. Can anyone
>enlighten me ??
>
>TIA
>
>Nick
>
>
Some days ago, there appeared the following contribution to the piclist.
It describes generating pseudo noise with a PIC - see below.
As Henry Carl Ott stated earlier, it seems to be some overkill to use a PIC for
that simple algorithm. You can build up such a noise generator with some
shift registers, exor-gates and an additional or-gate, too:
Take a 16bit shift-register (or a chain of two 8bit-ters), serial in, parallel
out, connect adequate register bits to exor-gates (this is equal to
calculating the parity) and use the output (=parity) as the new input for
the shift regs. Clock the shift reg. at the desired frequency (well above
20 kHz for 'acoustic white' noise). Use one of the shift register bits as the
white noise output. If the content of the shift reg. is 00000000 00000000, then
no noise will be generated. So add an OR-gate between shift input and exor
output, to be able to start the noise generator.
Now the old message:
=========================================================================
Date: Fri, 2 Jun 1995 03:07:34 +0600
From: Mike Keitz <@spam@mkeitzEraseMEspamBEV.NET>
Subject: Re: Microchip - Shift-Registers - Suggestion
[deleted]
Here's my first crack at a chip generator, with speed as the only priority.
This should make a lot of noise on Port B, using the standard {17,14} sequence.
; Spread Spectrum sequence generator.
; Implements a 17-stage shift register with feedback from the 14th and 17th
; stages. 8 bits of the shift register are output to port B, which must be set
; as all output. Any one pin of Port B will output the PN sequence.
start
movlw 0
tris PORT_B ;Make B all output.
movlw 1 ;Constant used since C is bit 0 of status reg.
movwf srgl ;If SR contains all 0's, generator will jam.
pnlp
rlf srgl,1
rlf PORT_B,1
btfsc PORT_B,6 ;14th bit. If it is 1,
xorwf srgl,1 ;invert the new bit.
goto pnlp
This takes 6 cycles per chip, so it should belt out 833.333 Kchips/sec with
a 20 MHz clock. I think there may be a way to re-write it to 5 instructions
per chip, but I'll leave that for someone else. Considering that three
discrete IC's costing about $0.50 could do the same job at 50 MHz, it is not
a very good application for a PIC. But the concept is there anyway. The
PIC is fast and smart. Discrete logic, FPGAs, etc. are VERY fast but dumb.
Making spread spectrum chips is a "dumb" process.
[...]
Disclaimer: All code examples are untested and may contain minor or major
bugs. Use this information at your own risk. I do NOT work for Microchip
or have any association with them other than as a customer.
>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'm working on my first PIC project. From the samples in the Parallax
documentation, I've been able to hack out enough to get by. However,
I can't find any references on the RC oscillator. Is there a simple
formula for component selection? Anything else I should be aware of?
I would like to thank all those that have helped me with connecting
MAXIM serial A/D's and D/A's to PICs. You know who you are. I have
succeeded in interfacing a MAX176 A/D and a MAX538 D/A to a PIC16C71.
The cct and code work in a basic loop test, confirmation of operation.
I am therefore posting this message to inform all that if you would
like a copy of the files, MAX176.ASM, adapted from 3WIRE.ASM and
MAX1.TIF, the scanned test schematic please feel free to email me
for these.
Once again, muchos gracias....
Nino Benci.
PS: Could I post these to the the MChip ftp site for all to access.
************************************************************************
* Antonio (Nino) Benci * *
* Chief Technical Officer * *
* Monash University - Dept of Physics * I think *
* Wellington Rd, Clayton. 3168 * Therefore I am *
* Victoria, Australia. * I eat *
* TEL - 61 3 9905 3649, FAX - 61 3 9905 3637 * Therefore I excrete *
* EMAIL - @spam@nino.benciSTOPspamsci.monash.edu.au * *
************************************************************************
>I'm working on my first PIC project. From the samples in the Parallax
>documentation, I've been able to hack out enough to get by. However,
>I can't find any references on the RC oscillator. Is there a simple
>formula for component selection? Anything else I should be aware of?
>
>Thanks...
>
>
I had the same problem with the Parallax documentation. Here is the table I
found in the Microchip Data Book.
From the desk of Karl Grabe 7/13/95
#240# CIM
SUBJECT: Macintosh and PickStart 16b/c
I'm posting this thread for anyone out there who'd like to use PickStart 16B
and 16C with a Macintosh running SoftPC. I've verified it works with a
PowerBook 180 and PicSTart 16B while Otmar has verified 16C with a mac.
Cable connections are included below. It should work with most Macs that are
as fast as a PB180
-Karl
*** Thread follows:
Hi Karl,
Thank You! It works well!
Here's what I found...
It only works on my PB180 with Soft AT only when most of the extensions are
off.
It works on a Power PC running Soft windows (Native) in dos mode with all
the extensions on.
It won't work on my Duo 230 with Soft AT at all. :-(
I find I'm still not totally clear on which pins are what but if it's wrong
I just flip it. I think the apple modem tool is correct if you use it to
look at the open end of the female on the picstart, or printer or whatever.
I found that a female DIN8 packages nice in a 9 pin D-sub cover. Just fill
it with hot glue. Makes a cute short adapter.
Thank you so much for the tip. Can I distribute it freely?
>Hi Otmar,
>I've looked at your setup and there are a few differences see my setup below.
>Note pins 6 & 7 on the DB9!
>Also you are correct about the apple modem tool diagram being slighly wrong.
>
>
>Macintosh DIN8 PicStart DB9
>
>Pin# Pin#
>1 Hsko.................4 Data Ready
>2 Hski.................8 RTS
>3 Txd-.................3 Rx
>4 Gnd..................5 Gnd
>5 Rxd-.................2 Tx
>6 Txd+ (n/c)
>7 Gpi (n/c)
>8 Rxd+.................5 gnd (see note below)
>
>
>Remaining DB9 Pins:
>1 (n/c)
>6 (+5v) connected to 7 (CTS)
>
>Notes:
>Pins connected together on DIN connector: 8 (Rxd+) and 4 (Gnd)
>Pins connected together on PC DB9 connector: 6 (+5v) and 7 (CTS).
>
>Let me know if you get this working and we could let other Mac users know via
>the picklist or bbs.
>-Karl
-Otmar-
-----------------------------------------------------------------------
Electric Vehicle Components Ltd.
It's often said that life is strange, But compared to what? sf
Otmar Ebenhoech TakeThisOuTtessTakeThisOuTRemoveMEnetcom.com (415) 494-9255
-----------------------------------------------------------------------
I'm using a MAX232 RS232 <--> TTL converter to connect a PC,
a PIC, and an 8051.
Communication paths are as follows:
PC <--> 8051 <--> PIC
The 8051 I'm using has 1 UART which is used for both communication
paths (ie I could implement the serial communications
in software for one communication path and use the UART for the
other, and this would alleviate my problem).
PROBLEM:
========
The MAX232 does not have open collector o/p's (Please correct me if
I'm wrong but I checked the MAXIM '95 New Releases Data Book and saw
no reference to same). Therefore, the PIC can't transmit to the 8051
because the MAX232 is forcing the line high when not transmitting.
POSSIBLE SOLUTION 1?:
=====================
To overcome this problem, I came up with the following:
When MAX232 o/p is low, Diode conducts => TxOut is at 0.7V = Logic 0
o/p is high, Diode doesn't conduct => TxOut is pulled up
to 5V.
I'd like to here comments / criticisms on this work-around or others
like it. I tested it at 9600 Baud and it seems to work fine.
POSSIBLE SOLUTION 2?:
=====================
There is a MAX232 version which does the following:
"Driver outputs turn off and enter a high-impedance state....
when in shutdown mode, in three-state mode, or when device
power is removed." Receivers remain active in shut down mode.
Problem is, I want to have one driver o/p permanently active
so shutting down the chip to facilitate communication is not
feasible.
ASIDE: (another open collector workaround)
======
Also, with the PIC (type 16C71), RA4, the open collector output was
unavailable, so I had to use another pin as the TX pin.
In order not to interfere with the PC <--> 8051 communication I
configured the tx pin as an i/p when not transmitting (interrupts
disabled). This too worked fine. This one didn't occur to me instantly,
but then, as an Irish man, given a box of 8032's and 6811's
I'd still go for the PIC!
> PROBLEM BACKGROUND:
> ===================
>
> I'm using a MAX232 RS232 <--> TTL converter to connect a PC,
> a PIC, and an 8051.
> Communication paths are as follows:
>
> PC <--> 8051 <--> PIC
>
> The 8051 I'm using has 1 UART which is used for both communication
> paths (ie I could implement the serial communications
> in software for one communication path and use the UART for the
> other, and this would alleviate my problem).
>
>
> PC / MAX232 8051 PIC
> TX RX RX TX TX RX
> ____________ _____________ ___________
> | | | | | |
> | | | | | |
> | ------------------------|-----*--------------------------
>
> | | |
> ------------------------------*--------------------------
>
>
> PROBLEM:
> ========
> The MAX232 does not have open collector o/p's (Please correct me if
> I'm wrong but I checked the MAXIM '95 New Releases Data Book and saw
> no reference to same). Therefore, the PIC can't transmit to the 8051
> because the MAX232 is forcing the line high when not transmitting.
>
>
> POSSIBLE SOLUTION 1?:
> =====================
> To overcome this problem, I came up with the following:
>
> +5v
> ___
> |
> | |
> |\ | |
> | \ |/| |
> ----| O---------| |----------------- TxOut
> | / |\|
> |/
> Max232 Diode Pullup
> inverter Resistor
>
>
> When MAX232 o/p is low, Diode conducts => TxOut is at 0.7V = Logic 0
> o/p is high, Diode doesn't conduct => TxOut is pulled up
> to 5V.
> I'd like to here comments / criticisms on this work-around or others
> like it. I tested it at 9600 Baud and it seems to work fine.
>
Well, TxOut(LOW) is the diode drop plus the VOL of the MAX232. Worst
case, you've probably blown your noise margin. If this is just
a onesy-twosy circuit that isn't intended for production, you can
usually get away with it. I wouldn't use this kind of kludge in a
production board, 'tho.
> POSSIBLE SOLUTION 2?:
> =====================
> There is a MAX232 version which does the following:
> "Driver outputs turn off and enter a high-impedance state....
> when in shutdown mode, in three-state mode, or when device
> power is removed." Receivers remain active in shut down mode.
> Problem is, I want to have one driver o/p permanently active
> so shutting down the chip to facilitate communication is not
> feasible.
>
Well, depending on how the MAX232 three-state mode works, I'd
consider that the best possibility. Why do you care if all drivers
are off? As long as you have a pull-up or -down (depending on how
you want your inactive line to float), you should be fine.
Alternatively, you could rig your own OC output using a cheap
switching transistor (2N2222 equiv), a base resistor, and a pull-up
resistor. Depending on how the numbers work out, you might be able to
even ditch the base resistor.
Till now, I have succedeed in finding
"hextofab" but it's not really what
I am searching for.
I have heard say that this program could
come from microchip technologies.
If one of you has got it or knows a
BBS/Internet Site where I could find it,
could you please tell it to me by
E-Mail.
If possible, I would be rather
interested by a UUEncoded version of
it sent to me by e-mail.
>Hi all,
>
> I have an interesting challenge. I am using a 16C57 to drive a
>nitinol wire actuator with PWM. The drive goes to multiple actuator and
>as it turns out I need a whopping current to drive them. I am lifting
>something heavy. Each takes 6 amps average. Everything was going along
>happy (in denial) until I started to purchase the power supply to provide
>the current.
>
> Now I am wondering if any of you have experience with sourcing
>PWM current from an un-regulated supply. I am thinking that maybe I can
>simply step down the ac line, full wave rectify it, and synch my PIC PWM
>timing to the zero crossing. I use IRF520 MOSFETs to switch the current.
>This would insure that my driving waveform would be uniform for each cycle.
>I do not believe that having a non-DC source current is any problem. After
>all, I am only heating wire.
>
> Also how about some clever (meaning cheap/simple) ideas for PIC
>sense zero crossing from the transformer secondary.
>
Use a full-wave rectifier to develop a bus having positive half-cycles of AC
(i.e. 120 Hz pulses). The transformer and diodes have to be rated for the
sum of the current through all the wires that will be heated at the same
time. Connect one end of all the wires to this bus, and the other end to
the anode of a SCR that controls that wire. The cathodes of the SCRs go to
ground, and the gates are driven by the PIC through resistors (as if they
were NPN transistor bases). About any SCR will work, for example the S2006L
(about $1.20 each in Digi-Key catalog) will switch 6A RMS and turn on with
15 mA of gate current. If you're driving multiple wires from each channel,
70 Amp SCRs are available (about $7.00), but you'll need to add a driver
transistor (emitter follower from PIC pin, with collector on 5V bus) to
supply the 50 mA gate current required.
The SCRs will turn on when positive gate voltage is applied, and turn off
during the zero-crossings of the bus voltage. If you want on/off control
with 1/120 second resolution, synchronizing is unnecessary. Just leave the
gate drive on while the wire is to heat up, and turn it off when not. If
proportional control is required, synchronize the PIC with a zero-crossing
voltage derived from the bus (by comparing when the bus voltage rises above
1V or so), and generate a delayed pulse for the gate. The more delay of
course, the less power will be applied. But the relation between phase
delay to power is not linear (think of integrating the sine squared
function), easily corrected with a table if required.
As far as conditioning the bus voltage for the PIC, it could be simply
applied to RTCC through a suitably large resistor to limit the current to
<500 uA when the protection diode clamps the pin voltage to 5V. Loading the
bus with a resistor to ensure that it does return to 0V at each half-cycle
would be a good idea. The turn-on point would be about 3V. If earlier
detection is required, a more sophisticated voltage comparator, for example
driving the base of an NPN transistor and using the collector with a pull-up
to 5V, would switch on while the bus voltage is more than 1V or so.
> > Now I am wondering if any of you have experience with sourcing
> >PWM current from an un-regulated supply. I am thinking that maybe I can
> >simply step down the ac line, full wave rectify it, and synch my PIC PWM
> >timing to the zero crossing. I use IRF520 MOSFETs to switch the current.
> >This would insure that my driving waveform would be uniform for each cycle.
> >I do not believe that having a non-DC source current is any problem. After
> >all, I am only heating wire.
I'm wondering - why not just use a triac and NOT convert to DC? Yes, you need
to sense the zero crossing. It's EASY! Just add one resistor. The app.
notes show you how.
>>how about some clever (meaning cheap/simple) ideas for PIC
>>sense zero crossing from the transformer secondary.
AN521, "Interfacing to AC PowerLines"
works like a charm. I have 2 projects where I did just that and they
have been working fine for over a year.
The only real reason to sync to zero cross is if you are using SCR or
Triac as the current switch.
Then you let the zero cross turn off the device.
If you are using MOSFETs, then you can turn them off anytime.
So, set the PWM frequency much higher than 60 Hz and don't worry about
sync.
This does not take into account switching transient noise if that is a
concern.
Thanks all for the suggestions. I am curious about Gary Skinner's
suggestion. How much higher than 60Hz is "much higher"? I do a single PWM
control loop that drives 8 separate actuators. They all function with the
same master cycle. All turn on at the same time and I just toggle the bit
for each off when the time for that one runs out. The 20MHz PIC is doing
about 230Hz at best the last I checked. Is that fast enough to avoid some
sort of beat frequency effect?
> >>how about some clever (meaning cheap/simple) ideas for PIC
> >>sense zero crossing from the transformer secondary.
>
> AN521, "Interfacing to AC PowerLines"
> works like a charm. I have 2 projects where I did just that and they
> have been working fine for over a year.
>
> The only real reason to sync to zero cross is if you are using SCR or
> Triac as the current switch.
> Then you let the zero cross turn off the device.
> If you are using MOSFETs, then you can turn them off anytime.
> So, set the PWM frequency much higher than 60 Hz and don't worry about
> sync.
> This does not take into account switching transient noise if that is a
> concern.
>
> Hope this helps, Gary Skinner, ESI
>
Martin writes:
ML> Thanks all for the suggestions. I am curious about Gary Skinner's
ML>suggestion. How much higher than 60Hz is "much higher"? I do a single PWM
ML>control loop that drives 8 separate actuators. They all function with the
ML>same master cycle. All turn on at the same time and I just toggle the bit
ML>for each off when the time for that one runs out. The 20MHz PIC is doing
ML>about 230Hz at best the last I checked. Is that fast enough to avoid some
ML>sort of beat frequency effect?
I don't really know exactly what much higher means.
The PWM is chopping up the sinewave into pulses. If it chopped up each
cycle into at least 3 or 4
pieces, then there should not be any "beat frequency" type of problems.
I suppose you could do a lot of math and verify some results, but I
would probably build a
simple device and measure the RMS output as a function of PWM on/off
ratio.
I expect it will be pretty linear with 230Hz period.
Please let us all know how the experiment works out.
>I'm in the middle of a project using a 16C64. However, I'm finding that
>the Parallax simulator isn't able to properly handle the '64; in
>particular, the additional I/O pins.
>
>Is there an up-to-date PIC simulator that can properly handle the '64?
Paul:
Of course.
Microchip's own MPSIM handles every one of the PIC microcontrollers. The
user interface is pretty awkward (at present, anyway), but the simulation
is completely accurate.
One thing you may want to look out for: MPSIM expects to find its symbol
tables in a ".COD" file; if you're assembling your code with anything
other than MPASM (but then, why would you?), the simulator won't be able
to use your symbols.
-> The only real reason to sync to zero cross is if you are using SCR or
-> Triac as the current switch.
Sorry to butt in here Gary...
The main reason to sync to the zero crossing is to minimize in-rush
current and its resulting EMI. Connecting the load to the mains while at
peak voltage results in a high dI/dT surge that many loads don't
appreciate. As well, EMI emanations will abound up into the MHZ region.
An inductive load just complicates this even further.
This is one of the reasons one can't (or shoudn't) use a dimmer switch
with an inductive load.
Ceramic resonators come in 2 types -
2 pin and 3 pin with built in capacitors
In general low frequency 2 pin is 150KHz
to a high of 1.5MHz
each extreme adds to cost.
In this range, 455KHz is probably lowest cost.
then another type covers 1.5M to 25 or 50MHz
available in 2 or 3 pin.
Again, the extremes cost the most.
4MHz is pretty inexpensive
I think both styles come in SMT but I'm not sure of cost.
Available from 4 main companies that I know of:
Integrity Technology 408-262-8640
least cost, only deals in large quantities (5000 or so)
I saw that there is a low quantity "dealer" in Canada
AVX/Kyocera 803-448-9411
4MHz with caps is KBR4.00MKS
I get these through Kent Elec. for $.26 in 100s
455KHz without caps is KBR455HKTS
I get these through Kent Elec. for $.20 in 100s
MuRata 404-436-3030
about .35 for equiv 4MHz part
Panasonic most expensive, available through Digi-Key (800-digikey)
.58 in 100s
You wrote:
>
>Where can I get ceramic resonators for the PICs? I want to try the
sine
>wave program in the Parallax documentation, and it calls for an 8 MHz
>ceramic resonator.
>
There are two companies that I know of that make Ceramic Resonators
1) Murata Eri 1-800-831-9172
2) Avx Kyocera I got this name through a distributor
At 06:10 PM 8/6/95 EDT, you wrote:
>I'm in the middle of a project using a 16C64. However, I'm finding that
>the Parallax simulator isn't able to properly handle the '64; in
>particular, the additional I/O pins.
>
>Is there an up-to-date PIC simulator that can properly handle the '64?
>
PSIM only has support for the 5x, 71 and 84 parts only. We have chosen not
to continue simulation support with the newer/other parts. They are
becoming more complex and simulation is not always feasible, ICE (emulation)
is the way to go.
_/_/_/_/_/ _/_/_/_/_/ _/_/_/_/_/ _/_/_/_/_/ Take care -Jim Hobbs
_/ _/ _/ _/ _/
_/ _/_/_/_/_/ _/_/_/_/_/ _/_/_/_/_/ Solid....wood!
_/ _/ _/ _/
_/_/_/ _/_/_/_/_/ _/_/_/_/_/ _/ Getting off never felt sooo good.
>I HAVE THE FOLLOWING
>
>
>ROW1 MOVLW 0x04 ;NO OF DATA BYTES TO SEND
> MOVWF COUNT2 ;PUT INTO COUNT2
>REP MOVF COUNT2,W ;W NOW ALSO CONTAINS TABLE POINTER
> CALL LCDROW1 ;GET DATA FOR LCD DISPLAY
> MOVWF LCDDATA ;PUT IN FILE USED BY SENDLCD
> CALL SENDLCD ;GO AND PUT IT ON THE LCD DISPLAY
> DECFSZ COUNT2 ;DEC NO OF INSTRUCTIONS AND TABLE POINTER
> GOTO REP ;IF NOT ZERO REPEAT ABOVE
> ;ZERO CONTINUE WITH SOMETHING ELSE
>
>LCDROW1 ADDWF PCL,F ADD OFFSET TO PROGRAM COUNTER
> RETLW ' '
> RETLW 'L'
> RETLW 'O'
> RETLW 'A'
> RETLW 'D'
What you have, Kenny, is code that'll display "DAOL " on the
display.
>I NEED TO REPEAT THE ABOVE BLOCK AS MANY TIMES AS I HAVE LOOKUP TABLES
>
>IS THERE ANY WAY, OF TURNING IT INTO A UNIVERSAL CALL ROUTINE, I
>COULD PRE LOAD THE COUNT2 FILE BEFORE THE CALL IS MADE, BUT IS THERE
>ANY WAY OF GETTING AROUND THE 'CALL LCDROW1'. THE 'LCDROW1' BEING THE
>ONLY VARIABLE IN THE ROUTINE.
Don't forget that the "MOVLW 0x04" is another variable for which
you'll have to account.
>IS THERE A WAY
>.
>.
>.
>.
>.
>.
>.
>.
>.
>.
>I've seen things you people wouldn't believe.
>Attack ships on fire off the sholder of Orion.
>I watched C-beams glitter in the darkness at Tan Hauser Gate.
>All those moments will be lost in time,
>like tears in rain.
>Time to die.
>
>Remember now, watch out for the Fairies......!
I wish I knew why your signature annoys me so damned much... When I
figure it out, I'll let you know.
On Fri, 4 Aug 1995 00:30:08 +0600, Mike Keitz <STOPspammkeitz.....BEV.NET> wrote:
> As far as conditioning the bus voltage for the PIC, it could be simply
> applied to RTCC through a suitably large resistor to limit the current to
> <500 uA when the protection diode clamps the pin voltage to 5V. Loading the
Note that the RTCC pin does not have an internal protection diode (to the
postive supply rail) as most of the other pins have. You will need to add
the diode externally, as shown in Microchip application note AN521.
I created a translator from Parallax assembly to microchip assembly.
It keeps all the comments. The Parallax psuedo ops are translated into
their microchip equivilants. Anyone interested in beta testing it? I
can mail you uuencoded file.
Aaron Wohl / ham callsign N3LIW / 412-731-3691 / 412-268-5032
-> IS THERE ANY WAY, OF TURNING IT INTO A UNIVERSAL CALL ROUTINE, I
-> COULD PRE LOAD THE COUNT2 FILE BEFORE THE CALL IS MADE, BUT IS THERE
-> ANY WAY OF GETTING AROUND THE 'CALL LCDROW1'. THE 'LCDROW1' BEING THE
-> ONLY VARIABLE IN THE ROUTINE.
The technique I use is:
1) Concatenate all output messages into one lookup table.
2) Delimit all output messages with a unique byte values, such as 00h.
3) Stuff the offset of the message in the table into COUNT2 before
calling the output routine.
4) The output routine should read the table element, test it for 00h,
and then exit if a match occurs. Otherwise send the element and
repeat.
The above method has an advantage in that if you have two messages, say
LFCRLF and CRLF, then you can simply supply LFCRLF<Delim> and index
to either the start (for LFCRLF) or the start+1 (for CRLF).
Another method may be used: CALLing a routine specified by a variable.
This one requires care however.
>The technique I use is:
>
>1) Concatenate all output messages into one lookup table.
>2) Delimit all output messages with a unique byte values, such as
> 00h.
>
> [etc...]
Dana:
Someone else suggested this technique as well. I didn't respond at
the time, but now that there are TWO of you advising this...
There's a very specific reason that the code I posted doesn't use
delimiters: The LCD displays that are the subject of this thread use
"00" to represent one of their 8 custom characters. "01" through "07"
are used, as well. This would appear to leave "08" through "1F" as
valid choices for delimiters, but those values are often stored in
lookup tables as well, and used to DEFINE custom characters.
If you're careful, you can use delimiters with no problems, but your
code will be a little more "bulletproof" (and just as efficient) if you
use a method like the one I posted.
>>I created a translator from Parallax assembly to microchip assembly.
>>Anyone interested in beta testing it? I
>
>Yes, I'm very interested !
>
>Regards
> Erik
>
--------------
Me Too!
Ciao,
Claus Kuehnel spamkuehnelspamspamdial.eunet.ch
Someone asked, "I'm reading four 4-bit BCD switches, and I need to
convert the numbers I get to one 16-bit binary number. I tried the
Microchip BCD-to-Binary appnote, but it didn't work."
I don't remember who it was, but he later posted the same question to
Parallax's "STAMPS" mailing list, so he must really be desperate.
Ok...
I don't know why Microchip's appnote didn't work for you... Those math
appnotes are abysmally slow, but I don't think any of them are WRONG.
In any case, your problem can probably be solved by the following code.
I say "probably" because I haven't tested (or even assembled) it; I
just wrote it on-line. I'm sure that if there are any errors, you and
I will both hear about them soon enough.
The code is a couple bytes longer than what's in the Microchip appnote,
but it's about 4 times faster. It also uses only one extra register,
instead of Microchip's 4, and doesn't eat up any subroutine stack
space.
The code assumes that your four 4-bit values are stored in registers
named "THOU", "HUND", "TENS", and "ONES". It also assumes that you've
defined a register named "TEMP".
It stores the 16-bit result in THOU:HUND (hi-byte in THOU, lo-byte in
HUND), and thoroughly scrambles the other three registers. If you need
to remember the original values, copy them elsewhere before you execute
this code.
;
; Four-Digit BCD to 2-Byte Binary Converter, written by Andy Warren.
; (C) 1995 Fast Forward Engineering. All right reserved.
;
; Permission is hereby granted for any non-commercial use, so long as
; this copyright notice remains intact.
;
; Enter with four-digit BCD value in THOU, HUND, TENS, and ONES.
; Exits with 16-bit result in THOU (hi-byte) and HUND (lo-byte); TENS,
; ONES, and TEMP are scrambled.
-> There's a very specific reason that the code I posted doesn't use
-> delimiters: The LCD displays that are the subject of this thread use
Thanks for your comments Andy. Actually, both techniques (strings
proceeded by a size byte, as used by DOS, and delimited strings) are
valid and have been used since the beginning of computing itself. Each
has its advantages and disadvantages. Both require a table read, an
index advance, a compare, and loop for each value. Both can be used to
concatenate strings together by two CALLS if the DISPLAY routine returns
the pre-advanced index in W.
However, the delimited method allows trailing substrings to be
transmitted so long as at least one value out of 256 is available as
EOS.
The sized approach has the advantage that leading substrings may be
transmitted if the DISPLAY routine has a second entry point (after size
byte read) and the caller preloads the size before calling DISPLAY.
I tend to use delimited strings for text, but have also used sized
strings (even in C!) when dealing with binary communications.
BTW thank you for your efforts to resolve the interrupts during ADDWF
PCL issue.
Tried calling (505)821-1945 collect today (16-Aug-95); it now has Telco
VoiceMail with a slick ``if you want the blueprints'' message; the collect
call then flops over to a real operator at that point. I suppose Telco
VoiceMessaging may have many megabytes of compressed storage, so we're only
burdening the Telco if we try to spam this number. (Still, Telco may go to
Jeff Slaton with, ``Solve your problems, and then we can do business with
you.'' But I doubt that.)
Information for Albuquerque lists a Jeff Slaton at (505)822-8919; this
number answers with a female voice on an answering machine; no idea if this
is the same cad.
If ever we could use a favor from 2600/MOD/LOD hackers, it seems like now.
Peter F. Klammer spamBeGonePKlammerACM.Org
w:(303)773-7411 h:(303)233-9485 EEPROM: mere bridge techology to FRAM
11221 West 27th Place Learn about League for Programming Freedom!
Lakewood, Colorado 80215 by sending email to: EraseMElpfEraseMEuunet.uu.net
>However, the delimited method allows trailing substrings to be
>transmitted so long as at least one value out of 256 is available as
>EOS.
You're right... This IS an advantage. In fact, I usually use
delimited strings, too; it just happens that I'm in the middle of a
project that displays text strings on a Hitachi LCD, and my code
broke as soon as I put custom characters in the strings.
>BTW thank you for your efforts to resolve the interrupts during ADDWF
>PCL issue.
>In any case, your problem can probably be solved by the following code.
>I say "probably" because I haven't tested (or even assembled) it; I
>just wrote it on-line. I'm sure that if there are any errors, you and
>I will both hear about them soon enough.
... and then I posted a BCD-to-Binary converter with a major bug. Duh.
This one should work. Again, I haven't assembled and tested it, but I
HAVE spent more than a couple minutes thinking about it, so already it's
got more going for it than the version I posted last night. Also, I moved
the comments around so that they'll make a little more sense to anyone
trying to understand how the code works. In this version, a comment like
"W = TENS*4" means that AS SOON AS THE LINE WITH THE COMMENT IS EXECUTED,
W will hold TENS' original value times 4; in the previous version, the
same comment meant that the following code, UNTIL THE NEXT COMMENT, worked
to fill W with TENS' original value times 4.
Ok... Here's version 2 (don't you wish Microsoft would find, admit to, and
fix bugs this quickly?):
;
; Four-Digit BCD to 2-Byte Binary Converter (version 2),
; written by Andy Warren.
;
; (C) 1995 Fast Forward Engineering. All right reserved.
;
; Permission is hereby granted for any non-commercial use, so long as
; this copyright notice remains intact.
;
; Enter with four-digit BCD value in THOU, HUND, TENS, and ONES.
; Exits with 16-bit result in THOU (hi-byte) and HUND (lo-byte); TENS,
; ONES, and TEMP are scrambled.
BCD2BIN:
CLRC ;------------------------
RLF TENS,W ;W = TENS*2. ;
MOVWF TEMP ; ; By the way, this
RLF TEMP,W ;W = TENS*4. ;-- is a pretty good
ADDWF TENS ;TENS = TENS*5. ; 2-digit BCD to
RLF TENS ;TENS = TENS*10. ; binary converter
ADDWF ONES ;ONES = TENS*10 + ONES. ; by itself...
;------------------------
Andrew Warren:
> You're right... This IS an advantage. In fact, I usually use
> delimited strings, too; it just happens that I'm in the middle of a
> project that displays text strings on a Hitachi LCD, and my code
> broke as soon as I put custom characters in the strings.
At least the LCDs that I have used have the 8 user-defined
characters both in 0..7 and 8..15, so it would still be
possible to use zero as a delimiter.
I'm in Albuquerque. I'll happily cruise by his house and/or call the
numbers if you think I can do some good. Actually I had thought about
making a video of me going to his door and offering to sell him some
spam, then putting it up on the web.
Your message to the piclist about videotaping your visit
to the spammer's door really gave me a good laugh. New
England (and elsewhere east of Mississippi) is suffering
from unusually hot and *HUMID*
weather, so I enjoyed the humor. Good idea, too!
There has been a lot of discussion about BCD to Binary recently, but how
bout the other way. The "Embedded Control Handbook", page 5-120 has a
16 bit to BCD listing but can take up to 885 clock cycles. Anything more
efficient out there? I need only a 10 bit to BCD routine (actually up to
999 ).
Okay. I've sent a SIGNOFF PICLIST message to the listserv about a
half-dozen times now. The first time, I got a response that my address
didn't match; the other 5 times I've gotten nothing.
The listserv won't let me REVIEW PICLIST so that I can tell what address
it really wants, either. I've tried e-mailing the supposed owner of the
list, and have heard nothing.
Will someone *please* get me off of this list?
Thanks,
Jorj
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jorj Bauer | gbauerspam@spam@eniac.seas.upenn.edu
CETS Network Operations | 200 S. 33rd St.
School of Engineering and Applied Science | Moore Building, Room 166-A
University of Pennsylvania | Philadelphia, PA 19104 http://binky.seas.upenn.edu/~gbauer | (215) 898-0575
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> There has been a lot of discussion about BCD to Binary recently, but how
> bout the other way. The "Embedded Control Handbook", page 5-120 has a
> 16 bit to BCD listing but can take up to 885 clock cycles. Anything more
> efficient out there? I need only a 10 bit to BCD routine (actually up to
> 999 ).
> Ross Lyle
> Victoria, BC <--- hey, that's where my sisters live!
Well, I did a binary to bcd routine that handled up to 512. You could
modify it to do 1024 without too much trouble, I suppose. I used the
fact that x / 100 = (x/2) / 50, much like the BCD->binary routines.
Using (x/4) / 25 to generate the hundreds digit will allow eight bit
subtractive calculation. Then you calculate (x/4 mod 25) * 4 + (x mod 4 )
and count the tens, leaving the ones. I wasn't concerned about time
of execution, a millisecond wasn't a problem for me. I was concerned
about RAM/ROM usage.
>I'm in Albuquerque. I'll happily cruise by his house and/or call the
>numbers if you think I can do some good. Actually I had thought about
>making a video of me going to his door and offering to sell him some
>spam, then putting it up on the web.
Go for it. "There is nothing illegal" about selling SPAM door-to-door.
He should get the point.
They suck, they are the scum of society... They annoy me greatly.
Our problem is thus: Once they get busted, the simply move to another site.
What we should do is find the system administrators of each site,
send them a message telling them to dissallow Slaton etc, and give them
a copy of the barred user list.
The punishment for letting a spammer on would be to have core dumps sent
to the site, garbage, nettiquite messages, re-postings of the
information. ie we spam the entire site continously. This would hurt
any site that for whatever reason *fell out of line*.
What we need is a federation of people who are willing to guard, post
and anti-spam as needed. One person can not do it, as all messages from
a prticular person can be barred from a site, thus you'll need a few
people. (the more the better).
What do you guys think?????
Catcha,
Mick.
--------------------------------------------------------------------------
Greetings and Salutations from Mick Kunstelj |MS - It took them 15 years @spam@u913596student.canberra.edu.au |to make a 20 bit OS almost
|work correctly...
I accept no care or responsibility for |--------------------------
anything, anywhere or anytime.... So NYAH!!!! |Windoze95 - Loser friendly
--------------------------------------------------------------------------
MS...Making "Hello World!" programs require 5 Meg & three hours to execute.4U
--------------------------------------------------------------------------
I am currently a user of the parallax assemblers pasm and pasmx. While I
enjoy using them they have constraints (No macros ,conditional asssembly etc
). I plan to move to the Microchip assembler on my next project.
Has anybody produced a FAQ on the mchip assembler. Printing out the
usrguide.txt resulted in a 90 page document
I would like the learning curve to be as steep and SHORT as possible does
any one out there have advice on the best way to make the transition without
too much pain :-)
Recently someone was offering a program to convert parallax to mpasm is this
available from an ftp site.
Thanks Ian
-------------------------------------------------------------------
Sender Ian Smart
Location Electronic Structure Of Materials Centre
Flinders University Adelaide Australia
Email ian.smartRemoveMEcc.flinders.edu.au
-------------------------------------------------------------------
When the PIC16C74 is in sleep mode, OSC1 is disabled (therefore the
internal clock). To wake up the processor, there must be a WDT timeout, or
an external event must be provided (either a change on portb or a clock to
the other peripherals, etc.). The A/D interrupt will not wake up the
processor. If your were trying to use the A/D interrupt to wake up the
processor, hopefully this will shine some light on the situation.
>
>The microchip opcodes mostly take a direction bit.
>
>The direction bit takes some getting used to. For example: incf reg,1
>increments register reg. While incf reg,0 moves reg+1 to w.
While we are on this topic what it the easiest way to convert
Actually, the key is to be sure that the A/D clock source is RC. This
will allow the A/D interrupt to wake up the part when conversion is
complete. If the A/D clock source is Fosc/n, the A/D will stop when
sleeping and not wake up.
Also, if the GIE bit is disabled when the A/D conversion starts, the
part will continue with program execution after the sleep instruction
as opposed to vectoring to the interrupt routine if GIE is enabled.
Rgds, Brian.
______________________________ Reply Separator _________________________________
Subject: Reply to A/D Sleep Mode
Author: pic microcontroller discussion list
<PICLIST%spam_OUTMITVMA.BITNET@spam@RemoveMEPSUVM.PSU.EDU> at internet
Date: 8/22/95 9:51 AM
Norman,
When the PIC16C74 is in sleep mode, OSC1 is disabled (therefore the
internal clock). To wake up the processor, there must be a WDT timeout, or
an external event must be provided (either a change on portb or a clock to
the other peripherals, etc.). The A/D interrupt will not wake up the
processor. If your were trying to use the A/D interrupt to wake up the
processor, hopefully this will shine some light on the situation.
> While we are on this topic what it the easiest way to convert
> movb serial_out,c ; moves carry bit to portb pin2
...
> BTFSC status,carry
> BSF portb,pin2
> BTFSS status,carry
> BCF portb,pin2
That's a good way to do it if you can't have glitches on the output.
If glitches aren't a problem you can use this code with is one cycle faster:
BCF portb,pin2
BTFSC status,carry
BSF portb,pin2
In this code, if pin2 was already high, and the status was set, there would be
a two instruction cycle low glitch on pin2.
Sometimes I find it necessary in extremely time to make sure that the
transition occurs on a particular cycle regardless of the direction of the
transition. In such cases I use code like:
Note that in any of these methods (even using BCF/BSF on portb directly)
there can be problems if port B has any pins configure as outputs that don't
read the same as the output latches due to external loading.
>I plan to move to the Microchip assembler on my next project.
>Has anybody produced a FAQ on the mchip assembler. Printing out the
>usrguide.txt resulted in a 90 page document
Ian:
Get a copy of the "Microchip MPASM Assembler User's Guide" (document
number DS33014C) from your local Microchip rep.
>While we are on this topic what it the easiest way to convert
>movb serial_out,c ; moves carry bit to portb pin2
>
>The best I could come up with was
>
>BTFSC status,carry
>BSF portb,pin2
>BTFSS status,carry
>BCF portb,pin2
Martin:
Eric Smith (who really knows what he's doing) has already given a very
good answer to your question, but here's a really cool solution that'll
work if yoor serial-out pin is set to portb,0 AND it's the only output
on port B:
MOVF STATUS,W
MOVWF PORTB
You can also use portb,1 (again, only if there are no other port B pins
configured as outputs):
I'm writing a tool which will display waveforms
of a PIC's IO pins from the output of MicroChip's
mpsim trace file.
I've got a PERL script which extracts register/timing
info from the .trc file and then either
a tcl/tk script that displays the waveforms on X
or a Visual Basic tool that will do it on Windows.
I've run in to a snag where mpsim does not generate
register information when a port changes value
from an external signal.
ie. If an instruction changes PORTB I get the following
entry:
0025 1186 bcf PORTB,3 |20.00 18 |PORTB:75
whereas if PORTB,4 changes in response to an external stimulus
the internal register changes but no PORTB trace entry is
generated:
Does anyone out there know if there is a way to get a PORTB entry
for every trace line? Are there other simulators around that
would provide the info I'm after?
>I'm writing a tool which will display waveforms
>of a PIC's IO pins from the output of MicroChip's
>mpsim trace file.
> ....
>I've run in to a snag where mpsim does not generate
>register information when a port changes value
>from an external signal.
>
>ie. If an instruction changes PORTB I get [an entry in the .trc file]
>.... whereas if PORTB,4 changes in response to an external stimulus
>the internal register changes but no PORTB trace entry is generated
Steven:
Maybe I'm misunderstanding your problem, but have you thought of
reading the ".STI" stimulus file as well as the ".TRC" trace file, and
combining the information from both sources?
By the way, Don Lekei has already written a program (for MS-DOS only, I
think) that does essentially what you want. Don can be reached through
his home page at:
Setting VERBOSE ON will echo all incoming stimuli to the screen. This should be
all the information you need, and though parsing is a little messy, it should be
easier than manually combining info from separate files.
Darrel J.
______________________________ Reply Separator _________________________________
Subject: Re: mpsim simulator questions
Author: Andrew Warren <@spam@fastfwdRemoveMEIX.NETCOM.COM> at Internet_Exchange
Date: 8/23/95 10:59 PM
>I'm writing a tool which will display waveforms
>of a PIC's IO pins from the output of MicroChip's
>mpsim trace file.
> ....
>I've run in to a snag where mpsim does not generate
>register information when a port changes value
>from an external signal.
>
>ie. If an instruction changes PORTB I get [an entry in the .trc file]
>.... whereas if PORTB,4 changes in response to an external stimulus
>the internal register changes but no PORTB trace entry is generated
Steven:
Maybe I'm misunderstanding your problem, but have you thought of
reading the ".STI" stimulus file as well as the ".TRC" trace file, and
combining the information from both sources?
By the way, Don Lekei has already written a program (for MS-DOS only, I
think) that does essentially what you want. Don can be reached through
his home page at:
A couple of days ago, someone (I don't remember who) asked for a 10-Bit
binary-to-BCD converter. Below is the best converter I could come up
with. It'll actually do a little more than 10 bits; it works on all
binary inputs from 0 to 1285.
Since it's that time of year again, I'm offering to buy a beer for the
first person who a) can explain how the code works, and b) will be at
the Embedded Systems Conference on Tuesday, September 12th.
If you won't be attending the Conference, post an explanation anyway...
I'll drink your beer for you.
; Enter with 10-bit binary number in REGB:REGC (high 2 bits in bits
; 1 and 0 of REGB, low 8 bits in REGC). Exits with BCD equivalent
; in REGA:REGB (thousands/hundreds digits in REGA, tens/ones in
; REGB).
;
;Executes in 113 cycles.
BIN2BCD MOVLW 00000001B
MOVWF REGA
B2BLOOP RLF REGC
RLF REGB
RLF REGA
BC DONE
MOVLW 003H
ADDWF REGB
BTFSS REGB,3
SUBWF REGB
MOVLW 030H
ADDWF REGB
BTFSS REGB,7
SUBWF REGB
GOTO B2BLOOP
DONE ....
-Andy
P.S. Terry Rudersdorfer solved last year's "Square Root" challenge,
posted on the Microchip BBS. Is he on the PICLIST? Maybe he can make
it two-for-two...
When replying to posts, unless they are of true value to the members
of the PICLIST please ensure that you reply to the original poster. I
find it ammusing that threads run for days (even weeks occasionally)
and that after the nth (n being >4 generally) reply the thread
nolonger has any relevance to the original question. This would
reduce the nuisance of sifting through 20-40 items every two days
roughly. Is this reasonable. If you think that this is not reasonable,
please relpy directly to me and NOT THE LIST.
Nino
Benci************************************************************************
* Antonio (Nino) Benci * *
* Chief Technical Officer * *
* Monash University - Dept of Physics * I think *
* Wellington Rd, Clayton. 3168 * Therefore I am *
* Victoria, Australia. * I eat *
* TEL - 61 3 9905 3649, FAX - 61 3 9905 3637 * Therefore I excrete *
* EMAIL - spamnino.benci@spam@sci.monash.edu.au * *
************************************************************************
Regarding a random number generator for a pic you may wish to try
the following algorithm. It is not truely random but it will produce
what at least looks random.
Take an 8 bit array with bit 7=msb and bit 0=lsb.
1) Assign a variable bit1=array(0) .xor. array(1)
2) Assign a variable bit2=array(6) .xor. array(7)
3) Assign a variable bit3=bit1 .xor. bit2
4) Rotate the array one to the right.
5) Assign array(7)=bit3
6) Goto 1
This algorithm requires an initial seed located in array. The
output of the random number generator will be in array.
The Binary-to-BCD code I posted works only on inputs from 0 to 999.
Notwithstanding the accompanying documentation, it does NOT work on
numbers between 1000 and 1285.
It will still solve the problem for which it was written; the guy who
originally asked for a binary-to-BCD converter needed a range of only
[0-999].
Many thanks to David Tait, who not only discovered the [0-999] limit
within a couple of hours of my posting the code, but graciously
refrained from calling me an idiot even after I insisted that the code
worked for numbers greater than 999.
>I'm the one who posted the original BCD request. Andy, your code works great
>and is much more compact than the code I ended up writing.
Glad you like it... The routine in the Embedded Control Handbook uses the
same algorithm; it also appears in an old General Instruments appnote for
the original NMOS PIC, circa 1980. In both appnotes, though, the
algorithm's coded significantly less-optimally.
>Now whats this about an Embedded Controls conference?
The Embedded Systems Conference is an annual affair put on by Embedded
Systems Programming magazine. It runs from September 12th through the 14th
at the San Jose Convention Center (in the heart of Silicon Valley, near San
Francisco). The exhibits-only fee is $25; if you have $600 or so, you can
attend three days' worth of classes, seminars, workshops, etc.
>
>Date: Mon, 28 Aug 1995 21:25:00 EET
>From: Norman Fick <EraseMEnfickspamBeGoneAZTEC.CO.ZA>
>Subject: Trig Functions on PIC16C74
>
>I need to do a SIN and COS function on the 16C74. Does anyone know about a
>routine out there (I don't feel up to re-inventing the wheel!!).
>
>A question for you guys who know-it-all. What are the
>dissadvantages/advantages of using a PIC (in general) as opposed to using
>the Motorola HC11 mcu. I am quite familiar with the PIC's, but have heard
>many good reports about the HC11's. (Please try to be unbiased in your
>answer :-) )
>
>Thanks a stack
>
>Norman
>
Norman,
Ditto for all the others comments.
The major gripe I've got against the pic parts is the fact that MicroChip
has not provided any
thing to compare to the HC11 in regards of direct access secondary storage
memory, with the
exception of the 17Cxx.
The Pic 74 series has the ability to go up against the HC11 in many areas
with one major problem. Where do you store
transient data. 192 bytes of RAM space forget it, in a moderate design a
large percentage of it is
taken up by the application. Don't by into Microchips endurance sales pitch
on their EEPROM as a
replacement for RAM. Tt will not work in situations that require moderate
Read/Write/Read cycle counts.
It amazes me that a company that has made the big boys at Motorola come out
with the 99 dollar
development system for the HC05 and a whack at winning a Jeep to boot,
doesn't get more serious about going
after their big dog the HC11.
Ability wise, the PICs with the exception of the 17Cxx, is closer to an HC05
then a HC11.
The PICS do scream compared to the HC11/HC05 but with limited lung capacity.
WOULD YOU LIKE TO MAKE ALOT OF MONEY? I have made a fortune in the AMWAY
Business opportunity. For more information on how YOU can be a distributor
for the most exciting business opportunity of the 90's, ...
PLEASE SEND AN E-MAIL REPLY TO: TakeThisOuTmhollowaTakeThisOuTcris.com (MIKE HOLLOWAY).
I will be happy to discuss YOUR FUTURE in detail in this lucrative business!
>
> WOULD YOU LIKE TO MAKE ALOT OF MONEY? I have made a fortune in the AMWAY
> Business opportunity. For more information on how YOU can be a distributor
> for the most exciting business opportunity of the 90's, ...
> PLEASE SEND AN E-MAIL REPLY TO: mhollowaspam_OUTcris.com (MIKE HOLLOWAY).
>
> I will be happy to discuss YOUR FUTURE in detail in this lucrative business!
>
> Best Wishes for your Future SUCCESS!
>
> MIKE
>
This shit does not belong on mailing lists, especially not a list like
the PIC microprocessor list. Keep this shit to yourself, don't bother
us with it.
--
-----------------------------------------------------------------------
Daniel Mahoney Product Manager spamdmahoney@spam@netcom.com Comarco Wireless Technologies
Riverside, CA Irvine, CA
(909) 360-3647 (home) (714) 450-4076
If you get annoyed by these spams and just _have_ to reply to it,
_please_ edit the receipient-field to contain the original sender _only_.
I guess _extremely_ few of the readers of this mailinglist is interested
in your replies.
The best thing however is to ignore the spams. A reply is an indication
to the poster that people really read them.
Regards,
-------------------------------------------------------------------------------
Ronny H. Kavli This message was composed by 10,000 monkeys spam_OUTkavliTakeThisOuTKILLspamludd.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've sent him 10 1MB mailings with text along the lines of, we
don't appreciate it, don't do it. It looks like the only way to
teach these people is to use fire on fire. Perhaps if it costs
him money to download junk, perhaps he'll be more considerative
of others.
Mark
:
:WOULD YOU LIKE TO MAKE ALOT OF MONEY? I have made a fortune in the AMWAY
:Business opportunity. For more information on how YOU can be a distributor
:for the most exciting business opportunity of the 90's, ...
:PLEASE SEND AN E-MAIL REPLY TO: RemoveMEmhollowa@spam@spamcris.com (MIKE HOLLOWAY).
:
:I will be happy to discuss YOUR FUTURE in detail in this lucrative business!
:
:Best Wishes for your Future SUCCESS
I tend to follow the proceeding here without too much input, but I feel
compelled to comment on the spams to this list and the responses that
result.
I am an amateur radio operator and one of the popular means of
communication is a 2 meter transceiver going through a repeater. It is
quite common in this environment to have folks trying to interrupt other
folks conversations. By far the best way to deal with this sort of
thing has been to ignore the interference and go on as if nothing was
out of the ordinary. If you comment on the interference, it just fuels
the problem. Ignoring the interference generally causes it to go away.
Now I'll admit that the mailing list is a different situation from the
amateur radio repeater, but I think the same approach would be
appropriate here. Imagine if the spammer never got a single response
from a spam. At worst he or she might send the spam again, thinking it
hadn't gotten through the first time. After two or three attempts, I
would suspect that the spammer would give up on the list as being a very
unproductive place to post and quit posting to it.
It sounds like these folks are constantly on the move, so in most cases
retaliation through email just makes the system administrator's life
miserable. The most productive action would be to contact the system
administrator and point out the transgressions of the user. Few sites
want the notoriety that comes from harboring such users.
Anyway, that's my $0.02 on the matter. Sorry to compound the matter by
posting about it, but it seems like we need to come to agreement on how
to deal with this problem.
--
Paul Lutt
Domain: paulTakeThisOuT@spam@tc.fluke.COM
Voice: +1 206 356 5059
UUCP: uunet!fluke!paul
Snail: Fluke Corporation / P.O. Box 9090 / Everett, WA 98206-9090
Ignoring the spammer is nice in theory, however we are dealing with a little
different creature than you are used to in ham radio.
The spammers we are dealing with know have found out that they can send one
message to a listserver and have it propogate to all the mailing lists. What
they do is get the names of every listserver they can find and then send their
advertisments to all of them. They are not reading the lists. To expect
everyone on hundreds, maybe even thousands of lists to ignore them is
obviously unrealistic. They don't even seem to mind if they lose their
accounts, as long as they get a few orders and make money.
My solution to the problem is as follows:
1. Do away with mass mailings from listservers, or at least make sure it is
the listserver admin doing them.
2. Turn off messages from people not subscribed to the list.
3. Have the option to send a copy of your letter back to you so you
always see your message.
The first 2 filter out the non-dedicated spammer, the last one makes sure he
loses his account immediately by filling up his providers mail spool.
I have a problem with the picmaster ICE , my program for the 16C71
works 100% on the emulator but when I download it to the micro it
does not work at all .
It seems that the voltage levels are different when using the
micro. Can someone give me any tips on what the problem could be?
Thanks
Cheers
**************************
Daniel Aylen DNATakeThisOuTspamBeGonemsi.imt.za
**************************
I submitted this problem to our hardware engineering people and
got this response:
"My guess is that he is either not initializing properly, or he
may not have the MCLR pin tied high... The emulator takes care of
that, so he may have a problem on his board.
These are the two most common problems when an emulator works, but
the real part doesn't."
Try these suggestions and let me know. I can help with the init
code if that is where the problem is.
> "My guess is that he is either not initializing properly, or he
> may not have the MCLR pin tied high... The emulator takes care of
> that, so he may have a problem on his board.
>
> These are the two most common problems when an emulator works, but
> the real part doesn't."
... Or his oscillator circuit isn't working properly, or he's programmed his
PIC for the wrong oscillator type. The emulator takes care of these things,
too.
On the EEPROM:
/HOLD pull-up +5V
/WP pull-up +5V
/CS connected via a multiplexor
I also have a AD-converter(MAXIM) connected to the SPI-bus and that works
just fine.
The problem is to get in contact with the EEPROM. It just sends #ff, no
matter what I send.
Here is the code that I use to read the status register on the EEPROM.
_RB0-_RB3 is connected to a multiplexor and generates /CS allright. I
really have no idea what is wrong, since it works fine with the AD I don't
think it's software problem but I'm not sure. When I measure on the bus the
signals from the PIC seems to be OK (SDO,SCK and /CS) but the SDI is just
dead.
It's probably a silly mistake made by me (I use to do such mistakes) but I
just can't find it.
The '74 can not be used in master mode using the
built in I2C hardware. You _MUST_ bit bang to get
it to talk in master mode. Code examples are in
the ECH.
It's been a while since I last programmed a PIC and I'm starting a new
project with a 16C54. I downloaded recent versions of the assembler,
simulator and Picstart software.
The assembler manual cautions that I should no longer use the OPTION
and TRIS commands. Okay, how do I go about accessing these registers
for setup, etc.? (My updated documentation on the micro's isn't here
yet but I want to get started.) Where can I look at a code snippet
of some "modern" 16C54 code?
uk.ac.bradford Mono: Cathedrow
