OT: How fetch random byte on PIC16F648A

..without using CALL/RETLW, and get from anywhere in program memory (say from 0x0100 to 0x1fff).

It is not clear if or how one could use EEDATA addressing, as well as not clear if or how one could use FSR/INDF addressing.

Help?

Thanks.

Reply to
Robert Baer
Loading thread data ...

Robert Baer wrote in news:pZqNx.53785$ snipped-for-privacy@fx22.iad:

You cant on the PIC16F6(27/28/48)A device family. Generally the ability to read a random program memory locaation (rather than executing a RETLW instruction at a location) is only available ib PICs that have self-write FLASH (i.e. can change their own program memory at runtime)

--
Ian Malcolm.   London, ENGLAND.  (NEWSGROUP REPLY PREFERRED)  
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk [at]=@, [dash]=- & 
 Click to see the full signature
Reply to
Ian Malcolm

See Bigtables with page crossings.

FSR/INDF is only for RAM memory.

Or use a 18F device with EEdata access to pgm memory, they are less expensive than 16F parts.

Cheers

Reply to
Martin Riddle

Thanks for the info. But it is stupid to NOT allow a READ.

Reply to
Robert Baer

Thanks. Suggestions for those with 8K or so memory?

Reply to
Robert Baer

Now your pushing it ;) I've been using the 18F45k22 lately . There is a 8k offering 43k22. I have a CRC in program memory so I use the EEData reg's to calc the CRC of the program memory.

Cheers

Reply to
Martin Riddle

It takes logic to read data. The point of PICs is to minimize the logic to the bare bones. Perhaps it's broken by design but it wasn't an oversight.

Reply to
krw

No one ever said PICs were good processors.

--

Rick
Reply to
rickman

A **few** midrange PICs have 16-bit FSRs that can address program memory (mainly to meet requirements for safety-critical systems such as UL1998 recommendations). I believe that the 16F648A is not one of those few. It is rarely required.

The functionality is built into higher end (many which are still cheap 8-bit parts) products- eg. TBLRD on PIC18F.

--sp

--
Best regards,  
Spehro Pefhany 
 Click to see the full signature
Reply to
Spehro Pefhany

Martin Riddle wrote in news: snipped-for-privacy@4ax.com:

Assuming you are lookng for an 18 pin device to replace the PIC16F648A, look at the PIC16F1847. However, if you are programming in assembler, the PIC1xF1xxx enhanced midrange architecture may be too much of a PITA, and you need a PICkit 3 or better to program/debug them so it may be worth paying a bit more for the PIC18F1320, which is easier to use with MPASM and older tools.

Alternatively use the MAPS PIC product selector and see what *actually* matches your requirements. Its slow and a little clunky but its worth persevering with it.

--
Ian Malcolm.   London, ENGLAND.  (NEWSGROUP REPLY PREFERRED)  
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk  
 Click to see the full signature
Reply to
Ian Malcolm

It is not as simple as simply allowing it. Due do the Harvard architecture, a read from program memory would require additional logic. The program memory is 14 bit, while the CPU core is 8 bit. How would you handle the remaining 6 bits? You could implement another SFR to store them, or you could read the word in two instruction cycles, but what's the use of 3/4 of a byte?

The RETLW instruction stores the command and the entire literal in one single program memory address, and it executes in one single instruction cycle. What would you gain by doing it in a different way?

--
RoRo
Reply to
Robert Roland

One might wonder why you would need to do this, since presumably you have programmed the chip and know what you have set each program location to. Or you could read the entire program memory using a PICkit or other programming / debugging tool.

It may not be that difficult to add external hardware to emulate a programmer / reader.

The PIC16F648A is a rather old device. I like the PIC16F1825 (14 pin) or PIC16F1829 (20 pin) for new designs. They have 8k flash memory and are in the $1 range for cost.

Paul

Reply to
P E Schoen

Well, the PIC16F648A has the FSR and some related registers; is not that logic??

Reply to
Robert Baer

Discovered a stupid ASS-u-ME-ption on my part, due to fact of 14-bit "byte" instruction / data storage. So used to 8-bit, 16-bit, 24-bit, 32-bit processors.

8K is more than sufficient to hold five 1024 data points each.

Thanks.

Reply to
Robert Baer

Did you even comprehend what I wrote? Can you?

Reply to
krw

It is a feature of the Harvard chip architecture. The program memory and data memory spaces are physically separate. No self modifying code.

formatting link

Yes. Logic to read and write *DATA* memory space.

It makes no sense to be able to read or write from program memory at runtime if you care about reliability.

You can read/write program memory when the chip is in programming mode provided that the security fuse has not been set to prevent it.

--
Regards, 
Martin Brown
Reply to
Martin Brown

What's wrong with reading program memory at run time? How/where do you store constant data tables?

--

Rick
Reply to
rickman

Read is OK but write is hard to prevent unless you have a segmented architecture of some sort. Harvard architecture is the most restrictive of all and prevents any access to program code space at runtime.

On a PIC you do it by using the equivalent of a computed goto to execute a RETURN instruction that loads a value into the W register. You literally cannot peek into the program address space at runtime.

I agree it is a nuisance for constant tables in hard access restricted architectures that are memory constrained. In the old days this was one bit we always did by hand coded assembler since the compiler was dumb enough to copy string constants from EPROM into precious ram.

Write cycles executed against an EPROM have very little effect.

Something that could be an embarrassment on embedded TI9900 series CPUs where all the registers including program counter were in ram.

If the active register bank pointer ever got corrupted to point at ROM then it became incredibly difficult to increment the PC.

--
Regards, 
Martin Brown
Reply to
Martin Brown

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.