Post by thread:16F84

Adrian Kennard <spam_OUTadrianTakeThisOuTrhanna.demon.co.uk> wrote: > I see that there is a 16F84 available - twice the RAM of the 16C84. > .... > Has anyone had any experience of this ? Is it a direct replacement ? Adrian: We've used it. It used to be called "16C84A"... I'm surprised that Microchip didn't follow their own example and change its name to "16C841"; such a name change would have been consistent with the 16C71/16C710 and 16C71A/16C711 silliness. The 16F84 is a direct replacement for the C84. -Andy Andrew Warren - .....fastfwdKILLspam@spam@ix.netcom.com Fast Forward Engineering, Vista, California http://www.geocities.com/SiliconValley/2499

Robert Lunn <robertspam_OUTHUEY.RDD.NECA.NEC.COM.AU> writes regarding the lack of info on whether the PIC16F84 is more secure than the PIC16C84: > Which is a pity, as the lack of response renders the > device unusable. Maybe you might be able to get Microchip to tell you whether the specific, well-known, security problems of the 'C84 have been fixed, but it is almost a certainty that they will not promise that it is "secure". AFAIK, even the makers of high-security processors deliberately intended for smart-cards don't actually guarantee that they are secure; there is no way to prove that a part is secure against arbitrarily clever or well-funded attacks. The 'C84 was only intended to have modest security on par with other typical inexpensive single-chip micros. Many of them have security that can easily be defeated; the 'C84 just has the misfortune of having a technique widely publicized (mostly due to European satellite TV pirates). If you pick some part other than an 'F84 solely on the basis of what you've heard about the 'C84, any sense of security you may have is probably misguided (IMNSHO). There *are* people out there who can extract the code. Cheers, Eric

> >If you pick some part other than an 'F84 solely on the basis of what you've >heard about the 'C84, any sense of security you may have is probably >misguided (IMNSHO). There *are* people out there who can extract the code. > >Cheers, >Eric > Yes, but the '84 is particularly vunerable. The later revisions of the other 16Cxx devices with the unerasable code protection do offer greater security. I don't see that Bob sense of security is misguided at all. It is true that any PIC can be "cell scanned" and the program contents reconstructed, but this proceedure is expensive and not 100% accurate. Nothing at all like being able to put a protected '84 in a reader and instantly copy the contents for no or little time/cost. However, I must say that so far, microchip appear to have addressed every weakness in the code protection of the eprom devices (as far as I can tell.) For example, I believe the newer devices actually have multiple code protection fuses, not just "logical" duplications. all are unerasable and "OR" configured. This make it very hard, if not impossible to selectively erase only the code protect fuse, one of the tricks previously used to break code protection. Devices vunerable to "incremental" programming, simply do not scramble the vunerable locations anymore. A beautifully simple solution. My point is it shows that microchip are at least thinking about the code protect issue. Therefore, it might be reasonable to expect the code protection on the 16F84 has been "beefed-up." Still, all this is not enough to assume your code is safe in an 16F84. The evidence that it is/isn't will come from those who have tried to break it. If it is not secure, I think we will hear about it quick enough. A statement from microchip is most unlikely! Jim

>The 'C84 was only intended to have modest security on par with other typical >inexpensive single-chip micros. Many of them have security that can easily be >defeated; the 'C84 just has the misfortune of having a technique widely >publicized (mostly due to European satellite TV pirates). I'm not a European satellite TV pirate, but I play on one TV. Since the real EsTVps seem to know about this security problem, would it hurt if somebody told the rest of us about it? I promise not to pirate any European Satellite TV signals.

Eric Smith wrote: > ... the 'C84 just has the misfortune of having a technique widely > publicized (mostly due to European satellite TV pirates). This might be a misfortune for the 'C84 and Microchip but I don't think it's unfortunate for potential users of the chip. Without the publicity you would have a PIC you _thought_ was secure but could be popped by your competitors. OK, there would always be rumours of insecurity but many might still use the PIC believing the rumours to be untrue and find out the truth the hard way. David -- @spam@david.taitKILLspamman.ac.uk

Hi Dave and all, At 04:45 5/09/96 -0500, you wrote: >I'm not a European satellite TV pirate, but I play on one TV. Since the real >EsTVps seem to know about this security problem, would it hurt if somebody >told the rest of us about it? Well, also I'm not a TV pirate (at least, not a comertial one :-), but I like to know the sort of infos that are posted, sometimes, on the Usenet groups: "alt.satellite.tv.europe" and "alt.satellite.tv.crypt" Also, as example, you can see: ftp://ftp.paranoia.com/pub/users/defiant/unsorted/%21hack57.txt ftp://ftp.paranoia.com/pub/users/defiant/picprog/picbust.zip and a lot of other files, about pirate emulation of Smart Cards to access Pay TV channels. I don't understand your term "EsTVps", but most of the pirated channels are used to change the encryption keys on a regular basis and some hours late there are pirate implementations available and in one o two days the new keys are on the "net" and used by a lot of comertial pirates. >I promise not to pirate any European Satellite TV signals. Don't problem and by the geometry of our planet, it's near imposible to get the European channels on the USA (and of the same dificult, to get the USA channels here :-). Best regards: -- Roberto Deza Asensio | KILLspamrdezaKILLspampopmail.cti.unav.es Universidad de Navarra | RemoveMErdezaTakeThisOuTcun.unav.es Centro de Proceso de Datos | spamBeGonerdaspamBeGonecpd.unav.es

I wrote: > If you pick some part other than an 'F84 solely on the basis of what you've > heard about the 'C84, any sense of security you may have is probably > misguided (IMNSHO). There *are* people out there who can extract the code. To which Jim Robertson <TakeThisOuTnewfoundEraseMEspam_OUTNE.COM.AU> replied: > I don't see that Bob sense of security is misguided at all. ... Your argument does not contradict my statement. > It is true that any PIC can be "cell scanned" and the program contents > reconstructed, but this proceedure is expensive and not 100% accurate. I don't know about "cell scanning", but there are companies that use microprobing. Unless you physically damage the part in deencapsulating it, there is no reason to expect this technique not to be 100% accurate. The known lack of security of the 16C84 does not prove that other parts from Microchip or from other vendors are more secure. Many other parts are in fact just as vulnerable as the 16C84. > Still, all this is not enough to assume your code is safe in an 16F84. There is no way to assume your code is safe in any part. Sorry, but it's a fact of life. Eric

On Thu, 5 Sep 1996, Eric Smith wrote: > There is no way to assume your code is safe in any part. Sorry, but it's > a fact of life. Exactly right. Once you distribute your code in any usable form, it's not a question of whether it's vulnerable, but only whether it's protection will be difficult enough to persude those who would like to access it not to bother. This is the point behind the observation that the 16C84 has "enjoyed" very motivated attacks: you simply can't compare it to another chip that hasn't been tested, not if you want to make a meaningful comparison. I expect that comparing microprocessor code protection schemes is comparable to judging the security of an encryption protocol, and the record there is littered with schemes that were thought to be impregnable but proved surprisngly easy to crack.

> On Thu, 5 Sep 1996, Eric Smith wrote: > > > There is no way to assume your code is safe in any part. Sorry, but it's > > a fact of life. > > Exactly right. Once you distribute your code in any usable form, it's > not a question of whether it's vulnerable, but only whether it's > protection will be difficult enough to persude those who would like to > access it not to bother. This is the point behind the observation that > the 16C84 has "enjoyed" very motivated attacks: you simply can't compare > it to another chip that hasn't been tested, not if you want to make a > meaningful comparison. > > I expect that comparing microprocessor code protection schemes is > comparable to judging the security of an encryption protocol, and the > record there is littered with schemes that were thought to be impregnable > but proved surprisngly easy to crack. This is very true. The PIC16C84 is unique in that: <A> The software in video descramblers is a target which appeals to a wide audience, thus many people might try to crack them. <B> People who do crack TV decoders effectively trumpet their success (it may be that the 8748 keyboard chip on motherboards is commonly hacked, but motherboard manufacturers would hardly boast about this and the existence of an 8748 on a motherboard is hardly suspicious. Nonetheless, since the PIC 16C84 weakness IS widely known, there is good reason not to use that particular chip in cases where code security is of any importance. On the other hand, unless other chips have THAT SAME weak- ness this should not be taken as a smear against Microchip IC's in general.

>If you pick some part other than an 'F84 solely on the basis of what you've >heard about the 'C84, any sense of security you may have is probably >misguided (IMNSHO). There *are* people out there who can extract the code. A schoolboy with a plugpak and a couple of diodes can defeat the code protection on a 'C84. A skilled engineer with $100k+ of specialized equipment can defeat the code protection on a 'C61. This difference in degree is, to me, significant. The various responses to this issue boil down to: "no code protection scheme is perfect, so the particular protection scheme used doesn't matter". Taken to its conclusion this argument would suggest we shouldn't bother using code protection at all. Nevertheless, microcontroller manufacturers continue to design chips with code protection facilities, and they use the relative merits of their code protection schemes to extract competitive advantage in the marketplace. We nearly all release chips with code protection enabled. We do this to maximise the resources that a competitor must expend to reverse engineer our products. We do this because it is prudent, and because we usually have a legal obligation to do so. Where a chip contains information that is the intellectual property of the company for which we work and which is 'company confidential' then we have a duty of non-disclosure. This requires us to talk all "reasonable" steps to prevent that information being made available to a third party. To the best of my knowledge, the code protection of a 'C84 is weaker than the code protection of a 'C61. All other things being equal, I am obliged to use a 'C61. To the best of my knowledge, the code protection of an 'F84 is the same as the code protection of a 'C84. I would like Microchip to improve my knowledge of the _relative_ strengths of the code protection schemes of these various chips so that I can make informed and responsible decisions about my use of them. Note that I am _not_ asking Microchip to discuss with me the details of their code protection mechanisms. Indeed, these details are 'company confidential' for Microchip! What confuses me is that Microchip is prepared to discuss the merits of the code protection of its devices (and par- ticularly the steps they take to improve code protection), excepting the 'C84. ___Bob

Robert Lunn <RemoveMErobertTakeThisOuTHUEY.RDD.NECA.NEC.COM.AU> wrote: > A schoolboy with a plugpak and a couple of diodes can > defeat the code protection on a 'C84. > A skilled engineer with $100k+ of specialized equipment > can defeat the code protection on a 'C61. Sorry, but you're only *guessing* that a schoolboy can't defeat the protection on a 'C61. You may be right, but you have no proof. I wasn't claiming that the 'C84 is as secure as anything else. I was claiming that there is no *hard evidence* that any particular other part is more secure. The lack of evidence does not constitute proof that other parts are more secure. It is only possible to prove that a part *isn't* secure. > To the best of my knowledge, the code protection of an 'F84 > is the same as the code protection of a 'C84. Based on what? I'm not aware of any evidence that suggests that the same vulnerability exists. Are you blindly assuming that, or have you tried the 'C84 techniques on it? If you really want to assume that the 16F84 security is weak, go right ahead. But I *still* stand by my original statement: > If you pick some part other than an 'F84 solely on the basis of what you've > heard about the 'C84, any sense of security you may have is probably > misguided (IMNSHO). There *are* people out there who can extract the code. And I'll add that for *many* chips it *doesn't* cost $100K. The 'C84 isn't the only one that is easy to defeat. And no, I'm not going to present any example to back up that claim. I find it useful to be able to disassemble other people's code from time to time, so I'm not giving away my trade secrets any more than Microchip is giving away theirs. Cheers, Eric

>>If you pick some part other than an 'F84 solely on the basis of what you've >>heard about the 'C84, any sense of security you may have is probably >>misguided (IMNSHO). There *are* people out there who can extract the code. > > A schoolboy with a plugpak and a couple of diodes can > defeat the code protection on a 'C84. > > A skilled engineer with $100k+ of specialized equipment > can defeat the code protection on a 'C61. > > This difference in degree is, to me, significant. Probably this is *THE DIFFERENCE*. Seems to be a matter of efforts/benefits, isn«t it?. If your application is a low price product which is just worth to manufacture in high volume production (so high volume sales) you would probably have not to get concern about code protect. Generaly, cheap and simple applications means *simple* code. If you spend your energy/money in a highly secure hardware you will be just getting a higer production cost. For anyone being able to compete with you clonning the product can be easier to reverse-eng the application and then write his OWN CODE. If your application is really worth to be cloned and/or one can really make money with it then you would have to look for a *secure* hardware and watch if your product can deal with a higer cost. There are manufacturers who claims for their CPUs to be highly secure, which (as discussed here) is something hard to demonstrate. Dallas has a secure version of his DS-5000 soft microcontroller (8051 clone). The local Dallas distributor told me that this secure micro (DS-5002) was certified by an European agency as being secure enought to handle cash transfers in bank applications (??). Dallas added the following security features to their DS-5002 - Memory stored in encrypted form - Encription using on-chip 64 bit generator (DES encryption) - Automatic true random key generator - Self Destruct Input (Code destruction only ... not exploding !) - Top die coating to prevent microprobe - Customer specific versions with one-of-a-kind encryption algorithm Now the bad news......ask for the price ! :-( You just have to quantify how much money you wanna spend in security. Of course it doesn't guarantee that your product is copy proof but the neccesary equipment and skills to do it are much higer. There are many applications were the code protection of a C84 is more than enought. But if you really have to protect your code go to other products. Luis Fernandez Cormenzana RadioBit Sistemas, S.L. Fax/Tel:+34-6-585 64 57 e-mail: radiobitEraseME.....dragonet.es

And I will yet again assert my seemingly unpopular position on copy protection. All it does is helps the bad guys. I write something nifty based around a microcontroller with copy protection. Joe Knockoff in someplace where the laws are ethically challenged breaks the copy protection (and if he wants in bad enough he will), and duplicates my code. He then proceeds to ship 500 times my volume for 1/3 the cost because of labor cost differences and puts me out of business. Being the honest person I am I have no clue how to defeat his copy protection to check so I lose big bucks. I write the same thing on a micro with no copy protection. He trivially copies my code, and starts shipping his knock-offs back to the US. At this point I grab one of his units, check and find the copyright on the chip still or compare his source to mine. Immediately I get a lawyer, an injunction against them shipping widgets, and a lawsuit to recover my losses. I now have evidence. Roger

>If your application is a low price product which is just worth to >manufacture in high volume production (so high volume sales) you would >probably have not to get concern about code protect. Yes and no. Perhaps you are a small manufacturer hoping to use this new 'high volume' product to grow your business. You would be very concerned about an existing large manufacturer ripping off your product and using their economies of scale to immediately swamp you in both quantity and price in the marketplace. >Generaly, cheap and simple applications means *simple* code. If you spend >your energy/money in a highly secure hardware you will be just getting a >higer production cost. For anyone being able to compete with you clonning >the product can be easier to reverse-eng the application and then write his >OWN CODE. Yes and no. Perhaps you have a novel method for implementing a previously difficult process that allows you to use a simple microprocessor (thus low cost). Being novel it is difficult to reverse engineer without access to details of the method (that is, the code). You would be very concerned aobout losing your cost benefit over your competitors by them reading your code. ___Bob

>If your application is a low price product which is just worth to >manufacture in high volume production (so high volume sales) you would >probably have not to get concern about code protect. Perhaps you are a small manufacturer hoping to use this new 'high volume' product to grow your business. You would be very concerned about an existing large manufacturer ripping off your product and using their economies of scale to immediately swamp you in both quantity and price in the marketplace. IMHO, you're all paranoid. If a product is worth making in high volume, a high volume manufacturer can throw a significantly larger and more powerful processor and still implement it at a higher profit margin than a low volume manufacturer can do with an "OTP" PIC. Look at a $100 video game some time. I know someone who built a $100 rs232 thermometer around a PIC. He sanded the part numbers off all the (5 or so) chips to make it harder to duplicate. While it was a nice product, this was silly (IMHO.) There are so many ways to make a $100 rs232 thermometer that it's not even worth hiding the code. BillW

>And I will yet again assert my seemingly unpopular position on copy >protection. All it does is helps the bad guys. > >I write something nifty based around a microcontroller with copy >protection. Joe Knockoff in someplace where the laws are ethically >challenged breaks the copy protection (and if he wants in bad enough >he will), and duplicates my code. He then proceeds to ship 500 times >my volume for 1/3 the cost because of labor cost differences and puts >me out of business. Being the honest person I am I have no clue how >to defeat his copy protection to check so I lose big bucks. > >I write the same thing on a micro with no copy protection. He trivially >copies my code, and starts shipping his knock-offs back to the US. At >this point I grab one of his units, check and find the copyright on >the chip still or compare his source to mine. Immediately I get a >lawyer, an injunction against them shipping widgets, and a lawsuit to >recover my losses. I now have evidence. Given that you are relying on copyright to protect your code then the issue of hardware code protection is irrelevant. If you have written a novel in English and someone else translates it into Spanish :) then they are in breach of your copyright, and you can prevent distribution of the translation and sue for damages. Likewise, Knockoff and Co doesn't avoid copyright by taking your software and re-translating or re-encoding (indeed, encrypting) it. You simply get a court order requiring them to release their source code for inspection by your lawyers. And there's the rub... My basic position is that if you are relying on the law for success in the marketplace then you have already lost. If you need to call in the lawyers to prevent someone else copying and selling your ideas then you may as well pack up and go home. Life's too short. For example, if they are in a foreign jurisdiction you probably can't stop them shipping units. You can only stop someone importing them. Who are you going to sue to recover losses? Does that entity have funds that you can recover? How do you stop the principals of the company opening up shop on Monday under a new name, etc... I suggest that a hardware solution of uncertain effect- iveness is better than a legal solution that can't be enforced (which is most of them). ___Bob

George Andreadakis <EraseMEPICLISTMITVMA.MIT.EDU> wrote: > What about new 16F84? > > Is it compatible with 16c84? George: The 16F84 is just a renamed 16C84A. Externally, it's exactly like a 16C84, only with more RAM registers and some slight shuffling of the configuration bits. -Andy === Andrew Warren - RemoveMEfastfwdEraseMEEraseMEix.netcom.com === === Fast Forward Engineering - Vista, California === === === === Custodian of the PICLIST Fund -- For more info, see: === === http://www.geocities.com/SiliconValley/2499/fund.html ===

George Andreadakis <RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU> wrote: > > The 16F84 is just a renamed 16C84A. Externally, it's exactly like > > a 16C84, only with more RAM registers and some slight shuffling of > > the configuration bits. > > Can I program it with the old Picstart 16b1 as 16c84? George: Yes, although the configuration bits will be wrong if you're using an old version of MPSTART. I don't know whether Microchip has a newer version of MPSTART that supports the 16F84 directly. -Andy === Andrew Warren - EraseMEfastfwdspamspamBeGoneix.netcom.com === === Fast Forward Engineering - Vista, California === === === === Custodian of the PICLIST Fund -- For more info, see: === === http://www.geocities.com/SiliconValley/2499/fund.html ===

He's more likely interested in reading a code protected part, as in 'PICbuster' and thinks that we might tell him! >---------------------- Information from the mail header ----------------------- >Sender: pic microcontroller discussion list <KILLspamPICLISTspamBeGoneMITVMA.MIT.EDU> >Poster: MaD RaCooN <EraseMEracoonEraseMESTARLINE.EE> >Subject: 16F84 >------------------------------------------------------------------------- ------ {Quote hidden}> >Hi! > >How is it possible to bust 16F84? > >Please reply... > > >Regards, > > >Herman >@spam@racoon@spam@spam_OUTstarline.ee

Paul BRITTON wrote: > He's more likely interested in reading a code protected part, as in > 'PICbuster' and thinks that we might tell him! Of course we will! 16F84 busting method 1 : Connect some pins to 0V, and the others to 220V. Be sure to hold the pins with your fingers for effecient electrocution. 16F84 busting method 2 : Hit PIC repeatedly with hammer. Now hit yourself with the hammer. 16F84 busting method 3 : Buy Myke Predko's book, read it, and write the software yourself. -- Friendly Regards Tjaart van der Walt spamBeGonetjaartKILLspamwasp.co.za |--------------------------------------------------| | WASP International | |R&D Engineer : GSM peripheral services development| |--------------------------------------------------| |SMS .....0832123443spam_OUTwasp.co.za (160 chars max)| | http://www.wasp.co.za/~tjaart/index.html | |Voice: +27-(0)11-622-8686 Fax: +27-(0)11-622-8973| | WGS-84 : 26¡10.52'S 28¡06.19'E | |--------------------------------------------------|

>> He's more likely interested in reading a code protected part, as >> in 'PICbuster' and thinks that we might tell him! >Of course we will! Ditto! {Quote hidden}>16F84 busting method 1 : >Connect some pins to 0V, and the others to 220V. Be >sure to hold the pins with your fingers for >effecient electrocution. >16F84 busting method 2 : >Hit PIC repeatedly with hammer. Now hit yourself >with the hammer. >16F84 busting method 3 : >Buy Myke Predko's book, read it, and write the >software yourself. No, Myke's book doesn't come in any of the Asian languages for reasons involving copyright law. It's a start, though. How about some more: 4. Using a hack-saw, remove the cover of the DUT (Device Under Trial.) Carefully examine the silicon chip using a magnifying glass and copy down the contents of its memory onto paper. Be sure to buy lots of duplicate chips because this scheme needs some practice to get it right. 5. Gently crack open the PIC using a hammer, and sweep up all the bits and bytes with a soft brush. All you have to do now is arrange them in the right order. 6. Call the guy who programming the PIC and ask for a full source code listing. Be diplomatic. Try each one in turn to see what works. (You do have plenty of time, right?) Later, Eric

At 11:45 AM 4/18/98 -0400, you wrote: >I have a real basic question: > >What's the difference between a 16C84 and a 16F84 as far as program memory is concerned? I know that the 'C84 has EEPROM and how to program one. But I don't know what Flash memory is. Is it the same idea as EEPROM, i.e. it can be programmed, and reprogrammed and retains it memory even when power is removed? Yes. If so, can a 16F84 be plugged into a 16C84 socket with no problem? Yes. Can even be programmed as a 16C84, but leave code protection off, if you want to be able to verify.

From: Bruce Shepherd <TakeThisOuTbshep.....TakeThisOuTINNOVA.NET> >I have a real basic question: >What's the difference between a 16C84 and a 16F84 as far as program memory is >concerned? I know that the 'C84 has EEPROM and how to program one. But I don't know >what Flash memory is. Is it the same idea as EEPROM, i.e. it can be programmed, and >reprogrammed and retains it memory even when power is removed? If so, can a 16F84 be >plugged into a 16C84 socket with no problem? Yes. C84 and F84 are the same. You can only invert PWRTE bit in Fuses if your programmer software is not understand "F" chip. >Thanks for your help Alex Torres, Kharkov, Ukraine (exUSSR) TakeThisOuTaltorKILLspamspamgeocities.com 2:461/28 FidoNet http://www.geocities.com/SiliconValley/Lab/6311

part 0 764 bytes Bruce R. Shepherd -----Original Message----- From: NCS Products [SMTP:.....ncsRemoveMEWORLDNET.ATT.NET] Sent: Sunday, April 19, 1998 1:47 AM To: RemoveMEPICLISTspamBeGoneMITVMA.MIT.EDU Subject: Re: 16F84 At 11:45 AM 4/18/98 -0400, you wrote: >I have a real basic question: > >What's the difference between a 16C84 and a 16F84 as far as program memory is concerned? I know that the 'C84 has EEPROM and how to program one. But I don't know what Flash memory is. Is it the same idea as EEPROM, i.e. it can be programmed, and reprogrammed and retains it memory even when power is removed? Yes. If so, can a 16F84 be plugged into a 16C84 socket with no problem? Yes. Can even be programmed as a 16C84, but leave code protection off, if you want to be able to verify.

part 0 761 bytes <META content=text/html;charset=iso-8859-1 http-equiv=Content-Type> <META content='"MSHTML 4.71.1712.3"' name=GENERATOR> </HEAD> <BODY bgColor=#ffffff> <DIV><FONT color=#000000 face=Arial size=2>It is really impossible to read the microcontroller 16F84.</FONT></DIV> <DIV><FONT color=#000000 face=Arial size=2></FONT> </DIV> <DIV> </DIV> <DIV><FONT color=#000000 face=Arial size=2>Dejair Muner<BR><A href="spamBeGonedeja@spam@spam_OUTst.com.br">TakeThisOuTdejaspamst.com.br</A></FONT></DIV>> <DIV><FONT color=#000000 face=Arial size=2></FONT> </DIV></BODY></HTML> </x-html>

At 10:01 12/06/98 +0200, you wrote: >Van: Dejair Jose Muner <@spam@dejaRemoveMEEraseMEST.COM.BR> >Aan: EraseMEPICLIST@spam@MITVMA.MIT.EDU >Onderwerp: 16F84 >Datum: donderdag 11 juni 1998 17:33 > >> It is really impossible to read the microcontroller 16F84 ? > >What made you think that ? (please answer, I'm curious ...) > >Normally you can read the thing as a book. If you enabled the code-protect >bit you will get garbeled data (high 7 bits are always Zero). Nope, that's the 16C84 your describing. The 16F84 will read all zero's when code protected. As for being able to read the 16F84 (after code protection,) well it would take a better man than me to spill the beans. Jim >Greetz, > Rudy Wieser >

Has any one tried turning on a led with the 16F84 or the 16C84? Such a simple program I don't see what I'm doing worng. I can get the led to turn on but when check with a logic probe I've noticed that there is a pulse on the pin. Also if I use an external clock and slow down to under 1KHz the led won't turn on. I tried doing the same thing with a 12c508 and had no problem. No Pulse. I just want to know if any one else has notice this problem. _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com

Roy Kasmir wrote: > Has any one tried turning on a led with the 16F84 or the 16C84? Yes, and it has always worked fine. However, if I am using pin RA4 I have to connect the LED to +5V rather than to ground. RA4 does not pull up. > DO YOU YAHOO!? I'd hate to use a free mailing service that does this to your every message. It's not free, because it costs you something in credibility. -- James Cameron (@spam@cameronspam_OUT.....stl.dec.com) OpenVMS, Linux, Firewalls, Software Engineering, CGI, HTTP, X, C, FORTH, COBOL, BASIC, DCL, csh, bash, ksh, sh, Electronics, Microcontrollers, Disability Engineering, Netrek, Bicycles, Pedant, Farming, Home Control, Remote Area Power, Greek Scholar, Tenor Vocalist, Church Sound, Husband. "Specialisation is for insects." -- Robert Heinlein.

> Van: Roy Kasmir <spamBeGoner_kasmirEraseMEYAHOO.COM> > Aan: PICLISTspamBeGoneMITVMA.MIT.EDU > Onderwerp: 16F84 > Datum: maandag 4 januari 1999 13:23 > > Has any one tried turning on a led with the 16F84 or the 16C84? Such a > simple program I don't see what I'm doing worng. I can get the led to > turn on but when check with a logic probe I've noticed that there is a > pulse on the pin. Also if I use an external clock and slow down to > under 1KHz the led won't turn on. I tried doing the same thing with a > 12c508 and had no problem. No Pulse. I just want to know if any one > else has notice this problem. Did you _disable_ your wach-dog ? Otherwise it will "reboot" your program after a while. That (the reset) will switch your output to input after wich your program will switch it back to Output again. Maybe that is the pulse you see (you did not tell us the frequency, so I'm just guessing :-). Greetz, Rudy Wieser

Thanks for your reply. I did disable the watchdog timer. But I think I'll double check to make sure it is being disabled. The frequency of normal operation for this program was 4MHz (Internal clock). Roy ---Caisson <RemoveMEcaisson@spam@spamBeGoneTELEBYTE.NL> wrote: > > > Van: Roy Kasmir <.....r_kasmir@spam@EraseMEYAHOO.COM> > > Aan: .....PICLISTRemoveMEMITVMA.MIT.EDU > > Onderwerp: 16F84 > > Datum: maandag 4 januari 1999 13:23 > > > > Has any one tried turning on a led with the 16F84 or the 16C84? Such a > > simple program I don't see what I'm doing worng. I can get the led to > > turn on but when check with a logic probe I've noticed that there is a > > pulse on the pin. Also if I use an external clock and slow down to > > under 1KHz the led won't turn on. I tried doing the same thing with a > > 12c508 and had no problem. No Pulse. I just want to know if any one > > else has notice this problem. > > Did you _disable_ your wach-dog ? Otherwise it will "reboot" your program > after a while. That (the reset) will switch your output to input after wich > your program will switch it back to Output again. Maybe that is the pulse > you see (you did not tell us the frequency, so I'm just guessing :-). > > Greetz, > Rudy Wieser > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com

> Van: Roy Kasmir <.....r_kasmirSTOPspam@spam@YAHOO.COM> > Aan: PICLISTEraseME@spam@MITVMA.MIT.EDU > Onderwerp: Re: 16F84 > Datum: dinsdag 5 januari 1999 12:53 <snip> > The frequency of normal operation for this program was 4MHz (Internal > clock). Sorry, I was not too clear with my question. Wat you said was "I can get the led to turn on but when check with a logic probe I've noticed that there is a pulse on the pin." What I ment was : what was the frequency of the pulse (width of and time between). Maybe you could provide us with (the relevant portion of) your program. Greetz, Rudy Wieser

I'll hook up the oscilloscope tomorrow and measure the time of the pulse. I haven't had a change to do that yet. Here the simple program. INCLUDE <P16F84.INC> ORG 0 START CLRF PORTB CLRF TRISB MOVLW 0x8F MOVWF PORTB HERE GOTO HERE END ---Caisson <RemoveMEcaissonspamBeGoneTELEBYTE.NL> wrote: > > > Van: Roy Kasmir <spamBeGoner_kasmirKILLspam@spam@YAHOO.COM> > > Aan: PICLISTspam_OUT@spam@MITVMA.MIT.EDU > > Onderwerp: Re: 16F84 > > Datum: dinsdag 5 januari 1999 12:53 > > <snip> > > > The frequency of normal operation for this program was 4MHz (Internal > > clock). > > Sorry, I was not too clear with my question. Wat you said was "I can get > the led to turn on but when check with a logic probe I've noticed that > there is a pulse on the pin." > What I ment was : what was the frequency of the pulse (width of and time > between). > > Maybe you could provide us with (the relevant portion of) your program. > > Greetz, > Rudy Wieser > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com

Ray, you need to change bank1 before trisb and after trisb bank0 Andre Abelian Roy Kasmir wrote: {Quote hidden}> I'll hook up the oscilloscope tomorrow and measure the time of the > pulse. I haven't had a change to do that yet. > Here the simple program. > > INCLUDE <P16F84.INC> > > ORG 0 > > START > CLRF PORTB > CLRF TRISB > MOVLW 0x8F > MOVWF PORTB > > HERE > GOTO HERE > > END > > ---Caisson <spamBeGonecaisson@spam@TELEBYTE.NL> wrote: > > > > > Van: Roy Kasmir <RemoveMEr_kasmirEraseMEKILLspamYAHOO.COM> > > > Aan: spamBeGonePICLISTspam_OUTRemoveMEMITVMA.MIT.EDU > > > Onderwerp: Re: 16F84 > > > Datum: dinsdag 5 januari 1999 12:53 > > > > <snip> > > > > > The frequency of normal operation for this program was 4MHz > (Internal > > > clock). > > > > Sorry, I was not too clear with my question. Wat you said was "I > can get > > the led to turn on but when check with a logic probe I've noticed that > > there is a pulse on the pin." > > What I ment was : what was the frequency of the pulse (width of and > time > > between). > > > > Maybe you could provide us with (the relevant portion of) your > program. > > > > Greetz, > > Rudy Wieser > > > > _________________________________________________________ > DO YOU YAHOO!? > Get your free @yahoo.com address at http://mail.yahoo.com

I would recommend one or two books: Easy Pic'n, Pic up the Pace, both by David Benson. These are excellent books for the 16F84 even if you have experience with other processors or uP languages. If you just want to know about the 16F84 instruction, the data sheet actually has an example of how each instruction will affect data. For Example ADDLW Add literal and W -------------------------------------- Ex. ADDLW 0x15 Before instruction W=0x10 After instruction W=0x25 The data book can be very helpful (sometimes). "Saulius L." wrote: > > Helo, > could somebody write about 16f84 commands? -- Jason ======================================== Website: http://www.execpc.com/~milsumai E-Mail: .....milsumaiRemoveMEexecpc.com ICQ # : 12978762 ======================================== .:::. ,,, _(- -)_ / ( ) \ \_/ : \_/ |_/ \_| | | | -TRY PRAYER-

Frank, That is a 16F84 that runs at 4MHz. All the 16F84 PICs are reprogrammable. The -XX number is the frequency it runs at. Best regards, Steve Steven Kosmerchock Radio Frequency systems Phoenix Arizona USA http://www.rfsworld.com http://www.geocities.com/resaerchtriangle/lab/6584 -----Original Message----- From: Frank Tarsitano [ftarsitano@spam@YAHOO.CA] Sent: Thursday, May 11, 2000 12:37 PM To: EraseMEPICLISTRemoveMESTOPspamMITVMA.MIT.EDU Subject: 16f84 Can anyone help? I want to buy a 16f84 that is re-programmable, would the part number be 16F84-04/p. thanks for any advice Frank _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca

What do you mean? The 16F84 is re-prgrammable hundreds of time; that is, the "f" means that the part has flash program memory so you can reprogram it. You can use MPLAB and the PICSTART-PLUS to program the 16f84. OK? Phil Anderson. On Thursday, May 11, 2000 2:37 PM, Frank Tarsitano [SMTP:RemoveMEftarsitanoKILLspamTakeThisOuTYAHOO.CA] wrote: {Quote hidden}> Can anyone help? > I want to buy a 16f84 that is re-programmable, would > the part number be 16F84-04/p. > > thanks for any advice > Frank > > _______________________________________________________ > Do You Yahoo!? > Get your free @yahoo.ca address at http://mail.yahoo.ca