Yes... it's a way of learning something about how the PIC works, and also (perhaps) of distinguishing different versions of the same chip.
Yes... it's a way of learning something about how the PIC works, and also (perhaps) of distinguishing different versions of the same chip.
Familiar 68HC11 phenomenon. I got it once by accidentally assembling an 'HC11 program with an 'HC12 assembler. Same assembly language, different opcodes!
Come to think of it, how are you going to find out what they do? How much of the state of a PIC can you read out?
:
I used to work with a bloke that worked on the first PIC when it was still a TTL breadboard. I dont remember him ever telling me about undocumented opcodes.
Some of the PIC16 series (later/more powerful chips) have IS debugging hardware on-chip which will allow you to read out the current state. Of course that doesn't directly tell you what the instruction did...
Best regards, Spehro Pefhany
-- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
This is why some flight control computers have exra circuits to detect invalid opcodes being presented to the cpu, and cause a power down type reset to keep the cpu working (sort of). Only discovered by chance, but confirmed by manufacturer as test opcode causing cpu to go into endless (ignoring non-maskable interrupt) loop cycling address bus. Neil
In the 1970's, practically any microcoded minicomputer had the concept of reserved instruction trap.
The PDP-11/70 mini was used for routing airline traffic long after the "best before" date of that system, since the replacements failed miserably :-).
Paul
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.