Why does write command take so many instruction cycles to execute?

[John Thompson]

I have a simple write line in a program ( write , 0 PositionsCommand where PositionsCommand is a 1 byte variable) which takes a long time to execute . So much of a time nuisance I REM out this line during simulation.

By rough count from the simulator information something around 8,000 instructions. Can anyone comment on this and anything that might be done to reduce the count?

 

[rjenkinsgb]

What's the device and what is being written?

If it's eg. something on an interface bus such as I2C or SPI, one operation on those, if the code waits for the operation to complete, will take thousands of cycle.

Likewise an EEPROM or flash ROM write, again if the code waits for it complete rather than only initiating it.

 

[Ian Rogers]

Yes! show your code... I agree with rjenkinsgb.. This seems like an eeprom write, these have to be 5~10ms ( housekeeping )

If this be the case swap the eprom for an FRAM... No write delay...

Incidentally! Which simulator? I use proteus and this delay is in the properties of said device and can be changed..

 

[John Thompson]

In trying to keep the post simple I have, as usual made things more difficult for those who may try to help. Sorry about that.

The relevant circuit and code explanations are very simple. The device is a 12F683 and the code is writing to its internal EEPROM using Oshonsoft Basic instruction line "Write 0, PositionsCommand" The rest of the program code is this not relevant (the whole code and circuit is included in an earlier post re simulation works, real circuit does not) as this line of code stands alone and is reached with a value for PositionsCommand calculated earlier in the code. PositionsCommand byte contains the current positions of three model railway point controller servos as bits 0-2, where 0 represents Through and 1 represents Divert.

(The whole code and circuit is included in an earlier post re "Simulation works, real circuit does not")

The simulator shows correct (expected) cycling through the whole code to this line, where it sits munching away for some time to execute it - by watching the instruction counter I get the about 8,000 instructions to execute this line. After toiling manfully, the program moves on as expected

Thanks to precious help, the program and hardware operate as programmed in simulation and on the real PCB.

The question is somewhat academic as the length of time does not affect the operations controlled by the program - the cycle time is plenty fast enough that this write time affects it little. My reason for the post is to understand what is going on in case I do run into an issue with the Write instruction in other programs I am working on with other Pics.

 

[Nigel Goodwin]

My reason for the post is to understand what is going on in case I do run into an issue with the Write instruction in other programs I am working on with other Pics.

It's not an 'issue with the Write instruction', nothing to do with it - as Ian already 'guessed' it's a write to EEPROM, and this requies slow timing in order to occur. It's fully explained in the datasheet, which you should study.

 

[Pommie]

If you write the function yourself there is no need to wait after the write. You will need to wait if you write again before the previous write has completed. Fully explained in the data sheet with example code.

Mike.

 

[John Thompson]

Thank you both for your prompt replies.

The datasheet, all 174 pages of it, has been my constant study companion in recent weeks, but I missed the part about slow timing being required for EEPROM writes. And, as in the previous discussion, I miss-read the section on the workings of PullUps on GP3. Lots of stuff in those pages!

I have, on another project using a Pic that does not have OshonSoft support for WRITE, used the assembler code READ & WRITE example from the relevant datasheet as suggested to perform WRITE and READ successfully (according to the simulator anyway). I was considering doing the same for this project but from your helpful comments there would be no gain for, as pointed out, timing is a function of the Pic hardware. And, as I said the inquiry was somewhat academic anyway as the the real world function of the PCB is not affected by the apparently extended "WRITE"time anyway.

Just trying to improve my understanding for future reference., and thanks to you guys, mission accomplished.

Thank you both again for assistance.

 

[Pommie]

Note that the code in the data sheet waits for any previous write to complete BEFORE writing which speeds the code up considerably.

Mike.

 

[John Thompson]

Thanks Mike.

I think as an education experiment I will put that code in place of the write instructions and try it to see what difference it makes.