>; Sets RA<0:3> as inputs and RB<0:7> as outputs
>; whatever appears on RA<0:3> is copied to RB<0:3>
>;
> include "pic84reg.equ"
>
>main movlw 1FH ; set up port A as all inputs
> movwf TRISA
> movlw 0h ; set up port B as all outputs
> movwf TRISB
>
>loop movf PORT_A,w ; get data from port A
> movwf PORT_B ; copy data to port B
>
> goto loop ; repeat
>
>start org 0h
> clrw
> goto main
>
>END
>
>The include file reads:
>
> LIST E=1, F=INHX16, P=16C84, R=HEX
> PORT_A equ 05h ; I/O Port A
> PORT_B equ 06h ; I/O Port B
> TRISA equ 85h ; Port A data direction
> TRISB equ 86h ; Port B data direction
However I got two errors which I don't really understand:
0127 movwf TRISA
Warning: [Warning 1] : line 127 : Filereg masked to appropriate number of bits
0129 movwf TRISB
Warning: [Warning 2] : line 129 : Filereg masked to appropriate number of bits
Can anybody explain this to me? Seeing as this is my first ever program I'm
sure it's me being a bit stupid.
Thanks in advance,
Rafe
----------------------------------------------------------------
Rafe Aldridge - spam_OUTrcaTakeThisOuTsirius.tn.rl.ac.uk
R65, Rutherford Appleton Lab, wwWWww
Chilton, Oxon, OX11 OQX, UK. o o
------------------------------------------------ooO--(__)--Ooo--
> 0127 movwf TRISA
> Warning: [Warning 1] : line 127 : Filereg masked to appropriate number of bits
> 0129 movwf TRISB
> Warning: [Warning 2] : line 129 : Filereg masked to appropriate number of bits
The problem is that the TRISA and TRISB registers are in the second register
bank. There are three ways to deal with this:
1) Switch to register bank 1
Write the TRISA and TRISB registers
Switch back to register bank 0
Note: You may still get the assembler warning, but the code should work
2) Use the FSR & IND registers to indirectly access the TRISA and TRISB
registers
movlw trisa
movwf fsr
movlw <value>
movwf ind
movlw trisb
movwf fsr
movlw <value>
movwf ind
3) Use the deprecated tris instructions
movlw <value>
tris porta
movlw <value>
tris portb
Microchip is trying to discourage people from using the tris instructions,
and claim that they may be removed from future parts.
I doubt that they would remove them from future versions of any existing
parts (i.e., 16C64, 16C71, 16C74, and 16C84); I think they just mean
that they might not put them in new designs.
At his request, I am forwarding a message from Don Lekei
<.....72677.2623KILLspam@spam@CompuServe.COM>. For the record, I completely agree with him,
and I use the TRIS instruction routinely. In my previous message which Don
quotes, I just presented all three ways of accessing the TRISA and TRISB
registers.
I should point out for the benefit of those using the 16C71 that the TRISA
register on the current parts doesn't actually have a bit for PA4. If you
write anything to PORTA with bit four low, it will drive PA4 low regardless of
what you have written to the TRISA register. The errata covers this, but in a
confusing manner. Mike Jedrezewski (sp?) of Microchip told me that there is a
new rev of the 16C71 silicon due out soon which is supposed to fix all known
errata, including the missing TRISA bit. I've also heard unofficially that
a 16C71A should be out in early '95, with improved performance (possibly
>20 MHz) and lower power consumption.
In the previous message, Eric Smith refers to Microchip's documentation:
>Microchip is trying to discourage people from using the tris instructions,
>and claim that they may be removed from future parts.
This advice from Microchip is some of the highest ranked BAD ADVICE in the
history of PIC programming. It is right up there with starting your code at
location zero in any PIC (other than an '84)!
You should ALWAYS use the TRIS instruction, unless it is necessary to
modify the TRIS register (eg. bi-directional i/o or open-drain emulation).
1) It is better to maintain code compatability and portability to the
existing economical PIC parts (5x) rather than some mythical future part.
2) TRIS takes less code and fewer cycles than accessing registers in bank
2.
3) MPSIM will not correctly track changes directly adjusting bank 2
registers.
4) If Microchip ever actually does remove the TRIS instruction on a future
part, then it is far more portable to define a macro to emulate the TRIS
instruction on that part, than to cut-off backward compatability with 16c5x
parts.
I just HAD to jump in here, it makes my skin crawl whenever I read that
part of the data sheet.
- Don
PS. Another handy way to start a lively thread is to mention using EQU to
define data addresses.
I need some beta testers for a piece of software I will be releasing to the net.
The program is a fairly basic pic disassembler, and I need to have as much code
run through it and checked as possible.
Now I realise this is NOT the most useful piece of software around (but it may
be useful to decode programs that have been "lost" in .asm format).
It is however a start on the road to an assembler/debugger system. The major
_feature_ of these tools being that they may be compiled/run on any machine
or OS having a C compiler capable of building them.
The disassembler decodes from an INHX16 style file (default output of MPALC) and
produces Microchip standard mnemonics. It will decode either 12 or 14 bit pic
code.
The beta testers in return for testing and suggestions will receive the huge kudos (?)
of having their names in the readme file :-) and some input on the final release
version of this and any other code.
The final bugs^H^H^H^Hfeatures are currently being hammered out, but the code should
be delivered (via e-mail) early next week to those lucky people who want it.
=%-)
Ian
p.s. I will just be supplying the C code, so beta testers must have a compiler
for their platform! The code has been developed on a Sun (Solaris 2.3) using Sun's own
compiler. I can produce MS-DOS and Linux targets (I hope ;-) for a final release but
others (amigas and macs) will require someone else to build them for me (hint hint).
p.p.s. The final release will probably be released as "postcard-ware" i.e. licence to use
requires the sending of a postcard of your hometown to me...
I4ve had some problems unzipping the file
"/pub/mchipsoft/mchipsoft/picapp/apnset02.zip" at ftp.sics.se.
(double-zipped file math.zip is corrupted)
Could anybody unzip it ??? I used the newest version (2.04g) of PKWARE's
pkunzip.exe for DOS. PKZIPFIX didn't work either. Perhaps this file should be
renewed! Others are OK.
Does anybody already have some experience with the MPASM (by Byte Craft Limited
of Waterloo and MCHIP itself)??? I got MPASM___.ZIP from the MCHIP BBS.
It seems to become the new enhenced general assembler for the PIC families or
is it already destributed along with any HW-tools? I'm just working with
the PICSTART-16B. There should also be a C-Compiler (MPC) soon! Am I right?
Please give me some respond about it...
By the way, for my research (MEMS) I designed a simple "Multi process Kernel"
for the PIC 16C71. All my programms (3 to be exact) now base on it. The main
part is an interrupt manager which branches to several processes (subroutines)
and it supports a serial line (RS 232/485 - half or full duplex) by interrupt
up to 19.6kB (8N1). A simple protocoll is suggested and only 7 file registers
are used for its minimum running (CRCs and double FSRs are also available
(+4bytes)).
The kernel exchanges serial data via two fileregisters and Ready/Send flags.
Errors are also flagged.
The usage of this "MpK" is fast and easy: fill up the empty structure with your
own code, data and initialization.
>
>Hi folks,
>
>I4ve had some problems unzipping the file
>"/pub/mchipsoft/mchipsoft/picapp/apnset02.zip" at ftp.sics.se.
>(double-zipped file math.zip is corrupted)
>Could anybody unzip it ??? I used the newest version (2.04g) of PKWARE's
>pkunzip.exe for DOS. PKZIPFIX didn't work either. Perhaps this file should be
>renewed! Others are OK.
>
>Does anybody already have some experience with the MPASM (by Byte Craft
Limited
>of Waterloo and MCHIP itself)??? I got MPASM___.ZIP from the MCHIP BBS.
>It seems to become the new enhenced general assembler for the PIC families or
>is it already destributed along with any HW-tools? I'm just working with
>the PICSTART-16B. There should also be a C-Compiler (MPC) soon! Am I right?
>Please give me some respond about it...
Yes there will be a C compiler out soon. I think it already is.. from BYTECRAFT.
There was a mail message earlier in this mail forum which had much better
detail about what was available.. But I did not save it sorry... Maybe
somone else will repost it?? (hint)
>
>By the way, for my research (MEMS) I designed a simple "Multi process Kernel"
>for the PIC 16C71. All my programms (3 to be exact) now base on it. The main
>part is an interrupt manager which branches to several processes (subroutines)
>and it supports a serial line (RS 232/485 - half or full duplex) by interrupt
>up to 19.6kB (8N1). A simple protocoll is suggested and only 7 file registers
>are used for its minimum running (CRCs and double FSRs are also available
>(+4bytes)).
>The kernel exchanges serial data via two fileregisters and Ready/Send flags.
>Errors are also flagged.
>The usage of this "MpK" is fast and easy: fill up the empty structure with your
>own code, data and initialization.
>
>Is there any interest for it ???
Yea! sounds like a good start for a lot of projects!! Microchip should use
code pieces like that for their app notes..
> I4ve had some problems unzipping the file
> "/pub/mchipsoft/mchipsoft/picapp/apnset02.zip" at ftp.sics.se.
> (double-zipped file math.zip is corrupted)
> Could anybody unzip it ??? I used the newest version (2.04g) of PKWARE's
> pkunzip.exe for DOS. PKZIPFIX didn't work either. Perhaps this file should be
> renewed! Others are OK.
You are right. We are hoping for Alex Baker from Microchip to upload
new versions. We just got the following message at SICS:
> First of all I should introduce myself properly - my name is Alex
> Baker, and I am Northern European Field Applications Engineer for
> Arizona Microchip, based in their Bourne End, Bucks, UK office. The
> geographical area I cover includes all of Scandinavia, Benelux and
> the UK.
>
> One of my current objectives is to start publicising the fact that I
> have an Internet email address, which people can use to communicate
> tech problems, comments etc. to Microchip in general; this is
> particularly following comments from you guys (the customers) during
> a seminar series I did in Sweden with Anders and the guys from Memec.
> You all apparently want Internet access to our BBS system and I feel
> that this is the first stage.
>
> To bring you up to date, full Internet access to the Microchip BBS is
> under consideration, but I notice from using archie that you are one
> of the sites across the world who already has a major portion of the
> files on the BBS available for anonymous FTP. My concern is that
> maybe you possibly don't have all the latest files. What follows is a
> list of files, pulled off the BBS yesterday. I have all of these
> available on my local PC, which I can upload via FTP to you.
<text skipped>
> Alex Baker Phone: +44 628 851077
> Norther European Field Applications Engineer Fax: +44 628 850259
> Arizona Microchip Technology Car: +44 831 494921
> Email: Alex Baker on Microchip BBS or KILLspamalexKILLspammicrochp.demon.co.uk
So hopefully, the complete set of Microchip BBS files will soon be
available by anonymous ftp from ~ftp/pub/mchipsoft/ at sics.se. Let's
keep up the pressure on Microchip becoming a full internetter!
Martin Nilsson
Swedish Institute of Computer Science E-mail: RemoveMEmnTakeThisOuTsics.se
Box 1263, S-164 28 Kista Fax: +46-8-751-7230
Sweden Tel: +46-8-752-1574
Can anyone point me at a description of the PicBuster contraption
which I've been reading about on the MicroChip BBS? I have read about
this gizmo - and remain unable to tell what it is or how it does
its putatively nasty task of dumping eprom in secured pic 54 series
parts. Has there been any discussion of the picbuster here?
It is a very nice name though, given its function. - JGN
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
Has anyone networked several PICs (or STAMPs) together ?
Did you use RS-485 ? How about simply wiring toegether several
open-drain outputs on different PICs ? Are there any examples
of software for networking ?
Bob Armstrong (TakeThisOuTbobEraseMEspam_OUTpoco-adagio.santa-clara.ca.us) wrote:
>
> Has anyone networked several PICs (or STAMPs) together ?
> Did you use RS-485 ? How about simply wiring toegether several
> open-drain outputs on different PICs ? Are there any examples
> of software for networking ?
>
Not yet, but I will be doing something pretty similar in the next couple
months. I've seen a neat wire-OR scheme for RS-485 where you use cheaper
RS-422 drivers ( a little, I think) and hook data input up to the driver
enable pin. Essentially allows wire-or with simpler protocols.
I'll post anything interesting that comes up.
/s/ Bill
Yes, we (Custom Hardware Engineering) have been networking the PIC for
home-automation products using our "RS232-BUS". It's simple, easy to use,
and an open protocol. We simply connect multiple PICs together on an RS232
line. Their is a transmit and a recieve line (just like RS232). The
transmit line connects to one of the data lines of multiple PICs through a
large resistor (1meg). So, there isn't much drain on this line. The
receive line is tied to -12V through a 2.2K resistor somewhere on the bus
and is tied to an opto-isolator which can pull the line to +12V by a normally
off pin on each PIC. When the communication is only between a "host"
(normally a PC), and the other devices on the bus, the data protocol is
simply two bytes of address data followed by two bytes of command/data. The
devices then return their address followed by two bytes of response data
(if needed). It is possible for devices to speak to one another on the bus
but in this case, it is required that the device respond in some manner, so
the sender knows that a collision has not occured.
For more specifics, feel free to write me back. Also, a quicky - we are
offering a line of home-automation products that work over our RS232-BUS
protocol. At present, we have a temperature sensor and a thermostat based
on the PIC and this protocol but we will have much more in the coming months.
We are also looking at offering kits if anyone is interested. To get on our
mailing list, just respond to this note asking to be placed on it and I'll
add you. We won't send out lots of mail - just notify you of new products
and any information you may want/need concerning out RS232-BUS devices.
*****************************************************************************
* Paul Greenwood -> -> -> -> -> -> -> Custom Hardware Engineering *
*---------------------------------------------------------------------------*
* "Any sufficiently advanced technology is indistinguishable from MAGIC." *
* - Arthur C. Clarke *
*****************************************************************************
>From: Mark <RemoveMEmbmooreTakeThisOuTbga.com>
>and an open protocol. We simply connect multiple PICs together on an RS232
>line. Their is a transmit and a recieve line (just like RS232). The
This sounds a little like RS485. I am curious why you decided not to
take this route as this would make you more compatible with other products
(including the line of home automation modules from Circuit Cellar).
YOurs, Ed
+---------------------------------------+-----------------------------------+
| Edward Cheung, Ph.D. | The opinions expressed herein |
|Satellite Servicing Robotics Laboratory| do not necessarily reflect |
| NASA Goddard Space Flight Center | those of my employers' |
| Code 714.1, Bldg T11B | |
| Greenbelt, MD 20771 | |
| 301-286-1269(office) 286-1717(fax) | My next book: |
| Internet: cheungEraseME.....asylum.gsfc.nasa.gov | Statistics, Demos and Other Lies |
+---------------------------------------+-----------------------------------+
A while ago I mailed the list with some storage allocation macros and
a threat to supply interested parties with code for I^2 C bus protocol
communications and timed finite state machines. Part of that is done:
but the code is moderately long so I suggest that you collect it, if you
are interested from ftp.dai.edinburgh.ac.uk, file /pub/user/pic-utils.tar.
You will find there the storage allocation macros I posted earlier, and some
other useful macros, e.g. a configuration macro that supports defaulting for
conditional compilation switches (the things that, when you forget to put
/D xxx=1 on the command line, MPALC says something like "line 1: Crit" and
crashes your machine ;-), as well as code for a multi-master I^2 C package
supporting master transmit and slave receive with interrupt detection of start
conditions (so your PIC doesn't have to spend all its time watching the bus).
The individual files in the directory in the tar file contain more information.
The finite state code will follow, as will other bits of the I^2 C stuff and
a neat UNIX c-shell script that calculates all the register values for a PIC
16C71 given clock rate, RTCC tick rate desired, and descriptions of the pin
functions (e.g. digital output, analogue input, digital tristate, etc.). I
didn't manage to do this today, 'cos I've got to go on holiday in about an hour.
The code is there for people in a hurry -- in a month there will be more.
Have fun,
John Hallam EraseMEjohnaifh.ed.ac.uk
Dept. of Artificial Intelligence
University of Edinburgh
5 Forrest Hill
Edinburgh EH1 2QL
Anyone interested in trading two UV erasable PIC16C57s for two UV
erasable 16C56s? I'll pay postage too - preferrably two-day US Post.
The two I'll give you haven't been used and I prefer that the 56s I get
to have not been erased more than 5 times.
--
------------------------------------------------------------------------------
If outside IBM network boundaries _^_ please pay attention to the following:
I speak for myself, not IBM. What (o o) I say MAY be wrong. No action should
be taken on my opinion alone. -oOO-(_)-OOo- (RemoveMEpabloEraseMEEraseMEnetmail.austin.ibm.com)
------------------------------------------------------------------------------
Don't know if this is what you want...
You can get the intel hex dump from your chip and then put it back in
the simulator. The simulator can then be made to show you the
assembler instructions.
> > Anyone come across a PIC16c5x decompiler?
> Don't know if this is what you want...
> You can get the intel hex dump from your chip and then put it back in
> the simulator. The simulator can then be made to show you the
> assembler instructions.
> /Anders
Yeah that will work, but it makes documenting the rev history a bitch,
(paperwork sucks) and I've got to have the record later on.
I NEED YOUR EXPERTISE!
I HAVE A PARALLAX CROSS COMPILED LISTING FOR A I BELIVE IS SOURCE FOR THE 8051
CONTROLLER. WHAT I NEED IS SOMTHING THAT WILL ETHIER LET ME COMPILE IN THE 8051 OR SOME WAY OF PRODUCING A LISTING OF 8051 CODES SO I CAN FIGURE OUT WHAT ALL
THE CODE IS DOING.
IM DO NOT HAVE ANY EXPERIANCE WITH THE 8051 AND DONT KNOW THE SYNTAX. TO SUM
IT UP A CROSS COMPILER TO COMPILE 8051 TO PIC CODE OR ANY IDEAS YOU GUYS MIGHT
HAVE.
THANKS FOR ANY SUGGESTIONS YOU CAN SEND.
JAMES.
CCK
I'm glad to see that the mail is starting to get out.
I'm new to this user group, and as a result I have a lot of questions.
I've tried out the floating point division provided in the float.asm
file contained in the an526 application note files, and it doesn't
seem to divide correctly for all numbers. I get a zero result in
many cases.
I'm using Parallax's assembler to target a 16C57. I noticed an
interesting behavior: When I use LCALL instruction to jump to a
sub-routine in another bank, subsequent jump instructions (JNZ, etc)
in the main code don't work correctly.
This is because the LCALL sets the bank select bits. When the RET
instruction is executed, these don't get reset back to the bank of the
LCALL. So any 9-bit jumps go to the bank where the subroutine was
located! This is easily fixed by using LSET just before the RET to set
the bank select bits back to the calling bank (which means you can only
call that subroutine from one bank).
Example:
org 00h ; bank 0
lcall other_sub ; call subroutine in bank 1
mov w, some_variable ; do something afterwards
xor w, #012h
jnz :not_twelve ; this jump will not work correctly! Bank select
... ; bits are set to 01.
..
:not_twelve ; this line will not be reached
... ; instead, jnz will jump to somewhere in bank 1
..
org 200h ; bank 1
other_sub ; bank select bits are 01 at this point
...
..
RET ; bank select bits do not change with this ret.
-------
Anyone have insight on this problem? The LSET workaround is OK, but I'm
wondering if I'm missing something.
--
Greg Bell | "Ever see a company's sales drop sharply due to an RemoveMEgregspamBeGonecqt.com | annoying ad campaign? You will."
-----------------------------------------------------------------------
CommQuest Technologies, Inc. (619) 633-1618 x133
You're right on top of the issue. I have noticed this too. My
current habit is to do this kind of thing:
lcall subroutine
lset $
The $ means the current address so that will always bring the page
select registers back to reality. I definitely take advantage of
optimizing situations, though. For example...
lcall subroutine
lset $
ljmp someplace
In the above you can remove the lset, since ljmp overwrites the page
select registers anyway. The same is true if there are no intervening
jumps in a string of code between "long" calls.
lcall subroutine
mov...
add...
or...
anything but a jump....
lcall someplaceelse
I'll usually put lset $ in anyway, then comment it out with an
additional comment that it is not needed any why.
My basic strategy to getting the most out of the '57 is the following:
and add code from there (replace nops as needed). That way if you
overflow a 256-word half-page, the assembler will tell you. You might
also want to change the order so all the legitimate call destinations
are together:
2. Using jump instructions, you can place subroutines at any location.
Of course, the actually destination of the call must be in the first
256 words of a given 512 word page.
For example
org 0h
Subroutine
ljmp Sub_body
org 100h
Sub_body
actual code here
ret
3. anything with a JMP PC+W (lookup table) must go in the first 256
words of a 512 word page.
4. Always explicitly clear FSR on startup. Initial register bank
selection is random! (Though it genuinely doesn't matter if you leave
FSR alone throughout your code.)
5. Unless you have grouped closely related subroutines, plan on using
LCALL always to call subroutines, and always follow with LSET $. That
way you can relocate code at will.
6. Certain optimizations beyond the above are easy. Long strings of
calls to the same routine can be one LCALL followed by a string of
simple CALLs and an LSET $ at the end, etc.
7. For some reason, I've had SLEEP fail when it's not in the first 256
words of a page. Just so ya know.
I'm curious to know if I'm using the right assembler for the pic 16c64.
Presently, I'm using the MPASM Assembler for PIC16/17, version 1.15.
I saw some notes about another assembler that I didn't know was available.
This caused me to wonder if I am using the best tool. Does someone have
a list of assemblers? What assemblers are you using?
I'm also interested in finding or writing a simulator for the pic 15/16
that will provide pin output and input with data tracking to a file.
Currently, I'm using the MPSIM Simulator for PIC16 v 4.16. Do others exist
for the 16c64?
Derrick Early asked:
> I'm curious to know if I'm using the right assembler for the pic 16c64.
> Presently, I'm using the MPASM Assembler for PIC16/17, version 1.15.
> I saw some notes about another assembler that I didn't know was
available.
> This caused me to wonder if I am using the best tool. Does someone have
> a list of assemblers? What assemblers are you using?
ASPIC, available as shareware from several ftp sites, Microchip BBS, and
the author's support BBS ((604) 597-3479), is 5 to 20 times faster than
MPALC or MPASM. It's powerful features allow considerable code compression,
since they make complex constructs much more maintainable.
It has some unique features such as character set translation, automatic
register bank management, text packing, true bit labels, full support for
IDE's like Brief, Codewrite, Winedit and Multiedit (even with multi-file
projects). It also works properly in makefiles, supports environment
variables, allows fuse and EEPROM data definition, automatically generates
RETLW tables, and more.
A complete working source code is provided as a code framework. It is
called DEMO.ZIP, and it is the complete source of a pocket logic analyzer
with LCD, KEYBOARD, etc. (Registered users also get the schematics and
block diagram).
Sorry if that sounded a bit biased, but I actually did try to use
restraint.
In AN510 Implementation of an Asynchronous Serial I/O must be a bug.
I must step the time delay loops for the right length.
Have you any other idea about Asynchronous Serial I/O?
> Have you any other idea about Asynchronous Serial I/O?
Well, one problem with Microchip's example source is that they've got
the RS-232 signals inverted. (On rs232, 1's are sent as low voltage,
0's as high). A scope is a great debugging aid for programming
RS-232, btw.
The RS-232 lines are reversed, but if you use some MAXIM interface chips,
it reverses the lines also. So you get an inverted invert, uhh, you know
what I mean.
on a list administrivia note (which will seem more towards the
trivial for experienced listserv users):
when i added all the "old" list members to the new list, the
listserv wanted to make "names" for everyone, so pretty much
everyone got names "pic user". in order to let the server properly
label your mail wth your correct name, you can send a message to:
you don't have to mention your email address or anything, since the
server software will see that from your mail.
having the server know your "real" name is not a big deal, but it
lets other list recipients see who a message is from (especially if
their mail software shows only the real name, and not the email
address).
finally/also, if you are getting "acknoledgement" email from the list
server when you send a message, you can send a message to the listserver
(same address as above) with the body:
set noack
you can send both commands ("register <your name>" and "set noack")
on separate lines in the same message.
hope this helps ome people.
feel free to send me comments on/about the list. especially and issues
pertaining to the changeover to the new server.
on a list administrivia note (which will seem more towards the
trivial for experienced listserv users):
when i added all the "old" list members to the new list, the
listserv wanted to make "names" for everyone, so pretty much
everyone got names "pic user". in order to let the server properly
label your mail wth your correct name, you can send a message to:
you don't have to mention your email address or anything, since the
server software will see that from your mail.
having the server know your "real" name is not a big deal, but it
lets other list recipients see who a message is from (especially if
their mail software shows only the real name, and not the email
address).
finally/also, if you are getting "acknoledgement" email from the list
server when you send a message, you can send a message to the listserver
(same address as above) with the body:
set noack
you can send both commands ("register <your name>" and "set noack")
on separate lines in the same message.
hope this helps ome people.
feel free to send me comments on/about the list. especially and issues
pertaining to the changeover to the new server.
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.
Sounds great!
could you fax me some details...
max no. of write cycles
max clock speed
prices for full range of memory capacities
ordering details and stockists
Thanks,
Bryan
--
---------------------------------
BRYAN CROTAZ - spamBeGoneb.crotazEraseMEic.ac.uk
---------------------------------
TECHNICAL MANAGER
Student Television Of Imperial College
Beit Quad, Prince Consort Road
London SW7 2BB
Tel. 071-594-8104
Fax. 071-225-2309 attn. STOIC
I am looking either for the internal software of the interpreter
pic chip of the BASIC STAMP, or better for an upgraded version (>1.4)
that would accept more than 256 bytes of code (many more please...)
Please answer me about the availability of a new basic with PIC chips.
Yours faithfuly,
~A
Herve GALMICHE
ALCATEL BUSINESS SYSTEMS
CC 696
1 rte du Docteur Albert Schweitzer
F- 67408 ILLKIRCH Cedex FRANCE
Phone +33 88677700 ask for 78004
e-mail galmichespamBeGonesxb.bsf.alcatel.fr
Thanks to everyone who has responded so far to my request for
opinions as to which PIC programmer to buy. I haven't bought one
yet, but it looks like it's come down to either the PICSTART from
Microchip, or the Parallax programmer, mainly due to cost.
I thought I had settled on the Parallax one, but I found out that there's a
Microchip seminar coming to town (Vancouver), and that I can get the
"PICSTART development system" for $79US there. The seminar costs $99US, so
that puts my total cost at about the same as the Parallax programmer. They
tell me that the seminar is very informative (5.5 hrs), and that you get
books and _product_samples_ with the PICSTART package. That part sounds
good to me, but, as I am a beginner, I think the seminar may be way over my
head...
I haven't heard from anyone who has used the PICSTART. Can someone
please give be a brief comparison of the PICSTART and the Parallax
programmers?
Thanks,
Richard Friesen Little Timmy took a drink,
(RemoveMERichard_Friesen@spam@spamBeGonemindlink.bc.ca) But now he'll drink no more,
For what he thought was H2O
Was H2SO4
----------------------------------------------------------------------------
----
--
Richard Friesen Little Timmy took a drink,
(.....Richard_Friesen@spam@EraseMEmindlink.bc.ca) But now he'll drink no more,
For what he thought was H2O
Was H2SO4
------------------------------------------------------------------------------
--
I use the PICSTART all the time and think it is fine. It doesn't "remember"
the fuse settings so you will program them incorrectly sometimes if you don't
remember to "reset" them. The tools are fine, the documentation is adequate
but poorly formatted on the disk. Once you get past that they are fine. And
since the PICSTART uses the serial port rather than the parallel port it works
on more systems (like my IBM ThinkPad laptop which parallax has said they
won't make it work on, even though it is an *IBM* PC (ISA bus even), and
that is pretty stupid on my part. (ed note, yes I think the Parallax folks
are wankers but that isn't why I don't reccomend their stuff)).
Richard Friesen prophesized:
> I haven't heard from anyone who has used the PICSTART. Can someone
> please give be a brief comparison of the PICSTART and the Parallax
> programmers?
Well, (lucky for me), I didn't have to buy two programmers to find one
that did what I needed. So, I can't compare the two for you. I have
been happy with Parallax' product.
The one HUGE selling point, in my book, are the Parallax mnemonics
which are very "8051-like". Actually they're even better than 8051
mnemonics because there are things like "CJE" to complement "CJNE"
(unlike the 8051). I have yet to learn the cryptic MicroChip
mneumonics which is kind of bad for me when I want to read sample code
from an app note or something. Made code development a lot quicker,
though.
You should be able to get about the same effect with any decent macro
assembler and your own time. Maybe the PICSTART package has a macro
assembler (?).
--
Greg Bell | "Counting SUCKS!" .....gregRemoveMEcqt.com | -Beavis
-----------------------------------------------------------------------
CommQuest Technologies, Inc. (619) 633-1618 x133
> I thought I had settled on the Parallax one, but I found out that there's a
> Microchip seminar coming to town (Vancouver), and that I can get the
> "PICSTART development system" for $79US there. The seminar costs $99US, so
> that puts my total cost at about the same as the Parallax programmer. They
> tell me that the seminar is very informative (5.5 hrs), and that you get
> books and _product_samples_ with the PICSTART package. That part sounds
> good to me, but, as I am a beginner, I think the seminar may be way over my
> head...
I attended the PIC seminar in Chicago and thought it was pretty
worthwhile. Actually, it is pretty much targeted toward people who
know little or nothing about PICs. So, if that's what you mean by "beginner"
I wouldnt' let that worry you. It probably would be helpful to have some
experience with other microcontrollers (such as the 8051), but if you have
a whole ot of PIC experience, you would probably find the seminar a little
slow.
I can't say too much about the PICSTART since I haven't used it for any
real projects yet. I did put it together and verify that it works.
Peter Fales AT&T, Room 9C-242
N9IYJ 2000 N. Naperville Rd.
UUCP: ...att!intgp1!psfales Naperville, IL 60566
Internet: .....peter.falesSTOPspam@spam@att.com work: (708) 979-8031
> I thought I had settled on the Parallax one, but I found out that there's
a
> Microchip seminar coming to town (Vancouver), and that I can get the
> "PICSTART development system" for $79US there. The seminar costs $99US,
so
> that puts my total cost at about the same as the Parallax programmer.
They
> tell me that the seminar is very informative (5.5 hrs), and that you get
> books and _product_samples_ with the PICSTART package. That part sounds
> good to me, but, as I am a beginner, I think the seminar may be way over
my
> head...
Richard,
I have a PICSTART programmer here and it works ok, and it accepts standard
Intel-hex format files so it will work with all true PIC assemblers
(including, of course ASPIC). I don't use it primarily due to it's lack of
command line automation, but I believe it can program fuses from the INTEL
HEX file, it's just that MPALC and MPASM won't let you.
DEMO.ZIP gives an example of programming the fuses for any PIC from the
hex file (including seting the device ID to the compile date and time).
DEMO.ZIP is the complete source code (writtten in ASPIC) to my pocket logic
analyzer that was a winning entry in the Picstart design contest last year.
You can pick it up from my BBS (which should be local for you) at (604)
597-3479 if you want (schematics and block diagrams are available only to
registered ASPIC users though).
The Parallax programmer seems to require that you use their special
assembler which does not compile real PIC code, but rather some sort of
80xx style pseudo-code cross compiler code which is really difficult to
read if you can actually program a PIC.
BOTH Picstart and the Parallax programmers use non-standard interface
protocols and
user-interferance screens (which is why in real life, I actually use the
Microburner from Baradine in North Van.).
I attended the Microchip seminar last time it was in Vancouver and it
really geared towards beginners to the PIC, but I still found it
interesting. The audience ranged from people who wanted to find out what a
PIC is, to people like myself who have written tens of thousands of lines
of PIC code.
- Don
This is not a TRUE internet message since the body is probably longer than
the message header.
I'm glad you put your question about programmers on the table.
As a result, I hope to build a programmer based on the
16c84 programmer that was located at bode.ee.ualberta.ca .
I know it will be a bit of work to make it program a 16c64,
but I think that it will be worthwhile.
Good luck with your decision, and please let us know what
you think of the seminar.
> As a result, I hope to build a programmer based on the
> 16c84 programmer that was located at bode.ee.ualberta.ca .
Just a few words of caution about this programmer:
* I developed this project using a 20MHz 386DX machine and have
subsequently found it to be unreliable when used with my 33MHz 486DX.
Obviously a timing problem. I will try to fix this when I get some
spare time. It would be useful if anybody that has successfully got
the programmer to work could let me know what type of PC they used.
* Please note that the executable packaged with the programmer info
was built for hardware using a 7406. If you use a 7407 you must
recompile. The Qbasic source is also intended for hardware using a
7406. If you want to use the Qbasic program with 7407 based hardware
then use these definitions
Note, due to a typo, the program erroneously suggests that you
should use ClkHi = 4. Sorry about that.
* If you don't use LS buffers you should substitute a 7805 for the
78L05.
On a happier note, I have designed a PCB for the programmer which
should make life easier for intending constructors (it was while
testing my PCB that I found the timing problem). The details will be
packaged with the next release of the software (i.e the one that
corrects the timing bug). I can't promise when that will be ready
though.
It doesn't seem to be as widely known as it should be that there is
information on another 16C84 programmer available on the net. This
one was designed by Henk Schaer and is (at least was when I last
looked) available as
I thought I had settled on the Parallax one, but I found out that there's a
Microchip seminar coming to town [...]
The seminar is excellent and I'll admit that if you consider the two
programmers equal, you get better value buying the picstart,
especially at the seminar. Here in Albuquerque it was an even better
deal -- the PICSTART was US$99, and the seminar was free!
I have the parallax, and I tend to prefer it. Here are some opinions.
Others may differ.
In Favor Of Parallax:
1. I like the parallax pseudo "8051-like" instruction set. Parallax's
assembler will work with native instructions as well, so you're not
stuck.
2. Their examples are simple and easy to follow, software is well
documented and easy to use, you're up and running in no time. Book is
excellent.
3. Programmer remembers fuse settings.
4. Can assemble native code from Microchip's assembler. Microchip's
assembler doesn't grok the Parallax pseudo instructions, though it's
probably possible with macros.
In Favor Of PICSTART:
1. Both the assembler and the simulator are more sophisticated.
Harder to get used to but definitely more capable once you get going.
2. Assembler can accept more file formats, if you care.
3. Has a ZIF socket. Parallax uses LIF which is not as nice.
4. Comes with product samples to play with, worth $$$.
Other Info:
1. Parallax uses parallel PC port, PICSTART uses serial. You could
probably use PICSTART from Linux with the DOS emulator, but you can't
do that with the parallax since the DOS emulator doesn't support the
parallel port.
Well that's all that comes to mind right now. Generally I'd say if
you're a beginner you'll want the Parallax cuz it's got the easiest
learning curve. If you're an advanced Microchip hacker, you may want
the better simulator and assembler in the PICSTART. I'd say if you're
that hardcore, get both kits. They're cheep!
>
> 1. Parallax uses parallel PC port, PICSTART uses serial. You could
> probably use PICSTART from Linux with the DOS emulator, but you can't
> do that with the parallax since the DOS emulator doesn't support the
> parallel port.
I know this list is not for Linux discussions, but I must disagree here.
The parallel port works fine under DOSEMU. Add the following line to your
/etc/dosemu.conf
> Additionally, the PicStart's serial connection is completely
> nonstandard/proprietary, with pretty low-level UART stuff. Would this still
> work with LINUX (even emulating DOS)? It definitely doesn't work with the
> MAC.
I've been looking at the PICStart communications with an HP 4952A protocol
analyzer. They use receive data, transmit data, and one handshake line in
each direction. The handshake lines are toggled after every command or data
byte.
I haven't completely worked out the details yet, but I think the Macintosh
could actually talk to it. A special cable might be needed.
>Hi PICers,
>
>David said,
>
>>
>> 1. Parallax uses parallel PC port, PICSTART uses serial. You could
>> probably use PICSTART from Linux with the DOS emulator, but you can't
>> do that with the parallax since the DOS emulator doesn't support the
>> parallel port.
>
>I know this list is not for Linux discussions, but I must disagree here.
>The parallel port works fine under DOSEMU. Add the following line to your
>/etc/dosemu.conf
Additionally, the PicStart's serial connection is completely
nonstandard/proprietary, with pretty low-level UART stuff. Would this still
work with LINUX (even emulating DOS)? It definitely doesn't work with the
MAC.
Again, I'll take this time to second Don Lekei's recommendation of the
Beradine MicroBurner 512 (see FAQ for more info). It is a little pricey
(maybe $350), but well worth it. I have both this and a PICSTART (which I
used before I found the microburner), and I don't even take the PICSTART
out of the box anymore. It uses a standard RS-232 serial connection, and
you can get new modules to let it program new/different chipsets (although
they are also admittedly a bit pricey at somewhat over $100 each). It also
uses a serial programming routine (WRT THE PIC), so I always have 5 wire
connectors on my oceanographic instrumnts, and I can update the frmware
with a simple 5-wire cable from the Microburner to the instrument's circuit
board (ie: in situ programming, whic I believe the Parallax TruFlight will
also do, but the PICSTART will not). Also, since you can download programs
from the host computer, to the microburner (which can run off the included
AC adapter or a 12V battery) you can program the new firmware into the
buner, and take it (no host computer) to the instrument and update the
firmware.
I have no cnoonction to the MicroBurner, except as a normal customer.
-jory
PS: Has anyone gotten a version the uASM (for the MAC, from MicroDialects)
that will work with the 16c84? Any work on any new MAC-based development
tools (I'd especially like a good c84 supporting simulator) I am really
trying to get away from SOFTPC! (and I don't have a UNIX or PC/LINUX box,
so those emerging avenues/alternatives don't help. :)
Gratuitous Background Info:I thought I had bought a c84/c71 uASM version,
but hadn't gotten around to using it for a long time. When I recently tried
assembling some c84 code with it, I found it wouldn't recognize page1
memory access, etc. I didn't see anywhere I could select the PIC version,
so I guessed I had the wrong version. I called MicroDialects, but could not
get a hold of anyone who could answer my questions. Several weeks ago, I
finally returned the original disk, with a polite letter asking for the
correct version (I have not heard back yet). Anyone else have ay particular
experiences with them?
> Additionally, the PicStart's serial connection is completely
> nonstandard/proprietary, with pretty low-level UART stuff. Would this still
> work with LINUX (even emulating DOS)? It definitely doesn't work with the
> MAC.
I've been looking at the PICStart communications with an HP 4952A protocol
analyzer. They use receive data, transmit data, and one handshake line in
each direction. The handshake lines are toggled after every command or data
byte.
I haven't completely worked out the details yet, but I think the Macintosh
could actually talk to it. A special cable might be needed.
> on more systems (like my IBM ThinkPad laptop which parallax has said they
> won't make it work on, even though it is an *IBM* PC (ISA bus even), and
> that is pretty stupid on my part. (ed note, yes I think the Parallax folks
> are wankers but that isn't why I don't reccomend their stuff)).
>
> --Chuck
Interesting! Neither does the Parallax programmer work on HP Omnibook.
Parallax told me essentially "We don't care". I'm a bit surprised that
Parallax writes their software so machine dependent that it can't be
run on these machines. Using the parallel port in a portable way isn't
really hard.
-- Martin
Martin Nilsson
Swedish Institute of Computer Science E-mail: mnEraseME@spam@sics.se
Box 1263, S-164 28 Kista Fax: +46-8-751-7230
Sweden Tel: +46-8-752-1574
I have the PGM16 from Advanced Transdata Corporation. Having never seen
a picstart or paralax programmer, it might be an OEM or clone of one of
them, but in my sample of 2 parallel ports to connect it to (clone
DX-2/66 and Zeos sub-notebook) it runs great.
I regularly travel with the Zeos & programmer. Very convenient. Their
real time ICE also runs well on the Contenda - I can't imagine tucking my
desktop system in the back seat of the plane to take my development
system on the road. AS it is, an old briefcase serves as a complete real
time ICE / programmer capable system.
If anyone knows if this PGM16 critter is a clone of one of the other
programmers please let me know.
Although many people have let me know that they have got the
programmer to work it is worth giving a few words of caution if you
are thinking of building it:
* I developed this project using a 20MHz 386DX machine and have
subsequently found the C version to be unreliable when used with my
33MHz 486DX. Obviously a timing problem and I will try to fix this
when I get some spare time. The Qbasic version still worked though,
and the C version worked with turbo mode switched off.
* Please note that the executable packaged with the programmer info
was built for hardware using a 7406. If you use a 7407 you must
uncomment "#define U7407" and recompile. The Qbasic source is also
intended for hardware using a 7406. To use the Qbasic program with
7407 based hardware then include these definitions:
(Due to a typo, the program erroneously suggests that you
should use ClkHi = 4. Sorry about that.)
* If you don't use LS buffers you should substitute a 7805 for the
78L05.
I recently designed a PCB for the programmer which should make life
easier for intending constructors (it was while testing my PCB that I
found the timing problem). The details will be packaged with the next
release of the software (i.e the one that corrects the timing bug). I
can't promise when that will be ready though.
It doesn't seem to be as widely known as it should be that there is
information on another 16C84 programmer available on the net. This
one was designed by Henk Schaer and is (at least was when I last
looked) available as
>
> Hi,
>
> I tried to mail this last week but it doesn't seem to have made it
> onto the list.
>
> Derrick Early mentioned he was hoping to build a 16C84 programmer.
> You can ftp the info about this programmer from:
>
> ftp://ftp.ee.ualberta.ca:/pub/cookbook/comp/ibm/pic84pgm.zip
>
David,
I received your message last week just fine. I looked at the picprog.zip
files, and it also looks like a good setup for a programmer. My only
problem with it is that it doesn't appear to include the source for the
software. I guess that someone could just send email to the author, and
you may be able to get a copy.
On Sep 6, 11:13, David Tait wrote:
[stuff deleted]
>
> * I developed this project using a 20MHz 386DX machine and have
> subsequently found the C version to be unreliable when used with my
> 33MHz 486DX. Obviously a timing problem and I will try to fix this
> when I get some spare time. The Qbasic version still worked though,
> and the C version worked with turbo mode switched off.
I've had this kind of problem before with other cctry connected to PC
parallel ports. One way to fix it is to edit the CMOS configuration of
the PC and slow down the 8-bit I/O access by adding a few wait states.
Maybe this can work in this case too.
I have just posted my PIC assembler for unix to ftp.funet.fi
called pictools.tgz and pictools.info (I hope). This will
no doubt be moved under the /pub/microprocs/pic heirarchy soon.
I has been written using gcc (ANSI C) under Linux, but should be
very portable! It is version 0.1 and may/will have bugs so don't
just trust it on OTP parts until you simulate (you mean you don't
already) and use EPROM/EEPROM parts for first prototypes!
Anyway hope you like it
=%-)
Ian
p.s. If it does not appear in a couple of days I will try again
p.p.s. If you really can't wait or don't have ftp access then I
could e-mail it to you (~40k bytes uuencoded), but the
number of people who I could do this for is limited!
> On Sep 6, 11:13, David Tait wrote:
> [stuff deleted]
> >
> > * I developed this project using a 20MHz 386DX machine and have
> > subsequently found the C version to be unreliable when used with my
> > 33MHz 486DX. Obviously a timing problem and I will try to fix this
> > when I get some spare time. The Qbasic version still worked though,
> > and the C version worked with turbo mode switched off.
>
> I've had this kind of problem before with other cctry connected to PC
> parallel ports. One way to fix it is to edit the CMOS configuration of
> the PC and slow down the 8-bit I/O access by adding a few wait states.
> Maybe this can work in this case too.
In many cases the chips of the parallel card are too slow to alllow the
high speed switching of a fast card. For instance, you might have a bt
set low, you then pulse the bit high, then a 486 clock cycle or two later
return it to low. All fine in theory, but the card hasn't had time to
switch to the high state before it was instructed to return low.
Yeah, putting in wait delays will work. Another one you could try is
feed the output of one or two of the bits back into parallel port. That
way, you could read when the card has made the switch.
Oh, by the way, I'm new to the PIC group. Can anyone tell me something
about the PIC? What it can do, features, nice stuff, etc? Thanks.
>
> 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.
Well, the 5x series is very different. You have to put the pragram data bits
on the proper lines in parrallel and strobe the program line, then stobe a
line to step the PC to the next address, etc. It would be a simple circuit ( a
couple of latches, strobes for the latches and the prgm and address step
strobe) but i'm pretty lazy, if someone's already done it i'll use their
design.
I found an article on a sophisticated 5x programmer in electronics now agazine
( used to be radio electronics) which even does the supply margining and
interfaces to the pc via a serial line. It's in the Jan. and Feb. 1994
issues if anyone is interested, it uses a 17c42 as it's controller. Of course
then I'd need to porgram a 17c42 ( or buy one preprog'ed from the author for
$30).
>
> 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.
While we are on the subject of memory I saw a new serial eeprom in the May
issue of Electronic Design.(shows how far back I am on my required
reading).
This chip is called the FRAM Here are the specs 10 billion yes 10 billion
cycles and now for the interesting part write time = 0 yes, no delay. I
believe that the truth in advertisement law has been passed, so if any of
you have tried this chip or heard of it let me know. Their number is
719-481-7012 Ramtron is the companys name.
I have read that some eeproms are not compatible with PICS (Parallax
Application note #11 ) Why is this?
Joseph D. West
Electronics Lab. Supervisor
College of Mechanical Eng.
Ohio State University
> This chip is called the FRAM Here are the specs 10 billion yes 10 billion
> cycles and now for the interesting part write time = 0 yes, no delay. I
> believe that the truth in advertisement law has been passed, so if any of
> you have tried this chip or heard of it let me know. Their number is
> 719-481-7012 Ramtron is the companys name.
Folks I saw this too and called for samples. We have some folks who kill
our Micorchip EEProms right and left. It was my first design using them
and I didnt expect people to use them like they do. Anyway I used 5V and
the worst reading and writting methods alive. To make a long story short
MC's EE's smoke about once a month. I tried the samples from FRAM and
they rock! Very little code mod was necessary in my xlinx(yea i have to
ship a new prom with the frams). But these things last forever at 5V(MC
wants 3V for long life). I put them to the test overnight and only had 4
read back errors after 5mil r/w cycles. Oh yea they are a wee bit more
expensive but hey I am an engineer not a purchasing agent :)
later
John
-----------------------------------------------------------------------------
John Johnson Team OS/2 member | spamBeGonejohnsonjKILLspam@spam@bga.com | johnsonjspam_OUT@spam@utdallas.edu
-----------------------------------------------------------------------------
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
> This chip is called the FRAM Here are the specs 10 billion yes 10 billion
The interesting thing about FRAM is that it has limited *read* endurance as
wells as limited write endurance. Ramtron originally claimed that FRAM would
replace DRAM, but I don't think people want main memory in their PCs that can
only be read 10 billion times. I'd have to replace the FRAM several times
a month in mine, since some memory locations get used quite frequently.
With serial memories the (relatively) low read endurance is tolerable, and the
high write endurance is great.
I haven't actually tried FRAMs yet. I wonder how cost competitive they are.
Both the 16C64 and 16C74 are becoming more freely available in sample
qtys now. Elbatex will have been allocated some, but I am not aware of their
priority
list for sample distribution
> I have Picstart Version 16C1. Is there a SW upgrade for the new
> chips 16C74, 16C73 etc.
I'm not sure if this may be a typing error on your part - if what you
have is a Picstart-16B1, there is no upgrade available to support the
16C74/73, you will need to purchase the Picstart-16C, which is just
becoming available. Obviously if what you have is a Picstart-16C the
software supplied with it should inherently support the 16C74/73
Alex R. Baker - Field Apps Engineer Ph: +44 628 851077 Car: +44 831 494921
Arizona Microchip Technology Fx: +44 628 850259 Email: spamBeGonealexspam_OUTRemoveMEmicrochp.demon.co.uk
ANY VIEWS EXPRESSED HERE ARE MINE AND DO NOT NECESSARILY REPRESENT THOSE OF MY
EMPLOYER
In article: <.....9409270615.aa27079RemoveMEpost.demon.co.uk> jory@spam@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: EraseMEalexRemoveMESTOPspammicrochp.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: RemoveMEalexspam_OUTmicrochp.dem
on.co.uk
ANY VIEWS EXPRESSED HERE ARE MINE AND DO NOT NECESSARILY REPRESENT THOSE OF MY E
MPLOYER
Is anyone else out there working on a decent development environment
for PIC programming under Linux? I'm writing a downloader to drive
a serial programming board like Russ Reiss' or David Tait's from the
parallel port. Right now it has decent libraries but the actual driver
code is pretty weak (I'm a fan of the add-features-as-I-need-'em school
of software design). However, a couple of weeks ago I mentioned
to several people that I'd probably be releasing an alpha version in
about a week, so I'm announcing version 0.1 now even though it's still
got a long way to go before it's even "alpha". I'd like to offer my
code to the community so that instead of having N different downloaders
each with its own strengths and weaknesses, we can have one comprehensive
programmer... so if you're thinking of writing a programmer or similar
tool, drop me a line and see if it would be easier to extend my code.
(If you just want a programmer and no hassle, though, my code isn't
at that stage yet.)
--
... William Lewis. ----- wimlspamnetcom.com ----- Seattle, WA, USA
"The mind is not a vessel to be filled, but a fire to be kindled."
I've been porting the C code for the assembler and serial programmer
by ED Technical Publications. They had an article for their 16C5X
programmer kit in Electronics Now(?).
Anyway, the code is truly gross and helps to feed my generalization
that engineers who are not "programmers" should not be allowed to
write code. I've got it compiling under Linux pretty clean using
gcc with almost all the warnings turned on (not just -Wall) for
the assembler and have yet to finish work on the downloader code.
If someone has the same kit, I can mail you my version and the originals.
DOSEMU works but is less that ideal.
I guess a copylefted simulator would be a noble eventual goal for
many of us.
> I've been porting the C code for the assembler and serial programmer
> by ED Technical Publications. They had an article for their 16C5X
> programmer kit in Electronics Now(?).
>
What sort of serial protocol is used ? Is it sustainable with common
Unix serial drivers, or do you have to do some clever stuff with the
handshake lines ?
A generic serial connection to the programmer sounds a nicer solution
than porting the parallel-port programmer, since it would be usable with
all Unixes rather than being Linux-specific. A special device driver
that only works on PC-Linux seems barely better than a DOS-only utility
to me.
Are the protocols that Microchip uses to talk to the Picstart (and
perhaps other programmers) published anywhere ? It seems to involve
a lot of handshake-line-waving, but perhaps it's just doing excessive
flowcontrol - I don't know whether it will work with the accepted
handshake protocols.
> If someone has the same kit, I can mail you my version and the originals.
> DOSEMU works but is less that ideal.
I don't have the kit. Are the sources copyright / not copyable ?
Sorry to have to correct my errors this way, but I have accidently
erased the address of RNDr. Viktor Dvorak who responded to my request
for help with an application using a PIC and an AD7714. I have a
return message ready to e-mail to him, but I no longer have his address.
If you get this message, Dr. Dvorak, please send me your address again.
>> I've been porting the C code for the assembler and serial programmer
>> by ED Technical Publications. They had an article for their 16C5X
>> programmer kit in Electronics Now(?).
I've been struggling along with the PICSTART and it sucks. My housemate has
a Linux machine and with the advent of this Linux base, we could share the
programmer.
Can somebody give me a firm reference to this serial programmer kit?
> 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 - b.crotazspamBeGone.....ic.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?
> What sort of serial protocol is used ? Is it sustainable with common
> Unix serial drivers, or do you have to do some clever stuff with the
> handshake lines ?
The source for the 16C7X chip in the programmer is also on the BBS.
>From what I have been able to understand from the source, the protocol
is pretty asynchronous (read: hideous amounts of time spent sending
handshake characters in lockstep back and forth instead of using flow
control) and can be implemented with really easy blocking I/O so the
code should be trivial to port. If I have to do funky serial setup
using termios or something, then one camp (BSD or SysV) will be
unhappy.
> A generic serial connection to the programmer sounds a nicer solution
> than porting the parallel-port programmer, since it would be usable with
> all Unixes rather than being Linux-specific. A special device driver
> that only works on PC-Linux seems barely better than a DOS-only utility
> to me.
If I had the choice again, I'd be inclined to get some commercial
serial-based product since kits are annoying. Good thing I got my
brother to put this one together. :-)
The one good thing about this kit is that it does verify at min and
max voltage levels. A definite drawback is that this thing only does the
16C5X series chips.
When I get around to porting the serial routines, it won't be very
Linux specific. I just won't promise it will work on platform XX unless
someone gives a nice XX system. :-)
> Are the protocols that Microchip uses to talk to the Picstart (and
> perhaps other programmers) published anywhere ? It seems to involve
> a lot of handshake-line-waving, but perhaps it's just doing excessive
> flowcontrol - I don't know whether it will work with the accepted
> handshake protocols.
Has someone tried asking for the protocol specs? It always amazes me
how hardware venders can be so protective about a few API/comm specs
that are absolutely useless without the hardware they sell!
> > If someone has the same kit, I can mail you my version and the originals.
> > DOSEMU works but is less that ideal.
> I don't have the kit. Are the sources copyright / not copyable ?
Everything is copyrighted. Automatically by law. However, there seems
to be no restriction on the distribution. I didn't need to do anything
special to get it from their BBS.
I offered to mail it to people because most people here use the MicroChip
or PICSTART products and couldn't care less about source for PICPROG.EXE
Personally, it would be nice to have a unified set of unix tools with
a back end for each product but that's probably wishful thinking.
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'm jumping in to this late, so please pardon me if I ask something obvious.
> > What sort of serial protocol is used ? Is it sustainable with common
> > Unix serial drivers, or do you have to do some clever stuff with the
> > handshake lines ?
What programmer is this? I've had a few ideas in my head for awhile for a
device such as this. It sounds like this might be specific to a certain
small part of the PIC family. What I have in mind would be a lot more
general purpose.
>
> The source for the 16C7X chip in the programmer is also on the BBS.
> From what I have been able to understand from the source, the protocol
> is pretty asynchronous (read: hideous amounts of time spent sending
> handshake characters in lockstep back and forth instead of using flow
> control) and can be implemented with really easy blocking I/O so the
> code should be trivial to port. If I have to do funky serial setup
> using termios or something, then one camp (BSD or SysV) will be
> unhappy.
Of course, the way to deal with this is to write two object modules (
one for BSD, one for SYSV) which abstract serial IO to the appropriate level,
and then link in the one that you need. The rest of the code doesn't have
to know about the differences then.
>
> > A generic serial connection to the programmer sounds a nicer solution
> > than porting the parallel-port programmer, since it would be usable with
> > all Unixes rather than being Linux-specific. A special device driver
> > that only works on PC-Linux seems barely better than a DOS-only utility
> > to me.
True. In fact, hey, just write another serial object module for DOS.
>
> If I had the choice again, I'd be inclined to get some commercial
> serial-based product since kits are annoying. Good thing I got my
> brother to put this one together. :-)
Well, I must be wierd then. I like building kits. The ones from Micromint
are a dream, BTW. Of course, they should offer you the choice of buying
an assembled and tested unit if you want to.
> The one good thing about this kit is that it does verify at min and
> max voltage levels. A definite drawback is that this thing only does the
> 16C5X series chips.
Aha, as I figured. If I ever get around to designing my programmer, it will
have a variety of Vcc and Vpp and programming algorithms. I will probably
base it on an 8051 due to external memory addressing issues and the presence of
a real UART onboard. Oh, and I already have a programmer for 8751s.
Programming will be via the serial port, with a choice of XON/XOFF or hardware
handshaking, and the protocol will be open. Normal asyncronous serial support
is necessary for platform independence. Once that is done, parallel port
support is just another access method. A major goal of this is to be
able to program not only the entire PIC family, but also other microcontrollers,
EPROMS, and EEPROMS.
Is somebody already doing this? Is anyone interested in banging out the details
and the hardware with me? Would the world be terribly mad at me if I wrote
the host side software in C++ instead of C?
> When I get around to porting the serial routines, it won't be very
> Linux specific. I just won't promise it will work on platform XX unless
> someone gives a nice XX system. :-)
Reasonable.
> Personally, it would be nice to have a unified set of unix tools with
> a back end for each product but that's probably wishful thinking.
Oh yes. And no fancy GUI stuff. I want to be able to use the tools from a
makefile. If someone else wants to write a fancy front end for the tools,
they can, but the command functionality must be there.
Right now, I'm working on an
assembler which will be flexible enough to work on all of the PIC family just
by loading up a different table of opcode descriptions. A feature of this
assembler will be strong typing and promotion such that:
clr label
translates to
clrf 6
if label is register file 6 and
clr label
translates to
cbf 6,0
if label is register file, bit 0.
I already have that functionality, but I am redesigning the assembler to make
expression parsing work correctly with parentheses, and make it more flexible.
Excerpts from mail: 31-Oct-94 Re: 16C84 downloader for Linux by Lou RemoveMESortmanRemoveMEEraseMENCINFO.IOG.U
> Aha, as I figured. If I ever get around to designing my programmer, it will
> have a variety of Vcc and Vpp and programming algorithms. I will probably
> base it on an 8051 due to external memory addressing issues and the
presence of
> a real UART onboard. Oh, and I already have a programmer for 8751s.
> Programming will be via the serial port, with a choice of XON/XOFF or
hardware
> handshaking, and the protocol will be open. Normal asyncronous serial
support
> is necessary for platform independence. Once that is done, parallel port
> support is just another access method. A major goal of this is to be
> able to program not only the entire PIC family, but also other
microcontrollers,
>
> EPROMS, and EEPROMS.
>
> Is somebody already doing this? Is anyone interested in banging out
the details
>
> and the hardware with me? Would the world be terribly mad at me if I wrote
> the host side software in C++ instead of C?
I'm going to design a _very_ similar universal programmer, but I
have a few other things that I'd like it to do such as chip
identification and verification. I've been researching bits and pieces
of it as I get time, but the actual project will have to wait until the
summer. I'm not much of an analog person, so that's the stuff that I
really have to research... Go ahead and use C++! It would be a crime
not to. I'm going to go with an HC11 or HC16 microcontroller instead of
an 8051 variant though.
Chris Kristof
Junior ECE
Carnegie Mellon University
>
> I have another 16C54 question as well. Since the '54 doesn't have
> an interrupt for the RTCC what's the usual procedure for running
> a given section of code periodically, say every 100mS or so? Can
> you run a tight loop waiting for the RTCC to roll over from some
> calculated value or will this methos "miss" the rollover if you simply
> test for it to be equal to zero?
>
I have used a very accurate method for timing control with the RTCC.
The main mechanism is this piece of code:
You define a value below 255 for "cycles", RTCC is set to count
instruction cycles without prescaler. That gives you around
"cycles-15" maximum clock cycles within you can do what you want and
return to this main poll loop any time. It will always time itself on
the exact cycle. Pretty neat when no interrupts are available..?
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...
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. RemoveMErdcspamBeGoneRemoveMEdoc.ic.ac.ukKILLspamstoicspamBeGoneic.ac.uk
----------------------------------------------------------------------------
I seem to remember a device which allow one to apply some
percentage of the AC waveform similar to pulse width modulation. That
is:
full power = full waveform
half power = 180 degrees of waveform
X% power = appropriate % of the waveform
>A quick follow on question,
>
> I seem to remember a device which allow one to apply some
>percentage of the AC waveform similar to pulse width modulation. That
>is:
> full power = full waveform
> half power = 180 degrees of waveform
> X% power = appropriate % of the waveform
>
>I do not remember what that device is. Any help?
I don't know the correct English name, but you find that in (most)
so-called dimmers for lamps. It's basically a triac, a
zero-crossing-detector, and some sort of delay device (might all boil down
to a RC and a trigger diode). If you want to use it with a PIC, you'll have
to detect the time of the zero-crosing of your AC, wait
(1 - X%) * (1/ACfrequency), and then trigger your triac (or opto-coupler
*without* zero-crossing detector) (basically).
>
>Thanks Markus for your quick reply.
You're welcome. Any distraction appreciated (at that moment :-) )
The 1993 data sheets for the 16C71 state that a branch to the interrupt
vector occurs on wake-up from SLEEP when global interrupt is disabled (GIE=0).
Surely can't be right.
The 16C84 specs describe what I would expect to happen: branch to the interrupt
vector when GIE=1, continue executing the next instruction after SLEEP when
GIE=0.
How does a 20 pin micro with 128 bytes RAM, 2K reprogrammable FLASH memory,
15 I/O lines, Serial IO, 5 Interrupts, 2 Timers etc sound to you? Well
this is exactly what ATMEL came up with in their new AT89C251 microcontroller
that is just being released. The chip is fully compatible with normal
8051 microcontrollers except for the fact that it's smaller, has less I/O
pins and draw less current. Just think of all the high-level compilers that
you can use with these devices. Hows that for competion for PIC's?
I know this newsgroup is about PIC microcontrollers and NOT its competitors,
but I think that I am more likely to find a solution to my problem from
you guys than anywhere else. My problem is namely this :
I'm very urgently trying to build a programmer for these devices. However
so far I was very unsuccesfull in locating programming info or algorithms
on how to do this. Even when I wrote to ATMEL themselves they only send
a data sheet which did not contain the vital info. A article in Usenet
sci.electronics also yielded no results. Any comments would be appreciated.
Just by the way speaking of programmers : I have build a very succesfull
low cost programmer for above chip's bigger brothers (the AT89C51 and
87C51). The programmer can be build for under $100. If anyone is
interested in building one for themselves I can send them the Orcad
schematic drawings as well as the software to implement it. Just
email directly to me at:
> How does a 20 pin micro with 128 bytes RAM, 2K reprogrammable FLASH memory,
> 15 I/O lines, Serial IO, 5 Interrupts, 2 Timers etc sound to you? Well
> this is exactly what ATMEL came up with in their new AT89C251 microcontroller
> that is just being released. The chip is fully compatible with normal
> 8051 microcontrollers except for the fact that it's smaller, has less I/O
> pins and draw less current. Just think of all the high-level compilers that
> you can use with these devices. Hows that for competion for PIC's?
I've used quite a few of the 40-pin 89C51 micros and they are indeed nice.
They aren't however as frugal with power as the smaller PIC chips and
they cost quite a bit more (don't know about the '251). The last time
we bought 89C51's they were around $11.00 ea for 500 pieces and the
89C52's (8052 compatible) was around $15.00.
I will concede the point about languages though--my C compiler with
floating point, etc. does tend to spoil me!
We were told by our Atmel rep (also our MicroChip rep by the way) that
Atmel sees the 89Cxx processors more as alternatives to prototyping
with 87Cxx series parts than they do for production use. I think
if they looked more towards people that use them in larger quantities
to set pricing they could own a much more significant share of the
market.
That's enough. Don't want the topic police after me... :)
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 spam_OUTcarlSTOPspampipeline.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,
> (TakeThisOuTRichard_FriesenspamRemoveMEmindlink.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.
Well, as long as Tom Kellett's going to put my code into a compilation
and slap his own copyright notice on it without even asking, I guess I
might as well post these 16C57 macros for easy GOTOs and CALLs across
page boundaries.
The code is written for use with Microchip's MPASM assembler; see the
comments for changes necessary for use with Microchip's old MPALC/PICALC
assemblers. Those of you using PASM are on your own (as usual).
; The following code was written by Andrew Warren and is
; copyright (C) 1992 by Fast Forward Engineering. Permission
; is hereby granted for any non-commercial use so long as
; this copyright notice is retained.
; "Long Call" macro. Invoked by "XCALL any_address".
; Thanks to Chris Dalla for pointing out the need for the "+2" and
; "+1" sums in the last two lines of the macro.
XCALL MACRO LABEL
DATA 010010100000B+STATUS+256*((LABEL>>9)&00000001B)
DATA 010011000000B+STATUS+256*(LABEL>>10)
LIST W=1 ;For MPALC/PICALC, make this an "E=2".
CALL LABEL
LIST W=0 ;For MPALC/PICALC, make this an "E=1".
DATA 010010100000B+STATUS+256*((($+2)>>9)&00000001B)
DATA 010011000000B+STATUS+256*(($+1)>>10)
ENDM
; "Long Goto" macro. Invoked by "XGOTO any_address".
XGOTO MACRO LABEL
DATA 010010100000B+STATUS+256*((LABEL>>9)&00000001B)
DATA 010011000000B+STATUS+256*(LABEL>>10)
> 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.
>
>Is the format of the Intel HEX file available in electronic format
>somewhere? Or is it so simple that someone can just quote it in an
>e-mail message?
The Intel Hex Format is viewable by a text editor where you will find
the following for example.
Looking at the second line for reference you have:
The new line marker :
Then the first two bytes are the number of data bytes in the record 06
Then is a 4 byte address 0010
Followed by the record type 00 (01 means EOF)
Then the actual data bytes followed by a two byte check sum DE
The check sum is the 2's complement of all preceding bytes in the record for
example:
6h + 10h + 2h + Ah = 22h = 00100010b
Take 2's complement = 11011101b
+ 1
_________
11011110b = DEh
I hope this helps.
Joseph D. West
Electronics Lab. Supervisor
College of Mechanical Eng.
Ohio State University
>Is the format of the Intel HEX file available in electronic format
>somewhere?
> ....
>I just want to write a simple filter to add device information to the
>output generated by the PCM C compiler for use with PEP84 and the
>Parallax programmer.
Jason:
Be careful... The addresses in the HEX file may not correspond exactly
to the addresses in your PIC, since the 16C84 uses 14-bit words and the
Intel Hex (8-Bit Merged) format expects only an 8-bit byte at each
address.
A quick look at the output of your compiler, using the information Joe
West posted, should make the correspondence between actual addresses
and HEX-file addresses clear.
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.
=> Can someone tell me how many AD/DA's the PIC has and how
=> much memory it can easily support?
My databook is pretty old, but neither it nor the PIC FAQ mentions
devices with A/D or D/A capability. (You can fake D/A by toggling an
output line, varying the duty cycle, and filtering it.) There are
several different types of PICs, and they have RAM/ROM/IO-line specs
ranging from 24/512/12 to 480/8K/33. (RAM is in *short* supply, but
you can always add one of Microchip's serial RAMs for external
storage. You could even add a regular RAM, but it would eat up a lot
of I/O lines.)
=> I am thinking about building a data acquisition system for a radio
=>control airplane. I want to record altitude, airspeed, temperature, engine
=>rpm, and if things go really well, to use the PWM features of whatever
=>chip I choose to actually aid in piloting the plane....
I'm currently designing a flight instrument (for paragliding) around a
PIC16C84. It'll have an altimeter, thermometer, real-time clock,
lift/sink audio alert, and an RS232 port for downloading info to a PC.
I think I'm going to have a lot of trouble getting all the software
into the 1K EEPROM, and I *know* I'm going to have a lot of trouble
making the 13 I/O pins suffice -- the RS232 may have to go.
I had originally planned to use the HC05 or HC11 for this, but you
can't get 'em. At least, I couldn't. And now that I've gone to the
trouble of building a programmer and writing a simulator, I'm going to
at least give the 16C84 a try.
Is there anything similar to a frequently asked questions list
concerning PIC's? I hear these chips described as reduced instruction set
devices. As one who has written assembly code for the 6502, 68HC11, and 8086,
what does this actually mean?
How many instructions per second can the garden-variety PIC's execute?
It seems that one good possible use for one of these devices would
be to give a second life to a cast-off infrared remote control. One could
feed the proprietary data stream from the remote to a PIC and program the
PIC to convert this format into ASCII or whatever to allow one to add remote
control capabilities to a project. In order to do this well, the PIC would
need to have shift and test capabilities and other such bit-wise operations
so that one could build data frames.
Finally, I saw a project in "QST" magazine which used a PIC1654
as a Morse Code generator. The device had a clock composed of a RC timing
circuit so that one could vary the speed by changing the R component. Can
these devices also run off of a crystal or an external timing signal derived
from a crystal?
Thank you for any and all tidbits of information.
Martin McCormick WB5AGZ Stillwater, OK
OSU Center for Computing and Information Services Data Communications Group
If anyone out there is an experianced PIC and (other processor) programmer and
Electronics Engineer or experienced Technologist, and are living in or planning
to move to the Vancouver BC area and looking for a permanent position (or you
know someone who is) contact me.
Experince that would be an asset would include video (AM and FM), audio and data
communications, microwave, RF or baseband satellite and cable. PIC (ASPIC
preferably) and/or 6502 (or Mitsubish 37700 etc.) assembly language and C, DOS,
Windows, C and Visual Basic.
We have 2 immediate openings to fill.
Cheers, all.
I hope messages like this are not out of line here in the list. If they are, I
appologise, flame me, I can take it.
I have read the messages about various "big machine" c-compilers which may be
portable to pic:s. I must say that there is no reason to program a 0,5k to 4k
microprocessor using such a compiler. It's probably better to use the powerful
macro features in MPASM to make small code fragments and make code writing
easier.
I usually start a project by writing special macros for input and output such as
TSW SkipON and TSW SkipOFF. This macro tests input from a port pin (Tilt Switch
connected) and if this input is ON the next instruction is skipped. If you need
to change pin function, just edit the macros.
I also have a couple of macros for conditional jumps (test for carry, zero, ...)
If we are talking about the 16C42 when used in microprocessor mode you might
want a C-compiler ... (it takes time to write 64k of assembler instructions).
As there has been a lot of interest in C compilers for the PIC, I
thought people might be interested in my current attempt at a Pascal
compiler for the 16C84.
The compiler needs ms windose and can successfully compile
simple pascal programs. It produces hex files with which i've
programmed a 16C84 (and it acutally worked!).
The compiler is still very much in the early stages of development,
but if anyone wants to get it then the src and exe's then they
are ftpable at dragon.herts.ac.uk:/pub/PIC/PICDEV.
I would be interested to hear if people think it is worth carrying on
with or if it's a waste of time and space.
Ian
******************************************************************************
Ian Munro - Electronic Engineering
University of Hertforshire, College Lane,
Hatfield, Hertforshire.
England
Email: TakeThisOuTI.MunroRemoveME@spam@herts.ac.uk EraseMEIanRemoveMEdragon.herts.ac.uk
Tel: +44(0) 1707 284160
******************************************************************************
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.
Thanks very much for your reply concerning solving of equations (with
natural logs in them). You've probably read my general reponse, which
shows that in my application a lookup table (not huge) would be plenty
sufficient for what I am trying to do. But I would be interested in the
topic of finding easy PICable ways to do natural logs if the information
is readily available. I'd hate to have somebody spend an hour digging
through their attic.
I think I've been fairly quiet recently, but I expect most of you
don't want to hear about my programmer yet again. However, the ever
increasing exposure of PICs in hobby magazines has meant that I am
getting more mail than ever about my DOS based 16C84 programmer. I
know my stuff is not without it's problems, but I hope a lot of people
are able get it going without too much hassle. Of course others need
some help and I spend a little of my time every week giving advice by
e-mail. I'm sure there are still others that have thrown the thing in
the bin in sheer frustration.
To help these people, and perhaps ease my e-mail burden, I have put
together a FAQ file. It can obtained from the circuit cookbook site
at the University of Alberta as:
(The programmer stuff is in the same directory as pic84pgm.zip)
Here is a short description of pic84faq.zip:
This file contains answers to frequently asked questions about the
simple 16C84 programmer distributed in PIC84PGM.ZIP. If you have had
problems getting it working grab this. Even if you have got it
working, it is worth picking up because it also includes C and QBasic
source to demonstrate how to dump 16C84 program memory as an Intel
Hex file (No. The programs can't read protected PICs :-)
If it helps you resurrect an abandoned attempt at getting my programmer
going let me know!
>
> I have seen a note somewhere about that the Mchip BBS was mirrored to a
> site on internet. It is expencive and troublesome to call Compuserve from
> where I live since it will be a long distance call.
>
> Ulf
>
Well, you can find Microchip stuff at a lot of ftp sites. For example:
I hope you find some of them appropriate. By the way, if you have access to
WWW-services you can find a lot of possibly interesting links on the WWW-pages
I maintain on behalf of Admittansen, the academic electronics society of
Linnkoping University. Most of the pages are in swedish, but the links
are also accessible from the english part. The URL to these pages are:
> 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 --
> 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.
I my recent design, I have 16 bright leds and they need a lot of current. If I
switch them very fast (2kHz or so) the PIC resets. It happens after some time
and it seems to be a problem with the power supply to the PIC. If I insert a
capacitor in parallell, the problem goes away until I raise the supply current
even more to the leds (I use buffers to control the leds so the PIC doesn't need
that much current).
How much did you raise the LED current?
How are you raising the supply current to the LED's?
What device is the buffer for the LED's?
Describe the trace lengths/locations of the supply, PIC, buffer & LED's?
What are the V and I spec's for the supply, PIC, LED's & buffer?
How much did you increase the filter cap?
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
> --
> TakeThisOuTdavid.taitman.ac.uk
>
> I my recent design, I have 16 bright leds and they need a lot of current. If I
> switch them very fast (2kHz or so) the PIC resets. It happens after some time
> and it seems to be a problem with the power supply to the PIC. If I insert a
> capacitor in parallell, the problem goes away until I raise the supply current
> even more to the leds (I use buffers to control the leds so the PIC doesn't
need
> that much current).
Scott Stephens wrote ...
> How much did you raise the LED current?
> How are you raising the supply current to the LED's?
> What device is the buffer for the LED's?
> Describe the trace lengths/locations of the supply, PIC, buffer & LED's?
> What are the V and I spec's for the supply, PIC, LED's & buffer?
> How much did you increase the filter cap?
The problem is that I don't want sixteen resistors on my board so I use
"built in" current limiting in two 74HC244:s. Yesterday I checked the
voltage drop over the PIC with my osc. and deltaV = 2V (too much I guess).
The simplest solution to this was to place a couple of diodes from
V+ to Vdd of the 74HC244 and now it works with deltaV = 0.2V (but with
a little less power output from the leds.)
-----------------------
Conny Andersson / LiTH
I remember somebody was looking for a picstart.
Saw this in sci.electronics and thought I'd repost it.
In sci.electronics Dave Fors said:
FOR SALE: Microchip's PICSTART-16B1 development system.
Microchip's PICSTART-16B1 development system provides design engineers a
fast, easy and very
low-cost way to begin evaluation and code developmenbt of PIC
microcontroller products. The
PICSTART-16B1 comes complete with:
assembler and simulator software
programmer board
PIC16CXX product samples
supports the full range of PIC16C54/C55/C56/C57, PIC16C71 and PIC16C8
products
90-250VAC - 50/60 Hz power supply
RS-232 cable
Assembler Manual
Simulator Manual.
System documentation includes Microchip's new Embedded Control Application
Handbook and the
Microchip Product Data Book. The PICSTART-16B1 programmer board accepts
18- and 28-lead
PIC16CXX devices. System software includes MPALC Assembler, MPSIM
Simulator and
programmer software to read and program all PIC16CXX products. MPALC is a
PC hosted
symbolic cross assembler used to convert source code into object code.
MPSIM is a very efficient
discrete event software simulator designed to imitate the operation of all
PIC16CXX
microcontrollers.
Digi-Key price $195. Your price $125 shipping within USA included.
(PICSTART never taken out
of box or used). I'm selling it because I got into computer servicing
instead of hardware design.
--------------------------------------------------------------------------------
--------------------------
later .......
carl
Henry Carl Ott N2RVQ EraseMEcarl.....KILLspampipeline.com
------------------------------------------------
No wife, no horse, no spell checker.
------------------------------------------------
I see in DigiKey the 16C64 has 33 I/O lines. Can you use all of these
lines for general I/O? The 68hc11 claims it has 30+ I/O lines too, but in
reality 8 lines are dedicated for A/D, 2 lines dedicated to SPI, 3 or 4
dedicated input compares, 5 or 4 dedicated output compares, etc.
It seems to be a common problem to not provide sufficient bypassing on PIC's
because they "use negligable current". There are two effects that happen when
you under-bypass a part like the PIC because they are CMOS (this is not new
btw., anyone remember the COSMAC 1802).
1) CMOS switches have low impedance, so when switching low impedance (or worse
yet capacitive) loads, if your PIC has insufficient bypass the power supply,
traces, etc. take a while (several nanoseconds) to catch up. The dip in voltage
can cause reset.
2) You should expect some very short pulses of high current when switching
capacitive or low impedance loads. This is because the output gates may turn
on/off asymetricly under adverse load conditions, causing a momentary current
path from VDD to VSS.
Proper bypasing with capacitors of various characteristics (and don't forget
proper termination of the reset line) is often a cure for this bizarre behavior.
As Scotty was so fond of saying:
"Ya canna change tha lawhz af phyzzicss, Caaptain"
- Don Lekei
PS. Of course I could be wrong, and this whole thing is a "not initializing all
registers" thing.
>It seems to be a common problem to not provide sufficient bypassing on
>PIC's because they "use negligable current". There are two effects that
>happen when you under-bypass a part like the PIC because they are CMOS
> .... etc.
Don:
Do you think it's possible to make a full-time career out of advising
people to use bypass caps? You have a pretty good start...
> Has anyone attempted to get a PIC to talk to a floppy drive (or IDE) so
> that data can be stored in a simple form. My ultimate goal is to send
> serial data to a floppy via a PIC for later retrieval, such as, a time
> stamp and 8 bits of data. Please Email me.
>
This should be a FAQ. If it already is, I would like to have a pointer to it.
To add some value to this post, you might want to have a look at the IDE spec
at:
ftp://wuarchive.wustl.edu:/pub/msdos_uploads/hard_disk/ide-tech.txt
or under
ftp://ftp.ncr.com/pub/standards/io/
in the ata files.
That doesn't help with the floppy interface, though. From what I've seen of
the floppy interface, it shouldn't be too hard to bit-bang. Does anybody out
there have a write-up of the gory details?
In either case, you're probably going to have to do some buffering or acquire
your data as you are writing it to disk.
>I have looked at the FP package for the pics from the MC BBS. It only
>supports basic FP stuff. Is there any place with a FP package that
>supports trig, log, etc...
>
>Is there a C that has FP built in?
>
>Thanks
>
>Mark
I don't know about the above, but check out an algorithm called CORDIC. It
provides a set of fixed-point trigonometric functions in an iterative
algorithm.
There are probably other references, I'm giving you the ones I've got
(Article plus references from that article):
Zahlenmuehle
Rafael Daliano, Raimund Perz
in elrad issue 3 1995, Heise Verlag, Hannover
p. 30
J.E. Volder
The CORDIC Trigonometric Computing Technique
IRE-EC 1959 (!)
p. 330
J.S. Walther
A unified algorithm for elementary functions
Spring Joint Computer Conference (SJCC) 1971
p. 379
Hope this helps a bit. I thought it is quite interesting. This algorithm
can deliver sin, cos, atan, sinh, cosh, atanh, division with nothing more
than a few add, multiply and shift operations.
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 bbolesSTOPspamKILLspammicrochip.com
>From: Brian Boles -- Applications <@spam@bboles.....spamMICROCHIP.COM>
>Subject: Is a moderator listening?
>
>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 spambboles..........microchip.com
Well, *I'm* pretty moderate at times. I think you should post away
with abandon! It'd be nice if you didn't flood the list with
marketing BS, since we all pretty much know that stuff already. Full
text of every magazine ad you're running, etc, is Right Out.
Technical discussion, new product announcements, responses to bug
reports, general state of the business, etc, would all be welcome.
Tom Mornini from Parallax is here, as are a number of other
commercial vendors. After all, quite a bunch of us here are using
these things to create products, make money and become good little
capitalists. :-)
If you wanted to talk about EEPROMs, weird little battery chips,
Basic Stamps or anything else small-system-related, we're the sorts
who'd enjoy it.
We don't have a moderator; Jory Bell maintains the list, but any
old bozo can post to it. And there *have* been a few..... forbesm.....peak.org
Mark G. Forbes
"Never ascribe to malice that which can be blamed on the engineer."
Brian's main intention is to post job openings at Microchip in his group.
He would like to know if this is ok with the readers of this list.
Obviously, this list is a good source of PIC-literate engineers :-).
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 :)
What about C? And/or Forth for the 16CXX stuff?
Byte Craft C is just way too expensive ... it's not
like it has a floating point package or something
really cool ...
Dear Daniel,
The following information is over a year old, but may still be
valid. A minimal Forth-like development system (and information on it) is
available from:
Alan M Robertson,
RAM Technology Systems Ltd.,
3 Kellaway Road,
Poole,
Dorset, BH17 7PD.
England
FAX 44 (0) 1258 456410.
It costs about 230 pounds plus 10 pounds carriage plus VAT at 17.5% in its
full form for hardware programmer and software development system. It
consists of a 'Smart-ICEPIC' which will program PIC 16C64/71/84, with a
header or cable to plug into the target system for ICE development.
Programming software runs on a PC using a few pins on the parallel printer
port.
However, the interesting part is that for the 16C84 there is a small
Forth-like 'Target Link Monitor' TLM, which lives in the PIC, of only about
120 EEPROM program words containing the code for the Forth words:
STACK> >STACK fC@ SP@ EXECUTE FREEZE PIC.RESET SERVER
These can be executed by sending the execution address down the same 2 wire
serial connection to the unit that is used for programming it. The STACK>
word waits for the host to send two bytes of data. The word EXECUTE
performes a computed goto to this value as a CFA code field address. The
SERVER word consists of
: SERVER ( S - ) BEGIN >STACK >STACK EXECUTE AGAIN ;
so two 16 bit values arrive over the serial link, are put on the stack and
consist of an address which is executed. A method of examining register
contents is:
STATUS fC@ H.
where STATUS is translated on the host, before sending information to the
target PIC. The host system on the PC is F-PC from Tom Zimmer which holds
the dictionary etc for the target PIC. There is also a library of useful
Forth word extensions etc.
At any time you can permanently load in extra words to the EEPROM by
programming them in, then switch back to interactive testing. Although the
initial words provided are minimal, the system can be extended with
whatever new words are desired.
The philosophy seems excellent for interactive development on a minimal
system. I am trying to decide whether to take the plunge and buy one!
>*>I am developing a 16C84 PIC based product with and RS-232 interface and a
>*>Real-Time Clock. Any hints, suggestions or recommendations?
>*>
>*>Dan Garlen
>
>For the clock: Philips PCF8573 or PCF8583 - Since the `84 has I2C
>built in these should work fine.
>
>
Wait a second. Since when does the '84 have I2C built in? On the other
hand it does not take much code to handle the I2C primitives. If you just
want to talk to a single I2C slave (such as the PCF8583) then it really is no
problem at all.
Speaking of which.
I have on hand a quantity of SMD PCF8583 (I2C real time clock,with 256
bytes ram) that I don't have an immediate use for. If anybody wants some for
experimental uses then send a self addressed stamped envelope to the below
address and I'll drop a couple of chips along with 32khz xtals into it and
smail it back to you. Keep in mind these are surface mount devices.
I'm doing this as a favor to readers of this list who have problems getting
samples. So to keep things from getting out of hand I'm limiting it to the
first 25 people and only one offer per address. As for data sheets and such
you're on your own.
Henry Carl Ott
22 Nixon Ave.
Staten ISland, NY 10304-2210
=>There's another Unix simulator around, too - it was posted to this group
=>by Dave Madden <.....dhmRemoveMEVHEISSU.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.
> Greetings,
>
> I am new to this ... I hope I'm doing this right!
>
> I am developing a 16C84 PIC based product with and RS-232 interface and a
> Real-Time Clock. Any hints, suggestions or recommendations?
Dan,
Tell us what you are up to and we will be able to give you some advice,
otherwise, look for the appropriate application notes.
-----------------------
Conny Andersson / LiTH
*>Aaron Sliwenkski <KILLspamaaronsTakeThisOuTIHS.COM> writes:
*>> *>I am developing a 16C84 PIC based product with and RS-232 interface and a
*>> *>Real-Time Clock. Any hints, suggestions or recommendations?
*>> *>
*>> *>Dan Garlen
*>>
*>> For the clock: Philips PCF8573 or PCF8583 - Since the `84 has I2C
*>> built in these should work fine.
*>
*>The '84 has I2C built in? I don't think so. If you want this, you
*>must implement protocols in software, and there's no I2C support in
*>hardware either. This does take up a certain amount of the (limited)
*>memory, of course....
*>
*>Richard H
You're right, I was thinking of the `74, but if one wants to use an
external clock the two wire interface is superior to any of the parallel
approaches that suck up a bunch more pins that could be put to better use.
I agree the `84 is a bit cramped for code space in comparison to the `74
but the code to implement the interface protocol is very simple and may
be worth the memory.
>>*>I am developing a 16C84 PIC based product with and RS-232 interface
and a
>>*>Real-Time Clock. Any hints, suggestions or recommendations?
>>*>
>>*>Dan Garlen
>>
>>For the clock: Philips PCF8573 or PCF8583 - Since the `84 has I2C
>>built in these should work fine.
>The '84 doesn't have I2C built in (oh how I wish it did). I think it
is the
>'64
>that does have it.
>
Correct, there is no I2C on the 16C84. But for real time clock why
don't you try the Dallas Semiconductors TimeInaCan(DS1494 TIC). It
takes only one I/O pin and some code to communicate with it.
Has 4K of memory, alarms, interupts on alarm and more....
On Thu, 18 May 1995, Jordanis Haralampopoulos wrote:
> Correct, there is no I2C on the 16C84. But for real time clock why
> don't you try the Dallas Semiconductors TimeInaCan(DS1494 TIC). It
> takes only one I/O pin and some code to communicate with it.
> Except if you are looking for something that has a wake-up
> function..... to wake-up a sleeping uP......
I have used the TIC with a 16C84 in a design. I wrote the support code
for the 1 wire protocol one night over a six pack. So it's not a major
time investment in software. But it is nice to have a scope available so
you can see if there is a hardware (i.e. pull-up resistor) or software
i.e. timing or TRIS register problem.
I wrote the routine in C (CCS compiler) -- I know people on this list
think that is a sin, but it simplified the job in my opinion. I can
send you the C (and the compiler generated assembler) if you would like.
>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.
Why you need:
-------------
1. VOLTAGE LEVEL CONVERSION
-------------------------
The MAX232/3 acts as a voltage level converter.
It converts the 0/5V TTL level of the PIC to
+12/-12V level of the RS232 target system.
The MAX232 employs a charge pump to achieve the
larger voltage. The charge pump requires external
resistors / capacitors for the MAX232.
The MAX233 has these resistors / capacitors on chip &
therefore offers a SINGLE CHIP TTL <--> RS232 VOLTAGE
LEVEL CONVERTER.
What you need to know:
----------------------
The MAX232/3 contains two receive & two transmit buffers
(ie you can convert two different TTL signals to RS232 &
two different RS232 signals to TTL).
For a bare-bones-up-and-running-quickly implementation
you need only one transmit and one receive buffer.
For handshaking (if it's necessary) the spare transmit and
receive buffer can be used for CLEAR_TO_SEND (CTS) and
REQUEST_TO_SEND (RTS) signals.
Using these spare buffers in this way will improve
communication reliability.
Example (My first attempt at ascii art!) :
--------
BARE-BONES-UP-AND-RUNNNG-QUICKLY IMPLEMENTATION:
> RS232 interfacing made easy.
>
> What you need:
> --------------
> 1. MAX232 / MAX233
Anyone know of a solution like this that allows you to tri-state the RS232
outputs? (The +/-12V side - NOT the TTL side.)
--
-- Paul Greenwood -- (RemoveMEpablospamSTOPspamaustin.ibm.com)
For an idea to be fashionable is ominous, since it must afterwards be
always old-fashioned.
"His super power is to turn into a scotch terrier."
Some of the Linear Technology RS232 transcievers let you externally
shut down the chip, I don't recall if it puts the inputs and outputs
in a high-Z state.
> > RS232 interfacing made easy.
> >
> > What you need:
> > --------------
> > 1. MAX232 / MAX233
>
> Anyone know of a solution like this that allows you to tri-state the RS232
> outputs? (The +/-12V side - NOT the TTL side.)
>
> --
> -- Paul Greenwood -- (.....pabloEraseMEaustin.ibm.com)
> For an idea to be fashionable is ominous, since it must afterwards be
> always old-fashioned.
>
> "His super power is to turn into a scotch terrier."
>
>> RS232 interfacing made easy.
>>
>> What you need:
>> --------------
>> 1. MAX232 / MAX233
>
>Anyone know of a solution like this that allows you to tri-state the RS232
>outputs? (The +/-12V side - NOT the TTL side.)
>
>--
> -- Paul Greenwood -- (spamBeGonepabloRemoveMEaustin.ibm.com)
>For an idea to be fashionable is ominous, since it must afterwards be
>always old-fashioned.
>
>"His super power is to turn into a scotch terrier."
I'm no expert but I might try using a diode to turn the RS232 Level to
pullup only and use a terminating resistor to pull the line low at the end
of your chain of devices.
Doug Sellner
Beach Tech
4131 Vincent Avenue South
Minneapolis MN 55410
Could someone point me to a library for microchip devices for Protel?
In particular I am interested in a library that might contain a PIC 16C57.
regards
Gary Gaskell Cooperative Research Centre for
Research Scientist Distributed Systems Technology
DSTC Ph: 61 7 864 1051
Level 12, ITE Building Fax: 61 7 864 1282
Queensland University of Technology Email: spamgaskellspam_OUT@spam@dstc.edu.au
Brisbane, Australia.
_________________________________________________________________
> 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 spamkalle@spam@STOPspamdata.co.za
Interface Products Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750 Fax: +27 (11) 402-7751
>
> Hi all,
> I use the HP rotary encoders alot, but I have never been able to get hold
> of HP linear encoders, the last I heard was that they had discontinued the
> linear stuff.
> I would REALLY like to be proved wrong!
> Do you have a Tel/ fax number/ email address for HP PhotoOptics?
> Cheers,
> David
>
Hi David,
I just looked through the HP Optoelectronics Designer's Catalog (1993)
and they feature an HEDS-9200 Linear Optical Incremental Encoder Module
with several options (resolution). I called a local San Francisco Bay
Area distributor and they had 500 pieces in stock at a price of $23.60
each for a quantity of at least 250. Single piece price is $28.50.
If you tell me where you are I can send you the Tel/FAX/address for
the sales or distribution center near you.
> I use the HP rotary encoders alot, but I have never been able to get hold
> of HP linear encoders, the last I heard was that they had discontinued the
> linear stuff.
> I would REALLY like to be proved wrong!
> Do you have a Tel/ fax number/ email address for HP PhotoOptics?
Hi, I picked up a data sheet from a trade show here that is copyright 95
by HP and describes a NEW reflective optical encoded for code wheels or
strips. Incremental types with 70-75 lines per inch. Supplied in a
SO-8 package with moulded in lenses and quadrature outputs.
Obviously for all the new printer and scanner technologies.
Part numbering starts at HEDR-8000
--
Kalle Pihlajasaari RemoveMEkalleRemoveMERemoveMEdata.co.za
Interface Products Box 15775, Doornfontein, 2028, South Africa
+27 (11) 402-7750 Fax: +27 (11) 402-7751
The following info is taken from ETI magazine and should enable
those in the US to obtain both issues (May & June 1995) of ETI,
detailing the design/construcion of both H/W & S/W for a
universal PIC Programmer.
(If you (can) order the article alone (not the entire magazine) bear )
( in mind that the PCB foils are usually at the back of the magazine,)
( and not in the article itself. )
ETI (Electronics Today International)
=====================================
=====================================
<< Don't know if this is relevant but I'll include it anyway: >>
ABC (Audit Bureau of Circulations)
ISSN 0142-7229
Consumer Press
Publisher / Overseas / Back Issue Address:
==========================================
* 1. Published by ARGUS SPECIALIST PUBLICATIONS:
* 2. Overseas & non-newstrade sales by Magazine Sales Department:
* 3. Back Issues can be obtained from:
(1., 2., 3. have the same address:)
Argus House, Boundary Way,
Hemel Hempstead HP2 7ST,
England.
tel. : (0442) 66551
fax. : (0442) 66998
USA Subscription:
=================
Subscription Rates: (Published Monthly)
US Dollars Overseas $56.00
Sterling Overseas k31.00
<< This answers the question: "how much is k35?" >>
US subscriptions by Wise Owl Worldwide Publications,
4314 West 238th Street, Torrance, CA90505 USA
> Does anyone know where I might be able to get C source for a nice PIC
> macro assembler? (My computer doesnt exactly emulate a PC very well - 1/4
> the speed of an XT at the last count!)
I have written an assembler for 12- and 14-bit PICs. I haven't
really widely distributed it, but I can send it to you if you want it.
It is written in ANSI-C and should compile on most machines.
> Its an uphill struggle to finish the programmer, port the software to a
> complete new architecture, and write an assembler before I can even start
> by target project....
I have also made a PIC16C84 programmer that uses a MC68HC11...
I don't have *C* source for a PIC macro assembler, but I *do* have some example
technology for constructing assemblers using Tcl. I don't know if Tcl will
run on your Archimedes, though. Using Tcl has the advantage that you don't
have to build your own symbol table management routines, and you get immensely
powerful macro facilities, such as looping, optional parameters, conditional
assembly, etc. etc.
If you want to take a look, you can get a sort of ``demonstration'' kit
of our assembler by anonymous ftp from:
I have to agree that I dont think the book is very good.
I am/was a completed beginner but have just finished my first PIC project
(very simple buts works) to control the rotation of a motor.
I bought the PIC book (A Beginners Guide to PIC) plus the PICstart?
development kit + data books. I had hoped that the beginners book would let
get me up to speed quickly. It did not. I found the examples poorly
documented and inaccurate. The book is very badly laid out, overall they
did not help me learn to program the device.
In the end I searched the net
(http://www.lancs.ac.uk/people/cpaame/pic/pic.htm?? is very good) and picked
up various bits of example code (which was more useful than any thing in
the book) and spent time reading the data books.
{Now I have done one project with a PIC I want a reason to do a second, I
had forgotten what fun low level programing can be!!!}
Mike Barrett
>Kevin R. Jones (TakeThisOuTKRJONE01spam_OUTULKYVX.LOUISVILLE.EDU) wrote:
>
>> Why do you feel the book "Sucks" ? I'm looking for very basic
>>information on the PICs and this book seems to be the only one
>>available. If you have any other recomendations ongeeting started with
>>the pic's please let me know.
>
>Kevin:
lots deleted...
>-Andy
>
>--
>Andrew Warren - KILLspamfastfwd.....TakeThisOuTix.netcom.com
>Fast Forward Engineering, Vista, California
>
>
=============================================
Mike Barrett E-mail: TakeThisOuTbarrettEraseMERemoveMEcambridge.scr.slb.com
Schlumberger Cambridge Research Phone: 01223 325200
PO Box 153, Cambridge, CB3 OHG. U.K Fax: 01223 327019
=============================================
>I belive you are refuring to the SPO256-al2 chip set that Radio Shack
>used to sell a few years back.
>
>One was the speech proc and the other is the interface CHIP.
>James K.
>I might have a few somwhere in my collection.
I am assuming, first of all, that Ron wanted to generate speech and not
recognize it. That is of course, something entirely different.
In the Radio Shack set, the SPO256 chip (28 pins) actaully generated the
speech. It could make about 50 different grunts and groans (technically
referred to as "allophones") which could be spliced together to make words.
It didn't sound very good, but theoretically it could say any word. The
other chip in the set was a ROMmed microcontroller (TI 7000 series?) which
would convert ASCII text into commands for the SPO256, attempting to use
phonics to pronounce any word that went into it. Considering what it was,
it worked fairly well. I don't know if either chip is available now.
For generating only a few words, a process which stores the complete words
and plays them back will probably produce better fidelity. I think TI and
National have chipsets to do that. I don't know the part numbers offhand.
I have here a surplus board which I know generates speech, it has TI chips
TMS5220CNL and CM62210NL on it. They were made in 1986 and may be obsolete
by now as well.
Another possiblity is the analog voice recorder chip currently sold by Radio
Shack. But I think they cost $10 apiece even if you don't buy them from
Radio Shack, and also each one would have to be 'programmed' before use by
feeding analog into it. These chips work by storing proportioned amounts of
charge on EEPROM cells (kind of like trying to crack a 16C84, right), so
each 'bit' is actually an entire sample. I think there are versions that
integrate an audio PA as well, so that could save another chip to drive the
speaker.
If you're really into do it yourself, you could sample the words and store
them in digital memory. About 8K bytes per second of speech would be
required, perhaps in an EPROM or Flash ROM. Depending on how much else the
PIC has to do, it would be involved in the playback to varying degrees.
Ron Hackett wrote:
I am looking for a simple (one chip) solution to add basic speech
capabilities to a PIC project. All I need is the digits 0-9 and a few other
words (seconds, minutes, hours, go, stop, time, etc.) Years ago I remember
seeing a chip that had this and many other basic control words built in. Is
anything like that still available??
----------------------------------------------------------
Hi Ron and all other PICcers,
I know three companies, who offer single-chip-solutions for speech/sound repro-
duction:
OKI, NEC and UMC (if somebody knows more, please let me know!)).
Also there exist preprogrammed sound ICs with the IC-code HTnnnn (nnnn is a
number), maybe somebody can tell me the name of the manufacturer???
(Conrad electronic offers them in Germany).
back to OKI, NEC and UMC:
normally all ICs of these manufacturers are thought to be used in high
quantity production.
UMC-ICs are the simplest and cheapest one, offering 4..15 samples at 3..20
seconds sampling time (at about 6 kHz). Only in ROM-version available,
min. order 20.000 pieces :-). They seem to be the right choice for cheap
toy applications. There exist preprogrammed ICs with farm sound (horse, cow,...)
car sound (starting, braking, horn), or animals (seal, lion, ...).
NEC offer better quality ICs, an OTP-version also exists. You will need a
development system, so uninteresting for hobby interests.
OKI offers best quality chips with various features: Speech reproduction only
and Speech recording&reproduction. One family of their chips offers a
certain voice memory (4,8,16,32 seconds @ 8 kHz) but this memory can be freely
partitioned into max. 111 phrases, so you can save max. 111 samples.
You need an expensive development system (of course) but OKI also offers
preprogrammed chips for clock applications. So if you want to say only the
time and date, or numbers from 0..59 this seems to be the adequate chip for
you.
If you need further info, please let me know.
If somebody has any experiece with OKI chips, please let me know - especially
if you know a method/programm to convert WAV-files into OKI's PCM/ADPCM-file-
format!!!
If this OKI-chip will not fit your requirements, the simply user programmable
ISD-chips may be the right solution.
Siggi
Siegfried Grob, |
student of electrical engineering, |
university of ulm, germany |
e-mail: spamsiegfried.grobKILLspamKILLspamstudent.uni-ulm.de |
tel&fax: +49 731 25148 |
--------------------------------------------------'
>The two-chip arrangement mentioned above is familiar to me but I
>can't remember the device numbers.
I think the other part number was CTS256: it was a micro with a
text-to-speech algorithm in ROM, and maybe a UART.
>Unfortunately, I haven't seen the SPO256 chip for a while. The last
>price for these before they disappeared was 2.5 pounds stirling
>(4 dollars US???). Cheap, I suppose, because of popularity; I don't
>know why they vanished.
They were made by General Instruments <doffing hat>. Perhaps
a certain company, well-known to members of the list, acquired the
rights to those chips, too? Nah...
>I have two or three of these but I have to hang
>on to them. I'd be interested if a supplier was found.....
I've seen references to B.G. Micro (in Texas) when people
ask on Usenet about these. I haven't bought from them in
years, though, so I don't have a catalog, and can't confirm it.
* 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.
* This message contains the file 'capture.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.
I used a IR LED - phototransistor pair from radio shack to provide
velocity feedback. The driven gear from the Meccano Errector set
had eight holes just the right size for the LED.
With all the talk on IrDA I browsed through the tech manual of an Intel high
integration Pentium motherboard with IrDA interface on board. On this board
you can redirect COM2 to the IrDA port and then use standard communication
software to communicate via the IR port - at a distance of up to 1M (ONLY?).
The hardware interface to the transceiver module consists of TX, RX, +5V and
GND lines. May it be that these could be RS232-like signals that need
buffering and/or inversion?
The opinions expressed herein is my very own and
does not reflect that of any other person or company.
___________________________________________________
I don't want to throw cold water on people's cool ideas, but
everyone needs to realize that IrDA is more than just a simple IR
modem. There is a specific comm protocol involved. The protocol
takes about 6 to 8 Kbytes when coded in assembler. It also requires
some reasonable sized buffers (several hundred bytes). It doesn't
sound to me like this is going to be very appealing on a PIC with
max 4K instructions.
Of course you could use IrDA hardware without the software for your
own projects, but the cool thing about IrDA is inter-operation of
different devices. For that you need the protocols.
Dave
---
David Boulton | knowledge is just a polite spamboultonspam_OUTnetcom.com | term for dead,
Peregrine Associates | but not buried imagination.
POB 1385 Redwood City, CA 94064 | -- e.e. cummings
I always kinda ignored the errors, because when burning OTPs, I would
also get an error on the fuse burn (more so on a 386SX vs a 486). I do
have a fast serial port on my 486, and not on the 386SX. However, if I
go in and burn the fuses only,, it will reburn them properly. BTW, the
error is that the fuse didn't burn at all (FF), so I am able to reburn the
fuse only. I have also had better success when first burning the fuses then
dumping the program to the part. Also never seems to happen on the window
parts.
On another subject, has anyone attended the seminar ? I hate to go to these
things when you just hear the same old marketing stuff. At least when they
are inhouse, you can always get up and leave. Comments anyone (even from
Microchip)? Besides, Motorola is trying to entice me with the new 6805 type
part right now. Who knows, maybe I'll use both on my next board.
I have more info on the IRDA devices that people have asked about in
the past few days. I received a pile of data sheets from the local HP
marketing guy including a preliminary sheet on the 4Mbit part. Let me
know if you have specific questions or if you want me to Snailmail a
data sheet to you, or FAX it. The marketing guy says:
"HP will be putting on a series of IR seminars in Europe in the
month of July. For more information please contact your local
European sales office or Sybilla Reck at 49-7031-14-2577."
______________________________ Forward Header __________________________________
Subject: PWM control of 90-volt, 2.4-amp DC motor
Author: "BOWDEN; ANDREW V JR" <EraseMEABOWDENRemoveMESCANA.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. .....forbesmspam_OUTpeak.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.
Oh by the way, I didn't forget the pull-up resistors.
Also, in the simulator, I notice that the PORTC bits do not change.
When controlling the TRISC bits in I2C the PORTC bits should indicate
the state of the ouput bit, correct or not? Anyways, whern scoping
the actual PORTC bits on the real hardware, bioth bits 3 and 4 remain
high.
>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
> I need non-volatile RAM for a PIC based design. Because of size restraints I
> would prefer it interfaced on the I2C bus. Also, the RAM will be used to stor
e
> individual parameters, requiring modifying single locations.
I don't know of any non-volatile RAM with I2C interface, but Philips Semiconduct
ors
have several I2C interfaced EEPROM devices. This should do the job for you, prov
iding
you don't want more than about 512 bytes.
> I need non-volatile RAM for a PIC based design. Because of size restraints I
> would prefer it interfaced on the I2C bus. Also, the RAM will be used to stor
e
> individual parameters, requiring modifying single locations.
>
> Does anybody know of companies that have such a product?
Usually you would use some serial EEPROM (or the 16c84). However, if
it must be RAM for some reason, you might want to try the 24KF04
by National Semiconductor.
This is a ferroelectric RAM, serially interfaced (like 24x04 of
other companies).
I have a couple (or few couples?) of problems. How to begin...
So, in one my application I need a kind of voltage source switch.
Let me explain, I'm putting up a circuit (controlled by a PIC, obviously)
that have to operate from the telephone line, when active, and automatically
switch to battery power if the line fails or the circuit is in standby mode.
All this have to be VERY low power, so that the battery do not discharge
too fast (few months min.). I intendend to use a voltage comparator(s) to do
this, then the problem of reference voltage come up. I tried to use a zenner,
but it draws too much current for stabile operation. I found some voltage
reference circuits, but they need too much current/voltage to work properly.
Can I trust the battery for a stabile voltage? Has anybody any suggestion
regarding voltage references (low power 50uW?) or, better, about a
"supply controller"? The entire circuit is working at 3.0-3.3V and draws
6mA max. when functioning and about 25uA when in stand by.
>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_OUTmkeitzspam.....BEV.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.
> I need non-volatile RAM for a PIC based design. Because of size restraints I
> would prefer it interfaced on the I2C bus. Also, the RAM will be used to
store
> individual parameters, requiring modifying single locations.
>
> Does anybody know of companies that have such a product?
If you can stand EEPROM rather than pure RAM, Microchip also manufactures
them, check their www. Other are Xicor and Phillips.
They behave as normal RAM - you can write single byte to them,then read.
They are probably a bit slow on writing (I2C acknowledgement is used
to slow master down), and number of writes is limited to about 10mln per
any byte.
>> I need non-volatile RAM for a PIC based design. Because of size restraints I
>> would prefer it interfaced on the I2C bus. Also, the RAM will be used
>>to stor
>e
>> individual parameters, requiring modifying single locations.
>
>I don't know of any non-volatile RAM with I2C interface, but Philips
>Semiconduct
>ors
>have several I2C interfaced EEPROM devices. This should do the job for
>you, prov
>iding
>you don't want more than about 512 bytes.
>
>Clyde
>
>
>--
> Clyde Smith-Stubbs | HI-TECH Software, | Voice: +61 7 300 5011
> clyde.....@spam@hitech.com.au | P.O. Box 103, Alderley, | Fax: +61 7 300 5246
> | QLD, 4051, AUSTRALIA. | BBS: +61 7 300 5235
> HI-TECH C: Compiling the real world...
Doug Sellner
Beach Tech
4131 Vincent Avenue South
Minneapolis MN 55410
In article: <EraseME9506231915.aa26619.....punt2.demon.co.uk> spamcarlottKILLspam@spam@interport.net writes:
:
: While the topic is on pseudo random noise generators (well sort of). Does
: anybody have a simple explanation of why specific feedback points are used
: in shift register designs.
: In the TTL cookbook (an excellent book) Don Lancaster shows the feedback
: points for 2 to 31 stage shift registers (for some odd reason he skips 19).
: I know the whole point is to have the largest possible sequence before
: repeating, but if you did not have this chart how would you calculate them
: for yourself?
Horowitz and Hill in 'The Art of Electronics' state that the maximum length
sequence is 2^m - 1, where m is the number of bits in the shift register
(obvious) and go on to state 'the criterion for maximal length is that the
polynomial 1 + x^n + x^m be irreducible and prime over the Galois field' (not
so obvious). m being the number of bits, n being the feedback bit.
Interestingly these things are symmetrical, i.e. instead of using the nth bit
you can use the m-n bit to the same effect. And you can use more than two
taps, eg. a 24 bit tapped at 17, 22 and 23 will also give a maximum length
sequence of 1,677,215 cycles. They also list some interesting properties of
maximal length shift registers. Worth looking up.
The advantage of using a PIC would be that you could control the 'clock'
frequency and the sequence length in software, thus shaping the output power
spectrum to your needs - something that the MM5437 couldn't do easily.
> Date: Thu, 22 Jun 1995 12:24:57 -0700
> From: Brad Morrow <RemoveMEmorrowRemoveMEMOUNTAIN.ASD.SGI.COM>
> Subject: Non-Volatile RAM for I2C.
>
> I need non-volatile RAM for a PIC based design. Because of size restraints I
> would prefer it interfaced on the I2C bus. Also, the RAM will be used to stor
e
> individual parameters, requiring modifying single locations.
>
> Does anybody know of companies that have such a product?
>
> --------------------------------------------------------------------------
> Brad Morrow Advanced Systems Group
> Product Design e-mail: TakeThisOuTmorrow@spam@@spam@asd.sgi.com
> Silicon Graphics, Inc. voice-mail: (415)390-1311
> 2011 N. Shoreline Blvd. fax: (415)961-9075
> Mountain View, CA 94039-7311
> --------------------------------------------------------------------------
RAMTRON makes I2C serial FRAM parts (and SPI parts, too) in 512- and 2K-byte
sizes; the I2C parts run at 100 or 400KHz with NO WRITE WAIT. Well, maybe
you aren't in a hurry, but it saves a few lines of code not to have to poll
for the ``done'' status from those SLOW EEPROM parts, and it's also nice to
be able to swallow 115200bps serial data into nonvolatile buffer memory.
Oh, did I mention endurance of 10^10 (10 billion) read or write cycles, and
100uA (microamps) write current? (FRAM is ``ferroelectric RAM'' -- please
don't let the ``ferro'' confuse you -- it's not a magnetic phenomenon;
there's nothing ferrous involved; it's a polar dielectric effect with
hysteresis which is analogous to ferromagnetism). Ramtron is in Colorado
Springs, Colorado: (719)481-7000; US:(800)545-FRAM; Fax:(719)488-9095.
Peter F. Klammer, Racom Systems Inc. TakeThisOuTPKlammerspamACM.Org
6080 Greenwood Plaza Boulevard (303)773-7411
Englewood, CO 80111 FAX:(303)771-4708
>Phillips makes PCF8570 & 8571, 128 X 8 & 256 X 8 Static
>RAMs. Both I2C devices in 8 pin packages.
.. And someone (Xicor or Dallas, I think) makes a chip that contains
both RAM and EEPROM. The way it works is, you write to and read from
the RAM until your power supply gets low, then the entire RAM array is
automatically copied to EEPROM. This gives all the advantages of both
RAM and EEPROM, but, of course, costs a little more than either alone.
> I'm hoping to develop and design apps for the 16C5x, 16Cxx line of the
> PIC processor. However, can anyone tell me of a good working enviornment
> for Windows or Linux. I'm looking for an editor, compiler(if avaliable),
> assembler, simulator type of package that uses windows. If nothing
> exists, can someone suggest to me the best environemtnt to develop. Thks
> for all the help.
Under Linux there is an assembler called pictools from a progrmammer in
England(He's probably on this list, I did some beta on it and lost
touch). For programming the 16C84 you can use a Russ Reiss
programmer(from CCI last year) and my picpgmr program available from
ftp.eskimo.com/~blane/
I don't remember the site for pictools, but an archie search should
find it.
Brian
- ---------------------------------------------------------------------------
email RemoveMEblanespamEraseMEguetech.com with 'Subject: blane-info' for PGP key
I have created a list for the disussion of water based
entertainment(for want of a better description). Send email to STOPspamwaterworks-request.....guetech.com with a SUBJECT of subscribe. A subject of
help will get you the mailing lists commands.
>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:
> Yep, DOS -- the wonder operating system (you wonder how you can get
> any work done at all). I've gotten the impression that embedded
> development system vendors think that upgrading to a "real" OS
> means Windows. :-(
It's not the vendors that are the problem - it's the users. We've
been using Unix for development since the year dot, cross-compiling
for DOS, and have offered compilers to run under Unix for all that
time. The number of Unix hosted compilers we've sold is miniscule compared
to the number of DOS hosted compilers. Sad but true.
I'd like to be able to program PIC16Cxx parts from a Mac (and on a budget).
I already own a Parallax PIC16Cxx Programmer for the PC, and am wondering
if anyone has worked out a Mac interface and software, or if the comm
protocol is in the public domain.
Alternatively, recommendations for a Mac based programmer would also be
appreciated. Thanks for any and all help!
On Jun 29, 1:18pm, R Duflon wrote:
|Subject: PIC programmer for Mac?
| I'd like to be able to program PIC16Cxx parts from a Mac (and on a budget).
| I already own a Parallax PIC16Cxx Programmer for the PC, and am wondering
| if anyone has worked out a Mac interface and software, or if the comm
| protocol is in the public domain.
|
| Alternatively, recommendations for a Mac based programmer would also be
| appreciated. Thanks for any and all help!
|
| Ray
| TakeThisOuTrduflonspamcup.portal.com
|-- End of excerpt from R Duflon
The Microchip tools will work under SoftPC on a Mac. But, the communications
protocols are different, so the programmer itself cannot exchange info with
the computer.
I attended the Microchip seminar yesterday, and asked if there were any
plans to develop a suite of tools for users with Macs. In response, the
instructor asked all those who would use the Mac tools if they were
available to raise their hands. Only three of us out of about a hundred
and fifty people raised their hands. The instructor said "There, that's
the answer to your question. We aren't going to get into the Mac
development tool business." So it looks like you and I and the rest of
the rest of the Mac users are SOL.
I bought an old XT just for the sole purpose of running MPASM, MPSIM
etc.
Regards,
Reg
*Reg Neale=spamBeGonenealeee.rochester.edu ....standard disclaimer applies...*
*..."Ignorance is a renewable resource."....P.J. O'Rourke............*
Last time I tried to get those little round Epson 4 MHz Xtals from
Digikey they were out of stock.
I tried the CTX006 microprocessor crystals by CTS and found that
they didn't work very well. I got lots of crashes and the occilator would
quit every time I put a probe on OSC1. This didn't happen with the small
ones.
Does anyone have any good sources for 4 Mhz crystals that work well
on the pic?
TIA
-Otmar-
-----------------------------------------------------------------------
Electric Vehicle Components Ltd.
It's often said that life is strange, But compared to what? sf
Otmar Ebenhoech EraseMEtessEraseMEnetcom.com (415) 494-9255
-----------------------------------------------------------------------
I've tried running picstart 16b on a mac running SoftPC.
It does work but only on 'fastish' machines like a pb180. Slower machines have
problems with communication timouts.
-Karl
--------------------------------------
Date: 6/29/95 16:51
To: Karl Grabe
From: pic microcontroller discussion
On Jun 29, 1:18pm, R Duflon wrote:
|Subject: PIC programmer for Mac?
| I'd like to be able to program PIC16Cxx parts from a Mac (and on a budget).
...snip snip ..
On Jun 30, 12:05am, jory bell wrote:
|Subject: Re: PIC programmer for Mac?
| uChip's comments about not supporting the Mac (recounted below at a
| seminar) seem quite lame given their stubborn use of a totally non-stadard
| serial protocol for their tools. Were it not for this totally unnecessary
| anti-standard, SoftPC (or the DOS-compatability card for the newer Macs)
| would at least get us into the development game without buying Actual
| Wintel hardware.
You're right. This may also interest you: at the same seminar, I prodded
the factory guy about the continuing reports that code protection can be
defeated by various conbinations of pulsing the progr. pin, applying
strange voltages and sequencing them in particular ways. He maintains
that they watch the same traffic, and have never been able to duplicate
any of the claimed results.
> I'm using a PIC 16C71 to drive 3 hobby RC servos but I'm preety new to this
> assembler. Does anyone know where there is some code to drive servos? I
> know...I'm lazy but the best code is already working code.
> Thanks for your help.
Application note 532 uses a PIC 17c42 for servo control. What you really
want is a copy of the October 1994 (#51) Circuit Cellar INK. There is a
description of a device based on two 16c55s which provide up to 256 servo
channels controlled by a PC serial port. There is also good information
in the Basic Stamp manual, note #4. Basically servos reach the end of their
travel when fed pulses of 1 or 2ms duration - they center when fed 1.5ms
pulses. The RC unit that I looked at sent one 1.5ms pulse every 20ms and
varied in either direction by .4ms.
Although I haven't seen the article, there was some info in Circuit
Cellar Ink (October 1994, Issue #51) about servos. You can get the
associated PIC code (for pasm I think) by ftpmail from circellar.com.
An easy way to do this is to use Lou Sortman's WWW interface to the
ftpmail service:
>> I'm using a PIC 16C71 to drive 3 hobby RC servos but I'm preety new to this
>> assembler. Does anyone know where there is some code to drive servos? I
>> know...I'm lazy but the best code is already working code.
>> Thanks for your help.
>
>Application note 532 uses a PIC 17c42 for servo control. What you really
>want is a copy of the October 1994 (#51) Circuit Cellar INK. There is a
>description of a device based on two 16c55s which provide up to 256 servo
>channels controlled by a PC serial port. There is also good information
>in the Basic Stamp manual, note #4. Basically servos reach the end of their
>travel when fed pulses of 1 or 2ms duration - they center when fed 1.5ms
>pulses. The RC unit that I looked at sent one 1.5ms pulse every 20ms and
>varied in either direction by .4ms.
>
>Adam Eberbach, R&D Engineer, Dataplex Pty. Ltd.
>
>
The code for the servo project is available from the Circuit Cellar FTPmail
server and is called "servopic.zip".
There is a very handy interface to the server available from WWW http://tfnet.ils.unc.edu/cgi-bin/CCBBS
There is also another very helpful reference project for servos by Scott
Edwards called "motion memory" He uses two joysticks to control 4 servos
with local memory for playback. I'm not sure where the source for this
project is. It used to be on the parallax board (in parallax format) but I'm
not sure it's still there. If you can't find it email me and I'll zap it to you.
I am having trouble in writing code for the PIC16C71 to compare two
12bit 'signed' numbers. Once the comparison is done I need to save
the lesser of the 12bit number, for example;
LOADA word1 ;get 12 bit signed value into acca
CMPA word2 ;compare word1 to word2
BLE savewd1 ;if word1 << word2 then save word1
STORA word2 ;if word1 >> word2, save word1 -> word2
RETN
savewd1:
STORA rseln ;save word1 value
RETN
Excuse the mnemonics chosen. I hope that its clear as to what I need
to do. Any pointers would be appreciated.
Nino Benci
************************************************************************
* 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.bencispamBeGonespamsci.monash.edu.au * *
************************************************************************
I was a few days off, so maybe that response is already to late...
>
> "supply controller"? The entire circuit is working at 3.0-3.3V and draws
> 6mA max. when functioning and about 25uA when in stand by.
In genral you should check MAXIM products for that purpose. They make
alot of stuff for handhelds and so an.
I would recommend you the MAX872. It takes 10uA from the supply and operates
down to 2,7V.
Henri
--
=============> The sanest place is still behind the trigger <===============
[]-------------------------------[]---------------------------------------[]
|| Henri Schultze || Magdeburg D-39122 Alt-Fermersleben 88 ||
|| KILLspamhenrifscz-md.boerde.de || The Cracker Company ||
[]-------------------------------[]---------------------------------------[]
=================> in a world of compromise, some don't <===================
In my attempt to use in system serial programming I decided
to write my own code to program PICs via the PC parallel port.
I'm using David Tait's code and the AN589 code to guide me, but I'm
trying to make the code versatile enough to program any of the
PICs that support issp.
I've encountered discrepencies (or my own inability to understand
something) while reading the Microchip literature. One of them
follows ... perhaps someone knows the answer.
1) When programming the configuration memory the Programming
Specification never tells you what data to send with the "Load
Configuration" command. The spec. implies that you program the
configuration memory with a programming cycle at location 0x2007
in the configuration memory. David Tait sends the fuse data for
both commands! Apparently this works ... but what is going on
here?
> In my attempt to use in system serial programming I decided
> to write my own code to program PICs via the PC parallel port.
Good luck.
> 1) When programming the configuration memory the Programming
> Specification never tells you what data to send with the "Load
> Configuration" command. The spec. implies that you program the
> configuration memory with a programming cycle at location 0x2007
> in the configuration memory.
This was discussed recently on the list. Here is the answer
according to Brian Boles of Microchip:
: The "load configuration" and "load data for program memory" commands
: are both actually commands that load data for program memory. The
: only difference is that the "load config" command will also set the
: address pointer to 02000h i.e. near the configuration register
: (actually 2000 is the start of our test memory area).
: So the answer to the question "What is in the 16 bit field?" is that
: normally you will place your data for the bits in the configuration
: register here with the "load config" command, and then do 7 increment
: commands to point the address to 2007 then do a program command.
So there. The only problem for me was that the spec said you should
do the increments and then perform a program cycle (i.e. load data,
begin prog, wait 10ms) but perhaps Brian is implying you can get away
without the load data part of the program cycle. As you say, what I do
works, but maybe it wasn't what was intended according to the spec.
>
> I'm using a PIC 16C71 to drive 3 hobby RC servos but I'm preety new to this
> assembler. Does anyone know where there is some code to drive servos? I
> know...I'm lazy but the best code is already working code.
> Thanks for your help.
>
Here it is, the code and schematic for a simple servo controller using a
PC joystick and a PIC 16c55. The code can be complied with MPALC or MPASM
and simulated with MPSIM. All are free from Microchip and available on
ftp.ultranet.com /biz/mchip + tons of other code examples. A demo version
of Circad is available mobius, but I can't remember the whole name of the
site. Some help? So you can play with this for free. If your in the Atlanta
area you can even come over and use my burner to make a chip if you bring
a beer.
Now a little on servos. Send one a 1ms pulse every 20-30 ms and it goes
all the way to the left, a 2ms pulse every 20-30ms and it goes all the way
to the right, 1.5 ms and it goes to the middle, simple. This code is simple
it just counts while the joystick pot charges a cap enough to be a 1, saves
the time, flips the pin to an output to discharge it (with a low out), then
flips it back to an input. The timing is all done in spin loops. If you want
to do something else the low time of 20-30ms is not critical. I actually
compensate for the variable high pulse time, but it isn't needed. The 16c5x
chips don't have interrupts and only 2 level deep stack, but hey they're
cheap and fast as hell. Remember, this is just something I cooked up one
afternoon, so it's not pretty but it works. Adjust the 47nF cap to compensate
for the variation in the joystick pots (that's why you have to twirl a
joystick when you start a new game).
My current project is a Xilinx SPROM programer. Anyone up on the *.MCS
file format. I've got the hardware designed, but I still don't have
all the info needed to parse the input file yet. The hardware is fully
software configurable so it'll make a good starting point for other
such project by the net.community. Anybody want a copy of my resume too :).
-Cheers Rick
------------------------- begin code ----------------------------------------
TITLE "Servo Controller"
LIST P = 16C55
; DATE 01SEP94
; AUTHOR RICK FARMER
; FILE NAME servo.ASM
; Clock = 4MHz -> 1 instruction takes 1us
PIC55 equ 1FFH
STATUS equ 3h ; F3 Reg is STATUS Reg.
PortA equ 5h
PortB equ 6h ; I/O Port Assignments
PortC equ 7h
PULSE equ 0Bh ; pulse time high
DELAY equ 0Ch ; 1 ms count
DOWN equ 0Dh ; # ms /4 of low time
CAP equ 0Eh ; time to charge cap
LOWPUL equ 0FH ; pulse time high for duty cycle
Z equ 2h
C equ 0h
;********************************************************************
START MOVLW B'000111' ;Select RTCC, internal clock source
; & prescale value = 256
OPTION ;Actually load OPTION reg.
movlw 00h ;setup port A as output
tris PortA
movwf PortA ;clear port A
movlw 0FFh ;setup ports B & C as input
tris PortB
tris PortC
BEGIN MOVLW 0FFh ;load 1ms. counter
MOVWF DELAY ;get it into reg
BSF PortA,0 ;start pulse output
HIMS NOP ;force loop into 4 cycle duty (even #)
NOP
DECFSZ DELAY ;loop for 1st 1ms. of duty cycle
GOTO HIMS
HIGH NOP ;force loop into 4 cycle duty (even #)
NOP
NOP
DECFSZ PULSE ;loop for high part of duty cycle
GOTO HIGH ;while pulse > 0
BCF PortA,0 ;end pulse output
HIPUL NOP ;force loop into 4 cycle duty (even #)
NOP ;duty cycle compensation
INCFSZ LOWPUL ;loop for high part of duty cycle
GOTO HIPUL ;while pulse > 0
MOVLW 03h ;load # ms * 4 counter
MOVWF DOWN ;get it into reg
MOVLW 0FAh ;load 1ms. counter
MOVWF DELAY ;get it into reg
LOW NOP ;force loop into 4 cycle duty (even #)
NOP
INLOOP NOP ;force loop into 4 cycle duty (even #)
NOP
DECFSZ DELAY ;loop for low part of duty cycle
GOTO INLOOP
DECFSZ DOWN ;loop for low part of duty cycle
GOTO LOW
movlw 0ffh ;make rb1 an input
tris PortB ;to let the cap charge
CHARGE INCFSZ CAP,1 ;start timing loop
GOTO NEXT ;check for overflow
DECF CAP,1 ;make it FFh
GOTO DONE
NEXT NOP ;timing nop
NOP
BTFSS PortB,1 ;check input pin RB1
GOTO CHARGE ;not charged yet
DONE MOVF CAP,0 ;but time in W
MOVWF PULSE ;save time in
MOVWF LOWPUL
DUTY NOP ;force this part to a constant 2ms
NOP
NOP
NOP
NOP
INCFSZ CAP,1 ;loop unit roll over for constant duty cycle
GOTO DUTY
movlw 0fdh ;make rb1 an output
tris PortB ;drive it low to discharge timing cap
bcf PortB,1 ;for a constant time
GOTO BEGIN ;restart loop
ORG PIC55
GOTO START
END
-------------------- end code, start uuencoded circad format servo.sch ------
> In searching for external memory solutions, it was soon found that nothing
> exists in the 16k byte, or larger size parts, with serial connectivity.
How about considering the following:
1. Use a PAL as a serial-to-parallel converter. (2 chips - PAL and RAM).
2. Use another (smaller/cheaper?) PIC as a serial-to-parallel converter
and memory controller (2 chips - PIC and memory chip, or 1 chip -
just use the PIC as a memory controller and internal memory as well).
3. Use dual-ported VRAM; these typically have both a parallel and a
serial port on them; in traditional frame buffer devices, the
parallel port on the VRAM is used by the processor, and the serial
port is used to shift data out of the VRAM to the DACs; you might be
able to get VRAMs that allow both shift-in and shift-out operations.
How about checking the usual suspects - Maxim and Dallas?
Here is a document a buddy and I wrote on the sony format. I hope
this is appropriate here. There has been some traffic on ir formats
lately.....
Sony SIRCS Protocol Specifications
Scott Coleman and Edward Cheung
The following is a reference guide to using a microcomputer to
control Sony equipment via the SIRCS protocol. This can occur either
via an infrared interface, or with a Control-S port. It is being
released in the hope that it will be useful to some of you. Apparently
there is no documentation on the protocol available from Sony (at least,
that's what their publications office said). Thus, the following
information is a synthesis of bits and pieces obtained from many
sources, including the Sony Service Manual for the RMT-124 IR
controller, some net.friends, and by connecting an oscilloscope across
the LED in a Sony IR remote controller and observing the signals sent as
various buttons on the controller were pressed, and writing computer
programs to try various codes. The timings given may not be exactly
those used by the Sony products, but these timings have been used
successfully in controlling a Sony SL-HF900 VCR and a SL-HF400 VCR via
their Control-S ports, and a XBR32 TV and SL-V585HF VCR via infrared, so
we figure they're pretty close. We make no guarantees of accuracy for
any of the information contained in this document, although we'd
appreciate hearing from you if you find any errors contained herein.
Also, the names used here may not correspond to any "official" Sony
names used for the various aspects of the protocol. We have made up some
reasonably descriptive names for various things, since there is no
official reference information (that we are aware of) which would tell
me the official names.
Acknowledgment
We'd like to acknowledge the assistance of Paul Milazzo
(milazzospam@spam@bbn.com) for providing valuable pointers in the right direction
when Scott first began to research this topic. Without his response to Scott's
usenet post, He might never have figured all this stuff out and gotten Scott's
controller program working.
Protocol Description
The wired Control-S protocol used by various Sony video products is
simply a TTL-level baseband version of the signals sent by the Sony
remote controllers (such as the RMT-124). The Control-S command word is
12 or 15 bits long, and consists of a 5 or 8-bit device ID code followed
by a 7-bit button code. The control-S data packet is preceded by a 2.4
millisecond TTL logic-1 pulse (start bit) followed by 0.4 ms of logic-0.
Each 1 bit in the control word is represented by a 1.2 ms logic-1 level
followed by a 0.4 ms logic-0 level, and each 0 bit is 0.8 ms high, 0.4
ms low. The end of the control packet is always a TTL logic-0 level, and
the total length of each packet usually fixed at 45 ms in length. The
bits in each control word are sent in increasing bit position order
(i.e. low order bit first, high order bit last). As an example, let's
look at the command to toggle the power on a SL-HF900. The device ID for
the VCR is 00010, and the button code for the power switch is 0010101.
Thus, the entire control word is 000100010101. To send this command to
the VCR, we first send out a 2.4 ms start bit, and then send the bits in
reverse order (i.e. 101010001000). We then hold the Control-S port to
logic-0 level to make the total packet time (i.e. the time since the
rising edge of the start pulse) equal 45 ms.
As mentioned above, command words are usually 12 bits long. However,
some commands are 15 bit long, the device code in that case is 8 bits
long. For example to command a Sony XBR32 TV to turn off Picture-in-
Picture, you send command 110 (decimal) to device 164 (decimal). Note
that the 12-bit command can be distinguished from a 15-bit command
becuase it is three bits shorter. Since both (0 and 1) logic levels
cause the transmission of hi and low transitions, one can tell the
length of the bit stream.
Interfacing
To send commands to a VCR equipped with a Control-S port, your
computer will need a TTL-level binary output port. A standard IBM-PC
parallel printer port works well, as does a data acquisition and control
adapter (IBM DACA board). As long as the port can send a TTL-level
signal (0VDC = logic-0, 5VDC = logic-1) you should be OK. Connect the
output line from the port to a 1/8" mini phone plug, with the tip
carrying the TTL signal and the ring grounded. A simple software routine
can then be written to toggle the status of a bit in the output port
corresponding to the output line. Setting the corresponding bit in the
output port will cause the line to go high, clearing the bit will cause
the line to go low. By controlling the pattern and timing of these high
and low signals, the commands may be sent to the VCR.
Instead of a hard wired connection, you can also emulate a pushbutton
remote and flash an Infra Red LED to the appliance(s) to be controlled.
One way is to set up a 40 kHz LED flasher which is gated by the
computerUs TTL output line mentioned above.
The following pseudocode outlines a routine to send a command through a
port setup such as that described above:
begin
/* send the start bit */
raise Ctrl-S line to TTL logic-1
wait 2.4 ms
lower Ctrl-S line to logic-0
wait 0.4 ms
for current_bit = low_order_bit to high_order_bit do begin
raise Ctrl-S line to logic-1
if (current_bit is a 1)
wait 1.2 ms
else
wait 0.8 ms
lower Ctrl-S line to logic-0
wait 0.4ms
end
wait a sufficient time to make the total message duration 45 ms (see
paragraph below).
end
We derived our SIRCS information independently from each other. Because
of that there are slight differences in our findings. Among the results
gathered by Ed is that the above packet needs to be sent twice (with a
small gap of a few msec. in between) in order for the device to respond;
he also did not observe the need to have the packet take a full 45 msec.
This was not the case with ScottUs findings. In addition, Ed observed
slightly different timing on the high and low duration of the stream.
The 0.8 msec and 0.4 msec times are both 0.6 msec.
One possible reason for this difference is that Ed used an Infra Red
interface, while Scott used the wired interface. We suspect that there
is sufficient tolerance built into the receivers to allow a wide range
of timing.
Example Device and Command codes
The following are some of the codes we've discovered while
experimenting with the protocol. Note that not all of these commands
work with all VCR or TV models. For example, button code 22 causes the
SL-HF900 to eject a tape, but the SL-HF400 ignores that command. If you
come across any codes which are not listed here, we'd appreciate it if
you'd send us a list of the codes you discover.
Note: All numbers in the following table are base 10.
Device ID Codes
1 TV
2 VTR1
4 VTR2
6 laserdisk
7 VTR2
11 VTR3
12 Surround Sound Processor
18 Equalizer
16 Cassette Deck and Tuner
17 CD Player
164 TV digital effects (note 8 bit device code)
Note that Ed found VTR2 to be Device code 7, while Scott found it to
be 2. Some devices can be contained in the same box. For example, the
Surround Sound Processor, Equalizer, and Tuner are in one box, and the
TV digital effects is combined with the TV.
Button Codes for VCR
000 1 button
001 2 button
002 3 button
003 4 button
004 5 button
005 6 button
006 7 button
007 8 button
008 9 button
009 10 button/0 button
010 11 button
011 12 button
012 13 button
013 14 button
020 X 2 play w/sound
021 power
022 eject
023 L-CH/R-CH/Stereo
024 stop
025 pause
026 play
027 rewind
028 FF
029 record
032 pause engage
035 X 1/5 play
040 reverse visual scan
041 forward visual scan
042 TV/VTR
045 VTR from TV
047 power off
048 single frame reverse/slow reverse play
049 single frame advance/slow forward play
060 aux
070 counter reset
078 TV/VTR
083 index (scan)
106 edit play
107 mark
Button Codes for TV
000 1 button
001 2 button
002 3 button
003 4 button
004 5 button
005 6 button
006 7 button
007 8 button
008 9 button
009 10 button/0 button
011 Enter
016 channel up
017 channel down
018 volume up
019 volume down
020 Mute
021 Power
022 Reset TV
023 Audio Mode:Mono/SAP/Stereo
024 Picture up
025 Picture down
026 Color up
027 Color down
030 Brightness up
031 Brightness down
032 Hue up
033 Hue down
034 Sharpness up
035 Sharpness down
036 Select TV tuner
038 Balance Left
039 Balance Right
041 Surround on/off
042 Aux/Ant
047 Power off
048 Time display
054 Sleep Timer
058 Channel Display
059 Channel jump
064 Select Input Video1
065 Select Input Video2
066 Select Input Video3
074 Noise Reduction on/off
078 Cable/Broadcast
079 Notch Filter on/off
088 PIP channel up
089 PIP channel down
091 PIP on
092 Freeze screen
094 PIP position
095 PIP swap
095 Guide
097 Video setup
098 Audio setup
099 Exit setup
107 Auto Program
112 Treble up
113 Treble down
114 Bass up
115 Bass down
116 + key
117 - key
120 Add channel
121 Delete channel
125 Trinitone on/off
127 Displays a red RtestS on the screen
Button Codes for TV digital effects
110 PIP off
115 replay last 15 seconds
116 channel preview
117 Split screen
If you have any questions, or would like to share some new device/button
codes, we can be reached at the following addresses:
+---------------------------------------------------------------------------+
| Edward Cheung, Ph.D. | The opinions expressed herein |
| NASA Goddard Space Flight Center | do not necessarily reflect |
| Code 714.1, Bldg T11B | those of my employers' |
| Greenbelt, MD 20771 | |
| 301-286-1269(office) 286-1717(fax) | My next book: |
| Internet: @spam@ebc714rs710.gsfc.nasa.gov | Statistics, Demos and Other Lies |
+---------------------------------------------------------------------------+
GEE... I WISH SOMEONE (MICROCHIP?) MADE LARGER SERIAL RAM CHIPS!
I have also run intro this RAM memory limitation. I would like to use PIC's
more often in my project, they have all the processing power I need, but
since I often need to buffer atleast a couple of K of data. This forces my
to turn to other chips (68HC11) that are more expensive and harder to get in
qty's.
GEE... I WISH SOMEONE (MICROCHIP?) MADE LARGER SERIAL RAM CHIPS!
Tried the dual PIC solution but cost became a factor. Not only did it double
the cost of the processor(s), but the cost of programming (time is money),
and added 1/3 to my pc board size!
GEE... I WISH SOMEONE (MICROCHIP?) MADE LARGER SERIAL RAM CHIPS!
Haven't tried VRAM'S, I don't have any experiance with them.
sirius.tn.rl.ac.uk
