Hi, Using at89c51 i want some data to copy from program memory to external Data memory.. without using memcopy()... any idea ?
As stated earlier, PUSH P2 is unreliable. It is not "unreliable" it is completely reliable, it does what the book says. "PUSH P2" doesn't necessarily push the value that's presently in the P2 output latch. NOT "doesn't necessarily" It never does. It is clearly documented that a READ operation reads the port pins. and a PUSh is READ operand, then write to stack. Erik
Unless you (pre)shadow P2 at ALL TIMES, you can't safely manipulate it and expect any other portion of the program to use it(namely interrupts), then restore it after said use is complete. absolutely correct. BUT THAT IS INO THE POINT The issue you brought up was INC P2. Which, as opposed to your statements can NOT be used when you shadow (the increment will be lost at next shadow to port copy). I wish you would discuss THIS instead of the relative merit of my posts, where I could not care less about your opinion. Erik
I could not care less about a "victory". HOWEVER I do care about someone leading the novices astray with blatantly incorrect statements. Really? And what do you call this: should have read "inc P2" can not be used when a shadow register is in use and that statement is self-evident. The only thing "evident" about that is that you simply don't get the big picture...yet you're concerned about the novice. Unless you (pre)shadow P2 at ALL TIMES, you can't safely manipulate it and expect any other portion of the program to use it(namely interrupts), then restore it after said use is complete. I admit when I'm wrong. I did that earlier in the thread and have since tried to correct it, at your request to elaborate on the topic. Your problem is you're an incessant know-it-all and you've appointed yourself the role of forum warden. Heck, look at the recent thread directed BY NAME to someone else, yet who's the first person to chime in and pontificating their wisdom? You. If you're really concerned about the novices, you'd consider how many of them you drive away with your pompous attitude.
the goal is simply a daily victory I could not care less about a "victory". HOWEVER I do care about someone leading the novices astray with blatantly incorrect statements. Erik
If you realized how ridiculous your statemet above is, now, THAT would be a miracle. And where would we go from there? Why would it matter? To a stereotypicle forum alpha-nerd such as yourself, the goal is simply a daily victory. One doesn't have to read too many of these threads to realize this. BTW, the spelling error is intentional. I figured if nothing else, you could pick the reply apart based on that. (wait for it... wait for it...)
Gosh...miracles DO happen. If you realized how ridiculous your statemet above is, now, THAT would be a miracle. Erik
Enough said Gosh...miracles DO happen.
That statement is not self-evident, its incorrect. On the contrary, the only way "inc P2" can safely be used IS with a shadow register technique Now it is getting ridiculous. Enough said Erik
This could have been umpteen posts shorter if you had introduced that you were discussing based on a shadow register earlier. There is, in most designs no shadow registers, only the few cases where interrupts handle ports pins that are also used in main are they used. You discussed this on the basis of P2 without even bringing in that a shadow register was used. Your initial statemnent "beware crossing page boundaries as "inc P2" won't necessarily produce what you expect" should have read "inc P2" can not be used when a shadow register is in use" and that statement is self-evident. That statement is not self-evident, its incorrect. On the contrary, the only way "inc P2" can safely be used IS with a shadow register technique. Thus, its not a discussion "based" on shadowing P2, rather I'm pointing out that shadowing P2 should be considered whenever P2 is manipulated. That's all I have to say on the matter for now.
Precisely!!! And this is why "INC P2" by itself doesn't work in the aforementioned model (where P2 is to be maintained across interrupts) ...as it MUST increment the shadow register before it increments P2. This could have been umpteen posts shorter if you had introduced that you were discussing based on a shadow register earlier. There is, in most designs no shadow registers, only the few cases where interrupts handle ports pins that are also used in main are they used. You discussed this on the basis of P2 without even bringing in that a shadow register was used. Your initial statemnent "beware crossing page boundaries as "inc P2" won't necessarily produce what you expect" should have read "inc P2" can not be used when a shadow register is in use" and that statement is self-evident. Erik
No, not at all. You just need to explain how it is relevant to the PUSH instruction. Its relavent because "PUSH P2" doesn't necessarily push the value that's presently in the P2 output latch. Should I put up a short code example?
"Do I need to copy the entire page?" No, not at all. You just need to explain how it is relevant to the PUSH instruction.
I wonder if you can provide a page number to back that statement up? Intel-MCS51 Family-user manual.pdf Order No.:272383-002 February 1994 Page 3-9 Do I need to copy the entire page?
"As stated earlier, PUSH P2 is unreliable because, according to "the bible", it does not read the register." I wonder if you can provide a page number to back that statement up?
with a shadow register Precisely!!! And this is why "INC P2" by itself doesn't work in the aforementioned model (where P2 is to be maintained across interrupts) ...as it MUST increment the shadow register before it increments P2.
View all questions in Keil forum