Can a PIC edit it's own code?

First off let me say I'm new to Microchip PIC programming, still reading up on them and trying to decide which model is appropriate for my first project. I think it will be a lot of fun once I get started.

I noticed the flash memory for storing instructions is generally much larger than the EEPROM built into these chips. So I was wondering if there is any posisible way that the PIC could write into unused spaces of program memory while it is running, and retrieve this data later? Maybe with a chip that allows in circuit debugging or something. Again, I'm still reading these things, so I'm not sure what the limitations at all.

Thanks for any input.

it depends on the pic. some can - 18F series, 16F87x, 16F88 and others can. I wouldn't use it for general storage as the writing time is pretty slow. this is how boot loaders can work.

How about a 16F628A? I think I am going to use this chip.

Could you describe basically what is involved? Do some of the pins need to be wired in a certain way? What sort of instructions are necessary to do it?

The speed of writing and reading doesn't matter a whole lot for the application I have in mind. I would imagine it's faster than 32bytes/sec, and that would be enough for me. It would just be nice to effectively double the nonvolatile memory available. I don't think the program itself will take up too much space, and I'd hate to see all that flash memory go to waste. :twisted:

no the 628A doesn't support it. I think the only 18 pin PIC that supports it is the 16F88 which is a better chip than the 628, anyway. It's all in software.

go find the source code for a bootloader. microchip has one for the 877A, I believe. Also, sparkfun has one for a number of chips (bloader) its site and it's in C so its a little easier to read than other asm bootloaders. That and the datasheets will tell you all you need to know.

I STRONGLY suggest you don't do it!. Writing self modifying code has always been a bad thing to do! - PIC's are good for this as they use Harvard architecture which prevents you doing it, as program and data are completely seperate.

If you want extra non-voltatile storage, add an external I2C EEPROM!.

As suggested, the 16F627/8 doesn't support it anyway!.

while I agree that using Flash as a general non-volitile storage isn't a great idea, there are plenty of places where it makes sense. I've seen a DDS project that loads different waveform tables into flash as needed, for example. Just keep in mind the cycle lifetime of flash isn't that great.

eeprom makes more sense for configuration type data, by the way.

I think it will be a lot of fun once I get started.

Click to expand...

It will definitely be fun. I'm so hooked on electronics, that now my programmer requires a double-sided board, and this is the first time I'm attempting a double sided PCB.

I noticed the flash memory for storing instructions is generally much larger than the EEPROM built into these chips.

Click to expand...

Flash is normally larger in size than ANY EEPROM. EEPROMS tend to be more expensive than flash as well, but they are easier to program (requires less external circuitry).

So I was wondering if there is any posisible way that the PIC could write into unused spaces of program memory while it is running, and retrieve this data later?

Click to expand...

It is possible, but as Nigel said, it is NOT recomended. Why do you want to write into the same memory the PIC is using to function?

Maybe with a chip that allows in circuit debugging or something. Again, I'm still reading these things, so I'm not sure what the limitations at all.

Click to expand...

The datasheet of any microcontroller you use will tell you what code set it is compatible with, its limitations, and the device pinout.

What you may want to do is go externally. Instead of a microcontroller, use a microprocessor and any ROM memory (either flash or EEPROM).

The code is stored in the EEPROM, and the microprocessor executes the code. Attach another ROM memory to any output of the microprocessor, and simply send data to it.

Have you visit Nigel's site? He may have alot of info on the PIC microcontrollers.

Do some of the pins need to be wired in a certain way?

Click to expand...

Most IC's want the top-left pin (VCC) to +5V, and the bottom-right pin (GND) to 0V. The datasheet on your microcontroller will explain more.

Could you describe basically what is involved?

Click to expand...

Basically in any microcontroller setup, the ROM (eeprom or flash) has the code in the format the chip can recognize. Once the chip becomes active, the code begins at byte 0, and the chip reads it. the external clock applied to the chip through XTAL pin (I don't know the exact pin name for a PIC) controls the speed in which the instructions are processed.

The instructions are simply bytes, and the parameters are bytes as well.
Each instruction is executed one after the other until it receives a command that makes the uC go to a different area of the rom.

First, you need to make a final decision on the chip before I can explain the instructions any further.

Peepsalot said:

I noticed the flash memory for storing instructions is generally much larger than the EEPROM built into these chips. So I was wondering if there is any posisible way that the PIC could write into unused spaces of program memory while it is running, and retrieve this data later? Maybe with a chip that allows in circuit debugging or something. Again, I'm still reading these things, so I'm not sure what the limitations at all.

Click to expand...

As noted this is how "bootloaders" work, but being able to write the code space is a general capability not limited to bootloading. It's not related to In Circuit Debugging.

A major limitation is that the data must be written in whole blocks, rather than arbitrary addresses. It is slow but so is writing EEPROM. I believe it is wise to disable interrupts while this is going on as well.

There is some risk of writing over the code itself and thus rendering the part inoperative until reprogrammed. Power fluctuations might be able to do it, for example. The whole thing IS a bit "new", you'll find lots of errata for different parts on what can and can't be done with it. The lowest block has a code protection fuse bit which can be set and it should make it (nearly) impossible to overwrite code in that block, but it's not very big so you probably won't be able to fit your whole prog in it. I think some of the later parts may have protection bits for more of the blocks of memory so you could protect all your code. I'm not sure though.

Note this is a completely separate thing from reading data stored in code space, which can be done easily, can be done to arbitrary addresses, and has no risks. For example, both code and a short sound file can be programmed into code space. But recording the sound would be the more complicated issue.

Also, IIRC, the program memory has less write endurance than, say EEPROM so you wouldn't want to use it for something that gets rewritten a lot (like a video buffer (although it's probably not fast enough anyway but that's not the point))

Rick

I have a design with a dot matrix graphical LCD. The user can use a serial port to write new configuration data to it that will rearrange the display or write in several new pages of text information.

Normally these changes would require a recompile. This is undesirable because I'd have to provide the source code AND the user would have to have a compile tool and go through a bootloading operation. Or alternately we could parse the hex file and change the necessary regions. That would mean providing the user with the compiled code which is somewhat less undersirable but still undesirable. And it would still require bootloading the entire thing.

It ended up quite practical to perform this infrequent operation by placing all the user-reconfigurable data past the code in ROM and not sharing a block with any program code. The main body of code- not the bootloader- can be put into a mode where it will take in serial port data and block write it to the ROM space.

Bit of a threadjack and I am probably revealing my ignorance here but what about using the data EEPROM memory for code?

Is it even possible?

If so, I guess there is some reason why you shouldnt do it, if someone could enlighten me I would appreciate it?

I have one or two projects where a couple more hundred words of code space would REALLY come in handy.


Cheers guys.
John

2camjohn said:

Bit of a threadjack and I am probably revealing my ignorance here but what about using the data EEPROM memory for code?

Is it even possible?

Click to expand...

No, for a number of reasons - for a start it's only 8 bit, program memory is 14 bit (on most PIC's, but is never 8 bit).

If so, I guess there is some reason why you shouldnt do it, if someone could enlighten me I would appreciate it?

I have one or two projects where a couple more hundred words of code space would REALLY come in handy.

Click to expand...

Generally PIC projects leave plenty of empty space, are you not using assembler?.

also, there are plenty of pics with larger code space. You might want to consider moving up. which PICs are you using?

2camjohn said:

Bit of a threadjack and I am probably revealing my ignorance here but what about using the data EEPROM memory for code?

Is it even possible?

Click to expand...

Yes, in a way, it is possible by installing an 'Interpreter' in PIC firmware which would interpret and execute program 'tokens' from EEPROM and/or RAM memory -- something like the old Apple ][ Integer BASIC language interpretor firmware...

Regards, Mike

Mike said:

2camjohn said:

Bit of a threadjack and I am probably revealing my ignorance here but what about using the data EEPROM memory for code?

Is it even possible?

Click to expand...

Yes, in a way, it is possible by installing an 'Interpreter' in PIC firmware which would interpret and execute program 'tokens' from EEPROM and/or RAM memory -- something like the old Apple ][ Integer BASIC language interpretor firmware...

Regards, Mike

Click to expand...

This is how a PICAxe works, with a BASIC interpreter in program memory, and the code stored as tokens in the data eeprom. However, it's NOT a solution to lack of space, in fact it's completely the opposite!.

The BASIC STAMP is similar, except it stores code in an external EEPROM, so can hold larger BASIC programs.

Nigel,
Unfortunately my programs really are that big. The code when printed out was over 40 pages (with comments).
It is not in assembler but it is heavily optimised to take up as little code space as possible.


Philba,
Yes I am aware of larger chips, Luckily Winpicprog beta supports the 16f648a which has 7K. There is no other chip that fits my specification (20 pins max).



Having an interpreter would obviously take up more room than the code space it is supposed to save, but it has given me the idea of trying to make the user interface use tokens from the data memory, to reduce the interface down as small as possible.

The 16F648A actually has 4K of codespace. They say 7K, because it's 14 bits wide.

If your program really is that big, then you really do need a larger chip.

Why are you limited to 20-pin PICs? Seems like an odd constraint. Unless you move to 28 pins you won't get more than 4K of codespace.

Mike

Thanks for the heads up Mike.



Just to confirm I have read it right, the 648a has twice the program memory of the 628a ? I hope this is correct as that is how I interpreted it from the datasheets.
I have ordered a loaf of 648as, if they turn out to have the same code space as the 628a then I will feel quite the fool....

2camjohn said:

Thanks for the heads up Mike.



Just to confirm I have read it right, the 648a has twice the program memory of the 628a ? I hope this is correct as that is how I interpreted it from the datasheets.
I have ordered a loaf of 648as, if they turn out to have the same code space as the 628a then I will feel quite the fool....

Click to expand...

Yes, the 16F648 has twice the program memory of the 16F628, however this doesn't mean you have twice the programming space! - the 16F628 only has one memory page, the 16F648 has two memory pages, so you need page switching code which makes the programs longer anyway!.

Thanks for that Nigel.

I wasnt sure if Mike meant they all have 2k words max.